Cloud Functions-Standorte

Cloud Functions ist regional. Das bedeutet, dass sich die Infrastruktur, auf der Ihre Funktion ausgeführt wird, in bestimmten Regionen befindet und von Google so verwaltet wird, dass sie in allen Zonen innerhalb dieser Regionen redundant verfügbar ist.

Bei der Entscheidung für eine Region zur Ausführung Ihrer Funktionen sollten Latenz und Verfügbarkeit an erster Stelle stehen. Im Allgemeinen können Sie zwar Regionen auswählen, die Ihren Nutzern am nächsten sind. Sie sollten aber auch den Standort der anderen Produkte und Dienste, die Ihre Anwendung nutzt, berücksichtigen. Eine regionenübergreifende Nutzung von Diensten kann die Latenz der Anwendung sowie die Preise beeinflussen.

Standardmäßig stellt die Firebase CLI Funktionen in einer Region bereit, die auf der Konfiguration Ihres Projekts basiert. Ereignisgesteuerte Funktionen werden in der Regel in einer Region der auslösenden Datenquelle (z. B. einer Cloud Firestore-Datenbank oder einem Cloud Storage-Bucket) bereitgestellt. Als Fallback wird us-central1 verwendet.

Nach der Bereitstellung können Sie die Region in der Firebase-Konsole oder durch Ausführen von firebase functions:list prüfen. Wenn Sie möchten, dass Ihre Funktion in einer anderen Region ausgeführt wird, können Sie die Region ändern.

Unterstützte Regionen

In den Listen in diesem Abschnitt gibt das Symbol energy_savings_leaf an, dass der Strom für diese Region mit geringem CO₂-Ausstoß erzeugt wird. Weitere Informationen finden Sie unter CO₂-freie Energie für Google Cloud-Regionen.

Preisstufe 1

Cloud Functions ist in den folgenden Regionen mit Preisstufe 1 verfügbar:

Preisstufe 2

Cloud Functions ist in den folgenden Regionen mit Preisstufe 2 verfügbar:

Funktionen innerhalb einer Region und eines Projekts müssen eindeutige Namen haben (Groß- und Kleinschreibung ist irrelevant). Funktionen in verschiedenen Regionen oder Projekten können denselben Namen haben.

Best Practices für die Angabe einer Region

Standardmäßig stellt die Firebase CLI Funktionen in einer Region bereit, die auf der Konfiguration Ihres Projekts basiert. Ereignisgesteuerte Funktionen werden in der Regel in einer Region der auslösenden Datenquelle (z. B. einer Cloud Firestore-Datenbank oder einem Cloud Storage-Bucket) bereitgestellt. Als Fallback wird us-central1 verwendet.

Wir empfehlen, bestimmte Regionen festzulegen, anstatt sich auf die Firebase-Standardeinstellungen zu verlassen, die sich im Laufe der Zeit ändern können. Beachten Sie beim Festlegen von Regionen die Empfehlungen in diesem Abschnitt für jeden Triggertyp.

Wenn Sie die Region festlegen möchten, in der eine Funktion ausgeführt wird, legen Sie den Parameter region in der Funktionsdefinition wie folgt fest:

exports.firestoreAsia = onDocumentCreated(
  {
    document: "my-collection/{docId}",
    region: "asia-northeast1",
  },
  (event) => {},
);

# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
    pass

# After
@firestore_fn.on_document_created("my-collection/{docId}",
                                  region="asia-northeast1")
def firestore_trigger_asia(event):
    pass

Sie können mehrere Regionen angeben, indem Sie mehrere kommagetrennte Regionsstrings in region übergeben. Wenn Sie für viele Hintergrund-Triggertypen eine Region angeben, müssen Sie außerdem den richtigen Ereignisfilter zusammen mit der Region angeben. Im obigen Beispiel ist dies die Cloud Firestore document, die das Ereignis ausgibt. Bei einem Cloud Storage-Trigger könnte der Ereignisfilter bucket sein, bei einem Pub/Sub-Trigger topic usw.

Weitere Informationen zum Ändern der Region für eine Funktion, die Produktionstraffic verarbeitet, finden Sie unter Region einer Funktion ändern.

HTTP- und vom Client aufrufbare Funktionen

Bei HTTP- und aufrufbaren Funktionen empfehlen wir, die Funktion zuerst in der Zielregion oder in der Region festzulegen, in der sich die meisten erwarteten Kunden befinden. Ändern Sie dann die ursprüngliche Funktion, um die HTTP-Anfrage an die neue Funktion weiterzuleiten (sie können denselben Namen haben). Wenn Clients Ihrer HTTP-Funktion Weiterleitungen unterstützen, können Sie Ihre ursprüngliche Funktion einfach so ändern, dass sie einen HTTP-Weiterleitungsstatus (301) zusammen mit der URL Ihrer neuen Funktion zurückgibt. Wenn Ihre Clients Weiterleitungen nicht gut verarbeiten, können Sie die Anfrage von der ursprünglichen Funktion an die neue Funktion weiterleiten, indem Sie eine neue Anfrage von der ursprünglichen Funktion an die neue Funktion initiieren. Im letzten Schritt müssen Sie dafür sorgen, dass alle Clients die neue Funktion aufrufen.

Clientseitige Standortauswahl für aufrufbare Funktionen

Für aufrufbare Funktionen sollten die gleichen Richtlinien wie für HTTP-Funktionen gelten. Der Client kann auch eine Region angeben. Dies sollte er tun, wenn die Funktion in einer anderen Region als der Standardregion des Projekts ausgeführt wird.

Wenn Sie Regionen auf dem Client festlegen möchten, geben Sie bei der Initialisierung die gewünschte Region an:

lazy var functions = Functions.functions(region:"europe-west1")

@property(strong, nonatomic) FIRFunctions *functions;
// ...
self.functions = [FIRFunctions functionsWithRegion:@"europe-west1"];

var functions = firebase.app().functions('europe-west1');

private FirebaseFunctions mFunctions;
// ...
mFunctions = FirebaseFunctions.getInstance("europe-west1");

firebase::functions::Functions* functions;
// ...
functions = firebase::functions::Functions::GetInstance("europe-west1");

firebase.Functions.FirebaseFunctions functions;

functions = Firebase.Functions.FirebaseFunctions.GetInstance("europe-west1");

Hintergrundfunktionen

Hintergrundfunktionen verwenden eine Semantik für die mindestens einmalige Ereignisübermittlung. Das bedeutet, dass sie unter bestimmten Umständen doppelte Ereignisse empfangen können. Daher sollten Sie Funktionen so implementieren, dass sie idempotent sind. Wenn Ihre Funktion bereits idempotent ist, können Sie sie in der neuen Region mit demselben Ereignistrigger noch einmal bereitstellen und die alte Funktion entfernen, nachdem Sie geprüft haben, ob die neue Funktion Traffic korrekt empfängt. Während dieser Umstellung erhalten beide Funktionen Ereignisse. Unter Region einer Funktion ändern finden Sie die empfohlene Befehlsfolge zum Ändern der Regionen für Funktionen.

Wenn Ihre Funktion nicht idempotent ist oder die Idempotenz nicht über die Region hinausreicht, empfehlen wir, zuerst die Idempotenz zu implementieren, bevor Sie die Funktion verschieben.

Die Empfehlungen für die optimale Region unterscheiden sich je nach Ereignistriggertyp:

Regionen basierend auf Cloud Firestore- und Cloud Storage-Standorten auswählen

Die für Funktionen verfügbaren Regionen stimmen nicht immer genau mit den Regionen überein, die für Ihre Cloud Firestore-Datenbank und Ihre Cloud Storage-Buckets verfügbar sind.

Wenn sich Ihre Funktion und Ihre Ressource (Datenbankinstanz oder Cloud Storage-Bucket) an verschiedenen Orten befinden, können höhere Latenz und Abrechnungskosten entstehen.

Hier finden Sie eine Zuordnung der nächstgelegenen von Funktionen unterstützten Regionen für Cloud Firestore und Cloud Storage, falls dieselbe Region nicht unterstützt wird: