Cloud Functions की जगहें

Cloud Functions एक क्षेत्रीय सेवा है. इसका मतलब है कि आपके फ़ंक्शन को चलाने वाला इन्फ़्रास्ट्रक्चर, कुछ खास क्षेत्रों में मौजूद है. साथ ही, Google इसे मैनेज करता है, ताकि यह उन क्षेत्रों के सभी ज़ोन में उपलब्ध रहे.

फ़ंक्शन चलाने के लिए इलाके चुनते समय, आपको मुख्य तौर पर इन बातों का ध्यान रखना चाहिए: लेटेन्सी और उपलब्धता. आम तौर पर, अपने उपयोगकर्ताओं के आस-पास के इलाके चुने जा सकते हैं. हालांकि, आपको उन अन्य प्रॉडक्ट और सेवाओं की जगह की जानकारी भी ध्यान में रखनी चाहिए जिनका इस्तेमाल आपका ऐप्लिकेशन करता है. एक से ज़्यादा क्षेत्रों में सेवाओं का इस्तेमाल करने से, आपके ऐप्लिकेशन की लेटेन्सी और कीमत पर असर पड़ सकता है.

डिफ़ॉल्ट रूप से, फ़ंक्शन us-central1 क्षेत्र में चलते हैं. ध्यान दें कि यह Cloud Storage बकेट जैसे इवेंट सोर्स के क्षेत्र से अलग हो सकता है. इस पेज पर आगे, उस इलाके के बारे में बताने का तरीका जानें जहां फ़ंक्शन काम करता है.

इन देशों और इलाकों में मान्य है

इस सेक्शन में दी गई सूचियों में, energy_savings_leaf आइकॉन से पता चलता है कि इस इलाके के लिए बिजली का उत्पादन, कम कार्बन उत्सर्जन के साथ किया जाता है. ज़्यादा जानकारी के लिए, Google Cloud क्षेत्रों के लिए कार्बन का उत्सर्जन न करने वाली ऊर्जा लेख पढ़ें.

टियर 1 की कीमत

Cloud Functions इन देशों/इलाकों में टियर 1 की कीमत पर उपलब्ध है:

क्षेत्र	जगह	प्रॉडक्ट के इस्तेमाल किए जा सकने वाले वर्शन	CO2 उत्सर्जन
africa-south1	जोहानेसबर्ग	सिर्फ़ दूसरी जनरेशन
asia-east1	ताइवान	पहली पीढ़ी, दूसरी पीढ़ी
asia-east2	हॉन्ग कॉन्ग	सिर्फ़ पहली जनरेशन के लिए
asia-northeast1	टोक्यो	पहली पीढ़ी, दूसरी पीढ़ी
asia-northeast2	ओसाका	पहली पीढ़ी, दूसरी पीढ़ी
europe-north1	फ़िनलैंड	सिर्फ़ दूसरी जनरेशन	energy_savings_leaf
europe-southwest1	मैड्रिड	सिर्फ़ दूसरी जनरेशन
europe-west1	बेल्जियम	पहली पीढ़ी, दूसरी पीढ़ी	energy_savings_leaf
europe-west4	नीदरलैंड्स	सिर्फ़ दूसरी जनरेशन
europe-west8	मिलान	सिर्फ़ दूसरी जनरेशन
europe-west9	पेरिस	सिर्फ़ दूसरी जनरेशन	energy_savings_leaf
me-west1	तेल अवीव	सिर्फ़ दूसरी जनरेशन
europe-west2	लंदन	सिर्फ़ पहली जनरेशन के लिए
us-central1	आयोवा	पहली पीढ़ी, दूसरी पीढ़ी	energy_savings_leaf
us-east1	दक्षिण कैरोलाइना	पहली पीढ़ी, दूसरी पीढ़ी
us-east4	उत्तरी वर्जीनिया	पहली पीढ़ी, दूसरी पीढ़ी
us-east5	कोलंबस	सिर्फ़ दूसरी जनरेशन
us-south1	डैलस	सिर्फ़ दूसरी जनरेशन
us-west1	ओरेगन	पहली पीढ़ी, दूसरी पीढ़ी	energy_savings_leaf

टियर 2 की कीमत

Cloud Functions इन देशों/इलाकों में टीयर 2 की कीमत पर उपलब्ध है:

क्षेत्र	जगह	प्रॉडक्ट के इस्तेमाल किए जा सकने वाले वर्शन	CO2 उत्सर्जन
asia-east2	हॉन्ग कॉन्ग	सिर्फ़ दूसरी जनरेशन
asia-northeast3	सोल	पहली पीढ़ी, दूसरी पीढ़ी
asia-southeast1	सिंगापुर	पहली पीढ़ी, दूसरी पीढ़ी
asia-southeast2	जकार्ता	पहली पीढ़ी, दूसरी पीढ़ी
asia-south1	मुंबई	सिर्फ़ दूसरी जनरेशन
asia-south2	दिल्ली, भारत	सिर्फ़ दूसरी जनरेशन
australia-southeast1	सिडनी	पहली पीढ़ी, दूसरी पीढ़ी
australia-southeast2	मेलबर्न	सिर्फ़ दूसरी जनरेशन
europe-central2	वॉरसॉ	पहली पीढ़ी, दूसरी पीढ़ी
europe-west2	लंदन	सिर्फ़ दूसरी जनरेशन
europe-west3	फ़्रैंकफ़र्ट	पहली पीढ़ी, दूसरी पीढ़ी	energy_savings_leaf
europe-west6	ज़्यूरिख़	पहली पीढ़ी, दूसरी पीढ़ी	energy_savings_leaf
europe-west10	बर्लिन	सिर्फ़ दूसरी जनरेशन
europe-west12	टूरीन	सिर्फ़ दूसरी जनरेशन
me-central1	दोहा	सिर्फ़ दूसरी जनरेशन
me-central2	दम्माम	सिर्फ़ दूसरी जनरेशन
northamerica-northeast1	मॉन्ट्रियल	पहली पीढ़ी, दूसरी पीढ़ी	energy_savings_leaf
northamerica-northeast2	टोरंटो	सिर्फ़ दूसरी जनरेशन	energy_savings_leaf
southamerica-east1	साओ पौलो	पहली पीढ़ी, दूसरी पीढ़ी	energy_savings_leaf
southamerica-west1	सैंटियागो, चिली	सिर्फ़ दूसरी जनरेशन
us-west2	लॉस एंजेलिस	पहली पीढ़ी, दूसरी पीढ़ी
us-west3	सॉल्ट लेक सिटी	पहली पीढ़ी, दूसरी पीढ़ी
us-west4	लास वेगस	पहली पीढ़ी, दूसरी पीढ़ी

किसी प्रोजेक्ट के किसी क्षेत्र में मौजूद फ़ंक्शन के नाम, केस-सेंसिटिव (बड़े और छोटे अक्षरों में अंतर) नहीं होने चाहिए. हालांकि, अलग-अलग क्षेत्रों या प्रोजेक्ट में मौजूद फ़ंक्शन के नाम एक जैसे हो सकते हैं.

किसी क्षेत्र की जानकारी देने के सबसे सही तरीके

डिफ़ॉल्ट रूप से, फ़ंक्शन us-central1 क्षेत्र में चलते हैं. ध्यान दें कि यह Cloud Storage बकेट जैसे इवेंट सोर्स के क्षेत्र से अलग हो सकता है. अगर आपको उस इलाके के बारे में बताना है जहां कोई फ़ंक्शन चलता है, तो हर फ़ंक्शन ट्रिगर टाइप के लिए, इस सेक्शन में दिए गए सुझावों का पालन करें.

