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 redundant in allen Zonen innerhalb dieser Regionen 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 regionsübergreifende Nutzung von Diensten kann die Latenz der Anwendung sowie die Preise beeinflussen.

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

Nach der Bereitstellung können Sie die Region in der Firebase-Konsole oder durch Ausführen von firebase functions:list überprü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 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:

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 werden Funktionen mit der Firebase CLI in einer Region bereitgestellt, die auf der Konfiguration Ihres Projekts basiert. Bei ereignisgesteuerten Funktionen wird die Funktion in der Regel in einer Region bereitgestellt, die der Region der auslösenden Datenquelle (z. B. einer Cloud Firestore-Datenbank oder einem Cloud Storage-Bucket) entspricht. Als Fallback wird sie in us-central1 bereitgestellt.

Es wird empfohlen, 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 die einzelnen Triggertypen.

Wenn Sie die Region festlegen möchten, in der eine Funktion ausgeführt wird, legen Sie den Parameter region in der Funktionsdefinition 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 eine Region für viele Hintergrundtrigger-Typen angeben, müssen Sie auch den richtigen Ereignisfilter zusammen mit der Region angeben. Im obigen Beispiel ist das 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 Produktions-Traffic verarbeitet, finden Sie unter Region einer Funktion ändern.

HTTP- und clientseitig aufrufbare Funktionen

Bei HTTP- und aufrufbaren Funktionen empfehlen wir, die Funktion zuerst auf die Zielregion oder die Region festzulegen, in der sich die meisten potenziellen Kunden befinden, und dann die ursprüngliche Funktion so zu ändern, dass ihre HTTP-Anfrage an die neue Funktion weitergeleitet wird (die Funktionen können denselben Namen haben). Wenn Clients Ihrer HTTP-Funktion Weiterleitungen unterstützen, können Sie einfach Ihre ursprüngliche Funktion 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 senden. 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.

Wenn Sie Regionen auf dem Client festlegen möchten, geben Sie die gewünschte Region bei der Initialisierung 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 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 neu bereitstellen und die alte Funktion entfernen, nachdem Sie überprüft haben, dass die neue Funktion Traffic empfängt. Während dieser Umstellung erhalten 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.

Empfehlungen für die optimale Region 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 höhere Latenz und Abrechnungskosten entstehen.

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