Lokalizacje Cloud Functions

Cloud Functions jest regionalna, co oznacza, że infrastruktura, na której działa Twoja funkcja, znajduje się w określonych regionach i jest zarządzana przez Google, aby zapewnić nadmiarową dostępność we wszystkich strefach w tych regionach.

Wybierając regiony, w których mają być uruchamiane funkcje, należy przede wszystkim wziąć pod uwagę czas oczekiwania i dostępność. Zwykle możesz wybrać regiony blisko użytkowników, ale weź też pod uwagę lokalizację innych usług, z których korzysta Twoja aplikacja. Korzystanie z usług w wielu regionach może wpływać na czas oczekiwania aplikacji, a także na ceny.

Domyślnie interfejs wiersza poleceń Firebase wdraża funkcje w regionie określonym w konfiguracji projektu. W przypadku funkcji opartych na zdarzeniach zwykle wdraża się je w regionie, w którym znajduje się źródło danych wyzwalających (np. baza danych Cloud Firestore lub zasobnik Cloud Storage), a w razie niepowodzenia – w regionie us-central1.

Po wdrożeniu możesz sprawdzić region w konsoli Firebase lub uruchamiając firebase functions:list. Jeśli chcesz, aby funkcja działała w innym regionie, możesz zmienić jej region.

Obsługiwane regiony

Na listach w tej sekcji ikona energy_savings_leaf wskazuje, że energia elektryczna w tym regionie jest wytwarzana przy niskiej emisji dwutlenku węgla. Więcej informacji znajdziesz w artykule Energia bezemisyjna w regionach Google Cloud.

Cennik poziomu 1

Usługa Cloud Functions jest dostępna w tych regionach z cenami na poziomie 1:

Region Lokalizacja Obsługiwane wersje usługi Emisja CO2
africa-south1 Johannesburg Tylko 2 generacja
asia-east1 Tajwan 1 generacja, 2 generacja
asia-east2 Hongkong Tylko 1 generacja
asia-northeast1 Tokio 1 generacja, 2 generacja
asia-northeast2 Osaka 1 generacja, 2 generacja
europe-north1 Finlandia Tylko 2 generacja energy_savings_leaf
europe-southwest1 Madryt Tylko 2 generacja
europe-west1 Belgia 1 generacja, 2 generacja energy_savings_leaf
europe-west4 Holandia Tylko 2 generacja
europe-west8 Mediolan Tylko 2 generacja
europe-west9 Paryż Tylko 2 generacja energy_savings_leaf
me-west1 Tel Awiw Tylko 2 generacja
europe-west2 Londyn Tylko 1 generacja
us-central1 Iowa 1 generacja, 2 generacja energy_savings_leaf
us-east1 Karolina Południowa 1 generacja, 2 generacja
us-east4 Północna Wirginia 1 generacja, 2 generacja
us-east5 Columbus Tylko 2 generacja
us-south1 Dallas Tylko 2 generacja
us-west1 Oregon 1 generacja, 2 generacja energy_savings_leaf

Cennik poziomu 2

Usługa Cloud Functions jest dostępna w tych regionach z cenami na poziomie 2:

Region Lokalizacja Obsługiwane wersje usługi Emisja CO2
asia-east2 Hongkong Tylko 2 generacja
asia-northeast3 Seul 1 generacja, 2 generacja
asia-southeast1 Singapur 1 generacja, 2 generacja
asia-southeast2 Dżakarta 1 generacja, 2 generacja
asia-south1 Mumbaj Tylko 2 generacja
asia-south2 Delhi, Indie Tylko 2 generacja
australia-southeast1 Sydney 1 generacja, 2 generacja
australia-southeast2 Melbourne Tylko 2 generacja
europe-central2 Warszawa 1 generacja, 2 generacja
europe-west2 Londyn Tylko 2 generacja
europe-west3 Frankfurt 1 generacja, 2 generacja energy_savings_leaf
europe-west6 Zurych 1 generacja, 2 generacja energy_savings_leaf
europe-west10 Berlin Tylko 2 generacja
europe-west12 Turyn Tylko 2 generacja
me-central1 Doha Tylko 2 generacja
me-central2 Dammam Tylko 2 generacja
northamerica-northeast1 Montreal 1 generacja, 2 generacja energy_savings_leaf
northamerica-northeast2 Toronto Tylko 2 generacja energy_savings_leaf
southamerica-east1 Săo Paulo 1 generacja, 2 generacja energy_savings_leaf
southamerica-west1 Santiago, Chile Tylko 2 generacja
us-west2 Los Angeles 1 generacja, 2 generacja
us-west3 Salt Lake City 1 generacja, 2 generacja
us-west4 Las Vegas 1 generacja, 2 generacja

Funkcje w danym regionie w danym projekcie muszą mieć unikalne nazwy (wielkość liter nie jest rozróżniana), ale funkcje w różnych regionach lub projektach mogą mieć takie same nazwy.

Sprawdzone metody określania regionu

Domyślnie interfejs wiersza poleceń Firebase wdraża funkcje w regionie określonym w konfiguracji projektu. W przypadku funkcji opartych na zdarzeniach zwykle wdraża się je w regionie, w którym znajduje się źródło danych wyzwalających (np. baza danych Cloud Firestore lub zasobnik Cloud Storage), a w razie niepowodzenia – w regionie us-central1.

Zalecamy ustawienie konkretnych regionów zamiast polegania na domyślnych ustawieniach Firebase, które mogą się zmieniać. Podczas ustawiania regionów postępuj zgodnie z zaleceniami opisanymi w tej sekcji dla każdego typu reguły.

