הגבלת הקצב של יצירת הבקשות

בדף הזה נסביר איך להשתמש ב-Service Infrastructure כדי להגביל את קצב יצירת הבקשות בשביל שירותים מנוהלים שמשולבים עם Service Management API.

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

הגדרה של הגבלת קצב של יצירת בקשות

כדי להשתמש בתכונה 'הגבלת קצב של יצירת בקשות' צריך להגדיר את המדד _quota metrics_ ואת המכסה _quota limits_ בהגדרות השירות של הפרויקט בשירות המנוהל.

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

מדדי המכסה

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

מגבלות המכסה

מגבלת המכסה מייצגת מגבלה שאפשר לאכוף על מדד המכסה. לדוגמה, מגבלת המכסה יכולה להיות מספר הבקשות בדקה לכל צרכן של השירות. בשלב זה, מגבלת המכסה היחידה שאפשר להשתמש בה היא מגבלה על מספר הבקשות לכל דקה לכל צרכן, ובאופן ספציפי, 1/min/{project}.‏

הגבלת הקצב של יצירת הבקשות לכל צמד (שירות, צרכן) נקבעת בפועל לפי 3 הגדרות:

  • מגבלת ברירת המחדל שצוינה לשירות המנוהל.
  • שינוי מברירת המחדל שהגדיר הבעלים של השירות המנוהל עבור צרכן השירות.
  • שינוי מברירת המחדל שהגדיר צרכן השירות עבור עצמו.

המגבלה של הגבלת הקצב של יצירת הבקשות פועלת לפי העקרונות הבאים:

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

אכיפה של הגבלת קצב של יצירת בקשות

כדי לאכוף את הגבלת הקצב של יצירת הבקשות, כל שרת ששייך לשירות מנוהל צריך להפעיל את השיטה services.allocateQuota של Service Control API באופן קבוע. אם התשובה שמוחזרת מהשיטה services.allocateQuota מציינת שהשימוש חורג מהמגבלה, השרת צריך לדחות את הבקשה הנכנסת ולהחזיר את השגיאה 429. למידע נוסף, עיינו במסמכי התיעוד של השיטה services.allocateQuota.

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

בעזרת הדוגמה הבאה תוכלו להבין איך מפעילים את השיטה services.allocateQuota כדי לבדוק אם יש הגבלת קצב של יצירת בקשות. הפרמטרים החשובים של הבקשה הם שם השירות, מזהה הצרכן, שם המדד וערך המדד, וחשוב להגדיר אותם נכון. המטרה של השיטה services.allocateQuota היא לנסות להגדיל את השימוש בכמות שצוינה עבור הצירוף (שירות, צרכן, מדד) ב-tuple. אם השימוש המוגדל יחרוג מהמגבלה, תוחזר שגיאה. בדוגמה הבאה השתמשנו בפקודה gcurl כדי להדגים את ההפעלה. במאמר תחילת העבודה עם Service Control API מוסבר איך מגדירים את מה שדרוש לצורך ההפעלה הזו.

gcurl -d '{
  "allocateOperation": {
    "operationId": "123e4567-e89b-12d3-a456-426655440000",
    "methodName": "google.example.hello.v1.HelloService.GetHello",
    "consumerId": "project:endpointsapis-consumer",
    "quotaMetrics": [{
      "metricName": "endpointsapis.appspot.com/requests",
      "metricValues": [{
        "int64Value": 1
      }]
    }],
    "quotaMode": "NORMAL"
  }
}' https://servicecontrol.googleapis.com/v1/services/endpointsapis.appspot.com:allocateQuota
{
  "operationId": "123e4567-e89b-12d3-a456-426655440000",
  "quotaMetrics": [
    {
      "metricName": "serviceruntime.googleapis.com/api/consumer/quota_used_count",
      "metricValues": [
        {
          "labels": {
            "/quota_name": "endpointsapis.appspot.com/requests"
          },
          "int64Value": "1"
        }
      ]
    }
  ],
  "serviceConfigId": "2017-09-10r0"
}

טיפול בשגיאות

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

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

שגיאת Fail Open

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

אם אתם משתמשים בשיטה services.allocateQuota בשירות שלכם, אתם צריכים להתעלם מהשגיאות 500,‎ 503 ו-504, בלי לנסות שוב. כדי למנוע תלות חזקה בזמינות של הגבלת הקצב של יצירת הבקשות, ב-Service Control API מונפקת באופן קבוע כמות מוגבלת של הזרקת שגיאות.