Standorte von Cloud Run Functions
Cloud Run Functions ist regional. Die Infrastruktur, in der eine Cloud Run-Funktion ausgeführt wird, befindet sich demnach in einer bestimmten Region. Aufgrund der Verwaltung durch Google ist sie in allen Zonen innerhalb dieser Region redundant verfügbar.
Bei der Entscheidung für eine Region zur Ausführung von Cloud Run-Functions-Funktionen sollten Latenz und Verfügbarkeit an erster Stelle stehen. Im Allgemeinen können Sie zwar die Region auswählen, die Ihren Cloud Run 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.
Die für Cloud Run Functions verfügbaren Regionen sind unten aufgeführt. Die verschiedenen Versionen von Cloud Run Functions haben unterschiedliche regionale Verfügbarkeit. Informationen dazu finden Sie in den Tabellen in der Spalte "Unterstützte Produktversionen".
Preisstufe 1
Cloud Run Functions ist in den folgenden Regionen mit Preisstufe 1 verfügbar:
| Region | Standort | CO₂-Emissionen |
|---|---|---|
asia-east1 |
Taiwan | |
asia-northeast1 |
Tokio | |
asia-northeast2 |
Osaka | |
europe-north1 |
Finnland |
 Niedriger CO2-Wert
|
europe-southwest1 |
Madrid | |
europe-west1 |
Belgien |
Niedriger CO2-Wert
|
europe-west4 |
Niederlande | |
europe-west8 |
Mailand | |
europe-west9 |
Paris |
Niedriger CO2-Wert
|
me-west1 |
Tel Aviv | |
us-central1 |
Iowa |
Niedriger CO2-Wert
|
us-east1 |
South Carolina | |
us-east4 |
Northern Virginia | |
us-east5 |
Columbus | |
us-south1 |
Dallas | |
us-west1 |
Oregon |
Niedriger CO2-Wert |
Preisstufe 2
Cloud Run Functions ist in den folgenden Regionen mit Preisstufe 2 verfügbar:
| Region | Standort | CO₂-Emissionen |
|---|---|---|
asia-east2 |
Hongkong | |
asia-northeast3 |
Seoul | |
asia-southeast1 |
Singapur | |
asia-southeast2 |
Jakarta | |
asia-south1 |
Mumbai | |
asia-south2 |
Delhi, Indien | |
australia-southeast1 |
Sydney | |
australia-southeast2 |
Melbourne | |
europe-central2 |
Warschau | |
europe-west2 |
London | |
europe-west3 |
Frankfurt |
Niedriger CO2-Wert
|
europe-west6 |
Zürich |
Niedriger CO2-Wert
|
europe-west10 |
Berlin | |
europe-west12 |
Turin | |
me-central1 |
Doha | |
me-central2 |
Dammam | |
northamerica-northeast1 |
Montreal |
Niedriger CO2-Wert
|
northamerica-northeast2 |
Toronto |
Niedriger CO2-Wert
|
southamerica-east1 |
São Paulo |
Niedriger CO2-Wert
|
southamerica-west1 |
Santiago, Chile | |
us-west2 |
Los Angeles | |
us-west3 |
Salt Lake City | |
us-west4 |
Las Vegas |
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.
gcloud functions deploy FUNCTION_NAME --region=REGION ...
REGION steht für eine der oben aufgeführten Regionen.
Console
Wenn Sie die Google Cloud Console verwenden, können Sie beim Erstellen und Bereitstellen einer Funktion die Region auswählen.
Wechseln Sie in der Google Cloud Console zur Übersichtsseite "Cloud Run-Funktionen".
Zur Übersichtsseite Cloud Run
Achten Sie darauf, dass das Projekt ausgewählt ist, für das Sie Cloud Run-Funktionen aktiviert haben.
Klicken Sie auf Funktion erstellen.
Wählen Sie im Feld Region eine Region aus.
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 relevant). Funktionen in verschiedenen Regionen oder Projekten können denselben Namen haben.
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 Run 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 Run Functions eine Konformität des Datenstandorts, sobald das vorgelagerte Produkt (ausgelöstes Produkt) das Ereignis an Cloud Run 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.