Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

יצירת פריסות מרובות אזורים ל-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) בפרויקט ב-Cloud. לשם כך נדרש תפקיד בעלים או עורך בפרויקט, או תפקידי ה-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(S)

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

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

כדי ליצור 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.
יוצרים שירות לקצה העורפי כדי להגדיר איך Cloud Load Balancing יבזר את תעבורת הנתונים.

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

כדי ליצור שירות לקצה העורפי ולהוסיף את ה-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.
יוצרים מפת 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 בדוגמה הזו מכוונת רק לשירות לקצה העורפי אחד שמייצג שער יחיד, ולכן לא נדרשים כללי מארח או התאמות נתיב. אם יש לכם יותר משירות קצה עורפי אחד, אתם יכולים להשתמש בכללי מארח כדי להפנות בקשות לשירותים שונים על סמך שם המארח. אפשר להשתמש ב-path matchers כדי להפנות בקשות לשירותים שונים על סמך נתיב הבקשה.

לדוגמה:
```
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.
יוצרים אישור SSL לשרת ה-proxy של היעד, כמו שמוצג באיור הבא:

כדי ליצור מאזן עומסים ב-HTTPS, נדרש משאב של אישור SSL עבור שרת היעד של ה-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
```
יוצרים שרת proxy של HTTP(S) ליעד כדי לנתב בקשות למפת 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
```
יוצרים כלל העברה כדי לנתב בקשות נכנסות לשרת ה-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.

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

כדי למצוא את כתובת ה-IP של כלל ההעברה הגלובלי, משתמשים בפקודה הבאה:
```
gcloud compute forwarding-rules list
```
מעדכנים את רשומת ה-DNS A או רשומת AAAA של הדומיין כך שהיא תפנה לכתובת ה-IP של מאזן העומסים, כדי שהתעבורה שנשלחת לכתובת ה-URL הקיימת של הדומיין המותאם אישית תנותב דרך מאזן העומסים. יכול להיות שיחלפו כמה שניות או כמה שעות עד שהשינוי הזה יתעדכן בשרת ה-DNS.
כדי לוודא שהשער מקבל תנועה, אפשר להשתמש ב-curl או להיכנס לכתובת ה-URL בדפדפן. לדוגמה: https://my-app-domain

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

לתשומת ליבכם

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

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

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

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