מדיניות SpikeArrest

אתם קוראים את מאמרי העזרה של Apigee Edge.
אפשר לעיין במסמכי התיעוד של Apigee X. מידע

המדיניות Spike Arrest (מניעת עליות פתאומיות בתנועה) מגנה מפני עליות פתאומיות בתנועה באמצעות הרכיב <Rate>. האלמנט הזה מגביל את מספר הבקשות שמעובדות על ידי שרת proxy של API ונשלחות אל ה-Backend, כדי להגן מפני עיכובים בביצועים והשבתה.

רכיב <SpikeArrest>

הגדרת המדיניות Spike Arrest (מניעת עליות פתאומיות בתנועה).

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <DisplayName>display_name</DisplayName>
  <Properties/>
  <Identifier ref="flow_variable"/>
  <MessageWeight ref="flow_variable"/>
  <Rate ref="flow_variable">rate[pm|ps]</Rate>
  <UseEffectiveCount>[false|true]</UseEffectiveCount>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="Spike-Arrest-1">
  <DisplayName>Spike Arrest-1</DisplayName>
  <Properties/>
  <Identifier ref="request.header.some-header-name"/>
  <MessageWeight ref="request.header.weight"/>
  <Rate>30ps</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

לרכיב הזה יש את המאפיינים הבאים, המשותפים לכל כללי המדיניות:

דוגמאות

בדוגמאות הבאות אפשר לראות כמה מהדרכים שבהן אפשר להשתמש במדיניות Spike Arrest:

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</Rate>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
  <Identifier ref="client_id" />
  <MessageWeight ref="request.header.weight" />
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate ref="request.header.runtime_rate" />
</SpikeArrest>

curl http://myorg-myenv.apigee.net/price -H 'runtime_rate:30ps'

הפניה לרכיב צאצא

בקטע הזה מתוארים רכיבי הבן של <SpikeArrest>.

<DisplayName>

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

הרכיב <DisplayName> משותף לכל סוגי המדיניות.

התחביר של רכיב <DisplayName> הוא:

<PolicyElement>
  <DisplayName>policy_display_name</DisplayName>
  ...
</PolicyElement>

<PolicyElement>
  <DisplayName>My Validation Policy</DisplayName>
</PolicyElement>

לרכיב <DisplayName> אין מאפיינים או רכיבי צאצא.

<Identifier>

מאפשרת לבחור איך לקבץ את הבקשות כדי שאפשר יהיה להחיל את המדיניות של מניעת עלייה פתאומית על סמך הלקוח. לדוגמה, אפשר לקבץ בקשות לפי מזהה מפתח. במקרה כזה, הבקשות של כל מפתח ייספרו במסגרת שיעור מניעת העלייה הפתאומית של הבקשות שלו, ולא כל הבקשות לשרת ה-proxy.

אפשר להשתמש בו בשילוב עם רכיב <MessageWeight> כדי לקבל שליטה מדויקת יותר על הגבלת קצב הבקשות.

אם משאירים את הרכיב <Identifier> ריק, מגבלת קצב אחת נאכפת על כל הבקשות ל-API proxy הזה.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Identifier ref="flow_variable"/>
</SpikeArrest>
        

<SpikeArrest name="Spike-Arrest-1">
  <Identifier ref="developer.id"/>
  <Rate>42pm</Rate/>
</SpikeArrest>

בטבלה הבאה מתוארים המאפיינים של <Identifier>:

הנושא הזה מוסבר גם בפוסט הבא בקהילת Apigee: Quota Identifier Across Different Policies.

<MessageWeight>

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

אפשר להשתמש בו בשילוב עם <Identifier> כדי לווסת עוד יותר את הבקשות לפי לקוחות או אפליקציות ספציפיים.

לדוגמה, אם הערך של Spike Arrest <Rate> הוא 10pm, ואפליקציה שולחת בקשות עם משקל של 2, אז מותר לשלוח מהלקוח הזה רק חמש הודעות בדקה, כי כל בקשה נחשבת כ-2.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <MessageWeight ref="flow_variable"/>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>12pm</Rate>
  <Identifier ref="client_id" />
  <MessageWeight ref="request.header.weight" />
</SpikeArrest>

בטבלה הבאה מתוארים המאפיינים של <MessageWeight>:

<Rate>

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

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <Rate ref="flow_variable">rate[pm|ps]</Rate>
</SpikeArrest>

<SpikeArrest name="Spike-Arrest-1">
  <Rate>5ps</Rate>
</SpikeArrest>

<SpikeArrest async="false" continueOnError="false" enabled="true" name="SpikeArreast">
  <DisplayName>SpikeArreast</DisplayName>
  <Rate>300pm</Rate>
</SpikeArrest>

בטבלה הבאה מתוארים המאפיינים של <Rate>:

<Rate ref="request.header.custom_rate">1pm</Rate>

<UseEffectiveCount>

מפיצה את הספירות של Spike Arrest בין מעבדי ההודעות (MPs) כשמשתמשים בקבוצות של שינוי גודל אוטומטי.

<SpikeArrest
  continueOnError="[false|true]"
  enabled="[true|false]"
  name="policy_name"
>
  <UseEffectiveCount>[false|true]</UseEffectiveCount>
</SpikeArrest>

<SpikeArrest name='Spike-Arrest-1'>
  <Rate>40ps</Rate>
  <UseEffectiveCount>true</UseEffectiveCount>
</SpikeArrest>

הרכיב <UseEffectiveCount> הוא אופציונלי. ערך ברירת המחדל הוא false אם לא מציינים את הרכיב במדיניות Spike Arrest.

בטבלה הבאה מתוארים המאפיינים של רכיב <UseEffectiveCount>:

ההשפעה של <UseEffectiveCount> תלויה בערך שלו:

• ‫true: מגבלת קצב העלייה של חברות בפרלמנט היא <Rate> חלקי המספר הנוכחי של חברות בפרלמנט באותו פוד. המגבלה המצטברת היא הערך של <Rate>. כשחברי פרלמנט מתווספים באופן דינמי (או מוסרים), מגבלות הקצב של העלייה החדה של כל אחד מהם גדלות (או קטנות), אבל המגבלה הכוללת נשארת זהה.
• ‫false: מגבלת קצב העלייה של כל MP היא פשוט הערך של <Rate>. המגבלה הכוללת היא סכום השיעורים של כל המודולים. כשמוסיפים (או מסירים) חברי פרלמנט, מגבלות הקצב האישיות שלהם לא משתנות, אבל המגבלה הכוללת גדלה (או קטנה).

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

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

• שיעורים לדקה מוחלקים לבקשות מלאות שמותרות במרווחים של שניות.
  

  לדוגמה, אם מגדירים 30pm, המערכת תחשב את המרווחים כך:
  60 שניות (דקה אחת) חלקי 30pm = מרווחים של 2 שניות, כלומר מותר לשלוח בקשה אחת כל 2 שניות. בקשה שנייה בתוך 2 שניות תיכשל. בנוסף, בקשה 31 בתוך דקה תיכשל.

• שיעורים של לשנייה מוחלקים לבקשות מלאות שמותרות במרווחי זמן של אלפיות השנייה.

  לדוגמה, אם המגבלה היא 10ps, המערכת תפעל כך:
  1,000 אלפיות שנייה (שנייה אחת) חלקי 10ps = מרווחים של 100 אלפיות שנייה, או בקשה אחת מותרת כל 100 אלפיות שנייה. בקשה שנייה בתוך 100 אלפיות השנייה תיכשל. בנוסף, בקשה 11 בתוך שנייה תיכשל.

בטבלה הבאה מוצגת ההשפעה של <UseEffectiveCount> על המגבלה של הגבלת הקצב של יצירת הבקשות של כל MP:

בדוגמה הזו, שימו לב שכאשר מספר המילימטרים יורד מ-4 ל-2, והערך של <UseEffectiveCount> הוא false, התעריף האפקטיבי למילימטר נשאר זהה (10). אבל אם הערך של <UseEffectiveCount> הוא true, הריבית בפועל לכל נקודת אחוז עולה מ-10 ל-20 כשהמספר של נקודות האחוז יורד מ-4 ל-2.

משתני תהליך

כשמדיניות Spike Arrest מופעלת, משתנה הזרימה הבא מאוכלס:

מידע נוסף זמין במאמר בנושא משתני זרימה.

הפניה לשגיאה

This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.

Runtime errors

These errors can occur when the policy executes.

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Fault variables

These variables are set when a runtime error occurs. For more information, see What you need to know about policy errors.

Example error response

Shown below is an example error response:

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.SpikeArrestViolation"
      },
      "faultstring":"Spike arrest violation. Allowed rate : 10ps"
   }
}

Example fault rule

Shown below is an example fault rule to handle a SpikeArrestViolation fault:

<FaultRules>
    <FaultRule name="Spike Arrest Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "SpikeArrestViolation") </Condition>
        </Step>
        <Condition>ratelimit.Spike-Arrest-1.failed=true</Condition>
    </FaultRule>
</FaultRules>

קוד הסטטוס הנוכחי של HTTP לחריגה ממגבלת קצב שהוגדרה על ידי מדיניות מכסה או מדיניות למניעת עליות פתאומיות הוא 429 (יותר מדי בקשות). כדי לשנות את קוד הסטטוס של HTTP ל-500 (שגיאה פנימית בשרת), צריך להגדיר את המאפיין features.isHTTPStatusTooManyRequestEnabled ל-false באמצעות ה-API‏ Update organization properties.

לדוגמה:

curl -u email:password -X POST -H "Content-type:application/xml" http://api.enterprise.apigee.com/v1/organizations/myorg -d \
"<Organization type="trial" name="MyOrganization">
    <Properties>
        <Property name="features.isHTTPStatusTooManyRequestEnabled">true</Property>
        . . .
    </Properties>
</Organization>"

סכימות

כל סוג מדיניות מוגדר על ידי סכימת XML ‏ (.xsd). סכימות מדיניות זמינות ב-GitHub.

נושאים קשורים

• מדיניות בנושא מכסות: מדיניות בנושא מכסות, כדי להגביל את התנועה בלקוחות ספציפיים
• הגבלת קצב של יצירת בקשות – סקירה כללית על הגבלת קצב של יצירת בקשות
• השוואה בין מכסה לבין מדיניות של SpikeArrest
• דוגמאות עובדות של שרתי proxy ל-API