מיקומים של 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 של הפונקציה החדשה. אם הלקוחות לא מטפלים בהפניות בצורה טובה, אפשר להעביר את הבקשה מהפונקציה המקורית לפונקציה החדשה על ידי הפעלת בקשה חדשה מהפונקציה המקורית לפונקציה החדשה. השלב האחרון הוא לוודא שכל הלקוחות קוראים לפונקציה החדשה.

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

בנוגע לפונקציה שאפשר להפעיל, ההגדרות של פונקציות שאפשר להפעיל מלקוח צריכות להיות בהתאם לאותן הנחיות כמו פונקציות 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 bucket) נמצאים במיקומים שונים, יכול להיות שתהיה עלייה בחביון ובעלויות החיוב.

במקרים שבהם אזור מסוים לא נתמך, אפשר להיעזר במיפוי הבא כדי לראות אילו אזורים קרובים נתמכים עבור Cloud Firestore ו-Cloud Storage: