טיפים & טריקים

במסמך הזה מתוארות שיטות מומלצות לעיצוב, להטמעה, לבדיקה ולפריסה של Cloud Functions.

נכונות

בקטע הזה מתוארות שיטות מומלצות כלליות לתכנון ולהטמעה של Cloud Functions.

כתיבת פונקציות אידמפוטנטיות

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

לא להפעיל פעילויות ברקע

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

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

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

מחיקת קבצים זמניים תמיד

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

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

אם אתם צריכים גישה לאחסון לטווח ארוך, כדאי להשתמש בCloud Run volume mounts עם Cloud Storage או ב-NFS volumes.

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

Functions Framework

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

כדי לעשות את זה, צריך לכלול את הגרסה המועדפת בקובץ הנעילה הרלוונטי (לדוגמה, package-lock.json ל-Node.js או requirements.txt ל-Python).

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

כלים

בקטע הזה מפורטות הנחיות לשימוש בכלים להטמעה, לבדיקה ולשימוש ב-Cloud Functions.

פיתוח מקומי

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

איך נמנעים מפסקי זמן של פריסה במהלך האתחול

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

ל-CLI ‏Firebase יש הגדרת זמן קצוב (timeout) כברירת מחדל לגילוי הפונקציות במהלך הפריסה. אם לוגיקת האתחול בקוד המקור של הפונקציות (טעינת מודולים, ביצוע קריאות לרשת וכו') חורגת מהזמן הקצוב הזה, יכול להיות שהפריסה תיכשל.

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

(מומלץ) שימוש ב-onInit() כדי לדחות את ההפעלה

כדי להימנע מהרצת קוד האתחול במהלך הפריסה, משתמשים ב-hook‏ onInit(). הקוד בתוך ה-hook‏ onInit() יפעל רק כשהפונקציה תיפרס ב-Cloud Functions, ולא במהלך תהליך הפריסה עצמו.

const { onInit } = require('firebase-functions/v2/core');
const { onRequest } = require('firebase-functions/v2/https');

// Example of a slow initialization task
function slowInitialization() {
  // Simulate a long-running operation (e.g., loading a large model, network request).
  return new Promise(resolve => {
      setTimeout(() => {
          console.log("Slow initialization complete");
          resolve("Initialized Value");
      }, 20000); // Simulate a 20-second delay
  });
}
let initializedValue;

onInit(async () => {
  initializedValue = await slowInitialization();
});

exports.myFunction = onRequest((req, res) => {
  // Access the initialized value. It will be ready after the first invocation.
  res.send(`Value: ${initializedValue}`);
});

from firebase_functions.core import init
from firebase_functions import https_fn
import time

# Example of a slow initialization task
def _slow_initialization():
  time.sleep(20)  # Simulate a 20-second delay
  print("Slow initialization complete")
  return "Initialized Value"

_initialized_value = None

@init
def initialize():
  global _initialized_value
  _initialized_value = _slow_initialization()

@https_fn.on_request()
def my_function(req: https_fn.Request) -> https_fn.Response:
  # Access the initialized value. It will be ready after the first invocation.
  return https_fn.Response(f"Value: {_initialized_value}")

(חלופה) הגדלת פסק הזמן לגילוי

אם אי אפשר לשנות את מבנה הקוד כדי להשתמש ב-onInit(), אפשר להגדיל את הזמן הקצוב לתפוגה של הפריסה ב-CLI באמצעות משתנה הסביבה FUNCTIONS_DISCOVERY_TIMEOUT:

$ export FUNCTIONS_DISCOVERY_TIMEOUT=30
$ firebase deploy --only functions

שימוש ב-Sendgrid לשליחת אימיילים

‫Cloud Functions לא מאפשר חיבורים לדואר יוצא ביציאה 25, ולכן אי אפשר ליצור חיבורים לא מאובטחים לשרת SMTP. הדרך המומלצת לשלוח אימיילים היא באמצעות שירות של צד שלישי כמו SendGrid. אפשר למצוא אפשרויות נוספות לשליחת אימייל במדריך שליחת אימייל ממופע של Google Compute Engine.

ביצועים

בקטע הזה מתוארות שיטות מומלצות לאופטימיזציה של הביצועים.

הימנעות משימוש במספר נמוך של תהליכים מקבילים

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

שימוש חכם בתלויות

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

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

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

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

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

console.log('Global scope');
const perInstance = heavyComputation();
const functions = require('firebase-functions');

exports.function = functions.https.onRequest((req, res) => {
  console.log('Function invocation');
  const perFunction = lightweightComputation();

  res.send(`Per instance: ${perInstance}, per function: ${perFunction}`);
});

import time

from firebase_functions import https_fn

# Placeholder
def heavy_computation():
  return time.time()

# Placeholder
def light_computation():
  return time.time()

# Global (instance-wide) scope
# This computation runs at instance cold-start
instance_var = heavy_computation()

@https_fn.on_request()
def scope_demo(request):

  # Per-function scope
  # This computation runs every time this function is called
  function_var = light_computation()
  return https_fn.Response(f"Instance: {instance_var}; function: {function_var}")
  

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

הגדרת מספר מינימלי של מופעים כדי לצמצם את ההפעלה במצב התחלתי (cold start)

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

הערות לגבי הפעלה במצב התחלתי (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"
  }
}

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.
});

דוגמאות לאתחול גלובלי

const functions = require('firebase-functions');
let myCostlyVariable;

exports.function = functions.https.onRequest((req, res) => {
  doUsualWork();
  if(unlikelyCondition()){
      myCostlyVariable = myCostlyVariable || buildCostlyVariable();
  }
  res.status(200).send('OK');
});

from firebase_functions import https_fn

# Always initialized (at cold-start)
non_lazy_global = file_wide_computation()

# Declared at cold-start, but only initialized if/when the function executes
lazy_global = None

@https_fn.on_request()
def lazy_globals(request):

  global lazy_global, non_lazy_global

  # This value is initialized only if (and when) the function is called
  if not lazy_global:
      lazy_global = function_specific_computation()

  return https_fn.Response(f"Lazy: {lazy_global}, non-lazy: {non_lazy_global}.")
  

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

משאבים נוספים

מידע נוסף על אופטימיזציה של הביצועים זמין בסרטון 'Google Cloud Performance Atlas' בנושא Cloud Functions זמן אתחול קר.