Cloud Functions-Standorte

Cloud Functions basiert auf Regionen. Das heißt, die Infrastruktur, auf der die Funktion ausgeführt wird, befindet sich in bestimmten Regionen. Sie wird von Google verwaltet, damit die Funktion 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 Regionen auswählen, die sich in der Nähe Ihrer Nutzer befinden. Sie sollten aber auch den Standort der anderen Produkte und Dienste berücksichtigen, die Ihre Anwendung nutzt. Eine standortübergreifende Nutzung von Diensten kann die Latenz der Anwendung sowie die Preise beeinflussen.

Standardmäßig stellt die Firebase CLI Funktionen in einer Region basierend auf der Konfiguration Ihres Projekts bereit. Bei ereignisgesteuerten Funktionen erfolgt die Bereitstellung in der Regel in einer Region der auslösenden Datenquelle (z. B. einer Cloud Firestore Datenbank oder Cloud Storage Bucket). Als Fallback wird die Bereitstellung in us-central1 durchgeführt.

Nach der Bereitstellung können Sie die Region in der Firebase Konsole oder mit dem Befehl firebase functions:list prüfen. Wenn die Funktion in einer anderen Region ausgeführt werden soll, können Sie die Region ändern.

Unterstützte Regionen

In den Listen in diesem Abschnitt weist das energy_savings_leaf Symbol darauf hin, dass der Strom für diese Region mit geringen CO2-Emissionen erzeugt wird. Weitere Informationen finden Sie unter CO2-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 basierend auf der Konfiguration Ihres Projekts bereit. Bei ereignisgesteuerten Funktionen erfolgt die Bereitstellung in der Regel in einer Region der auslösenden Datenquelle (z. B. einer Cloud Firestore Datenbank oder Cloud Storage Bucket). Als Fallback wird die Bereitstellung in us-central1 durchgeführt.

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

Legen Sie den Parameter region in der Funktionsdefinition fest, um die Region festzulegen, in der eine Funktion ausgeführt wird. Beispiel:

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. Beachten Sie außerdem, dass Sie beim Angeben einer Region für viele Hintergrundtriggertypen den richtigen Ereignisfilter zusammen mit der Region angeben müssen. Im obigen Beispiel ist dies das Cloud Firestore document das das Ereignis ausgibt. Bei einem Cloud Storage Trigger kann der Ereignisfilter bucket sein, bei einem Pub/Sub-Trigger topic usw.

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

HTTP- und clientseitig aufrufbare Funktionen

Für HTTP- und aufrufbare Funktionen empfehlen wir, zuerst die Funktion für die Zielregion oder die Region festzulegen, in der sich die meisten erwarteten Kunden befinden. Ändern Sie dann die ursprüngliche Funktion so, dass die HTTP-Anfrage an die neue Funktion weitergeleitet wird (sie können denselben Namen haben). Wenn Clients, die Ihre HTTP-Funktion verwenden, Weiterleitungen unterstützen, können Sie einfach die ursprüngliche Funktion so ändern, dass der HTTP-Statuscode zur Weiterleitung (301) zusammen mit der URL der neuen Funktion zurückgegeben wird. Wenn die Clients eher schlecht mit Weiterleitungen zurechtkommen, können Sie die Anfrage von der ursprünglichen auf die neue Funktion weiterleiten. Starten Sie dazu von der ursprünglichen Funktion aus eine neue Anfrage an die neue Funktion. 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 clientseitig aufrufbare Setups denselben Richtlinien wie HTTP-Funktionen folgen. Der Client kann auch eine Region angeben. Das sollte er tun, wenn die Funktion in einer anderen Region als der Standardregion des Projekts ausgeführt wird.

Legen Sie Regionen auf dem Client fest, indem Sie die gewünschte Region bei der Initialisierung angeben:

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 spezielle Semantik, um sicherzugehen, dass ein Ereignis mindestens einmal zugestellt wird. Das heißt, dass durchaus doppelte Ereignisse vorkommen können. Daher sollten Sie Funktionen so implementieren, dass sie idempotentsind. Wenn Ihre Funktion bereits idempotent ist, können Sie sie mit demselben Ereignistrigger in der neuen Region bereitstellen. Prüfen Sie dann, ob die neue Funktion Traffic korrekt empfängt. Wenn ja, entfernen Sie die alte Funktion. Während dieser Übergangsperiode empfangen beide Funktionen Ereignisse. Unter Region einer Funktion ändern finden Sie die empfohlene Befehlsfolge zum Ändern von 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.

Optimale Regionsempfehlungen variieren je nach Ereignistriggertyp:

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

Die verfügbaren Regionen für Funktionen 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 erhöhte Latenz und in Rechnung gestellte Kosten entstehen.

Hier ist eine Zuordnung der nächstgelegenen Regionen, die von Funktionen unterstützt werden, für Cloud Firestore und Cloud Storage, in Fällen, in denen dieselbe Region nicht unterstützt wird: