טיפים כלליים לפיתוח

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

איך לנסח שירותים אפקטיביים

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

פעילות ברקע

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

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

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

אם אתם משתמשים בחיוב לפי בקשות, הימנעו מפעילויות ברקע

אם אתם צריכים להגדיר את השירות לחיוב לפי בקשה, כששירות Cloud Run מסיים לטפל בבקשה, הגישה של המופע למעבד מושבתת או מוגבלת מאוד. אם אתם משתמשים בסוג החיוב הזה, אל תפעילו תהליכים או שגרות ברקע שפועלים מחוץ להיקף של ה-request handlers.

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

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

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

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

דיווח על שגיאות

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

ראו את המדריך ל-Error Reporting לקבלת מידע על איך לדווח על שגיאות בצורה נכונה.

אופטימיזציה של הביצועים

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

הפעלה מהירה של קונטיינרים

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

התרחיש להפעלה כולל:

• הורדת קובץ האימג' של הקונטיינר (באמצעות טכנולוגיית הסטרימינג של קובץ האימג' של הקונטיינר ב-Cloud Run)
• הפעלת הקונטיינר באמצעות הפקודה entrypoint.
• המערכת ממתינה שהמאגר יתחיל להאזין ביציאה שהוגדרה.

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

שימוש בהאצת המעבד בזמן אתחול כדי להפחית את זמן האחזור של האתחול

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

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

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

שימו לב: בקשה שממתינה להפעלת מופע תישאר בהמתנה בתור באופן הבא:

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

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

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

כדי לקצר את זמן הטעינה של האפליקציה:

• כדי ליצור שירות קל, צמצמו את המספר והגודל של יחסי התלות.
• אם השפה תומכת בכך, כדאי להשתמש בטעינה מדורגת של קוד שלא משתמשים בו לעיתים קרובות.
• משתמשים באופטימיזציות של טעינת קוד, כמו composer autoloader optimization של PHP.

שימוש במשתנים גלובליים

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

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

const functions = require('@google-cloud/functions-framework');

// TODO(developer): Define your own computations
const {lightComputation, heavyComputation} = require('./computations');

// Global (instance-wide) scope
// This computation runs once (at instance cold-start)
const instanceVar = heavyComputation();

/**
 * HTTP function that declares a variable.
 *
 * @param {Object} req request context.
 * @param {Object} res response context.
 */
functions.http('scopeDemo', (req, res) => {
  // Per-function scope
  // This computation runs every time this function is called
  const functionVar = lightComputation();

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

import time

import functions_framework


# 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()


@functions_framework.http
def scope_demo(request):
    """
    HTTP Cloud Function that declares a variable.
    Args:
        request (flask.Request): The request object.
        <http://flask.pocoo.org/docs/1.0/api/#flask.Request>
    Returns:
        The response text, or any set of values that can be turned into a
        Response object using `make_response`
        <http://flask.pocoo.org/docs/1.0/api/#flask.Flask.make_response>.
    """

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

// h is in the global (instance-wide) scope.
var h string

// init runs during package initialization. So, this will only run during an
// an instance's cold start.
func init() {
	h = heavyComputation()
	functions.HTTP("ScopeDemo", ScopeDemo)
}

// ScopeDemo is an example of using globally and locally
// scoped variables in a function.
func ScopeDemo(w http.ResponseWriter, r *http.Request) {
	l := lightComputation()
	fmt.Fprintf(w, "Global: %q, Local: %q", h, l)
}

import com.google.cloud.functions.HttpFunction;
import com.google.cloud.functions.HttpRequest;
import com.google.cloud.functions.HttpResponse;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Arrays;

public class Scopes implements HttpFunction {
  // Global (instance-wide) scope
  // This computation runs at instance cold-start.
  // Warning: Class variables used in functions code must be thread-safe.
  private static final int INSTANCE_VAR = heavyComputation();

  @Override
  public void service(HttpRequest request, HttpResponse response)
      throws IOException {
    // Per-function scope
    // This computation runs every time this function is called
    int functionVar = lightComputation();

    var writer = new PrintWriter(response.getWriter());
    writer.printf("Instance: %s; function: %s", INSTANCE_VAR, functionVar);
  }

  private static int lightComputation() {
    int[] numbers = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
    return Arrays.stream(numbers).sum();
  }

  private static int heavyComputation() {
    int[] numbers = new int[] { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
    return Arrays.stream(numbers).reduce((t, x) -> t * x).getAsInt();
  }
}

ביצוע אתחול מדורג של משתנים גלובליים

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

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

const functions = require('@google-cloud/functions-framework');

// Always initialized (at cold-start)
const nonLazyGlobal = fileWideComputation();

// Declared at cold-start, but only initialized if/when the function executes
let lazyGlobal;

/**
 * HTTP function that uses lazy-initialized globals
 *
 * @param {Object} req request context.
 * @param {Object} res response context.
 */
functions.http('lazyGlobals', (req, res) => {
  // This value is initialized only if (and when) the function is called
  lazyGlobal = lazyGlobal || functionSpecificComputation();

  res.send(`Lazy global: ${lazyGlobal}, non-lazy global: ${nonLazyGlobal}`);
});

import functions_framework

# 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


@functions_framework.http
def lazy_globals(request):
    """
    HTTP Cloud Function that uses lazily-initialized globals.
    Args:
        request (flask.Request): The request object.
        <http://flask.pocoo.org/docs/1.0/api/#flask.Request>
    Returns:
        The response text, or any set of values that can be turned into a
        Response object using `make_response`
        <http://flask.pocoo.org/docs/1.0/api/#flask.Flask.make_response>.
    """
    global lazy_global, non_lazy_global  # noqa: F824

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

    return f"Lazy: {lazy_global}, non-lazy: {non_lazy_global}."

// Package tips contains tips for writing Cloud Functions in Go.
package tips

import (
	"context"
	"log"
	"net/http"
	"sync"

	"cloud.google.com/go/storage"
	"github.com/GoogleCloudPlatform/functions-framework-go/functions"
)

// client is lazily initialized by LazyGlobal.
var client *storage.Client
var clientOnce sync.Once

func init() {
	functions.HTTP("LazyGlobal", LazyGlobal)
}

// LazyGlobal is an example of lazily initializing a Google Cloud Storage client.
func LazyGlobal(w http.ResponseWriter, r *http.Request) {
	// You may wish to add different checks to see if the client is needed for
	// this request.
	clientOnce.Do(func() {
		// Pre-declare an err variable to avoid shadowing client.
		var err error
		client, err = storage.NewClient(context.Background())
		if err != nil {
			http.Error(w, "Internal error", http.StatusInternalServerError)
			log.Printf("storage.NewClient: %v", err)
			return
		}
	})
	// Use client.
}

import com.google.cloud.functions.HttpFunction;
import com.google.cloud.functions.HttpRequest;
import com.google.cloud.functions.HttpResponse;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Arrays;

public class LazyFields implements HttpFunction {
  // Always initialized (at cold-start)
  // Warning: Class variables used in Servlet classes must be thread-safe,
  // or else might introduce race conditions in your code.
  private static final int NON_LAZY_GLOBAL = fileWideComputation();

  // Declared at cold-start, but only initialized if/when the function executes
  // Uses the "initialization-on-demand holder" idiom
  // More information: https://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom
  private static class LazyGlobalHolder {
    // Making the default constructor private prohibits instantiation of this class
    private LazyGlobalHolder() {}

    // This value is initialized only if (and when) the getLazyGlobal() function below is called
    private static final Integer INSTANCE = functionSpecificComputation();

    private static Integer getInstance() {
      return LazyGlobalHolder.INSTANCE;
    }
  }

  @Override
  public void service(HttpRequest request, HttpResponse response)
      throws IOException {
    Integer lazyGlobal = LazyGlobalHolder.getInstance();

    var writer = new PrintWriter(response.getWriter());
    writer.printf("Lazy global: %s; non-lazy global: %s%n", lazyGlobal, NON_LAZY_GLOBAL);
  }

  private static int functionSpecificComputation() {
    int[] numbers = new int[] {1, 2, 3, 4, 5, 6, 7, 8, 9};
    return Arrays.stream(numbers).sum();
  }

  private static int fileWideComputation() {
    int[] numbers = new int[] {1, 2, 3, 4, 5, 6, 7, 8, 9};
    return Arrays.stream(numbers).reduce((t, x) -> t * x).getAsInt();
  }
}

שימוש בסביבת ביצוע אחרת

יכול להיות שזמני ההפעלה יהיו מהירים יותר אם תשתמשו בסביבת הפעלה אחרת.

אופטימיזציה של בו-זמניות (concurrency)

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

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

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

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

התאמת מספר החיבורים בו-זמנית לשירות

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

כדי לבצע אופטימיזציה של השירות כך שיוכל לתמוך במספר מקסימלי של משתמשים בו-זמנית:

1. לשפר את ביצועי השירות.
2. מגדירים את רמת התמיכה הצפויה בריבוי משימות בכל הגדרה של ריבוי משימות ברמת הקוד. לא כל סטאק תוכנות דורש הגדרה כזו.
3. פורסים את השירות.
4. הגדירו את בו-זמניות הבקשות ב-Cloud Run לשירות שלכם כך שתהיה שווה או קטנה מכל הגדרה ברמת הקוד. אם אין הגדרה ברמת הקוד, משתמשים בערך הצפוי של מספר הפעולות בו-זמנית.
5. משתמשים בכלים לבדיקות עומס שתומכים בהגדרה של מספר הבקשות בו-זמנית. צריך לוודא שהשירות שלכם נשאר יציב תחת העומס והמקבילות הצפויים.
6. אם השירות לא פועל בצורה טובה, עוברים לשלב 1 כדי לשפר את השירות או לשלב 2 כדי לצמצם את מספר הפעולות שמתבצעות בו-זמנית. אם השירות פועל בצורה טובה, חוזרים לשלב 2 ומגדילים את מספר הבקשות המקבילות.

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

התאמת הזיכרון לריבוי משימות

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

הימנעו ממצב גלובלי שניתן לשינוי

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

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

הפשרות בין תפוקה, זמן אחזור ועלות

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

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

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

שיקולי עלות

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

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

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

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

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

Container Security

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

כדי לשפר את אבטחת הקונטיינר:

• השתמשו בקובצי אימג' בסיסיים מאובטחים ומתוחזקים באופן פעיל, כמו קובצי האימג' הבסיסיים של Google או קובצי האימג' הרשמיים של Docker Hub.

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

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

• מטמיעים תהליך build דטרמיניסטי שכולל גרסאות ספציפיות של תוכנות וספריות. כך אפשר למנוע הכללה של קוד לא מאומת במאגר התגים.

• מגדירים את הקונטיינר כך שיפעל כמשתמש שאינו root באמצעות הצהרת USER של קובץ Docker. יכול להיות שחלק מקובצי האימג' של קונטיינר כבר כוללים משתמש ספציפי שהוגדר.

• כדי למנוע שימוש בתכונות בגרסת Preview, אפשר להשתמש במדיניות ארגונית בהתאמה אישית.

סריקת אבטחה אוטומטית

הפעלת סריקת נקודות חולשה כדי לבצע סריקת אבטחה של קובצי אימג' של קונטיינרים שמאוחסנים ב-Artifact Registry.

פיתוח קובצי אימג' מינימליים של קונטיינרים

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

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

כדי ליצור קונטיינר מינימלי, כדאי לעבוד עם קובץ אימג' בסיסי ופשוט, כמו:

• אלפיני
• scratch

Ubuntu הוא קובץ אימג' בסיסי גדול יותר, אבל הוא נפוץ יותר וכולל סביבת שרת מוכנה לשימוש שהיא מלאה יותר.

אם תהליך ה-build של השירות שלכם כולל הרבה כלים, כדאי להשתמש בתהליכי build בכמה שלבים כדי שהקונטיינר יהיה קל בזמן הריצה.

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

• שיטות מומלצות ל-Kubernetes: איך ולמה כדאי ליצור קובצי אימג' קטנים של קונטיינרים
• 7 שיטות מומלצות ליצירת קונטיינרים