מיקומים של Cloud Functions

‫Cloud Functions הוא שירות אזורי, כלומר התשתית שמריצה את הפונקציה נמצאת באזורים ספציפיים, ו-Google מנהלת אותה כך שתהיה זמינה באופן יתיר בכל האזורים האלה.

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

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

אחרי הפריסה, אפשר לאמת את האזור במסוף Firebase או על ידי הפעלת firebase functions:list. אם רוצים שהפונקציה תפעל באזור אחר, אפשר לשנות את האזור שלה.

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

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

תמחור ברמה 1

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

תמחור ברמה 2

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

לפונקציות באזור מסוים בפרויקט מסוים צריכים להיות שמות ייחודיים (לא תלויי-רישיות), אבל לפונקציות באזורים שונים או בפרויקטים שונים יכולים להיות שמות זהים.

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

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

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

כדי להגדיר את האזור שבו הפונקציה פועלת, מגדירים את הפרמטר 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 תומכים בהפניות אוטומטיות, אתם יכולים פשוט לשנות את הפונקציה המקורית כך שתחזיר סטטוס הפניה אוטומטית של HTTP ‏ (301) יחד עם כתובת ה-URL של הפונקציה החדשה. אם הלקוחות שלכם לא מטפלים היטב בהפניות אוטומטיות, אתם יכולים להעביר את הבקשה מהפונקציה המקורית לפונקציה החדשה באמצעות שרת proxy, על ידי הפעלת בקשה חדשה מהפונקציה המקורית לפונקציה החדשה. השלב האחרון הוא לוודא שכל הלקוחות קוראים לפונקציה החדשה.

בחירת מיקום בצד הלקוח לפונקציות שניתן להפעיל

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

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

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, למקרים שבהם אותו אזור לא נתמך: