במסמך הזה מתוארות שיטות מומלצות לתכנון, להטמעה, לבדיקה ולפריסה של פונקציות Cloud Run.
נכונות
בקטע הזה מתוארות שיטות מומלצות כלליות לתכנון וליישום של פונקציות Cloud Run.
כתיבת פונקציות אידמפוטנטיות
הפונקציות צריכות להפיק את אותה תוצאה גם אם קוראים להן כמה פעמים. כך תוכלו לנסות שוב הפעלה אם ההפעלה הקודמת נכשלה באמצע הקוד. מידע נוסף זמין במאמר בנושא ניסיון חוזר של פונקציות מבוססות-אירועים.
מוודאים שפונקציות HTTP שולחות תגובת HTTP
אם הפונקציה מופעלת על ידי HTTP, חשוב לשלוח תגובת HTTP, כמו שמוצג בהמשך. אם לא תעשו את זה, הפונקציה תמשיך לפעול עד שתגיע לזמן הקצוב לתפוגה. במקרה כזה, תחויבו על כל משך הזמן של פסק הזמן. פסק זמן עלול גם לגרום להתנהגות בלתי צפויה או להפעלות קרות בקריאות הבאות, וכתוצאה מכך להתנהגות בלתי צפויה או לחביון נוסף.
Node.js
Python
Go
Java
C#
Ruby
PHP
לא להפעיל פעילויות ברקע
פעילות ברקע היא כל מה שקורה אחרי שהפונקציה מסתיימת.
הפעלת פונקציה מסתיימת כשהפונקציה מחזירה ערך או מסמנת שהיא הושלמה, למשל על ידי קריאה לארגומנט callback בפונקציות מבוססות-אירועים ב-Node.js. לכל קוד שיופעל אחרי סיום תקין לא תהיה גישה למעבד, והוא לא יתקדם.
בנוסף, כשמבצעים הפעלה עוקבת באותה סביבה, הפעילות ברקע ממשיכה ומשבשת את ההפעלה החדשה. הדבר עלול לגרום להתנהגות לא צפויה ולשגיאות שקשה לאבחן. גישה לרשת אחרי סיום הפונקציה מובילה בדרך כלל לאיפוס החיבורים (ECONNRESET קוד שגיאה).
לעתים קרובות אפשר לזהות פעילות ברקע ביומנים של קריאות נפרדות לפונקציה, על ידי חיפוש של כל מה שמתועד אחרי השורה שמציינת שהקריאה לפונקציה הסתיימה. לפעמים פעילות ברקע מוסתרת עמוק יותר בקוד, במיוחד כשקיימות פעולות אסינכרוניות כמו קריאות חוזרות או טיימרים. בודקים את הקוד כדי לוודא שכל הפעולות האסינכרוניות מסתיימות לפני שמסיימים את הפונקציה.
מחיקת קבצים זמניים תמיד
אחסון בדיסק מקומי בספרייה הזמנית הוא מערכת קבצים בזיכרון. קבצים שאתם כותבים צורכים זיכרון שזמין לפונקציה, ולפעמים נשמרים בין הפעלות. אם לא מוחקים את הקבצים האלה באופן מפורש, יכול להיות שבסופו של דבר תתקבל שגיאת חוסר זיכרון, ולאחר מכן יתבצע אתחול קר.
כדי לראות את הזיכרון שבו נעשה שימוש בפונקציה מסוימת, בוחרים אותה ברשימת הפונקציות בGoogle Cloud מסוף ובוחרים בתרשים Memory usage (שימוש בזיכרון).
אם אתם צריכים גישה לאחסון לטווח ארוך, כדאי להשתמש בהרכבות של נפחים ב-Cloud Run עם Cloud Storage או נפחי NFS.
כדי להקטין את דרישות הזיכרון כשמעבדים קבצים גדולים יותר, אפשר להשתמש בצינורות. לדוגמה, אפשר לעבד קובץ ב-Cloud Storage על ידי יצירת זרם קריאה, העברתו דרך תהליך מבוסס-זרם וכתיבת זרם הפלט ישירות ל-Cloud Storage.
Functions Framework
כדי לוודא שאותן תלויות מותקנות באופן עקבי בסביבות שונות, מומלץ לכלול את ספריית Functions Framework במנהל החבילות ולהצמיד את התלות לגרסה ספציפית של Functions Framework.
כדי לעשות את זה, צריך לכלול את הגרסה המועדפת בקובץ הנעילה הרלוונטי (לדוגמה, package-lock.json ל-Node.js או requirements.txt ל-Python).
אם Functions Framework לא מופיע במפורש כרכיב תלוי, הוא יתווסף אוטומטית במהלך תהליך הבנייה באמצעות הגרסה העדכנית ביותר שזמינה.
כלים
בקטע הזה מפורטות הנחיות לשימוש בכלים להטמעה, לבדיקה ולביצוע אינטראקציה עם פונקציות Cloud Run.
פיתוח מקומי
פריסת הפונקציה אורכת זמן, ולכן בדרך כלל מהר יותר לבדוק את הקוד של הפונקציה באופן מקומי.
דיווח על שגיאות
בשפות שמשתמשות בטיפול בחריגים, אל תפעילו חריגים שלא נתפסו, כי הם גורמים להפעלות במצב התחלתי (cold start) בהפעלות עתידיות.
לא יוצאים באופן ידני
יציאה ידנית עלולה לגרום להתנהגות לא צפויה. במקום זאת, צריך להשתמש בביטויים הבאים שספציפיים לשפה:
Node.js
אל תשתמשו ב-process.exit(). פונקציות HTTP צריכות לשלוח תגובה עם res.status(200).send(message), ופונקציות מבוססות-אירוע יסיימו את הפעולה שלהן אחרי שהן יחזירו ערך (באופן מרומז או מפורש).
Python
אל תשתמשו ב-sys.exit(). פונקציות HTTP צריכות להחזיר באופן מפורש תגובה כמחרוזת, ופונקציות מבוססות-אירועים יסיימו את הפעולה ברגע שהן יחזירו ערך (באופן מרומז או מפורש).
Go
אל תשתמשו ב-os.Exit(). פונקציות HTTP צריכות להחזיר באופן מפורש תגובה כמחרוזת, ופונקציות מבוססות-אירועים יסיימו את הפעולה ברגע שהן יחזירו ערך (באופן מרומז או מפורש).
Java
אל תשתמשו ב-System.exit(). פונקציות HTTP צריכות לשלוח תגובה עם response.getWriter().write(message), ופונקציות מבוססות-אירוע יסיימו את הפעולה שלהן אחרי שהן יחזירו ערך (באופן מרומז או מפורש).
C#
אל תשתמשו ב-System.Environment.Exit(). פונקציות HTTP צריכות לשלוח תגובה עם context.Response.WriteAsync(message), ופונקציות מבוססות-אירוע יסיימו את הפעולה שלהן אחרי שהן יחזירו ערך (באופן מרומז או מפורש).
Ruby
אסור להשתמש ב-exit() או ב-abort(). פונקציות HTTP צריכות להחזיר באופן מפורש תגובה כמחרוזת, ופונקציות מבוססות-אירועים יסיימו את הפעולה ברגע שהן יחזירו ערך (באופן מרומז או מפורש).
PHP
אסור להשתמש ב-exit() או ב-die(). פונקציות HTTP צריכות להחזיר באופן מפורש תגובה כמחרוזת, ופונקציות מבוססות-אירועים יסיימו את הפעולה ברגע שהן יחזירו ערך (באופן מרומז או מפורש).
שימוש ב-Sendgrid לשליחת אימיילים
פונקציות Cloud Run לא מאפשרות חיבורים יוצאים ביציאה 25, ולכן אי אפשר ליצור חיבורים לא מאובטחים לשרת SMTP. הדרך המומלצת לשלוח אימיילים היא באמצעות שירות של צד שלישי כמו SendGrid. אפשר למצוא אפשרויות נוספות לשליחת אימייל במדריך שליחת אימייל ממופע של Google Compute Engine.
ביצועים
בקטע הזה מתוארות שיטות מומלצות לאופטימיזציה של הביצועים.
הימנעות משימוש במספר קטן של תהליכים מקבילים
הפעלות במצב התחלתי (cold start) הן יקרות, ולכן היכולת לעשות שימוש חוזר במופעים שהופעלו לאחרונה במהלך עלייה חדה היא אופטימיזציה מצוינת לטיפול בעומס. הגבלת מספר הבקשות בו-זמנית מגבילה את האופן שבו אפשר להשתמש במופעים קיימים, ולכן גורמת ליותר הפעלות במצב התחלתי (cold start).
הגדלת מספר הבקשות המקבילות עוזרת לדחות מספר בקשות לכל מופע, וכך קל יותר לטפל בעליות פתאומיות בעומס.שימוש חכם בתלות
מכיוון שהפונקציות הן חסרות מצב, סביבת ההפעלה מאותחלת לעיתים קרובות מאפס (במהלך מה שנקרא הפעלה קרה). כשמתרחש אתחול קר, ההקשר הגלובלי של הפונקציה נבדק.
אם הפונקציות מייבאות מודולים, זמן הטעינה של המודולים האלה יכול להוסיף לזמן האחזור של הקריאה במהלך הפעלה קרה. כדי לצמצם את זמן האחזור הזה ואת הזמן שנדרש לפריסת הפונקציה, צריך לטעון את התלויות בצורה נכונה ולא לטעון תלויות שהפונקציה לא משתמשת בהן.
שימוש במשתנים גלובליים כדי לעשות שימוש חוזר באובייקטים בהפעלות עתידיות
אין ערובה לכך שהמצב של פונקציית Cloud Run יישמר עבור הפעלות עתידיות. עם זאת, פונקציות Cloud Run ממחזרות לעיתים קרובות את סביבת ההפעלה של קריאה קודמת. אם מצהירים על משתנה בהיקף גלובלי, אפשר לעשות שימוש חוזר בערך שלו בהפעלות הבאות בלי לחשב אותו מחדש.
כך אפשר לשמור במטמון אובייקטים שיכול להיות שיקר ליצור מחדש בכל הפעלה של פונקציה. העברת אובייקטים כאלה מגוף הפונקציה להיקף גלובלי עשויה להוביל לשיפורים משמעותיים בביצועים. בדוגמה הבאה נוצר אובייקט כבד רק פעם אחת לכל מופע של פונקציה, והוא משותף לכל הקריאות לפונקציה שמגיעות למופע הנתון:
Node.js
Python
Go
Java
C#
Ruby
PHP
חשוב במיוחד לשמור במטמון חיבורים לרשת, הפניות לספריות ואובייקטים של לקוחות API בהיקף גלובלי. דוגמאות מפורטות במאמר בנושא שיטות מומלצות לניהול רשתות.
הפחתת הפעלות במצב התחלתי (cold start) על ידי הגדרת מספר מינימלי של מופעים
כברירת מחדל, פונקציות Cloud Run משנות את מספר המכונות בהתאם למספר הבקשות הנכנסות. אפשר לשנות את התנהגות ברירת המחדל הזו על ידי הגדרת מספר מינימלי של מופעים שפונקציות Cloud Run צריכות לשמור במצב מוכן כדי לטפל בבקשות. הגדרת מספר מינימלי של מופעים מצמצמת את ההפעלה האיטית במצב התחלתי של האפליקציה. אם האפליקציה רגישה לזמן האחזור, מומלץ להגדיר מספר מינימלי של מופעים ולהשלים את האתחול בזמן הטעינה.
במאמר שימוש במספר מינימלי של מכונות מוסבר איך להגדיר מספר מינימלי של מכונות.
הערות לגבי הפעלה במצב התחלתי (cold start) ואתחול
אתחול גלובלי מתבצע בזמן הטעינה. בלעדיו, הבקשה הראשונה תצטרך להשלים את האתחול ולטעון מודולים, ולכן זמן האחזור יהיה גבוה יותר.
עם זאת, לאתחול גלובלי יש גם השפעה על הפעלות במצב התחלתי (cold start). כדי לצמצם את ההשפעה הזו, כדאי לאתחל רק את מה שנדרש לבקשה הראשונה, כדי לשמור על זמן האחזור של הבקשה הראשונה נמוך ככל האפשר.
זה חשוב במיוחד אם הגדרתם את מספר המופעים המינימלי כפי שמתואר למעלה עבור פונקציה שרגישה לזמן האחזור. במקרה כזה, השלמת האתחול בזמן הטעינה ושמירת נתונים שימושיים במטמון מבטיחה שהבקשה הראשונה לא תצטרך לעשות זאת, והיא תטופל עם זמן אחזור נמוך.
אם מאתחלים משתנים בהיקף גלובלי, בהתאם לשפה, זמני אתחול ארוכים יכולים להוביל לשני סוגי התנהגויות: - בשילוב מסוים של שפות וספריות אסינכרוניות, פונקציית המסגרת יכולה לפעול באופן אסינכרוני ולחזור באופן מיידי, ולגרום לקוד להמשיך לפעול ברקע, מה שיכול לגרום לבעיות כמו חוסר אפשרות לגשת למעבד. כדי למנוע את הבעיה הזו, צריך לחסום את הפעלת המודול כמו שמתואר בהמשך. כך גם מוודאים שהבקשות לא יטופלו עד שהאתחול יסתיים. – מצד שני, אם ההפעלה היא סינכרונית, זמן ההפעלה הארוך יגרום להפעלות קרות ארוכות יותר, וזו יכולה להיות בעיה, במיוחד בפונקציות עם מקביליות נמוכה במהלך עליות פתאומיות בעומס.
דוגמה לחימום מראש של ספריית node.js אסינכרונית
Node.js עם Firestore היא דוגמה לספריית Node.js אסינכרונית. כדי להשתמש ב-min_instances, הקוד הבא משלים את הטעינה והאתחול בזמן הטעינה, וחוסם את טעינת המודול.
נעשה שימוש ב-TLA, כלומר נדרש ES6, באמצעות הסיומת .mjs לקוד node.js או הוספת type: module לקובץ package.json.
{ "main": "main.js", "type": "module", "dependencies": { "@google-cloud/firestore": "^7.10.0", "@google-cloud/functions-framework": "^3.4.5" } }
Node.js
import Firestore from '@google-cloud/firestore'; import * as functions from '@google-cloud/functions-framework'; const firestore = new Firestore({preferRest: true}); // Pre-warm firestore connection pool, and preload our global config // document in cache. In order to ensure no other request comes in, // block the module loading with a synchronous global request: const config = await firestore.collection('collection').doc('config').get(); functions.http('fetch', (req, res) => { // Do something with config and firestore client, which are now preloaded // and will execute at lower latency. });
דוגמאות לאתחול גלובלי
Node.js
Python
Go
Java
C#
Ruby
PHP
פונקציות PHP לא יכולות לשמור משתנים בין בקשות. בדוגמה שלמעלה לגבי היקפים נעשה שימוש בטעינה מדורגת כדי לשמור במטמון ערכים של משתנים גלובליים בקובץ.
זה חשוב במיוחד אם מגדירים כמה פונקציות בקובץ אחד, ופונקציות שונות משתמשות במשתנים שונים. אם לא משתמשים באתחול עצלן, יכול להיות שתבזבזו משאבים על משתנים שאותחלו אבל אף פעם לא נעשה בהם שימוש.
מקורות מידע נוספים
מידע נוסף על אופטימיזציה של הביצועים זמין בסרטון 'Google Cloud Performance Atlas' בנושא זמן אתחול קר של פונקציות Cloud Run.