Cloud Functions basiert auf Regionen. Das heißt, die Infrastruktur, auf der die Funktion ausgeführt wird, befindet sich in bestimmten Regionen. Sie wird von Google verwaltet, damit die Funktion 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 Regionen auswählen, die sich in der Nähe Ihrer Nutzer befinden. Sie sollten aber auch den Standort der anderen Produkte und Dienste berücksichtigen, die Ihre Anwendung nutzt. Eine standortübergreifende Nutzung von Diensten kann die Latenz der Anwendung sowie die Preise beeinflussen.
Standardmäßig werden Funktionen in der us-central1 Region ausgeführt. Das kann sich von der Region einer Ereignisquelle wie einem Cloud Storage Bucket unterscheiden.
Informationen zum Festlegen 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 gibt das energy_savings_leaf Symbol an, 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 us-central1 Region ausgeführt. Das 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.
Legen Sie die Region, in der eine Funktion ausgeführt wird, fest, indem Sie den region Parameter in der
Funktionsdefinition wie unten gezeigt festlegen:
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 Region
strings 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 das Cloud Firestore document
das das Ereignis ausgibt. Für einen Cloud Storage Trigger könnte der Ereignisfilter
bucket sein, für einen 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
Für HTTP- und aufrufbare Funktionen empfehlen wir, dass Sie zuerst die Funktion für die Zielregion oder die Region festlegen, die sich am nächsten an den meisten erwarteten Kunden befindet. Ändern Sie dann die ursprüngliche Funktion so, 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 Funktion 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 clientseitig aufrufbare Setups denselben
Richtlinien wie HTTP-Funktionen folgen. Der Client kann auch eine Region angeben. Das ist
erforderlich, 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. Deshalb sollten Sie Funktionen so implementieren, dass sie idempotentsind. Wenn Ihre Funktion bereits idempotent ist, können Sie sie 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 Befehlsfolge 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 variieren je nach Ereignistriggertyp:
| Triggertyp | Regionsempfehlung |
|---|---|
| Cloud Firestore | Region, die sich am nächsten am Standort der Cloud Firestore Instanz befindet (siehe nächster Abschnitt) |
| Realtime Database | Dieselbe Region wie die Realtime Database Instanz |
| Cloud Storage | Region, die sich am nächsten am Standort des Cloud Storage Buckets befindet (siehe nächster Abschnitt) |
| Sonstiges | Wenn Sie in der Funktion mit einer Realtime Database Instanz, einer Cloud Firestore
Instanz oder einem Cloud Storage Bucket interagieren, ist die empfohlene
Region dieselbe, als wenn eine Funktion durch eine dieser
Ressourcen ausgelöst würde. Verwenden Sie andernfalls die Standardregion us-central1.
Funktionen, die mit Firebase Hosting verbunden sind, können sich in jeder Region befinden. Empfehlungen finden Sie jedoch in
der Übersicht zu serverlosem Hosting. |
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 Standorten befinden, können erhöhte Latenz und in Rechnung gestellte Kosten entstehen.
Hier ist eine Zuordnung der nächstgelegenen Regionen, die von Funktionen unterstützt werden, für Cloud Firestore und Cloud Storage, in Fällen, 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 |