Lokalizacje w Cloud Functions

Usługa Cloud Functions jest regionalna, co oznacza, że infrastruktura, w której działa Twoja funkcja, 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.

Wybierając regiony, w których będą uruchamiane funkcje, należy wziąć pod uwagę przede wszystkim czas oczekiwania i dostępność. Ogólnie możesz wybierać regiony znajdujące się w pobliżu użytkowników, ale musisz też wziąć pod uwagę lokalizację innych produktów i usług, z których korzysta Twoja aplikacja. Używanie 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. Pamiętaj, że może się on różnić od regionu źródła zdarzeń, takiego jak zasobnik Cloud Storage. Na tej stronie dowiesz się, jak określić region, w którym działa funkcja.

Obsługiwane regiony

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

Usługa Cloud Functions jest dostępna w tych regionach w cenniku 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 cenniku 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 danym projekcie muszą mieć unikalne nazwy (wielkość liter nie jest rozróżniana), ale funkcje w różnych regionach lub w wielu projektach mogą mieć tę samą nazwę.

Sprawdzone metody określania regionu

Domyślnie funkcje są uruchamiane w regionie us-central1. Pamiętaj, że 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 opisanymi w tej sekcji w przypadku każdego typu aktywatora funkcji.

Aby ustawić region, w którym działa funkcja, ustaw w definicji funkcji parametr region w podany niżej 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, przekazując w funkcji region wiele ciągów regionalnych rozdzielonych przecinkami. Pamiętaj też, że podczas określania regionu dla wielu typów aktywatorów w tle musisz podać odpowiedni filtr zdarzeń oraz region. W przykładzie powyżej jest to instancja document Cloud Firestore, która emituje zdarzenie. W przypadku aktywatora Cloud Storage filtr zdarzeń może mieć wartość bucket, w przypadku aktywatora Pub/Sub – topic itd.

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

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

W przypadku funkcji HTTP i funkcji wywoływanych zalecamy, aby najpierw ustawić funkcję na region docelowy lub w miejscu, w którym znajdują się najbardziej spodziewani klienci, a następnie zmodyfikować pierwotną funkcję, aby przekierowywała swoje żądanie HTTP do nowej funkcji (mogą one mieć taką samą nazwę). Jeśli klienty Twojej funkcji HTTP obsługują przekierowania, możesz zmienić pierwotną funkcję, tak aby zwracała stan przekierowania HTTP (301) wraz z adresem URL nowej funkcji. Jeśli Twoje klienty nie obsługują przekierowań, możesz zastąpić żądanie z funkcji oryginalnej do nowej, inicjując nowe żądanie z funkcji oryginalnej do nowej. Ostatnim krokiem jest sprawdzenie, czy wszyscy klienci wywołują nową funkcję.

Wybór lokalizacji po stronie klienta na potrzeby funkcji wywoływanych

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

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

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ą semantyczną metodę dostarczania zdarzeń co najmniej raz, co oznacza, że w pewnych okolicznościach mogą występować zduplikowane zdarzenia. Dlatego warto zaimplementować funkcje, by były idempotentne. Jeśli Twoja funkcja ma już idempotentność, możesz ponownie wdrożyć ją w nowym regionie z tym samym aktywatorem zdarzeń i usunąć starą po sprawdzeniu, czy nowa funkcja prawidłowo odbiera ruch. W tym okresie obie funkcje będą otrzymywać zdarzenia. W sekcji Zmiana regionu funkcji znajdziesz zalecaną sekwencję poleceń zmieniających regiony dla funkcji.

Jeśli funkcja nie jest obecnie idempotentna lub jej idempotentność nie wykracza poza region, zalecamy, aby najpierw wdrożyć mechanizm idempotentności, zanim przeniesiesz funkcję.

Rekomendacje dotyczące optymalnych regionów 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 rozliczeń mogą być większe.

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