מיקומים של Cloud Functions

Cloud Functions היא אזורית, כלומר התשתית שמפעילה את נמצאים באזורים ספציפיים ומנוהלת על ידי Google זמינות יותר מדי בכל כל האזורים בתוך האזורים האלה.

כשבוחרים את האזורים שבהם רוצים להריץ את הפונקציות, השיקולים צריכים להיות זמן אחזור וזמינות. אפשר בדרך כלל לבחור אזורים שקרובים למשתמשים, צריך לקחת בחשבון גם את המיקום מוצרים ושירותים אחרים שהאפליקציה שלכם משתמשת בהם. שימוש בשירותים במספר אזורים יכול להשפיע את זמן האחזור של האפליקציה, וגם את התמחור.

כברירת מחדל, הפונקציות פועלות באזור us-central1. חשוב לזכור שהאזור הזה עשוי להיות שונה מהאזור של מקור האירוע, כמו קטגוריה Cloud Storage. בעזרת הקישור הבא אפשר מציינים את האזור שבו פונקציה פועלת בהמשך הדף הזה.

אזורים נתמכים

ברשימות בקטע הזה, עלה_חיסכון_באנרגיה מציין שהחשמל באזור הזה מופק עם פליטות פחמן נמוכות. מידע נוסף זמין במאמר הבא: אנרגיה נטולת פחמן באזורים של Google Cloud.

השירות Cloud Functions זמין באזורים הבאים עם תמחור ברמה 1:

