Lokalizacje Cloud Functions

Cloud Functions działa regionalnie, co oznacza, że infrastruktura, na której działa Twoja funkcja, znajduje się w określonych regionach i jest zarządzana przez Google w taki sposób, aby była dostępna w każdej strefie w tych regionach.

Wybierając regiony, w których mają być wykonywane funkcje, należy przede wszystkim wziąć pod uwagę opóźnienie i dostępność. Zazwyczaj możesz wybrać regiony zlokalizowane blisko użytkowników, ale musisz też wziąć pod uwagę lokalizację innych produktów i usług, z których korzysta Twoja aplikacja. Korzystanie z usług w różnych regionach może wpływać na opóźnienia w aplikacji oraz na ceny.

Domyślnie funkcje są wykonywane w regionie us-central1. Pamiętaj, że może to być inny region niż region źródła zdarzenia, np. zasobnika Cloud Storage. Jak określić region, w którym ma działać funkcja, dowiesz się dalej na tej stronie.

Obsługiwane regiony

Na listach w tej sekcji ikona energy_savings_leaf wskazuje, że energia elektryczna w danym regionie jest produkowana z niską emisją dwutlenku węgla. Więcej informacji znajdziesz w artykule Energetyka bezemisyjna w regionach Google Cloud.

Cennik poziomu 1

Cloud Functions jest dostępny w tych regionach: Cennik poziomu 1:

Cennik poziomu 2

Cloud Functions jest dostępny w tych regionach w ramach poziomu 2 cen:

Funkcje w danym regionie w danym projekcie muszą mieć unikalne nazwy (niezależne od wielkości liter), ale funkcje w różnych regionach lub projektach mogą mieć tę samą nazwę.

Sprawdzone metody określania regionu

Domyślnie funkcje są wykonywane w regionie us-central1. Pamiętaj, że może to być inny region niż region źródła zdarzenia, np. zasobnika Cloud Storage. Jeśli musisz określić region, w którym ma działać funkcja, postępuj zgodnie z zaleceniami w tej sekcji dla każdego typu funkcji.

Aby ustawić region, w którym ma działać funkcja, w definicji funkcji ustaw parametr region w ten sposób:

exports.firestoreAsia = onDocumentCreated(
  {
    document: "my-collection/{docId}",
    region: "asia-northeast1",
  },
  (event) => {},
);

# 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, podając w parametrze region wiele ciągów znaków oddzielonych przecinkami. Pamiętaj też, że podczas określania regionu dla wielu typów reguł działających w tle musisz podać odpowiedni filtr zdarzeń wraz z regionem. W przykładzie powyżej jest to Cloud Firestore document, które emituje zdarzenie. W przypadku reguły Cloud Storage filtr zdarzeń może mieć wartość bucket, w przypadku reguły Pub/Sub będzie to topic itd.

Więcej informacji o zmianie regionu funkcji, która obsługuje ruch produkcyjny, znajdziesz w artykule Zmienianie regionu funkcji.

Funkcje wywoływane przez klienta i HTTP

W przypadku funkcji HTTP i funkcji wywoływalnych zalecamy najpierw ustawienie funkcji w regionie docelowym lub w najbliższym regionie docelowym, w którym znajduje się najwięcej klientów, a potem zmodyfikowanie pierwotnej funkcji w celu przekierowania jej żądania HTTP do nowej funkcji (mogą mieć one 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 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 dla funkcji wywoływalnych

W przypadku funkcji wywoływalnej konfiguracja wywołania przez klienta powinna być zgodna z wytycznymi dotyczącymi funkcji HTTP. Klient może też określić region i musi to zrobić, jeśli funkcja działa w regionie innym niż us-central1.

Aby ustawić regiony na kliencie, określ żądany region podczas inicjalizacji:

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

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

var functions = firebase.app().functions('europe-west1');

private FirebaseFunctions mFunctions;
// ...
mFunctions = FirebaseFunctions.getInstance("europe-west1");

firebase::functions::Functions* functions;
// ...
functions = firebase::functions::Functions::GetInstance("europe-west1");

firebase.Functions.FirebaseFunctions functions;

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

Funkcje w tle

Funkcje działające w tle korzystają z semantyki 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 ją ponownie wdrożyć w nowym regionie przy użyciu tego samego wyzwalacza zdarzenia i usunąć starą funkcję po potwierdzeniu, że nowa funkcja prawidłowo odbiera ruch. Podczas tej zmiany obie funkcje będą otrzymywać zdarzenia. Zapoznaj się z artykułem Zmiana regionu funkcji, aby poznać zalecaną sekwencję poleceń do zmiany regionów funkcji.

Jeśli funkcja nie jest idempotentna lub idempotentyzacja nie obejmuje całego regionu, zalecamy najpierw wdrożenie idempotentyzacji, a dopiero potem przeniesienie funkcji.

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

Wybieranie regionów na podstawie lokalizacji Cloud Firestore i Cloud Storage

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

Pamiętaj, że jeśli Twoja funkcja i Twój zasób (instancja bazy danych lub Cloud Storagezasobnik) znajdują się w różnych lokalizacjach, czas oczekiwania i koszty rozliczeniowe mogą być większe.

Oto mapowanie regionów obsługiwanych przez funkcje Cloud Firestore i Cloud Storage w przypadkach, gdy ten sam region jest nieobsługiwany: