Bulut İşlevleri konumları

Bulut İşlevleri bölgeseldir ; bu, Bulut İşlevinizi çalıştıran altyapının belirli bölgelerde bulunduğu ve bu bölgelerdeki tüm bölgelerde yedekli olarak kullanılabilir olacak şekilde Google tarafından yönetildiği anlamına gelir.

İşlevlerinizi hangi bölgelerde çalıştıracağınızı seçerken öncelikli dikkate almanız gereken hususlar gecikme ve kullanılabilirlik olmalıdır. Genel olarak kullanıcılarınıza yakın bölgeleri seçebilirsiniz ancak uygulamanızın kullandığı diğer ürün ve hizmetlerin konumunu da göz önünde bulundurmalısınız. Hizmetlerin birden fazla bölgede kullanılması, uygulamanızın gecikmesinin yanı sıra fiyatlandırmasını da etkileyebilir.

Desteklenen bölgeler

Bu bölümdeki listelerde enerji_tasarruf_yaprağı simgesi bu bölge için elektriğin düşük karbon emisyonuyla üretildiğini belirtmektedir. Daha fazla bilgi için bkz. Google Cloud bölgeleri için karbonsuz enerji .

Cloud Functions, aşağıdaki bölgelerde 1. Kademe fiyatlandırmayla sunulmaktadır:

  • asia-east1 (Tayvan)
  • asia-east2 (Hong Kong) yalnızca 1. nesil
  • asia-northeast1 (Tokyo)
  • asia-northeast2 (Osaka)
  • europe-north1 (Finlandiya) enerji_tasarrufu_leaf yalnızca 2. nesil
  • europe-west1 (Belçika) enerji_tasarrufu_leaf
  • europe-west2 (Londra) yalnızca 1. nesil
  • us-central1 (Iowa) enerji_tasarrufu_leaf
  • us-east1 (Güney Carolina)
  • us-east4 (Kuzey Virginia)
  • us-west1 (Oregon) enerji_tasarrufu_leaf

Cloud Functions, aşağıdaki bölgelerde Katman 2 fiyatlandırmasıyla kullanılabilir:

  • asia-east2 (Hong Kong) yalnızca 2. nesil
  • asia-northeast3 (Seul)
  • asia-southeast1 (Singapur)
  • asia-southeast2 (Cakarta)
  • asia-south1 (Mumbai) yalnızca 2. nesil
  • australia-southeast1 (Sidney)
  • australia-southeast2 (Melbourne) yalnızca 2. nesil
  • europe-central2 (Varşova)
  • europe-west2 (Londra) yalnızca 2. nesil
  • europe-west3 (Frankfurt)
  • europe-west6 (Zürih) enerji_tasarrufu_leaf
  • northamerica-northeast1 (Montreal) enerji_tasarrufu_leaf
  • northamerica-northeast2 (Toronto) Energy_Saves_leaf Yalnızca 2. nesil
  • southamerica-east1 (Sao Paulo) enerji_tasarrufu_leaf
  • southamerica-west1 (Santiago, Şili) yalnızca 2. nesil
  • us-west2 (Los Angeles)
  • us-west3 (Salt Lake City)
  • us-west4 (Las Vegas)

Belirli bir projedeki belirli bir bölgedeki işlevlerin benzersiz (büyük/küçük harfe duyarlı olmayan) adları olmalıdır, ancak bölgeler veya projeler arasındaki işlevler aynı adı paylaşabilir.

Bölge belirtmeye yönelik en iyi uygulamalar

Varsayılan olarak işlevler us-central1 bölgesinde çalışır. Bunun, Cloud Storage paketi gibi bir olay kaynağının bölgesinden farklı olabileceğini unutmayın. Bir işlevin çalıştığı bölgeyi belirtmeniz gerekiyorsa her işlev tetikleyici türü için bu bölümdeki önerileri izleyin.

Bir fonksiyonun çalıştığı bölgeyi ayarlamak için fonksiyon tanımındaki region parametresini gösterildiği gibi ayarlayın:

Node.js

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

Python

# 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

region içinde virgülle ayrılmış birden çok bölge dizesi ileterek birden çok bölge belirtebilirsiniz. Ayrıca, birçok arka plan tetikleyici türü için bir bölge belirlerken bölgeyle birlikte doğru olay filtresini de belirtmeniz gerekeceğini unutmayın. Yukarıdaki örnekte bu, olayı yayınlayan Cloud Firestore document . Cloud Storage tetikleyicisi için etkinlik filtresi bucket olabilir; Pub/Sub tetikleyicisi için bu, topic vb. olacaktır.

Üretim trafiğini yöneten bir işlevin bölgesini değiştirme hakkında daha fazla bilgi için bkz. işlevin bölgesini değiştirme .