• asia-east1 (טייוואן)
• asia-east2 (הונג קונג) דור ראשון בלבד
• asia-northeast1 (טוקיו)
• asia-northeast2 (אוסקה)
• europe-north1 (פינלנד) energy_savings_leaf דור שני בלבד
• europe-west1 (בלגיה) עלה_חיסכון_באנרגיה
• europe-west2 (לונדון) דור ראשון בלבד
• us-central1 (איווה) עלה_חיסכון_באנרגיה
• us-east1 (דרום קרוליינה)
• us-east4 (וירג'יניה הצפונית)
• us-west1 (אורגון) עלה_חיסכון_באנרגיה

השירות Cloud Functions זמין באזורים הבאים עם תמחור ברמה 2:

• asia-east2 (הונג קונג) דור שני בלבד
• asia-northeast3 (סיאול)
• asia-southeast1 (סינגפור)
• asia-southeast2 (ג'קרטה)
• asia-south1 (מומבאי) דור שני בלבד
• australia-southeast1 (סידני)
• australia-southeast2 (מלבורן) דור שני בלבד
• europe-central2 (ורשה)
• europe-west2 (לונדון) דור שני בלבד
• europe-west3 (פרנקפורט)
• europe-west6 (ציריך) עלה_חיסכון_באנרגיה
• northamerica-northeast1 (מונטריאול) עלה_חיסכון_באנרגיה
• northamerica-northeast2 (טורונטו) עלה_חיסכון_באנרגיה דור שני בלבד
• southamerica-east1 (סאו פאולו) energy_savings_leaf
• southamerica-west1 (סנטיאגו, צ'ילה) דור שני בלבד
• us-west2 (לוס אנג'לס)
• us-west3 (סולט לייק סיטי)
• us-west4 (לאס וגאס)

הפונקציות באזור נתון בפרויקט מסוים חייבות להיות ייחודיות שמות לא רגישים), אבל פונקציות שונות באזורים או בפרויקטים שונים עשויות לשתף אותו שם.

שיטות מומלצות לציון אזור

כברירת מחדל, הפונקציות פועלות באזור us-central1. לתשומת ליבכם: שונה מהאזור של מקור אירוע, כמו קטגוריה של Cloud Storage. אם המיקום צריך לציין את האזור שבו פונקציה פועלת, מזינים את בקטע הזה לכל סוג טריגר של פונקציה.

כדי להגדיר את האזור שבו פונקציה פועלת, מגדירים את הפרמטר region בשדה הגדרת הפונקציה כפי שמוצג כאן:

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

אפשר לציין כמה אזורים על ידי העברת כמה אזורים שמופרדים בפסיקים מחרוזות ב-region. כמו כן, כשמציינים אזור של סוגי הטריגרים ברקע, צריך לציין את מסנן האירועים הנכון וגם האזור. בדוגמה שלמעלה, זהו ה-Cloud Firestore document שמפיק את האירוע. עבור טריגר Cloud Storage, מסנן האירועים יכול להיות bucket; עבור טריגר של Pub/Sub זה יהיה topic, וכן הלאה.

צפייה שינוי אזור של פונקציה למידע נוסף על שינוי האזור של פונקציה שמטפלת התנועה בסביבת הייצור.

פונקציות HTTP ופונקציות קריאה ללקוח

עבור פונקציות HTTP ופונקציות קריאה, מומלץ להגדיר קודם את הפונקציה את אזור היעד, או את המיקום הקרוב ביותר למיקום שבו נמצאים רוב הלקוחות הצפויים, וכן לאחר מכן לשנות את הפונקציה המקורית כדי להפנות את בקשת ה-HTTP שלה (הם יכולים להיות בעלי אותו שם). אם הלקוחות של פונקציית ה-HTTP תומכים אפשר פשוט לשנות את הפונקציה המקורית ולהחזיר ההפניה האוטומטית (301) יחד עם כתובת ה-URL של הפונקציה החדשה. אם הלקוחות שלכם לא מטפלים היטב בהפניות אוטומטיות, אפשר שרת proxy לבקשה מהמקור בפונקציה החדשה, על ידי שליחת בקשה חדשה מהמקור בפונקציה החדשה. השלב האחרון הוא לוודא שכל הלקוחות קריאה לפונקציה החדשה.

בחירת מיקום בצד הלקוח לפונקציות קריאה

לגבי הפונקציה שניתנת לקריאה, ההגדרות של לקוחות שניתנות לקריאה צריכות להיות זהות בתור פונקציות HTTP. הלקוח יכול גם לציין אזור, חובה לעשות זאת אם הפונקציה פועלת בכל אזור שאינו us-central1.

כדי להגדיר אזורים בלקוח, מציינים את האזור הרצוי בזמן האתחול:

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

פונקציות ברקע

פונקציות רקע משתמשות בסמנטיקה של העברת אירוע לפחות פעם אחת. כלומר, שבנסיבות מסוימות הם עשויים לקבל אירועים כפולים. לכן, אתם צריכים להטמיע פונקציות כדי אידמפוטנטית. אם הפונקציה כבר אידמפוטנטית, תוכלו לפרוס מחדש את הפונקציה באזור החדש עם אותו טריגר אירוע ומסירים את הפונקציה הישנה אחרי שמוודאים הפונקציה החדשה מקבלת תנועה באופן תקין. במהלך המעבר, שתי הפונקציות יקבלו אירועים. צפייה שינוי אזור של פונקציה לרצף הפקודות המומלץ לשינוי אזורים בפונקציות.

אם הפונקציה לא אידמפוטנטית כרגע, או שהאידמפוטנטיות שלה לא מתרחבות אל מעבר לאזור, ולכן מומלץ ליישם תחילה אידמפוטנטיות לפני העברת הפונקציה.

ההמלצות לאזורים אופטימליים משתנות בהתאם לסוג הטריגר של האירוע:

בחירת אזורים על סמך המיקומים Cloud Firestore ו-Cloud Storage

האזורים הזמינים לפונקציות לא תמיד תואמים במדויק האזורים הזמינים למסד הנתונים שלך ל-Cloud Firestore ול-Cloud Storage קטגוריות.

חשוב לשים לב שאם הפונקציה והמשאב שלך (מופע של מסד נתונים או Cloud Storage) ) במיקומים שונים, ייתכן שתיתקלו זמן אחזור ארוך עלויות חיוב.

הנה מיפוי של האזורים הקרובים ביותר שבהם יש תמיכה בפונקציות ב-Cloud Firestore וגם Cloud Storage, במקרים שבהם אין תמיכה באותו אזור: