יצירת פריסות מרובות אזורים ל-API Gateway

במדריך הזה מוסבר איך להגדיר מאזן עומסים (LB) מסוג HTTP(S) כדי להפעיל פריסות בכמה אזורים ב-API Gateway.

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

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

לפני שמתחילים

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

במדריך הזה, תפרסו את השירות בשני אזורים שונים. לדוגמה, אפשר לפרוס שתי מכונות API Gateway:

  • ‫my-gateway-eu לאזור באירופה
  • ‫my-gateway-us לאזור בארה"ב

הגדרת ההרשאות

במדריך הזה תיצרו קבוצה של נקודות קצה (endpoint) ברשת (NEG) בלי שרת ומאזן עומסים חיצוני מסוג HTTP(S) בפרויקט בענן. לשם כך נדרש תפקיד של בעלים או עורך בפרויקט, או תפקידי ה-IAM הבאים ב-Compute Engine:

משימה תפקיד נדרש
יצירת מאזן עומסים ורכיבי רשת אדמין רשתות
יצירה ושינוי של קבוצות NEG Compute Instance Admin
יצירה ושינוי של אישורי SSL Security Admin

יצירת משאב של אישור SSL

כדי ליצור מאזן עומסים ב-HTTPS, צריך להוסיף משאב של אישור SSL לממשק הקצה של מאזן העומסים. יוצרים משאב של אישור SSL באמצעות אישור SSL בניהול Google או אישור SSL בניהול עצמי.

  • אישורים שמנוהלים על ידי Google. מומלץ להשתמש באישורים שמנוהלים על ידי Google כי Google Cloud היא מקבלת, מנהלת ומחדשת את האישורים האלה באופן אוטומטי. כדי ליצור אישור שמנוהל על ידי Google, צריך דומיין ורשומות DNS של הדומיין הזה כדי שהאישור יוקצה. אם עדיין אין לכם דומיין, אתם יכולים לקבל אותו מ-Google Domains. בנוסף, תצטרכו לעדכן את רשומת ה-A ב-DNS של הדומיין כך שתפנה לכתובת ה-IP של מאזן העומסים שנוצרה בשלב מאוחר יותר. הוראות מפורטות זמינות במאמר בנושא שימוש באישורים שמנוהלים על ידי Google.

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

במדריך הזה אנחנו מניחים שכבר יצרתם משאב של אישור SSL.

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

יצירת מאזן עומסים מסוג HTTP או HTTPS

  1. יוצרים NEG ללא שרת לכל מופע של API Gateway.

    קבוצה של נקודות קצה ברשת (NEG) מציינת קבוצה של נקודות קצה בקצה העורפי של מאזן עומסים. קבוצת נקודות קצה ללא שרת היא קצה עורפי שמפנה לשירות כמו API Gateway, כפי שמוצג באיור הבא:

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

    כדי ליצור NEG בלי שרת (serverless) לכל מכונה של שער, מריצים את הפקודה הבאה, כאשר:

    • ‫SERVERLESS_NEG_NAME הוא השם של ה-NEG חסר השרת שרוצים ליצור.
    • ‫GATEWAY_ID מציין את שם השער.
    • ‫REGION_ID הוא אזור הפריסה של ה-NEG ללא שרת (צריך להיות זהה לאזור השער).
    gcloud beta compute network-endpoint-groups create SERVERLESS_NEG_NAME \
  --region=REGION_ID \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=GATEWAY_ID

    לדוגמה:

    gcloud beta compute network-endpoint-groups create api-gateway-serverless-neg-eu \
  --region=europe-west1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway-eu

    חוזרים על הפקודה הזו כדי ליצור NEG בלי שרת (serverless) עבור מופע השער הבא, באמצעות הערכים המתאימים למופע השער השני, לדוגמה,api-gateway-serverless-neg-us בשביל my-gateway-us באזור us-central1.

  2. יוצרים שירות קצה עורפי כדי להגדיר איך Cloud Load Balancing מבזר את תעבורת הנתונים.

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

    שירות לקצה העורפי שמחובר לכמה קבוצות של נקודות קצה ברשת בלי שרתים (serverless) באזורים שונים

    כדי ליצור שירות קצה עורפי ולהוסיף את ה-NEG חסר השרתים כקצה עורפי לשירות הקצה העורפי, מריצים את הפקודות הבאות, כאשר:

    • ‫BACKEND_SERVICE_NAME הוא השם של שירות הקצה העורפי.
    • ‫SERVERLESS_NEG_NAME הוא השם של קבוצת ה-NEG ללא שרתים שנוצרה בשלב הקודם.
    • ‫REGION_ID הוא אזור הפריסה של ה-NEG ללא שרת (צריך להיות זהה לאזור השער).
    gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --global \ 
    gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --global \ 
  --network-endpoint-group=SERVERLESS_NEG_NAME \
  --network-endpoint-group-region=REGION_ID

    לדוגמה:

    gcloud compute backend-services add-backend api-gateway-backend-service \
  --global \
  --network-endpoint-group=api-gateway-serverless-neg-eu \
  --network-endpoint-group-region=europe-west1

    חוזרים על הפקודה הזו כדי להוסיף את ה-NEG השני בלי שרת (serverless) לשירות לקצה העורפי, באמצעות הערכים המתאימים ל-NEG השני בלי שרת (serverless), לדוגמה, api-gateway-serverless-neg-us בשביל my-gateway-us באזור us-central1.

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

    ניתוב תנועה במפת URL לשירות הקצה העורפי לכמה פריסות

    כדי ליצור את מפת URL, מריצים את הפקודה הבאה, כאשר:

    • ‫URL_MAP_NAME הוא השם של מפת ה-URL שרוצים ליצור.
    • ‫BACKEND_SERVICE_NAME הוא השם של שירות הקצה העורפי.
    gcloud compute url-maps create URL_MAP_NAME \
  --default-service BACKEND_SERVICE_NAME

    לדוגמה:

    gcloud compute url-maps create api-gateway-url-map \
  --default-service api-gateway-backend-service

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

    לדוגמה:

    gcloud compute url-maps add-path-matcher api-gateway-url-map \
  --path-matcher-name=my-pm2 \
  --default-service=my-host-default-backend \
  --path-rules="/video=video-service,/video/*=video-service" \
  --new-hosts my-hosts.com
     
    gcloud compute url-maps add-host-rule api-gateway-url-map \
  --hosts=my-app-domain \
  --path-matcher-name=my-app-path-matcher

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

  4. יוצרים אישור SSL לשרת proxy לחלוקת העומס של היעד, כמו שמוצג באיור הבא:

    אישור SSL שמוקצה לשרת ה-proxy של היעד לניתוב מאובטח של תנועה

    כדי ליצור מאזן עומסים ב-HTTPS, נדרש משאב של אישור SSL לשרת ה-proxy של יעד ה-HTTPS. אפשר ליצור משאב של אישור SSL באמצעות אישור SSL בניהול Google או אישור SSL בניהול עצמי. מומלץ להשתמש באישורים שמנוהלים על ידי Google.

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

    כדי ליצור משאב של אישור SSL בניהול Google:

    gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME
  --domains DOMAIN

    כדי ליצור משאב של אישור SSL בניהול עצמי:

    gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
  --certificate CRT_FILE_PATH \
  --private-key KEY_FILE_PATH

  5. יוצרים שרת proxy יעד מסוג HTTP(S) כדי להפנות בקשות למפת כתובות ה-URL, כמו שמוצג באיור הבא:

    שרת proxy לחלוקת העומס שמקבל בקשות ומעביר אותן למפת URL

    כדי ליצור את שרת ה-proxy של היעד, משתמשים בפקודה הבאה, כאשר:

    • ‫TARGET_HTTP_PROXY_NAME הוא שם ה-proxy של היעד שרוצים ליצור.
    • ‫URL_MAP_NAME הוא השם של מפת URL שנוצרה בשלב הקודם.
    • אופציונלי: SSL_CERT_NAME הוא השם של אישור ה-SSL שנוצר.
    gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
  --ssl-certificates=SSL_CERT_NAME
  --url-map=URL_MAP_NAME

    לדוגמה:

    gcloud compute target-http-proxies create api-gateway-https-proxy \
  --ssl-certificates=hello-cert
  --url-map=api-gateway-url-map

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

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

    כדי ליצור את כלל ההעברה, משתמשים בפקודה הבאה, כאשר:

    • ‫HTTPS_FORWARDING_RULE_NAME הוא שם הכלל שרוצים ליצור.
    • ‫TARGET_HTTP_PROXY_NAME הוא שם ה-proxy של היעד שרוצים ליצור.
    gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
  --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
  --global \
  --ports=443

    לדוגמה:

    gcloud compute forwarding-rules create my-fw \
  --target-https-proxy=api-gateway-https-proxy \
  --global \
  --ports=443

עדכון רשומות ה-DNS עם כתובת ה-IP של מאזן העומסים

אם יש לכם דומיין בהתאמה אישית, אתם צריכים לבצע את השלב הזה כדי להגדיר את הגדרות ה-DNS של הדומיין כך שיפנו לכתובת ה-IP החדשה של השירות. היא נדרשת גם אם יצרתם מאזן עומסים ב-HTTP(S) עם אישור שמנוהל על ידי Google (שנדרש לו דומיין). מומלץ להקצות כתובת IP סטטית ולהשתמש בה כשמשתמשים ב-DNS. ההוראות הספציפיות לשלב הזה תלויות בספק ה-DNS.

  1. כדי לשלוח תעבורה למאזן העומסים, רשומת ה-DNS של הדומיין (במדריך הזה, my-app-domain) צריכה להפנות לכתובות ה-IP של מאזן העומסים.

    כדי למצוא את כתובת ה-IP של כלל ההעברה הגלובלי, משתמשים בפקודה הבאה:

    gcloud compute forwarding-rules list

  2. מעדכנים את רשומת ה-DNS A או רשומת AAAA של הדומיין כך שתפנה לכתובת ה-IP של מאזן העומסים, כדי שתעבורת הנתונים שנשלחת לכתובת ה-URL הקיימת של הדומיין המותאם אישית תנותב דרך מאזן העומסים. יכול להיות שיחלפו כמה שניות או כמה שעות עד שהשינוי הזה יתעדכן בשרת ה-DNS.

  3. כדי לוודא ששער התשלום מקבל תנועה, אפשר להשתמש ב-curl או לעבור לכתובת ה-URL בדפדפן. לדוגמה: none https://my-app-domain

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

לתשומת ליבכם

לפני שמיישמים פריסה של API Gateway בכמה אזורים, כדאי לקחת בחשבון את הנקודות הבאות:

  1. ‫API Gateway לא תומך בבדיקות תקינות. בהגדרת הניתוב בין אזורים שמתוארת למעלה, אם השער או שירות לקצה העורפי שלו מחזירים שגיאות באזור מסוים, אבל התשתית הכוללת של API Gateway באזור זמינה ויש לה קיבולת, מאזן העומסים של HTTP(S) לא יפנה את התנועה לאזורים אחרים.

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

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

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