SpikeArest की नीति

Apigee Edge के दस्तावेज़ देखे जा रहे हैं.
Apigee X के दस्तावेज़ पर जाएं. info

स्पाइक अरेस्ट नीति, <Rate> एलिमेंट की मदद से, ट्रैफ़िक में अचानक होने वाली बढ़ोतरी से सुरक्षा करती है. यह एलिमेंट, एपीआई प्रॉक्सी से प्रोसेस किए गए अनुरोधों की संख्या को सीमित करता है. साथ ही, उन्हें बैकएंड में भेजता है. इससे परफ़ॉर्मेंस में होने वाली रुकावटों और डाउनटाइम से सुरक्षा मिलती है.

<SpikeArrest> एलिमेंट

यह स्पाइक अरेस्ट नीति तय करता है.

<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>

इस एलिमेंट में ये एट्रिब्यूट शामिल होते हैं, जो सभी नीतियों में शामिल हैं:

उदाहरण

यहां कुछ उदाहरण दिए गए हैं, जिनसे पता चलता है कि स्पाइक अरेस्ट की नीति का इस्तेमाल कैसे किया जा सकता है:

<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 एट्रिब्यूट के साथ किया जाता है. इससे, मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) के प्रॉक्सी एडिटर में नीति को लेबल किया जा सकता है. इसके लिए, किसी दूसरे और ज़्यादा स्वाभाविक नाम का इस्तेमाल किया जाता है.

<DisplayName> एलिमेंट, सभी नीतियों में शामिल होता है.

<DisplayName> एलिमेंट में इस सिंटैक्स का इस्तेमाल किया जाता है:

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

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

<DisplayName> एलिमेंट में कोई एट्रिब्यूट या चाइल्ड एलिमेंट नहीं है.

<Identifier>

इस कुकी की मदद से, अनुरोधों को ग्रुप करने का तरीका चुना जा सकता है, ताकि क्लाइंट के आधार पर स्पाइक अरेस्ट नीति लागू की जा सके. उदाहरण के लिए, डेवलपर आईडी के हिसाब से अनुरोधों को ग्रुप किया जा सकता है. ऐसे में, हर डेवलपर के अनुरोधों को, स्पाइक अरेस्ट रेट में गिना जाएगा. प्रॉक्सी के सभी अनुरोधों को नहीं गिना जाएगा.

अनुरोध थ्रॉटलिंग पर ज़्यादा बेहतर कंट्रोल के लिए, <MessageWeight> एलिमेंट के साथ इसका इस्तेमाल करें.

अगर आपने <Identifier> एलिमेंट को खाली छोड़ दिया है, तो उस एपीआई प्रॉक्सी में किए गए सभी अनुरोधों के लिए, दर की एक सीमा लागू की जाती है.

<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>

इससे हर मैसेज के लिए तय किए गए वज़न की जानकारी मिलती है. मैसेज के साइज़ से, स्पाइक अरेस्ट रेट के हिसाब पर एक अनुरोध के असर में बदलाव होता है. मैसेज का वेट, कोई भी फ़्लो वैरिएबल हो सकता है. जैसे, एचटीटीपी हेडर, क्वेरी पैरामीटर, फ़ॉर्म पैरामीटर या मैसेज के मुख्य हिस्से का कॉन्टेंट. JavaScript नीति या AssignMessage नीति का इस्तेमाल करके भी कस्टम वैरिएबल का इस्तेमाल किया जा सकता है.

<Identifier> के साथ इसका इस्तेमाल करके, खास क्लाइंट या ऐप्लिकेशन से मिले अनुरोधों को और थ्रॉटल किया जा सकता है.

उदाहरण के लिए, अगर स्पाइक अरेस्ट <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>

ऑटो-स्केलिंग ग्रुप का इस्तेमाल करते समय, यह मैसेज प्रोसेसर (एमपी) में स्पाइक अरेस्ट की संख्या को डिस्ट्रिब्यूट करता है.

<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 होती है.

यहां दी गई टेबल में, <UseEffectiveCount> एलिमेंट के एट्रिब्यूट के बारे में बताया गया है:

<UseEffectiveCount> का असर, इसकी वैल्यू पर निर्भर करता है:

• true: किसी एमपी के स्पाइक रेट की सीमा, <Rate> को एक ही पॉड में मौजूद एमपी की मौजूदा संख्या से भाग देने पर मिलती है. कुल सीमा, <Rate> की वैल्यू है. जब एमपी को डाइनैमिक तरीके से जोड़ा (या हटाया) जाता है, तो उनकी अलग-अलग स्पाइक रेट की सीमाएं बढ़ (या घट) जाएंगी. हालांकि, कुल सीमा वही रहेगी.
• false: हर एमपी के लिए, स्पाइक रेट की सीमा, उसके <Rate> की वैल्यू होती है. कुल सीमा, सभी सांसदों की दरों का योग होती है. एमपी जोड़ने (या हटाने) पर, उनकी स्पाइक रेट की सीमाएं वही रहेंगी. हालांकि, कुल सीमा बढ़ जाएगी (या कम हो जाएगी).

