Lokalizacje Cloud Functions

Cloud Functions ma charakter regionalny , co oznacza, że ​​infrastruktura, na której działa funkcja Cloud Functions, znajduje się w określonych regionach i jest zarządzana przez Google w celu zapewnienia nadmiarowej dostępności we wszystkich strefach w tych regionach .

Podczas wybierania regionów, w których mają być uruchamiane funkcje, należy wziąć pod uwagę przede wszystkim opóźnienie i dostępność. Zasadniczo możesz wybrać regiony blisko użytkowników, ale powinieneś 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 mieć wpływ na czas oczekiwania aplikacji, a także na jej ceny .

Obsługiwane regiony

Na listach w tej sekcji ikona energy_savings_leaf wskazuje, że energia elektryczna dla tego regionu jest wytwarzana przy niskiej emisji dwutlenku węgla. Aby uzyskać więcej informacji, zobacz Energia bez emisji dwutlenku węgla dla regionów Google Cloud .

Usługa Cloud Functions jest dostępna w następujących regionach z cenami poziomu 1 :

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

Usługa Cloud Functions jest dostępna w następujących regionach z cenami poziomu 2 :

• asia-northeast3 (Seul)
• asia-southeast1 (Singapur)
• asia-southeast2 (Dżakarta)
• asia-south1 (Mumbaj)
• australia-southeast1 (Sydney)
• europe-central2 (Warszawa)
• europe-west3 (Frankfurt)
• europe-west6 (Zurych) energy_savings_leaf
• northamerica-northeast1 (Montreal) energy_savings_leaf
• southamerica-east1 (Sao Paulo) energy_savings_leaf
• us-west2 (Los Angeles)
• us-west3 (Salt Lake City)
• us-west4 (Las Vegas)

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

Sprawdzone metody zmiany regionu

Domyślnie funkcje działają w regionie us-central1 . Pamiętaj, że może się to różnić od regionu źródła zdarzenia, takiego jak zasobnik Cloud Storage. Jeśli musisz zmienić region, w którym działa funkcja, postępuj zgodnie z zaleceniami w tej sekcji dla każdego typu wyzwalacza funkcji.

Aby ustawić region, w którym działa funkcja, ustaw parametr region w definicji funkcji, jak pokazano:

exports.myStorageFunction = functions
    .region('europe-west1')
    .storage
    .object()
    .onFinalize((object) => {
      // ...
    });

Możesz określić wiele regionów, przekazując wiele ciągów regionów oddzielonych przecinkami w functions.region() . Zobacz zmiana regionu funkcji, aby uzyskać więcej informacji na temat zalecanych procedur.

Funkcje HTTP i wywoływane przez klienta

W przypadku funkcji HTTP i wywoływalnych zalecamy, aby najpierw ustawić funkcję w regionie docelowym lub najbliższym miejscu, w którym znajduje się większość oczekiwanych klientów, a następnie zmienić pierwotną funkcję, aby przekierować jej żądanie HTTP do nowej funkcji (mogą mieć te same nazwa). 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 oryginalnej funkcji do nowej funkcji, inicjując nowe żądanie z oryginalnej funkcji do nowej funkcji. Ostatnim krokiem jest upewnienie się, że wszyscy klienci wywołują nową funkcję.

Wybór lokalizacji po stronie klienta dla 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 również określić region i musi to zrobić, jeśli funkcja działa w innym regionie 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 tła

Funkcje działające w tle przyjmują semantykę dostarczania zdarzeń co najmniej raz, co oznacza, że ​​w pewnych okolicznościach mogą odbierać zduplikowane zdarzenia. Powinieneś więc zaimplementować funkcje, które będą idempotentne . Jeśli Twoja funkcja jest już idempotentna, możesz ponownie wdrożyć funkcję w nowym regionie z tym samym wyzwalaczem zdarzenia i usunąć starą funkcję po sprawdzeniu, czy nowa funkcja prawidłowo odbiera ruch. Podczas tego przejścia obie funkcje będą odbierać zdarzenia. Zobacz zmianę regionu funkcji , aby zapoznać się z zalecaną sekwencją poleceń do zmiany regionów funkcji.

Jeśli Twoja funkcja nie jest obecnie idempotentna lub jej idempotentność nie wykracza poza region, zalecamy najpierw zaimplementować idempotentność przed przeniesieniem funkcji.

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

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

Dostępne regiony dla funkcji nie zawsze dokładnie odpowiadają regionom dostępnym 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, możesz potencjalnie doświadczyć zwiększonego opóźnienia i kosztów rozliczeń .

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: