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 verwaltet wird, damit 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 App nutzt, berücksichtigen. Eine standortübergreifende Nutzung von Diensten kann die Latenz der Anwendung sowie die Preise beeinflussen.

Standardmäßig werden Funktionen in der Region us-central1 ausgeführt. Diese kann sich von der Region einer Ereignisquelle wie einem Cloud Storage-Bucket unterscheiden. Informationen zum Angeben der Region, in der eine Funktion ausgeführt wird, finden Sie weiter unten auf dieser Seite.

Unterstützte Regionen

In den Listen in diesem Abschnitt weist das Symbol energy_savings_leaf 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:

Region Standort Unterstützte Produktversionen CO-Emissionen
africa-south1 Johannesburg Nur 2. Generation
asia-east1 Taiwan 1. Generation, 2. Generation
asia-east2 Hongkong Nur 1. Generation
asia-northeast1 Tokio 1. Generation, 2. Generation
asia-northeast2 Osaka 1. Generation, 2. Generation
europe-north1 Finnland Nur 2. Generation energy_savings_leaf
europe-southwest1 Madrid Nur 2. Generation
europe-west1 Belgien 1. Generation, 2. Generation energy_savings_leaf
europe-west4 Niederlande Nur 2. Generation
europe-west8 Mailand Nur 2. Generation
europe-west9 Paris Nur 2. Generation energy_savings_leaf
me-west1 Tel Aviv Nur 2. Generation
europe-west2 London Nur 1. Generation
us-central1 Iowa 1. Generation, 2. Generation energy_savings_leaf
us-east1 South Carolina 1. Generation, 2. Generation
us-east4 Northern Virginia 1. Generation, 2. Generation
us-east5 Columbus Nur 2. Generation
us-south1 Dallas Nur 2. Generation
us-west1 Oregon 1. Generation, 2. Generation energy_savings_leaf

Preisstufe 2

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

Region Standort Unterstützte Produktversionen CO-Emissionen
asia-east2 Hongkong Nur 2. Generation
asia-northeast3 Seoul 1. Generation, 2. Generation
asia-southeast1 Singapur 1. Generation, 2. Generation
asia-southeast2 Jakarta 1. Generation, 2. Generation
asia-south1 Mumbai Nur 2. Generation
asia-south2 Delhi, Indien Nur 2. Generation
australia-southeast1 Sydney 1. Generation, 2. Generation
australia-southeast2 Melbourne Nur 2. Generation
europe-central2 Warschau 1. Generation, 2. Generation
europe-west2 London Nur 2. Generation
europe-west3 Frankfurt 1. Generation, 2. Generation energy_savings_leaf
europe-west6 Zürich 1. Generation, 2. Generation energy_savings_leaf
europe-west10 Berlin Nur 2. Generation
europe-west12 Turin Nur 2. Generation
me-central1 Doha Nur 2. Generation
me-central2 Dammam Nur 2. Generation
northamerica-northeast1 Montreal 1. Generation, 2. Generation energy_savings_leaf
northamerica-northeast2 Toronto Nur 2. Generation energy_savings_leaf
southamerica-east1 São Paulo 1. Generation, 2. Generation energy_savings_leaf
southamerica-west1 Santiago, Chile Nur 2. Generation
us-west2 Los Angeles 1. Generation, 2. Generation
us-west3 Salt Lake City 1. Generation, 2. Generation
us-west4 Las Vegas 1. Generation, 2. Generation

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 werden Funktionen in der Region us-central1 ausgeführt. Diese kann sich von der Region einer Ereignisquelle wie einem Cloud Storage-Bucket unterscheiden. Wenn Sie die Region angeben müssen, in der eine Funktion ausgeführt wird, folgen Sie den Empfehlungen in diesem Abschnitt für jeden Funktionstriggertyp.

Um die Region festzulegen, in der eine Funktion ausgeführt wird, legen Sie den Parameter region in der Funktionsdefinition fest, wie unten gezeigt:

Node.js

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

Python

# 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 durch Kommas getrennte Regionsstrings in region übergeben. Wenn Sie eine Region für viele Hintergrundtriggertypen angeben, müssen Sie außerdem den richtigen Ereignisfilter zusammen mit der Region angeben. Im obigen Beispiel ist das die Cloud Firestore document, die das Ereignis ausgibt. Für einen Cloud Storage-Trigger könnte der Ereignisfilter bucket sein, für einen Pub/Sub-Trigger wäre er 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, dass Sie zuerst die Funktion für die Zielregion oder die Region festlegen, die dem Standort der meisten erwarteten Kunden am nächsten ist, und dann die ursprüngliche Funktion so ändern, 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 muss er tun, wenn die Funktion in einer anderen Region als us-central1 ausgeführt wird.

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

Swift

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

Objective-C

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

Web


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

Android

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

C++

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

Einheit

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 idempotent sind. Wenn Ihre Funktion bereits idempotent ist, können Sie sie einfach 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 Reihenfolge von Befehlen 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 unterscheiden sich je nach Ereignistriggertyp:

Triggertyp Region empfehlen
Cloud Firestore Die Region, die dem Cloud Firestore-Instanzstandort am nächsten ist (siehe nächster Abschnitt)
Realtime Database Immer us-central1
Cloud Storage Region, die dem Cloud Storage-Bucket-Speicherort am nächsten ist (siehe nächster Abschnitt)
Sonstige Wenn Sie mit einer Realtime Database-Instanz, einer Cloud Firestore-Instanz oder einem Cloud Storage-Bucket innerhalb der Funktion interagieren, ist die empfohlene Region dieselbe, als ob Sie eine Funktion hätten, die durch eine dieser Ressourcen ausgelöst wird. Verwenden Sie andernfalls die Standardregion us-central1. Mit Firebase Hosting verbundene Funktionen können sich in einer beliebigen Region befinden. In der Übersicht zu serverlosem Hosting finden Sie Empfehlungen.

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 Funktionen für Cloud Firestore und Cloud Storage unterstützen, für Fälle, in denen dieselbe Region nicht unterstützt wird:

Region/Multiregion für Cloud Firestore und Cloud Storage Nächstgelegene Region für Funktionen
nam5 oder us-central (Multiregion) us-central1
eur3 oder europe-west (Multiregion) europe-west1
europe-west4 (Niederlande) europe-west1
asia-south1 (Mumbai) asia-east2
asia-south2 (Delhi) asia-east2
australia-southeast2 (Melbourne) australia-southeast1