תלויות במישור הבקרה הן ממשקי ה-API ושירותי המטא-נתונים שמנהלים את הגדרות המשאבים באפליקציות שלכם. כדי ליצור אפליקציות עם זמינות גבוהה ועמידות גבוהה, וכדי לבצע אוטומציה של תהליכי פריסה ב-Compute Engine, חשוב לבודד את התלות הזו. למרות שנקודות קצה ל-API גלובליות מספקות מודל עקביות חזק בכל האזורים, כל עלייה זמנית בזמן טעינה או שיבוש במישור הבקרה הגלובלי או באזור מרוחק עלולים לעכב או לחסום שירותים מקומיים.
כדי ליצור אפליקציות אמינות שיכולות לפעול באופן עצמאי בכל אזור גם אם יש שיבושים ב-API ברמה הגלובלית, אפשר להגדיר את השירותים כך שישאלו שאילתות לגבי תצוגות אזוריות של משאבים גלובליים. כשמשתמשים בנקודות קצה אזוריות לקריאה בלבד של API כדי לקרוא הגדרות של משאבים, האפליקציה מתקשרת רק עם מישור הבקרה של אזור ספציפי. בידוד התקלות האזורי הזה מבטיח שהשירותים שלכם יישארו עם זמינות גבוהה ורספונסיביים, גם במקרה של שיבושים גלובליים.
סוגי המשאבים שנתמכים
נקודות קצה (endpoints) של תצוגה אזורית זמינות למשאבים הגלובליים הבאים:
- Projects: נקודת הקצה
projectViewsמספקת גישה אזורית לקריאה בלבד למשאב הפרויקט הגלובלי. - קובצי אימג' של מערכת ההפעלה: נקודת הקצה
imageViewsמספקת גישה אזורית לקריאה בלבד אל משאבי קובצי אימג' של מערכת ההפעלה ברמה הגלובלית.
מגבלות
המטא-נתונים של כל המשאבים הגלובליים מאוחסנים במסד נתונים גלובלי מרכזי. כשיוצרים, קוראים, מעדכנים או מוחקים משאב באמצעות נקודות קצה גלובליות סטנדרטיות של API, בקשות Compute Engine קוראות ישירות ממסד הנתונים הגלובלי המרכזי וכותבות ישירות אליו, וכך מספקות עקביות חזקה.
נקודות קצה (endpoints) של תצוגה אזורית קוראות מטא-נתונים של משאבים מרפליקות אזוריות לקריאה בלבד של מסד הנתונים הגלובלי המרכזי. השינויים מועתקים באופן אסינכרוני לרפליקות האזוריות האלה, ולכן יכול להיות שתיתקלו בהתנהגויות הבאות כשאתם שולחים שאילתות לתצוגות אזוריות:
- עיכובים קלים: כשיוצרים, מעדכנים או מוחקים משאב באופן גלובלי, יכול להיות שיעברו עד 60 שניות עד שהשינוי יועתק לכל נקודות הקצה של התצוגה האזורית. במהלך חלון הזמן הקצר הזה, קריאה מתצוגה אזורית עשויה להחזיר נתונים קצת יותר ישנים.
- חזרה אוטומטית למצב קודם: אם תבקשו משאב מתצוגה אזורית לפני שההעתקה לאזור הזה תסתיים, Compute Engine יקרא באופן אוטומטי ישירות ממסד הנתונים הגלובלי המרכזי, כדי שהבקשה תצליח.
ההבדלים בין תצוגה אזורית לבין API גלובלי
בכרטיסיות הבאות מפורטים ההבדלים בין נקודות הקצה של התצוגה האזורית לבין נקודות הקצה הגלובליות הרגילות של ה-API, לכל סוג משאב:
פרויקטים
בטבלאות הבאות מפורטים ההבדלים בין נקודות הקצה של התצוגה האזורית לבין נקודות הקצה הגלובליות הרגילות של ה-API, עבור משאב הפרויקט:
| תכונה | Global API | Regional view API |
|---|---|---|
| נקודת קצה (endpoint) | עולמי | אזורי |
| כתובת ה-URL של מקור המידע | /projects/PROJECT_ID |
/projects/PROJECT_ID/regions/REGION/projectViews |
| דומיין כשל | עולמי | מבודד לאזור שצוין |
| השיטות הנתמכות | קריאה וכתיבה | קריאה בלבד (Get) |
| מכסת API | צריכת מכסות גלובליות של קריאה וכתיבה ב-API | צריכת מכסות קריאה של API אזורי |
| עקביות קריאה בסיום הכתיבה | עקביות חזקה (קריאה ממסד נתונים גלובלי מרכזי) | עקביות הדרגתית (קריאה מרפליקה אזורית) |
| התנהגות של שדה המכסה | מחזירה את המערך quota, תוך שימוש ב-fanout בין אזורים כדי לספק נתוני שימוש במכסות בזמן אמת בכל האזורים והתחומים. |
המערך quota לא נכלל באובייקט Project שמוחזר. מכיוון שנקודת הקצה (endpoint) של projectViews קוראת אך ורק מרפליקה אזורית ולא מבצעת fanout בין אזורים כדי לאסוף מדדי מכסות, המערך quota לא מוחזר בכלל. כדי לראות את מגבלות המכסות ואת מדדי השימוש המדויקים בזמן אמת, צריך לשלוח שאילתה לנקודת הקצה (endpoint) הגלובלית projects.get. |
קובצי אימג' של מערכת ההפעלה
בטבלאות הבאות מפורטים ההבדלים בין נקודות קצה של תצוגה אזורית לבין נקודות קצה גלובליות סטנדרטיות של API, למשאב של קובץ אימג' של מערכת ההפעלה:
| תכונה | Global API | Regional view API |
|---|---|---|
| נקודת קצה (endpoint) | עולמי | אזורי |
| כתובת ה-URL של מקור המידע | /projects/PROJECT_ID/global/images |
/projects/PROJECT_ID/regions/REGION/imageViews |
| דומיין כשל | עולמי | מבודד לאזור שצוין |
| השיטות הנתמכות | קריאה וכתיבה | קריאה בלבד (Get ו-List) |
| מכסת API | צריכת מכסות גלובליות של קריאה וכתיבה ב-API | צריכת מכסות קריאה של API אזורי |
| עקביות קריאה בסיום הכתיבה | עקביות חזקה (קריאה ממסד נתונים גלובלי מרכזי) | עקביות הדרגתית (קריאות משכפול אזורי) |
תמחור
הגישה לתצוגות אזוריות דרך נקודות קצה ל-API אזוריות לקריאה בלבד לא כרוכה בחיובים נוספים. כמו בקשות גלובליות רגילות ל-Compute Engine API, בקשות לנקודות קצה של תצוגות אזוריות מנצלות את מכסות ה-API הרגילות של הפרויקט, ובמיוחד את מכסות הקריאה האזוריות של ה-API, אבל לא כרוכות בעמלות נוספות.
שיטות מומלצות להשגת זמינות גבוהה
כדי למקסם את העמידות של האפליקציה, למנוע עומס לא פרופורציונלי על מישור הבקרה ולהימנע מיצירת נקודות חמות באזור יחיד, כדאי לפעול לפי שיטות האמינות הבאות כשמגדירים מערכות אוטומטיות ועומסי עבודה של לקוחות:
- שליחת שאילתות לאזורים מקומיים כדי לצמצם את האזור המושפע: שולחים בקשות API של
projectViewsו-imageViewsלאזור המדויק שבו פועלים עומס העבודה של הלקוח או אשכול הפריסה. לעומסי עבודה אזוריים, משתמשים באזור ההורה. לוקליזציה של קריאות מבטיחה ששיבוש ברשת או הפסקה זמנית בשירות באזור אחר לא ישפיעו על השירות המקומי שלכם. - זיהוי דינמי של מחרוזות אזור: לא לכתוב בתוך הקוד מחרוזות אזור ספציפיות שמוגדרות כברירת מחדל בספריות לקוח משותפות או בתבניות פריסה. במקום זאת, צריך לזהות באופן דינמי את אזור הביצוע הנוכחי של עומס העבודה מסביבת זמן הריצה המקומית שלו, כדי שהמעבר לגיבוי בעת כשל בכמה אזורים יפעל באופן שקוף.
- שימוש בבידוד מכסות אזוריות כדי למנוע תחרות בין עומסי עבודה:
Compute Engine אוכף את הגבלת קצב של יצירת בקשות של ה-API בכל אזור. עליות חדות בתנועה או סקריפטים שיוצאים משליטה באזור מסוים צורכים את מכסת הקריאה מהקטגוריה של אותו אזור, בלי להשפיע על הזמינות של ה-API או להפעיל מגבלות קצב (
429 Too Many Requests) באזורים קריטיים אחרים.
המאמרים הבאים
- איך ניגשים למשאבים גלובליים ברמה האזורית כדי להשיג זמינות גבוהה
- איך פותרים בעיות בתצוגות אזוריות של משאבים גלובליים