Aby ustawić region, w którym funkcja ma być uruchamiana, ustaw parametr region w definicji funkcji w następujący sposób:

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

Możesz określić wiele regionów, przekazując w parametrze region wiele ciągów znaków regionów rozdzielonych przecinkami. Pamiętaj też, że gdy określasz region dla wielu typów aktywatorów działających w tle, musisz podać prawidłowy filtr zdarzeń wraz z regionem. W powyższym przykładzie jest to Cloud Firestore document, który emituje zdarzenie. W przypadku aktywatora Cloud Storage filtr zdarzeń może mieć wartość bucket, a w przypadku aktywatora Pub/Sub – topic itd.

Więcej informacji o zmienianiu regionu funkcji obsługującej ruch produkcyjny znajdziesz w artykule o zmianie regionu funkcji.

Funkcje HTTP i funkcje wywoływane przez klienta

W przypadku funkcji HTTP i wywoływalnych zalecamy najpierw ustawić funkcję na region docelowy lub najbliższy region, w którym znajduje się większość oczekiwanych klientów, a następnie zmienić pierwotną funkcję, aby przekierowywała żądanie HTTP do nowej funkcji (mogą mieć tę samą nazwę). Jeśli klienci Twojej funkcji HTTP obsługują przekierowania, możesz po prostu zmienić pierwotną funkcję, aby zwracała stan przekierowania HTTP (301) wraz z adresem URL nowej funkcji. Jeśli Twoi klienci nie radzą sobie dobrze z przekierowaniami, możesz przekazać żądanie z pierwotnej funkcji do nowej, inicjując nowe żądanie z pierwotnej funkcji do nowej. Ostatnim krokiem jest upewnienie się, że wszyscy klienci wywołują nową funkcję.

Wybór lokalizacji po stronie klienta w przypadku funkcji wywoływalnych

Jeśli chodzi o funkcję wywoływalną, konfiguracje wywoływalne przez klienta powinny być zgodne z tymi samymi wytycznymi co funkcje HTTP. Klient może też określić region i powinien to zrobić, jeśli funkcja działa w regionie innym niż domyślny region projektu.

Aby ustawić regiony w kliencie, określ odpowiedni region podczas inicjowania:

Swift

lazy var functions = Functions.functions(region:"europe-west1")

Objective-C

@property(strong, nonatomic) FIRFunctions *functions;
// ...
self.functions = [FIRFunctions functionsWithRegion:@"europe-west1"];

Sieć


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");

Unity

firebase.Functions.FirebaseFunctions functions;

functions = Firebase.Functions.FirebaseFunctions.GetInstance("europe-west1");

Funkcje działające w tle

Funkcje działające w tle stosują semantykę dostarczania zdarzeń co najmniej raz, co oznacza, że w pewnych okolicznościach mogą otrzymywać zduplikowane zdarzenia. Dlatego funkcje powinny być idempotentne. Jeśli funkcja jest już idempotentna, możesz wdrożyć ją ponownie w nowym regionie z tym samym aktywatorem zdarzeń i usunąć starą funkcję po sprawdzeniu, czy nowa funkcja prawidłowo odbiera ruch. W tym okresie przejściowym obie funkcje będą otrzymywać zdarzenia. Zalecaną sekwencję poleceń do zmiany regionów funkcji znajdziesz w artykule o zmianie regionu funkcji.

Jeśli funkcja nie jest obecnie idempotentna lub jej idempotencja nie wykracza poza region, zalecamy najpierw wdrożyć idempotencję, a dopiero potem przenieść funkcję.

Zalecenia dotyczące optymalnego regionu różnią się w zależności od typu aktywatora zdarzenia:

Typ aktywatora Rekomendacja dotycząca regionu
Cloud Firestore Region najbliższy lokalizacji instancji Cloud Firestore (patrz następna sekcja)
Realtime Database Ten sam region co instancja Realtime Database
Cloud Storage Region najbliższy lokalizacji zasobnika Cloud Storage (patrz następna sekcja)
Inne Jeśli w funkcji korzystasz z instancji Realtime Database, instancji Cloud Firestore lub zasobnika Cloud Storage, zalecany region jest taki sam jak w przypadku funkcji wywoływanej przez jeden z tych zasobów. Funkcje połączone z Firebase Hosting mogą znajdować się w dowolnym regionie, ale zalecenia znajdziesz w omówieniu hostingu bezserwerowego.

Wybieram regiony na podstawie lokalizacji Cloud Firestore i Cloud Storage

Dostępne regiony funkcji nie zawsze dokładnie odpowiadają regionom dostępnym dla bazy danych Cloud Firestore i zasobników Cloud Storage.

Pamiętaj, że jeśli funkcja i zasób (instancja bazy danych lub zasobnik Cloud Storage) znajdują się w różnych lokalizacjach, może to spowodować zwiększenie opóźnienia i rozliczonych kosztów.

Oto mapowanie najbliższych regionów obsługiwanych przez funkcje dla Cloud Firestore i Cloud Storage w przypadkach, gdy ten sam region nie jest obsługiwany:

Region lub wiele regionów w przypadku Cloud Firestore i Cloud Storage Najbliższy region dla funkcji
nam5 lub us-central (wiele regionów) us-central1
eur3 lub europe-west (wiele regionów) europe-west1
europe-west4 (Holandia) europe-west1
asia-south1 (Mumbaj) asia-east2
asia-south2 (Delhi) asia-east2
australia-southeast2 (Melbourne) australia-southeast1