Cloud Functions ist regional. Das bedeutet, dass sich die Infrastruktur, in 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. Sie können im Allgemeinen Regionen in der Nähe Ihrer Nutzer auswählen. Sie sollten aber auch den Standort der anderen Produkte und Dienste berücksichtigen, die Ihre App nutzt. 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 von der Region einer Ereignisquelle wie eines Cloud Storage-Buckets abweichen.
Wie Sie die Region angeben, in der eine Funktion ausgeführt wird, erfahren Sie weiter unten auf dieser Seite.
Unterstützte Regionen
In den Listen in diesem Abschnitt gibt das Symbol energy_savings_leaf an, dass der Strom für diese Region mit geringen CO₂-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 |
---|---|---|---|
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 von der Region einer Ereignisquelle wie eines Cloud Storage-Buckets abweichen. 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 wie unten gezeigt fest:
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 in region
mehrere durch Kommas getrennte Regionsstrings übergeben. Wenn Sie für viele Arten von Hintergrundtriggern eine Region angeben, müssen Sie zusätzlich den richtigen Ereignisfilter angeben. Im obigen Beispiel ist das Cloud Firestore document
, das das Ereignis auslöst. 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 Produktionstraffic verarbeitet, finden Sie unter Region einer Funktion ändern.
HTTP- und clientseitig aufrufbare Funktionen
Bei HTTP- und aufrufbaren Funktionen empfehlen wir, die Funktion zuerst für die Zielregion oder die Region festzulegen, die dem Standort der meisten erwarteten Kunden am nächsten ist. Ändern Sie dann die ursprüngliche Funktion so, dass die HTTP-Anfrage an die neue Funktion weitergeleitet wird. Die Funktionen 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 die aufrufbare Funktion sollten die vom Kunden aufrufbaren Konfigurationen denselben Richtlinien wie HTTP-Funktionen folgen. Der Client kann auch eine Region angeben und muss dies 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 dafür zu sorgen, 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. Die empfohlene Befehlsabfolge zum Ändern der Region für Funktionen finden Sie unter Region einer Funktion ändern.
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.
Die Empfehlungen für die optimale Region unterscheiden sich je nach Ereignistriggertyp:
Triggertyp | Empfehlung für die Region |
---|---|
Cloud Firestore | Die Region, die dem Standort der Cloud Firestore-Instanz am nächsten ist (siehe nächster Abschnitt) |
Realtime Database | Immer us-central1 |
Cloud Storage | Die Region, die dem Speicherort des Cloud Storage-Buckets am nächsten ist (siehe nächster Abschnitt) |
Sonstige | Wenn Sie innerhalb der Funktion mit einer Realtime Database-Instanz, einer Cloud Firestore-Instanz oder einem Cloud Storage-Bucket interagieren, ist die empfohlene Region dieselbe wie bei einer Funktion, die von einer dieser Ressourcen ausgelöst wird. Andernfalls verwenden Sie die Standardregion us-central1 .
Funktionen, die mit Firebase Hosting verbunden sind, können sich in jeder Region befinden. Empfehlungen finden Sie in der Übersicht über das serverlose Hosting. |
Regionen anhand von Cloud Firestore- und Cloud Storage-Standorten auswählen
Die für Funktionen verfügbaren Regionen 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 finden Sie eine Zuordnung der nächstgelegenen Regionen, in denen Cloud Firestore und Cloud Storage unterstützt werden, für den Fall, dass die Region nicht unterstützt wird:
Region/Multiregion für Cloud Firestore und Cloud Storage | Nächste Region für Funktionen |
---|---|
nam5 oder us-central (Multi-Region) |
us-central1 |
eur3 oder europe-west (Multi-Region) |
europe-west1 |
europe-west4 (Niederlande) |
europe-west1 |
asia-south1 (Mumbai) |
asia-east2 |
asia-south2 (Delhi) |
asia-east2 |
australia-southeast2 (Melbourne) |
australia-southeast1 |