שיטות מומלצות ל-Compute Engine API

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

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

שימוש בספריות לקוח

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

מידע נוסף על ספריות לקוח של Compute Engine ועל שיטות מומלצות לשימוש בספריות לקוח

יצירת בקשות REST באמצעות מסוף Cloud

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

איך יוצרים בקשות REST

המתנה לסיום הפעולות

אל תניחו שפעולה – כל בקשת API שמשנה משאב – הושלמה או הצליחה. במקום זאת, צריך להשתמש בשיטת wait עבור המשאב Operation כדי לוודא שהפעולה בוצעה. (אין צורך לאמת בקשה שלא משנה משאבים – כמו בקשת קריאה באמצעות פועל HTTP‏ GET – כי תגובת ה-API כבר מציינת אם הבקשה הצליחה. לכן, Compute Engine API לא מחזיר משאבי Operation לבקשות האלה).

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

כל בקשה ליצור, לעדכן או למחוק פעולה ממושכת מחזירה משאב Operation שמתעד את הסטטוס של הבקשה. פעולה מסתיימת כשהשדה status של משאב Operation הוא DONE. כדי לבדוק את הסטטוס, משתמשים בשיטה wait שמתאימה להיקף של משאב Operation שהוחזר:

השיטה wait מחזירה ערך כשהפעולה מסתיימת או כשהבקשה מתקרבת למועד האחרון של 2 דקות. כשמשתמשים בשיטה wait, צריך להימנע מסקרים קצרים, כלומר ממצב שבו הלקוחות שולחים בקשות לשרת באופן רציף בלי לחכות לתגובה. שימוש בשיטה wait בלולאת ניסיון חוזר עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff) כדי לבדוק את הסטטוס של הבקשה, במקום שימוש בשיטה get עם סקר קצר לזיהוי שינויים במשאב Operation, עוזר לשמור על מכסות הקצב ומקטין את זמן האחזור.

מידע נוסף על השימוש בשיטה wait ודוגמאות לשימוש בה זמינים במאמר טיפול בתגובות של API.

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

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

עימוד של תוצאות ברשימה

כשמשתמשים בשיטת רשימה (כמו שיטת *.list, שיטת *.aggregatedList או כל שיטה אחרת שמחזירה רשימה), כדאי להשתמש בחלוקה לדפים של התוצאות בכל הזדמנות כדי לוודא שקוראים את כל התגובה. אם לא משתמשים בהחלפה אוטומטית של דפים, אפשר לקבל רק עד 500 רכיבים ראשונים, כפי שנקבע על ידי פרמטר השאילתה maxResults.

מידע נוסף על מעברי עמוד ב-Google Cloud זמין במאמר בנושא מעברי עמוד ברשימה. לפרטים ספציפיים ולדוגמאות, אפשר לעיין במאמרי העזרה של שיטת הרשימה שרוצים להשתמש בה, כמו instances.list.

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

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

כשמשתמשים במסננים עם שיטות *.list או *.aggregatedList, חלים חיובים נוספים על המכסה אם יש יותר מ-10,000 משאבים מסוננים מהבקשות. מידע נוסף מפורט בקטע filtered_list_cost_overhead בנושא מכסות קצב.

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

הסתמכות על קודי שגיאה, לא על הודעות שגיאה

ממשקי Google APIs חייבים להשתמש בקודי השגיאה הקנוניים שמוגדרים על ידי google.rpc.Code, אבל הודעות השגיאה עשויות להשתנות ללא הודעה מוקדמת. הודעות שגיאה מיועדות בדרך כלל לקריאה על ידי מפתחים, ולא על ידי תוכנות.

מידע נוסף על שגיאות ב-API

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

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

  • מומלץ להימנע מסקרים קצרים.
  • השתמשו בשיטת ה-bursting במשורה ובאופן סלקטיבי.
  • תמיד כדאי לבצע את השיחות בלולאת ניסיון חוזר עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff).
  • שימוש במגביל קצב בצד הלקוח.
  • פיצול האפליקציות בין כמה פרויקטים.

איך להימנע מסקרים קצרים

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

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

השתמשו ב-bursting במשורה ובאופן סלקטיבי

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

כשנדרש שימוש ב-bursting, מומלץ להשתמש בממשקי API ייעודיים לפעולות מקובצות, כמו bulk instance API או managed instance groups.

מידע נוסף על בקשות באצווה

תמיד כדאי לבצע את השיחות בלולאת ניסיון חוזר עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff)

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

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

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

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

דוגמה להטמעה של השהיה מעריכית לפני ניסיון חוזר מופיעה במאמר בנושא אלגוריתם של השהיה מעריכית לפני ניסיון חוזר ב-Identity and Access Management API.

שימוש במגביל קצב בצד הלקוח

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

פיצול האפליקציות בין כמה פרויקטים

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

סיכום רשימת המשימות

ברשימת המשימות הבאה מפורטות השיטות המומלצות לשימוש ב-Compute Engine API.

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