HTTP ve istemci tarafından çağrılabilen işlevler

HTTP ve çağrılabilir işlevler için, öncelikle işlevinizi hedef bölgeye veya en çok beklenen müşterilerin bulunduğu yere en yakın yere ayarlamanızı ve ardından orijinal işlevinizi, HTTP isteğini yeni işleve yönlendirecek şekilde değiştirmenizi öneririz (aynı işleve sahip olabilirler). isim). HTTP işlevinizin istemcileri yönlendirmeleri destekliyorsa, orijinal işlevinizi, yeni işlevinizin URL'siyle birlikte bir HTTP yönlendirme durumu (301) döndürecek şekilde değiştirebilirsiniz. İstemcileriniz yönlendirmeleri iyi yönetemiyorsa, orijinal işlevden yeni işleve yeni bir istek başlatarak orijinal işlevden gelen isteği yeni işleve proxy olarak aktarabilirsiniz. Son adım, tüm istemcilerin yeni işlevi çağırdığından emin olmaktır.

Çağrılabilir işlevler için istemci tarafı konum seçimi

Çağrılabilir işlevle ilgili olarak, istemcinin çağrılabilir kurulumları, HTTP işlevleriyle aynı yönergeleri izlemelidir. İstemci ayrıca bir bölge de belirtebilir ve eğer işlev us-central1 dışında herhangi bir bölgede çalışıyorsa bunu yapmalıdır .

İstemcide bölgeleri ayarlamak için başlatma sırasında istediğiniz bölgeyi belirtin:

Süratli

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

Amaç-C

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


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

Android

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

C++

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

Birlik

firebase.Functions.FirebaseFunctions functions;

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

Arka plan işlevleri

Arka plan işlevleri, en az bir kez olay teslimi semantiğini benimser; bu, bazı durumlarda yinelenen olaylar alabilecekleri anlamına gelir. Bu nedenle, idempotent olacak işlevleri uygulamanız gerekir. İşleviniz zaten bağımsızsa, aynı olay tetikleyicisiyle işlevi yeni bölgede yeniden dağıtabilir ve yeni işlevin trafiği doğru şekilde aldığını doğruladıktan sonra eski işlevi kaldırabilirsiniz. Bu geçiş sırasında her iki işlev de olay alacaktır. İşlevlerin bölgelerini değiştirmeye yönelik önerilen komut sırası için bkz. işlevin bölgesini değiştirme .

İşleviniz şu anda idempotent değilse veya idempotentliği bölgenin dışına taşmıyorsa, işlevi taşımadan önce ilk olarak idempotency uygulamanızı öneririz.

En uygun bölge önerileri olay tetikleyici türüne göre farklılık gösterir:

Tetikleyici Türü Bölge Tavsiyesi
Bulut Firestore Cloud Firestore bulut sunucusu konumuna en yakın bölge (sonraki bölüme bakın)
Gerçek Zamanlı Veritabanı Daima us-central1
Bulut depolama Cloud Storage paketi konumuna en yakın bölge (sonraki bölüme bakın)
Diğerleri İşlev içindeki bir Gerçek Zamanlı Veritabanı örneğiyle, bir Cloud Firestore örneğiyle veya bir Cloud Storage paketiyle etkileşimde bulunuyorsanız önerilen bölge, bu kaynaklardan biri tarafından tetiklenen bir işleve sahipmişsiniz gibi olur. Aksi takdirde us-central1 varsayılan bölgesini kullanın. Firebase Hosting'e bağlı işlevler herhangi bir bölgede olabilir ancak öneriler için sunucusuz barındırma genel bakışına bakın.

Cloud Firestore ve Cloud Storage konumlarına göre bölgeleri seçme

İşlevler için mevcut bölgeler, Cloud Firestore veritabanınız ve Cloud Storage gruplarınız için mevcut olan bölgelerle her zaman tam olarak eşleşmez.

İşleviniz ve kaynağınız (veritabanı örneği veya Cloud Storage paketi) farklı konumlardaysa gecikme ve faturalandırma maliyetlerinde artışla karşılaşabileceğinizi unutmayın.

Aynı bölgenin desteklenmediği durumlar için Cloud Firestore ve Cloud Storage için en yakın işlevlerin desteklediği bölgelerin haritasını burada bulabilirsiniz:

Cloud Firestore ve Cloud Storage için Bölge/Çoklu Bölge İşlevler için en yakın bölge
nam5 veya us-central (çoklu bölge) us-central1
eur3 veya europe-west (çoklu bölge) europe-west1
europe-west4 (Hollanda) europe-west1
asia-south1 (Mumbai) asia-east2
asia-south2 (Delhi) asia-east2
australia-southeast2 (Melbourne) australia-southeast1