Lokalizacje w Cloud Functions

Usługa Cloud Functions jest regionalna, co oznacza, że infrastruktura, w której działa funkcja, znajduje się w określonych regionach i zarządzana przez Google w sposób zapewniający nadmiarowość we wszystkich strefach w tych regionach.

Wybierając regiony, w których będą uruchamiane funkcje, należy wziąć pod uwagę czas oczekiwania i dostępność. Ogólnie możesz wybrać regiony znajdujące się w pobliżu użytkowników, ale warto też wziąć pod uwagę lokalizację innych produktów i usług, z których korzysta Twoja aplikacja. Korzystanie z usług w wielu regionach może wpływać na czas oczekiwania aplikacji oraz na ceny.

Domyślnie funkcje są uruchamiane w regionie us-central1. Może się on różnić od regionu źródła zdarzeń, takiego jak zasobnik Cloud Storage. Później na tej stronie dowiesz się, jak określić region, w którym będzie działać funkcja.

Obsługiwane regiony

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

Usługa Cloud Functions jest dostępna w tych regionach w ramach ceny poziomu 1:

• asia-east1 (Tajwan)
• asia-east2 (Hongkong) tylko 1 generacji
• asia-northeast1 (Tokio)
• asia-northeast2 (Osaka)
• europe-north1 (Finlandia) energy_savings_leaf tylko 2 generacji
• europe-west1 (Belgia) energy_savings_leaf
• europe-west2 (Londyn) Tylko 1 generacji
• us-central1 (Iowa) energy_savings_leaf
• us-east1 (Karolina Południowa)
• us-east4 (Wirginia Północna)
• us-west1 (Oregon) energy_savings_leaf

Usługa Cloud Functions jest dostępna w tych regionach w ramach ceny poziomu 2:

• asia-east2 (Hongkong) tylko 2 generacji
• asia-northeast3 (Seul)
• asia-southeast1 (Singapur)
• asia-southeast2 (Dżakarta)
• asia-south1 (Mumbaj) Tylko 2 generacji
• australia-southeast1 (Sydney)
• australia-southeast2 (Melbourne) tylko 2 generacji
• europe-central2 (Warszawa)
• europe-west2 (Londyn) Tylko 2 generacji
• europe-west3 (Frankfurt)
• europe-west6 (Zurych) energy_savings_leaf
• northamerica-northeast1 (Montreal) energy_savings_leaf
• northamerica-northeast2 (Toronto) energy_savings_leaf tylko 2 generacji
• southamerica-east1 (Sao Paulo) energy_savings_leaf
• southamerica-west1 (Santiago, Chile) tylko 2 generacji
• us-west2 (Los Angeles)
• us-west3 (Salt Lake City)
• us-west4 (Las Vegas)

Funkcje w danym regionie w projekcie muszą mieć unikalne nazwy (wielkość liter nie jest rozróżniana), ale funkcje w regionach i projektach mogą mieć taką samą nazwę.

Sprawdzone metody określania regionu

Domyślnie funkcje są uruchamiane w regionie us-central1. Może się on różnić od regionu źródła zdarzeń, takiego jak zasobnik Cloud Storage. Jeśli musisz określić region, w którym działa funkcja, postępuj zgodnie z zaleceniami w tej sekcji dla poszczególnych typów aktywatorów funkcji.

Aby ustawić region, w którym działa funkcja, ustaw parametr region w definicji funkcji w następujący 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 podać wiele regionów, przekazując w polu region wiele ciągów znaków dotyczących regionów rozdzielonych przecinkami. Pamiętaj też, że przy określaniu regionu dla wielu typów reguł działających w tle musisz wraz z regionem określić prawidłowy filtr zdarzeń. W przykładzie powyżej jest to obiekt document Cloud Firestore, który emituje zdarzenie. W przypadku aktywatora Cloud Storage filtrem zdarzeń może być bucket, w przypadku aktywatora Pub/Sub – topic itd.

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

Funkcje HTTP i możliwe do wywołania przez klienta

W przypadku funkcji HTTP i możliwości wywołania zalecamy ustawienie najpierw regionu docelowego lub miejsca, w którym znajdują się najbardziej spodziewani klienci, a potem zmodyfikowanie pierwotnej funkcji w taki sposób, aby przekierowywała żądanie HTTP do nowej funkcji (mogą one mieć taką samą nazwę). Jeśli klienty funkcji HTTP obsługują przekierowania, możesz po prostu zmienić pierwotną funkcję, by zwracała stan przekierowania HTTP (301) wraz z adresem URL nowej funkcji. Jeśli klienty nie radzą sobie dobrze z przekierowaniami, możesz przesłać żądanie z pierwotnej funkcji do nowej, inicjując nowe żądanie z pierwotnej funkcji do nowej. Ostatnim krokiem jest sprawdzenie, czy wszyscy klienci wywołują nową funkcję.

Wybór lokalizacji po stronie klienta na potrzeby funkcji z możliwością wywoływania

Jeśli chodzi o funkcję wywoływaną przez klienta, konfiguracje możliwe do wywołania przez klienta powinny być zgodne z tymi samymi wytycznymi co funkcje HTTP. Klient może też określić region i musi to zrobić, jeśli funkcja działa w dowolnym regionie innym niż us-central1.

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

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 działające w tle

Funkcje działające w tle przyjmują semantykę realizacji co najmniej raz zdarzenia, co oznacza, że w pewnych okolicznościach mogą otrzymywać zduplikowane zdarzenia. Musisz więc wdrożyć funkcje tak, aby były idempotentne. Jeśli Twoja funkcja jest już idempotentna, możesz ją wdrożyć w nowym regionie za pomocą tego samego aktywatora zdarzenia i usunąć starą funkcję po sprawdzeniu, czy nowa funkcja prawidłowo odbiera ruch. W tym czasie obie funkcje będą otrzymywać zdarzenia. W sekcji o zmienianiu regionu funkcji znajdziesz zalecaną sekwencję poleceń do zmiany regionu funkcji.

Jeśli funkcja nie jest obecnie idempotentna lub jej idempotentność nie wykracza poza region, przed jej przeniesieniem zalecamy wdrożenie idempotentności.

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

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

Dostępne regiony dla funkcji nie zawsze są dokładnie dopasowane do regionów dostępnych dla bazy danych Cloud Firestore i zasobników Cloud Storage.

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

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