Lokalizacje Cloud Functions

Cloud Functions działa regionalnie, co oznacza, że infrastruktura umożliwiająca uruchamianie funkcji znajduje się w określonych regionach i jest zarządzana przez Google, aby zapewnić redundantną dostępność we wszystkich strefach w tych regionach.

Przy wyborze regionów, w których mają być uruchamiane funkcje, należy przede wszystkim wziąć pod uwagę czas oczekiwania i dostępność. Zazwyczaj możesz wybrać regiony znajdujące się blisko użytkowników, ale musisz też uwzględnić lokalizację innych usług i produktów , z których korzysta Twoja aplikacja. Korzystanie z usług w wielu regionach może wpłynąć na czas oczekiwania w aplikacji oraz na ceny.

Domyślnie wiersz poleceń Firebase wdraża funkcje w regionie na podstawie konfiguracji projektu. W przypadku funkcji opartych na zdarzeniach zwykle wdraża je w regionie źródła danych wywołującego (np. bazy danych Cloud Firestore lub Cloud Storage zasobnika), a w razie potrzeby wdraża je 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 go zmienić.

Obsługiwane regiony

Na listach w tej sekcji ikona energy_savings_leaf oznacza, ż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.

Ceny na poziomie 1

Cloud Functions jest dostępny w tych regionach z cenami na poziomie 1:

Ceny na poziomie 2

Cloud Functions jest dostępny w tych regionach z cenami na poziomie 2:

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

Sprawdzone metody określania regionu

Domyślnie wiersz poleceń Firebase wdraża funkcje w regionie na podstawie konfiguracji projektu. W przypadku funkcji opartych na zdarzeniach zwykle wdraża je w regionie źródła danych wywołującego (np. bazy danych Cloud Firestore lub Cloud Storage zasobnika), a w razie potrzeby wdraża je w regionie us-central1.

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

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

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ć kilka regionów, przekazując w parametrze region kilka ciągów znaków z nazwami regionów oddzielonych przecinkami. Pamiętaj też, że podczas określania regionu 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 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 artykule Zmienianie regionu funkcji.

Funkcje HTTP i funkcje wywoływane przez klienta

W przypadku funkcji HTTP i funkcji wywoływanych zalecamy najpierw ustawienie funkcji w regionie docelowym lub w regionie najbliższym lokalizacji większości oczekiwanych klientów, a następnie zmianę oryginalnej funkcji tak, aby przekierowywała żądania HTTP do nowej funkcji (mogą mieć tę samą nazwę). Jeśli klienci funkcji HTTP obsługują przekierowania, możesz po prostu zmienić oryginalną funkcję tak, aby zwracała stan przekierowania HTTP (301) wraz z adresem URL nowej funkcji. Jeśli klienci nie obsługują dobrze przekierowań, możesz przekierować żądanie z oryginalnej funkcji do nowej, inicjując nowe żądanie z oryginalnej 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ływanych

W przypadku funkcji wywoływanych konfiguracje wywoływane 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 po stronie klienta, określ żądany 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 stosują semantykę dostarczania zdarzeń co najmniej raz, co oznacza, że w pewnych okolicznościach mogą otrzymywać zduplikowane zdarzenia. Dlatego należy zaimplementować funkcje tak, aby były idempotentne. Jeśli funkcja jest już idempotentna, możesz wdrożyć ponownie funkcję w nowym regionie z tym samym aktywatorem zdarzeń i usunąć starą funkcję po sprawdzeniu, czy nowa funkcja prawidłowo odbiera ruch. Podczas tego przejścia obie funkcje będą otrzymywać zdarzenia. Zalecaną kolejność poleceń do zmiany regionów funkcji znajdziesz w artykule Zmienianie regionu funkcji.

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

Optymalne rekomendacje dotyczące regionów różnią się w zależności od typu aktywatora zdarzeń:

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

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

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

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