מדיניות של SpikeArst

אתם קוראים את מאמרי העזרה של 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 כדי לתת למדיניות שם אחר, שנשמע טבעי יותר, ולתייג אותה בכלי לעריכת מדיניות ב-UI של ניהול ה-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: http://community.apigee.com/questions/2807/how-does-the-edge-quota-policy-work-when-no-identi.html.

<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>. המגבלה הכוללת היא סכום השיעורים של כל המודולים. כשמוסיפים (או מסירים) חברי פרלמנט, מגבלות הקצב האישיות שלהם לא משתנות, אבל המגבלה הכוללת גדלה (או קטנה).

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

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

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

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

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

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

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

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

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

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