אוטומציה של מעבר לגיבוי ולשחזור בין אזורים באמצעות תקינות השירות של Cloud Run

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

Service Health של שירות Cloud Run חושפת את התקינות המצטברת של השירות בכל אזור באמצעות קבוצות של נקודות קצה ברשת (NEG) בלי שרת (serverless).

איך זה עובד

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

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

מגבלות

המגבלות הבאות חלות על Service Health של Cloud Run:

  • כדי לחשב את התקינות, צריך להגדיר לפחות מכונה אחת מינימלית ברמת השירות או ברמת הגרסה בכל אזור. אפשר גם להשתמש במדד Container instance count ב-Cloud Monitoring כדי להעריך את מספר המכונות המינימלי הנדרש לאזורים שלכם.
  • כדי להגדיר יתירות כשל, צריך לפחות שני שירותים מאזורים שונים. אחרת, אם אחד מהשירותים נכשל, מוצגת הודעת השגיאה no healthy upstream.
  • אי אפשר להגדיר מסכת כתובת URL או תגים בקבוצות NEG בלי שרת (serverless).
  • אם שירות Cloud Run נמחק, Cloud Run לא מדווח על סטטוס לא תקין למאזן העומסים.
  • כשמפעילים מכונה חדשה, בדיקת המוכנות הראשונה לא נספרת, ולכן יכול להיות שבקשה תנותב לזמן קצר לשירות שהופעל לאחרונה לפני שהוא יהפוך ללא תקין.
  • התקינות של שירות Cloud Run מחושבת בכל המכונות. גרסאות ללא בדיקות ומופעים חדשים שהתחילו ולא השלימו את בדיקת המוכנות הראשונה שלהם נחשבים כלא ידועים. במהלך העברה של כל התנועה בין גרסאות, יכול להיות שב-Service Health יופיע לזמן קצר הערך UNKNOWN בזמן שהמכונות החדשות מתחילות ומשלימות את בדיקת המוכנות הראשונה שלהן. מאזן העומסים מתייחס למכונות לא ידועות כתקינות.
  • אם המכונות קורסות במהירות, יכול להיות שחישוב Service Health יניב תוצאות לא מדויקות.

שיטות מומלצות

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

כשמגדירים בדיקות באפליקציה, צריך להוסיף נקודת קצה (endpoint) של HTTP/1 (ברירת המחדל של Cloud Run, לא HTTP/2) בקוד השירות כדי להגיב לבדיקה. שם נקודת הקצה (לדוגמה, /startup, /health או /are_you_ready) חייב להתאים ל-path בהגדרת הבדיקה. אפשר לגשת לנקודות הקצה של בדיקת התקינות של HTTP מבחוץ, והן פועלות לפי אותם עקרונות כמו כל נקודות קצה אחרות של שירות HTTP שחשופות כלפי חוץ.

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

  1. פורסים את הגרסה החדשה באזור "קנרית" אחד עם בדיקת מוכנות מוגדרת.

  2. שולחים נפח תנועה קטן (לדוגמה, 1%) לגרסה החדשה.

  3. השתמשו במספר מינימלי של מכונות שאינו אפס ברמת השירות, ולא ברמת הגרסה.

  4. בודקים את מדד בדיקת המוכנות (run.googleapis.com/container/instance_count_with_readiness) כדי לוודא שהמכונות החדשות תקינות.

  5. מגדילים בהדרגה את אחוז התנועה לגרסה החדשה. בזמן ההרחבה, עוקבים אחרי מדד התקינות של שירות Cloud Run האזורי (run.googleapis.com/service_health_count), שמשמש את מאזן העומסים. שירות Cloud Run מדווח על Service Health של UNKNOWN עד שמועברת מספיק תנועה לגרסה החדשה.

  6. אחרי שהגרסה מקבלת 100% מהתנועה וה-Service Health של שירות Cloud Run האזורי יציב ותקין, חוזרים על התהליך הזה בכל שאר האזורים.

בשירותים שכבר משתמשים ב-Cloud Run Service Health, אפשר להריץ השקה בשני שלבים במקביל באזורים שונים כדי להימנע מדיווח על UNKNOWN:

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

  2. מפנים 100% מהתנועה לגרסה החדשה.

מדריך: הגדרת יתירות כשל אוטומטית

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

במדריך הזה תלמדו:

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

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

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

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  5. Verify that billing is enabled for your Google Cloud project.

  6. מפעילים את ממשקי ה-API הבאים, אם הם עדיין לא מופעלים: Artifact Registry,‏ Cloud Build,‏ Cloud Run Admin API,‏ Network Services API ו-Compute Engine.

    התפקידים שנדרשים כדי להפעיל ממשקי API

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    הפעלת ממשקי ה-API

  7. מתקינים ומפעילים את ה-CLI של gcloud.
  8. מעדכנים את הרכיבים: 
    gcloud components update
  9. מגדירים את משתני התצורה שמשמשים במדריך הזה: 
    PROJECT_ID= gcloud config set core/project PROJECT_ID
PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")
SERVICE=health-example
REGION_A=us-west1
REGION_B=europe-west1
     מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

הגדרת התפקידים הנדרשים

כדי לפרוס מקוד מקור עם build, אתם או האדמין שלכם צריכים להקצות לחשבון השירות של Cloud Build את תפקידי ה-IAM הבאים.

כדי לראות את התפקידים הנדרשים לחשבון השירות ב-Cloud Build, לחצו כאן

כברירת מחדל, Cloud Build משתמש באופן אוטומטי בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לבנות את קוד המקור ואת המשאב של Cloud Run, אלא אם משנים את ההתנהגות הזו. כדי ש-Cloud Build יוכל ליצור את המקורות, צריך לבקש מהאדמין להקצות את התפקיד Cloud Run Builder (roles/run.builder) לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine בפרויקט:

  gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role=roles/run.builder

מחליפים את PROJECT_NUMBER במספר הפרויקט ב- Google Cloud, ואת PROJECT_ID במזהה הפרויקט ב- Google Cloud. במאמר יצירה וניהול של פרויקטים מוסבר איך למצוא את מזהה הפרויקט ואת מספר הפרויקט.

הקצאת התפקיד "מפתח ב-Cloud Run" לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine מתעדכנת תוך כמה דקות.

כדי לקבל את ההרשאות שנדרשות לזהות השירות כדי לגשת לקובץ ולקטגוריה של Cloud Storage, צריך לבקש מהאדמין להקצות לזהות השירות את התפקיד אדמין של אחסון (roles/storage.admin). למידע נוסף על תפקידים והרשאות ב-Cloud Storage, קראו את המאמר IAM ל-Cloud Storage.

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

הכנת האפליקציה לדוגמה

כדי לאחזר את דוגמת הקוד לשימוש:

  1. משכפלים את המאגר לדוגמה ומעבירים אותו למכונה המקומית:

    git clone https://github.com/GoogleCloudPlatform/golang-samples

  2. עוברים לספרייה שמכילה את הקוד לדוגמה של Cloud Run:

    cd golang-samples/run/service-health

פריסת שירות Cloud Run בשני אזורים עם בדיקות מוכנות

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

  1. פורסים את השירות health-example ב-us-west1 וב-europe-west1 מספריית קובצי המקור. כדי להגדיר את Service Health באמצעות בדיקות מוכנות, צריך לפחות מכונה אחת:

    gcloud run deploy $SERVICE \
--source=. \
--regions=$REGION_A,$REGION_B \
--min=10 \
--readiness-probe httpGet.path="/are_you_ready"

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

הגדרת מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)

כדי להגדיר מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) לניתוב תעבורת נתונים בין us-west1 ל-europe-west1, מבצעים את השלבים הבאים. אם אתם מעדיפים להקצות את מאזן העומסים באמצעות Terraform, קראו את המאמר יצירת מאזן עומסים חיצוני גלובלי של אפליקציות (ALB).

  1. יוצרים שירות לקצה העורפי:

    gcloud compute backend-services create $SERVICE-bs \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --global

  2. מגדירים כתובת IP חיצונית סטטית גלובלית כדי להגיע למאזן העומסים:

    gcloud compute addresses create $SERVICE-ip \
  --network-tier=PREMIUM \
  --ip-version=IPV4 \
  --global

  3. יוצרים מפת URL כדי לנתב בקשות נכנסות לשירות לקצה העורפי:

    gcloud compute url-maps create $SERVICE-lb \
  --default-service $SERVICE-bs

  4. יוצרים שרת proxy ל-HTTP לניתוב בקשות למפת URL:

    gcloud compute target-http-proxies create $SERVICE-hp \
--url-map=$SERVICE-lb

  5. יוצרים כלל העברה כדי לנתב בקשות נכנסות לשרת ה-proxy:

    gcloud compute forwarding-rules create $SERVICE-fr \
  --load-balancing-scheme=EXTERNAL_MANAGED \
  --network-tier=PREMIUM \
  --address=$SERVICE-ip \
  --target-http-proxy=$SERVICE-hp \
  --global \
  --ports=80

הוספת השירותים באמצעות NEG ללא שרת (serverless)

כדי להוסיף את השירותים שפרסתם ב-us-west1 וב-europe-west1 באמצעות NEG ללא שרת (serverless), צריך לבצע את השלבים הבאים. אם אתם מעדיפים להקצות את קבוצות ה-NEG ללא שרת באמצעות Terraform, קראו את המאמר הגדרת קבוצות אזוריות של נקודות קצה ברשת.

  1. יוצרים קבוצת נקודות קצה ברשת ללא שרת (serverless) (NEG) לשירות Cloud Run ב-us-west1 וב-europe-west1:

    gcloud compute network-endpoint-groups create $SERVICE-neg-$REGION_A \
    --region $REGION_A \
    --network-endpoint-type=serverless \
    --cloud-run-service=$SERVICE

    gcloud compute network-endpoint-groups create $SERVICE-neg-$REGION_B \
    --region $REGION_B \
    --network-endpoint-type=serverless \
    --cloud-run-service=$SERVICE

  2. מוסיפים את ה-NEG בלי שרת (serverless) כקצה עורפי לשירותי הקצה העורפי ב-us-west1 וב-europe-west1:

    gcloud compute backend-services add-backend $SERVICE-bs \
    --global \
    --network-endpoint-group=$SERVICE-neg-$REGION_A \
    --network-endpoint-group-region=$REGION_A

    gcloud compute backend-services add-backend $SERVICE-bs \
    --global \
    --network-endpoint-group=$SERVICE-neg-$REGION_B \
    --network-endpoint-group-region=$REGION_B

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

דיווח על סטטוס הבריאות באזור

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

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

    gcloud run deploy SERVICE_NAME \
--regions=REGION_A,REGION_B \
--min=MIN_INSTANCES

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE_NAME: שם השירות.
    • ‫REGION_A, ‏REGION_B: אזורים שונים לגרסת השירות. לדוגמה, מגדירים את REGION_A ל-us-central1 ואת REGION_B ל-europe-west1.
    • ‫MIN_INSTANCES: מספר המכונות של הקונטיינר שצריך לשמור במצב פעיל, מוכנות לקבלת בקשות. הערך המינימלי צריך להיות 1 ומעלה.

  2. מגדירים בדיקת מוכנות של gRPC או HTTP בכל מכונה של קונטיינר.

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

  4. מגדירים קבוצות NEG ללא שרת (serverless) לכל שירות Cloud Run בכל אזור.

  5. מגדירים שירות לקצה העורפי כדי להתחבר לקבוצות NEG ללא שרת (serverless).

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

בדיקה ואימות של יתירות כשל

כדי לבדוק את יתירות הכשל ולוודא שהשירותים של Cloud Run אמינים וגמישים, פועלים לפי השלבים הבאים:

  1. מריצים את הפקודה הבאה כדי לקבל את כתובת ה-IP של מאזן העומסים:

    LBIP=$(gcloud compute addresses describe $SERVICE-ip --global --format='value(address)')

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

    curl  -H "Authorization: Bearer $(gcloud auth print-identity-token)" $LBIP

  3. כדי לקבל את הערך של המשתנה LBIP, מריצים את הפקודה echo $LBIP. כך מוצגת כתובת ה-IP של מאזן העומסים. לדוגמה, 11.22.33.44.

  4. כדי לבדוק את יתירות הכשל, עוברים לכתובת ה-URL‏ http://LOAD_BALANCER_IP, כאשר LOAD_BALANCER_IP הוא הערך שקיבלתם בשלב הקודם. בקטע אזורי הצגה, לוחצים על המתג של האזור הרלוונטי. כך מציינים את האזור התקין ואת המכונה שמטפלת בתנועה:

    איך להגדיר יתירות כשל אוטומטית בין אזורים באמצעות Service Health של Cloud Run

מעקב אחרי בדיקות תקינות

אחרי שמגדירים את תקינות השירות של Cloud Run, קבוצות NEG ללא שרת (serverless) אוספות את מדד תקינות השירות של Cloud Monitoring. אתם יכולים לראות את סטטוס התקינות של השירותים האזוריים הקיימים.

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

שימוש במינויי דחיפה מאומתים של Pub/Sub עם פריסה במספר אזורים

כברירת מחדל, שירות Pub/Sub מעביר הודעות לנקודות קצה (endpoints) של Push באותו אזור ב- Google Cloud שבו השירות מאחסן את ההודעות. כדי לעקוף את הבעיה הזו, אפשר לעיין במאמר שימוש במינוי דחיפה מאומת של Pub/Sub עם פריסה של Cloud Run בכמה אזורים.

אפשרות חלופית: הגדרת יתירות כשל ידנית

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

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

    gcloud compute backend-services remove-backend BACKEND_NAME \
--network-endpoint-group=NEG_NAME \
--network-endpoint-group-region=REGION \
--global

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫BACKEND_NAME: השם של שירות הקצה העורפי.
    • ‫NEG_NAME: השם של משאב קבוצת נקודות הקצה ברשת, לדוגמה myservice-neg-uscentral1.
    • ‫REGION: האזור שבו נוצרה קבוצת ה-NEG ושממנו רוצים להסיר את השירות. לדוגמה, us-central1,asia-east1.

  2. כדי לוודא שהאזור התקין מטפל עכשיו בתנועה, נכנסים לכתובת https://<domain-name>.

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

מחיקת הפרויקט

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

הדרך הקלה ביותר לבטל את החיוב היא למחוק את הפרויקט שיצרתם בשביל המדריך.

כדי למחוק את הפרויקט:

  1. נכנסים לדף Manage resources במסוף Google Cloud .

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

מחיקת המשאבים של המדריך

  1. מוחקים את שירות Cloud Run שפרסתם במדריך הזה. שירותי Cloud Run לא צוברים עלויות עד שהם מקבלים בקשות.

    כדי למחוק את השירות ב-Cloud Run, מריצים את הפקודה הבאה:

    gcloud run services delete SERVICE-NAME

    מחליפים את SERVICE-NAME בשם השירות.

    אפשר גם למחוק שירותי Cloud Run ממסוףGoogle Cloud .

  2. מסירים את הגדרת ברירת המחדל של האזור gcloud שהוספתם במהלך הגדרת המדריך:

     gcloud config unset run/region

  3. מסירים את הגדרות הפרויקט:

     gcloud config unset project

המאמרים הבאים