किसी फ़ंक्शन के चलने की जगह सेट करने के लिए, फ़ंक्शन की परिभाषा में region पैरामीटर को इस तरह सेट करें:

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 में कॉमा लगाकर अलग की गई कई क्षेत्र की स्ट्रिंग पास करके, एक से ज़्यादा क्षेत्र तय किए जा सकते हैं. यह भी ध्यान दें कि कई बैकग्राउंड ट्रिगर टाइप के लिए क्षेत्र तय करते समय, आपको क्षेत्र के साथ-साथ सही इवेंट फ़िल्टर भी तय करना होगा. ऊपर दिए गए उदाहरण में, Cloud Firestore document इवेंट को ट्रिगर करता है. Cloud Storage ट्रिगर के लिए, इवेंट फ़िल्टर bucket हो सकता है. Pub/Sub ट्रिगर के लिए, यह topic होगा. इसी तरह, अन्य ट्रिगर के लिए भी इवेंट फ़िल्टर अलग-अलग होंगे.

प्रोडक्शन ट्रैफ़िक को मैनेज करने वाले फ़ंक्शन के लिए क्षेत्र बदलने के बारे में ज़्यादा जानने के लिए, किसी फ़ंक्शन का क्षेत्र बदलना लेख पढ़ें.

एचटीटीपी और क्लाइंट-कॉल किए जा सकने वाले फ़ंक्शन

एचटीटीपी और कॉल किए जा सकने वाले फ़ंक्शन के लिए, हमारा सुझाव है कि आप पहले अपने फ़ंक्शन को डेस्टिनेशन क्षेत्र में सेट करें. इसके अलावा, आप इसे उस जगह के सबसे करीब सेट करें जहां ज़्यादातर संभावित ग्राहक मौजूद हैं. इसके बाद, अपने ओरिजनल फ़ंक्शन में बदलाव करके, उसके एचटीटीपी अनुरोध को नए फ़ंक्शन पर रीडायरेक्ट करें. इन दोनों फ़ंक्शन का नाम एक जैसा हो सकता है. अगर आपके एचटीटीपी फ़ंक्शन के क्लाइंट, रीडायरेक्ट करने की सुविधा के साथ काम करते हैं, तो अपने ओरिजनल फ़ंक्शन को बदलकर, एचटीटीपी रीडायरेक्ट स्टेटस (301) दिखाएं. साथ ही, अपने नए फ़ंक्शन का यूआरएल भी दिखाएं. अगर आपके क्लाइंट, रीडायरेक्ट को अच्छी तरह से हैंडल नहीं करते हैं, तो ओरिजनल फ़ंक्शन से नए फ़ंक्शन पर नया अनुरोध करके, अनुरोध को प्रॉक्सी किया जा सकता है. आखिरी चरण में, यह पक्का करना होता है कि सभी क्लाइंट नए फ़ंक्शन को कॉल कर रहे हों.

कॉल किए जा सकने वाले फ़ंक्शन के लिए, क्लाइंट-साइड पर जगह की जानकारी चुनने की सुविधा

कॉल किए जा सकने वाले फ़ंक्शन के लिए, क्लाइंट से कॉल किए जा सकने वाले सेटअप को एचटीटीपी फ़ंक्शन के लिए बनी गाइडलाइन का पालन करना चाहिए. क्लाइंट, क्षेत्र की जानकारी भी दे सकता है. अगर फ़ंक्शन us-central1 के अलावा किसी अन्य क्षेत्र में चलता है, तो क्लाइंट को यह जानकारी ज़रूर देनी चाहिए.

क्लाइंट पर क्षेत्र सेट करने के लिए, शुरुआत में ही मनचाहा क्षेत्र तय करें:

Swift

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

Objective-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");

Unity

firebase.Functions.FirebaseFunctions functions;

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

बैकग्राउंड फ़ंक्शन

बैकग्राउंड फ़ंक्शन, इवेंट को कम से कम एक बार डिलीवर करने के सिमैंटिक का इस्तेमाल करते हैं. इसका मतलब है कि कुछ मामलों में, उन्हें डुप्लीकेट इवेंट मिल सकते हैं. इसलिए, आपको ऐसे फ़ंक्शन लागू करने चाहिए जो आईडम्पोटेंट हों. अगर आपका फ़ंक्शन पहले से ही आइडेमपोटेंट है, तो उसे नए क्षेत्र में फिर से डिप्लॉय किया जा सकता है. इसके लिए, उसी इवेंट ट्रिगर का इस्तेमाल करें. साथ ही, यह पुष्टि करने के बाद कि नए फ़ंक्शन को सही तरीके से ट्रैफ़िक मिल रहा है, पुराने फ़ंक्शन को हटा दें. इस बदलाव के दौरान, दोनों फ़ंक्शन को इवेंट मिलेंगे. फ़ंक्शन के लिए क्षेत्र बदलने के लिए, कमांड का सुझाया गया क्रम जानने के लिए, किसी फ़ंक्शन के क्षेत्र में बदलाव करना लेख पढ़ें.

अगर आपका फ़ंक्शन फ़िलहाल आइडेमपोटेंट नहीं है या इसका आइडेमपोटेंसी, क्षेत्र से आगे नहीं बढ़ता है, तो हमारा सुझाव है कि आप फ़ंक्शन को ट्रांसफ़र करने से पहले, आइडेमपोटेंसी लागू करें.

इवेंट ट्रिगर टाइप के हिसाब से, सबसे सही क्षेत्र के सुझाव अलग-अलग होते हैं:

ट्रिगर का प्रकार	इलाके के हिसाब से सुझाव
Cloud Firestore	Cloud Firestore इंस्टेंस की जगह के सबसे पास का इलाका (अगला सेक्शन देखें)
Realtime Database	Realtime Database इंस्टेंस वाला इलाका
Cloud Storage	Cloud Storage बकेट की जगह की जानकारी के हिसाब से सबसे नज़दीकी क्षेत्र (अगला सेक्शन देखें)
अन्य	अगर फ़ंक्शन के अंदर Realtime Database इंस्टेंस, Cloud Firestore इंस्टेंस या Cloud Storage बकेट के साथ इंटरैक्ट किया जा रहा है, तो सुझाया गया क्षेत्र वही होगा जो इन संसाधनों में से किसी एक से ट्रिगर किए गए फ़ंक्शन के लिए होता है. ऐसा न होने पर, us-central1 के डिफ़ॉल्ट क्षेत्र का इस्तेमाल करें. Firebase Hosting से कनेक्ट किए गए फ़ंक्शन किसी भी इलाके में हो सकते हैं. हालांकि, सुझावों के लिए होस्टिंग सर्वरलेस की खास जानकारी देखें.

Cloud Firestore और Cloud Storage जगहों के आधार पर इलाके चुनना

ऐसा हो सकता है कि फ़ंक्शन के लिए उपलब्ध क्षेत्र, आपके Cloud Firestore डेटाबेस और Cloud Storage बकेट के लिए उपलब्ध क्षेत्रों से पूरी तरह मेल न खाएं.

ध्यान दें कि अगर आपका फ़ंक्शन और संसाधन (डेटाबेस इंस्टेंस या Cloud Storage बकेट) अलग-अलग जगहों पर हैं, तो आपको लेटेन्सी बढ़ने और बिलिंग की लागत बढ़ने की समस्या हो सकती है.

यहां Cloud Firestore और Cloud Storage के लिए, उन इलाकों की मैपिंग दी गई है जहां ये फ़ंक्शन काम करते हैं. ऐसा उन मामलों में किया गया है जहां एक ही इलाके में ये फ़ंक्शन काम नहीं करते:

Cloud Firestore और Cloud Storage के लिए क्षेत्र/एक से ज़्यादा क्षेत्र	फ़ंक्शन के लिए सबसे नज़दीकी क्षेत्र
nam5 या us-central (एक से ज़्यादा इलाके)	us-central1
eur3 या europe-west (एक से ज़्यादा इलाके)	europe-west1
europe-west4 (नीदरलैंड्स)	europe-west1
asia-south1 (मुंबई)	asia-east2
asia-south2 (दिल्ली)	asia-east2
australia-southeast2 (मेलबर्न)	australia-southeast1