מגבלות קצב

‫Google Ads API אוכף את הגבלת הקצב של יצירת הבקשות לפי שאילתות לשנייה (QPS) גם על מספרי לקוחות וגם על פרויקטים ב-Google Cloud באופן נפרד. בנוסף למגבלות על מספר הבקשות לדקה (שמודדות את תדירות הקריאות ל-API), ב-Google Ads API יש גם מגבלות על מספר הפעולות לדקה (שמודדות את המספר הכולל של פעולות ה-API בכל הבקשות). ב-Google Ads API נעשה שימוש באלגוריתם token bucket כדי למדוד את הבקשות ולקבוע מגבלת QPS מתאימה, כך שהמגבלה המדויקת משתנה בהתאם לעומס הכולל על השרת בכל זמן נתון.

המטרה של הגבלת קצב יצירת הבקשות היא למנוע ממשתמש אחד לשבש את השירות למשתמשים אחרים, על ידי הצפת שרתי Google Ads API בכמות גדולה של בקשות (בכוונה או בטעות).

בקשות שחורגות ממגבלות הקצב נדחות ומוצגת השגיאה: RESOURCE_TEMPORARILY_EXHAUSTED.

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

יש כמה דרכים לצמצם את הסיכויים לחריגה ממגבלת הקצב. כדי ליצור אפליקציית לקוח חזקה יותר, כדאי להכיר את המושגים של Enterprise Integration Patterns (EIP), כמו העברת הודעות, שליחה מחדש וויסות נתונים.

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

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

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

הגבלת מספר המשימות שפועלות בו-זמנית

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

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

בנוסף, אפשר לשקול ויסות של QPS מצד הלקוח (ראו ויסות והגבלת קצב של יצירת בקשות).

בקשות Batch

כדאי לשקול לאחד כמה פעולות לבקשה אחת. האפשרות הזו רלוונטית בעיקר לקריאות ל-Mutate בשירותים שונים. לדוגמה, אם אתם מעדכנים את הסטטוס של כמה מופעים של AdGroupAd, אתם יכולים להפעיל את MutateAdGroupAds פעם אחת ולהעביר כמה operations במקום להפעיל את MutateAdGroupAds פעם אחת לכל AdGroupAd. דוגמאות נוספות מפורטות בהנחיות לפעולות באצווה.

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

ויסות נתונים והגבלת קצב של יצירת בקשות

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

אפשר לעיין ב-Guava RateLimiter או להטמיע אלגוריתם token bucket משלכם לסביבה מקובצת. לדוגמה, אתם יכולים לנהל אסימונים במאגר נתונים מבוזר בזיכרון עם זמן אחזור קצר, כמו Redis או Memcached, שבו כל לקוח רוכש אסימון ומשתמש בו לפני שהוא מעבד בקשה. אם הטוקנים נגמרים, הלקוח ממתין עד שהקבוצה הבאה של הטוקנים מתחדשת.

הוספה לתור

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

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

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

הקודם
ניהול יעיל של נתונים
הבא
כינויים משותפים