מדיניות 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> ריק, מגבלת קצב אחת נאכפת על כל הבקשות ל-proxy ל-API הזה.

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

מדיניות 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, התעריף האפקטיבי לכל MP עולה מ-10 ל-20 כשמספר ה-MP יורד מ-4 ל-2.

משתני זרימה

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

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

הפניה לשגיאה

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

שגיאות זמן ריצה

השגיאות האלה עשויות להתרחש כשהמדיניות מופעלת.

שגיאות פריסה

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

משתני כשל

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

דוגמה לתגובת שגיאה

למטה מוצגת דוגמה לתגובת שגיאה:

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

דוגמה לכלל שגוי

למטה מוצגת דוגמה לכלל שגיאה לטיפול בתקלה מסוג SpikeArrestViolation:

<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