SpikeArrest नीति, "टोकन बकेट" एल्गोरिदम का इस्तेमाल करती है. यह एल्गोरिदम, ट्रैफ़िक में अचानक होने वाली बढ़ोतरी को कम करता है. इसके लिए, यह आपकी तय की गई दर की सीमा को छोटे-छोटे इंटरवल में बांट देता है. इस तरीके की एक समस्या यह है कि कम समय में किए गए कई सही अनुरोधों को अस्वीकार किया जा सकता है.

उदाहरण के लिए, मान लें कि आपने 30pm (हर मिनट में 30 अनुरोध) की दर डाली है. टेस्टिंग के दौरान, आपको लग सकता है कि एक मिनट में 30 अनुरोध भेजे जा सकते हैं. भले ही, वे एक सेकंड में भेजे गए हों. हालांकि, नीति के तहत सेटिंग लागू करने का तरीका यह नहीं है. अगर इस बारे में सोचा जाए, तो एक सेकंड में 30 अनुरोधों को कुछ एनवायरमेंट में मिनी स्पाइक माना जा सकता है.

• हर मिनट के हिसाब से तय की गई दरें, सेकंड के इंटरवल में अनुमति दिए गए पूरे अनुरोधों में बदल जाती हैं.
  

  उदाहरण के लिए, 30pm को इस तरह से स्मूथ किया जाता है:
  60 सेकंड (1 मिनट) / 30pm = 2 सेकंड के अंतराल, या हर 2 सेकंड में एक अनुरोध की अनुमति है. दो सेकंड के अंदर किया गया दूसरा अनुरोध पूरा नहीं होगा. इसके अलावा, एक मिनट में 31वां अनुरोध करने पर, उसे पूरा नहीं किया जा सकेगा.

• प्रति सेकंड की दर को, मिलीसेकंड के इंटरवल में अनुमति दिए गए पूरे अनुरोधों में बदल दिया जाता है.

  उदाहरण के लिए, 10ps को इस तरह से स्मूथ किया जाता है:
  1, 000 मिलीसेकंड (एक सेकंड) / 10ps = 100 मिलीसेकंड के इंटरवल या हर 100 मिलीसेकंड में एक अनुरोध की अनुमति. 100 मि॰से॰ के अंदर किया गया दूसरा अनुरोध पूरा नहीं होगा. इसके अलावा, एक सेकंड में 11वां अनुरोध करने पर भी अनुरोध पूरा नहीं होगा.

नीचे दी गई टेबल में, हर एमपी की असरदार रेट लिमिट पर <UseEffectiveCount> का असर दिखाया गया है:

इस उदाहरण में ध्यान दें कि जब एमपी की संख्या को 4 से घटाकर 2 कर दिया जाता है और <UseEffectiveCount> false होता है, तो हर एमपी के लिए असरदार दर वही रहती है (10 पर). हालांकि, जब <UseEffectiveCount> true होता है, तो एमपी की संख्या 4 से 2 होने पर, हर एमपी के लिए असरदार दर 10 से 20 हो जाती है.

फ़्लो वैरिएबल

जब स्पाइक अरेस्ट की नीति लागू होती है, तो यह फ़्लो वैरिएबल भर जाता है:

ज़्यादा जानकारी के लिए, फ़्लो वैरिएबल का रेफ़रंस देखें.

गड़बड़ी की जानकारी

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>

कोटा या स्पाइक अरेस्ट नीति के तहत तय की गई दर की सीमा से ज़्यादा अनुरोध करने पर, मौजूदा एचटीटीपी स्टेटस कोड 429 (बहुत ज़्यादा अनुरोध) है. एचटीटीपी स्टेटस कोड को 500 (इंटरनल सर्वर की गड़बड़ी) में बदलने के लिए, संगठन की प्रॉपर्टी अपडेट करें एपीआई का इस्तेमाल करके, features.isHTTPStatusTooManyRequestEnabled प्रॉपर्टी को false पर सेट करें.

उदाहरण के लिए:

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>"

स्कीमा

नीति के हर टाइप को एक्सएमएल स्कीमा (.xsd) के ज़रिए तय किया जाता है. रेफ़रंस के लिए, नीति के स्कीमा GitHub पर उपलब्ध हैं.

मिलते-जुलते विषय

• कोटा नीति: कोटा नीति, ताकि अलग-अलग क्लाइंट पर ट्रैफ़िक को सीमित किया जा सके
• अनुरोध संख्या सीमित करने के बारे में खास जानकारी के लिए, अनुरोध संख्या सीमित करना लेख पढ़ें
• कोटा और SpikeArrest नीतियों की तुलना करना
• एपीआई प्रॉक्सी के वर्किंग सैंपल