Standorte für Cloud Functions

Cloud Functions basiert auf Regionen, das heißt, die Infrastruktur, auf der die Cloud Functions-Funktionen ausgeführt werden, befindet sich in einer bestimmten Region. Sie wird von Google verwaltet, damit die Funktionen in allen Zonen innerhalb dieser Region redundant verfügbar sind.

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

Preisstufe 1

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

Preisstufe 2

Cloud Functions ist in der folgenden Region mit Preisstufe 2 verfügbar:

  • us-west2 (Los Angeles)
  • us-west3 (Salt Lake City)
  • us-west4 (Las Vegas)
  • northamerica-northeast1 (Montreal) Blattsymbol Niedriger CO2-Ausstoß
  • southamerica-east1 (Sao Paulo) Blattsymbol Niedriger CO2-Ausstoß
  • europe-west3 (Frankfurt)
  • europe-west6 (Zürich) Blattsymbol Niedriger CO2-Ausstoß
  • europe-central2 (Warschau)
  • australia-southeast1 (Sydney)
  • asia-south1 (Mumbai)
  • asia-southeast1 (Singapur)
  • asia-southeast2 (Jakarta)
  • asia-northeast3 (Seoul)

Sie können Funktionen in verschiedenen Regionen innerhalb eines Projekts bereitstellen, aber sobald eine Region für eine Funktion ausgewählt wurde, kann sie nicht mehr geändert werden.

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

Beachten Sie, dass Sie die neuesten Standorte mithilfe der Methode project.locations/list aus der Cloud Functions API programmatisch abrufen können.

Region auswählen

Sie können bei der Bereitstellung der Funktion eine Region auswählen.

gcloud

Wenn Sie die Google Cloud CLI verwenden, können Sie die Region mit dem Flag --region angeben. Beispiel:

gcloud functions deploy FUNCTION_NAME --region REGION FLAGS...

REGION steht für eine der oben aufgeführten Regionen.

Im obigen Beispiel bezieht sich FLAGS... auf andere Argumente, die Sie während der Bereitstellung der Funktion übergeben. Eine vollständige Referenz zum deploy-Befehl finden Sie unter gcloud functions deploy.

Console

Wenn Sie die Cloud Console verwenden, können Sie beim Erstellen und Bereitstellen einer Funktion die Region auswählen.

  1. Rufen Sie in der Cloud Console die Übersichtsseite von Cloud Functions auf.

    Zur Cloud Functions-Übersichtsseite

    Achten Sie darauf, dass das Projekt ausgewählt ist, für das Sie Cloud Functions aktiviert haben.

  2. Klicken Sie auf Funktion erstellen.

  3. Erweitern Sie das Menü Mehr.

  4. Unter Region können Sie die Region auswählen.

Standardregion festlegen

So legen Sie mit der Google Cloud CLI eine Standardregion fest:

gcloud config set functions/region REGION

Beispiel:

gcloud config set functions/region europe-west1

Datenstandort

Cloud Functions bietet eine Datenstandortgarantie für den Geltungsbereich der Funktionsausführung (Geltungsbereich A: Compliance der Funktionsausführung). Zu einer bestimmten Funktion wird damit der Datenstandort für den Funktionsaufruf bzw. die Funktionsausführung sichergestellt.

Diese Compliance gilt sowohl für HTTP-Funktionen als auch für ereignisgesteuerte Funktionen. Für ereignisgesteuerte Funktionen besteht bei Cloud Functions eine Konformität des Datenstandorts, sobald das vorgelagerte Produkt (ausgelöstes Produkt) das Ereignis an Cloud Functions gesendet hat. Daher muss sichergestellt werden, dass für das vorgelagerte Produkt (z. B. Cloud Storage oder Pub/Sub) selbst eine Konformität des Datenstandorts besteht.

Best Practices für das Ändern von Regionen

Orientieren Sie sich an den folgenden Empfehlungen, wenn Sie eine Region ändern müssen, in der eine Funktion bereitgestellt wird.

HTTP-Funktionen

Für HTTP-Funktionen empfehlen wir, dass Sie zuerst die HTTP-Funktion für die Zielregion neu bereitstellen (sie kann denselben Namen haben) und dann die ursprüngliche Funktion so abändern, dass die HTTP-Anfrage an die neue Funktion umgeleitet wird. Wenn Clients, die Ihre HTTP-Funktion verwenden, Weiterleitungen unterstützen, können Sie einfach die ursprüngliche Funktion so ändern, dass der HTTP-Redirect-Status (301) zusammen mit der URL der neuen Funktion zurückzugeben 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 eine Anfrage an die neue Funktion. Im letzten Schritt müssen Sie dafür sorgen, dass alle Clients die neue Funktion aufrufen.

Ereignisgesteuerte Funktionen

Ereignisgesteuerte Funktionen verwenden eine spezielle Semantik, um sicherzugehen, dass ein Ereignis mindestens einmal zugestellt wird. Das heißt, dass durchaus doppelte Ereignisse vorkommen können, und diese Funktionen deswegen immer so implementiert werden sollten, 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.

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.