Kebijakan kuota

Anda sedang melihat dokumentasi Apigee Edge.
Buka Dokumentasi Apigee X. info

Apa

Gunakan kebijakan Kuota untuk mengonfigurasi jumlah pesan permintaan yang diizinkan oleh proxy API periode waktu, seperti menit, jam, hari, minggu, atau bulan. Anda dapat menetapkan kuota untuk sama untuk semua aplikasi yang mengakses proxy API, atau Anda dapat menyetel kuota berdasarkan:

• Produk yang berisi proxy API
• Aplikasi yang meminta API
• Developer aplikasi
• Banyak kriteria lain

Jangan gunakan Kuota untuk melindungi dari lonjakan traffic secara keseluruhan. Untuk itu, gunakan Spike Arrest lebih lanjut. Lihat Penangkapan Lonjakan kebijakan kami.

Video

Video berikut memperkenalkan pengelolaan kuota dengan kebijakan Kuota:

Contoh

Contoh kode kebijakan ini menggambarkan cara memulai dan mengakhiri periode kuota dengan:

<Quota name="CheckQuota"> 
  <Interval ref="verifyapikey.verify-api-key.apiproduct.developer.quota.interval">1</Interval>
  <TimeUnit ref="verifyapikey.verify-api-key.apiproduct.developer.quota.timeunit">hour</TimeUnit>
  <Allow count="200" countRef="verifyapikey.verify-api-key.apiproduct.developer.quota.limit"/>
</Quota>

<Quota name="DeveloperQuota"> 
  <Identifier ref="verifyapikey.verify-api-key.client_id"/> 
  <Interval ref="verifyapikey.verify-api-key.developer.timeInterval"/> 
  <TimeUnit ref="verifyapikey.verify-api-key.developer.timeUnit"/> 
  <Allow countRef="verifyapikey.verify-api-key.developer.limit"/> 
</Quota>

<Quota name="QuotaPolicy" type="calendar">
  <StartTime>2017-02-18 10:30:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<Quota name="QuotaPolicy">
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<AssignMessage async="false" continueOnError="false" enabled="true" name="ReturnQuotaVars">
    <AssignTo createNew="false" type="response"/>
    <Set>
        <Headers>
            <Header name="QuotaLimit">{ratelimit.QuotaPolicy.allowed.count}</Header>
            <Header name="QuotaUsed">{ratelimit.QuotaPolicy.used.count}</Header>
            <Header name="QuotaResetUTC">{ratelimit.QuotaPolicy.expiry.time}</Header>
        </Headers>
    </Set>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</AssignMessage>

<Quota name="MyQuota">
  <Interval>1</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="10000"/>
</Quota>

<Quota name="QuotaPolicy" type="calendar">
  <Identifier ref="request.header.clientId"/> 
  <StartTime>2017-02-18 10:00:00</StartTime>
  <Interval>5</Interval>
  <TimeUnit>hour</TimeUnit>
  <Allow count="99"/>
</Quota>

<Identifier ref="request.queryparam.id"/>

<Identifier ref="verifyapikey.verify-api-key.client_id"></Identifier>

<Quota name="QuotaPolicy">
  <Interval>1</Interval>
  <TimeUnit>day</TimeUnit>
  <Allow>
    <Class ref="request.header.developer_segment">
      <Allow class="platinum" count="10000"/>
      <Allow class="silver" count="1000" />
    </Class>
  </Allow>
</Quota>

Tentang kebijakan Kuota

Kuota adalah alokasi pesan permintaan yang dapat ditangani oleh proxy API selama jangka waktu tertentu, seperti menit, jam, hari, minggu, atau bulan. Kebijakan ini mempertahankan penghitung yang menghitung jumlah permintaan yang diterima oleh proxy API. Kemampuan ini memungkinkan penyedia API menerapkan batasan jumlah panggilan API yang dilakukan oleh aplikasi selama interval waktu tertentu. Dengan menggunakan kebijakan Kuota, Anda dapat, misalnya, batasi aplikasi hingga 1 permintaan per menit, atau hingga 10.000 permintaan per bulan.

Misalnya, jika Kuota ditetapkan sebagai 10.000 pesan per bulan, pembatasan kapasitas dimulai setelah pesan yang ke-10.000. Tidak masalah apakah 10.000 pesan dihitung pada hari atau hari terakhir menstruasi tersebut; tidak ada area permintaan tambahan yang diizinkan hingga penghitung Kuota otomatis direset pada akhir interval waktu yang ditentukan, atau hingga Kuota secara eksplisit reset menggunakan Reset Kuota kebijakan kami.

Variasi pada Kuota yang disebut SpikeArrest mencegah lonjakan traffic (atau burst) yang dapat disebabkan oleh peningkatan penggunaan yang mendadak, klien yang memiliki bug, atau serangan berbahaya. Untuk selengkapnya untuk mengetahui informasi tentang SpikeArrest, lihat kebijakanSpike Arrest.

Kuota berlaku untuk proxy API individual dan tidak didistribusikan di antara proxy API. Misalnya, jika Anda memiliki tiga proxy API dalam satu produk API, satu kuota tidak dibagikan di ketiganya meskipun ketiganya menggunakan konfigurasi kebijakan kuota yang sama.

Jenis kebijakan kuota

Kebijakan Kuota mendukung beberapa jenis kebijakan: default, calendar, flexi, dan rollingwindow. Setiap jenis menentukan kapan penghitung kuota dimulai dan saat direset, seperti ditunjukkan dalam tabel berikut:

Untuk type="calendar", Anda harus menentukan nilai <StartTime>.

Tabel tidak mencantumkan nilai untuk jenis rollingwindow. Jendela Berkelanjutan kuota bekerja dengan menetapkan ukuran "periode" kuota, misalnya periode satu jam atau satu hari. Ketika seorang permintaan baru masuk, kebijakan akan menentukan apakah kuota telah terlampaui sebelumnya "jendela" waktu tertentu.

Misalnya, Anda menentukan periode dua jam yang mengizinkan 1.000 permintaan. Permintaan baru masuk pada pukul 16:45.Kebijakan itu menghitung jumlah kuota selama dua jam terakhir, yang berarti jumlah permintaan sejak pukul 14:45. Jika batas kuota belum terlampaui dua jam, maka permintaan akan diperbolehkan.

Satu menit kemudian, pada pukul 16.46, permintaan lain masuk. Sekarang kebijakan tersebut menghitung jumlah kuota sejak pukul 14.46 untuk menentukan apakah batas telah terlampaui.

Untuk jenis rollingwindow, penghitung tidak pernah direset, tetapi dihitung ulang pada setiap permintaan.

Memahami penghitung kuota

Secara default, kebijakan Kuota mempertahankan satu penghitung, terlepas dari berapa kali Anda merujuknya dalam proxy API. Nama penghitung kuota didasarkan pada atribut name kebijakan.

Misalnya, Anda membuat kebijakan Kuota bernama MyQuotaPolicy dengan batas 5 dan menempatkannya di beberapa flow (Alur A, B, dan C) di proxy API. Meskipun digunakan dalam beberapa alur, ia mempertahankan satu penghitung yang diperbarui oleh semua instance kebijakan:

• Alur A dieksekusi -> MyQuotaPolicy dijalankan dan penghitungnya = 1
• Alur B dieksekusi -> MyQuotaPolicy dijalankan dan penghitungnya = 2
• Alur A dieksekusi -> MyQuotaPolicy dijalankan dan penghitungnya = 3
• Alur C dieksekusi -> MyQuotaPolicy dijalankan dan penghitungnya = 4
• Alur A dieksekusi -> MyQuotaPolicy dijalankan dan penghitungnya = 5

Permintaan berikutnya ke salah satu dari ketiga alur ditolak karena penghitung kuota telah mencapai batasnya.

Menggunakan kebijakan Kuota yang sama di lebih dari satu tempat dalam alur proxy API, yang dapat secara tidak sengaja menyebabkan Kuota habis lebih cepat dari yang diperkirakan, adalah anti-pola yang dijelaskan di The Book of Apigee Edge Anti-pola.

Atau, Anda dapat menetapkan beberapa kebijakan Quota di proxy API dan menggunakan kebijakan di setiap alur. Setiap kebijakan Kuota mempertahankan penghitungnya sendiri, berdasarkan atribut name kebijakan.

Atau, gunakan <Class> atau <Identifier> elemen di kebijakan Kuota untuk menentukan beberapa penghitung unik dalam satu kebijakan. Dengan menggunakan satu kebijakan dapat mempertahankan penghitung yang berbeda berdasarkan aplikasi yang membuat permintaan, pengembang aplikasi yang membuat permintaan, ID klien atau ID klien lainnya, dan banyak lagi. Lihat contoh di atas untuk informasi lebih lanjut tentang penggunaan Elemen <Class> atau <Identifier>.

Notasi waktu

Semua waktu Kuota ditetapkan ke aplikasi Universal Terkoordinasi Zona waktu (UTC).

Notasi waktu kuota mengikuti notasi tanggal standar internasional yang ditentukan dalam ISO 8601 standar.

Tanggal didefinisikan sebagai tahun, bulan, dan hari, dalam format berikut: YYYY-MM-DD. Misalnya, 2015-02-04 merepresentasikan 4 Februari 2015.

Waktu dalam sehari didefinisikan sebagai jam, menit, dan detik dalam format berikut: hours:minutes:seconds. Misalnya, 23:59:59 mewakili waktu detik sebelum tengah malam.

Perhatikan bahwa dua notasi, 00:00:00 dan 24:00:00, tersedia untuk membedakan dua tengah malam yang dapat dikaitkan dengan satu tanggal. Oleh karena itu, 2015-02-04 24:00:00 adalah tanggal dan waktu yang sama dengan 2015-02-05 00:00:00. Yang terakhir adalah biasanya notasi yang disukai.

Mendapatkan setelan kuota dari konfigurasi produk API

Anda dapat menetapkan batas kuota dalam konfigurasi produk API. Batasan tersebut tidak otomatis memberlakukan kuota. Sebagai gantinya, Anda dapat merujuk setelan kuota produk dalam kebijakan kuota. Berikut beberapa keuntungan penetapan kuota pada produk untuk referensi kebijakan kuota:

• Kebijakan kuota dapat menggunakan setelan seragam di semua proxy API di produk API.
• Anda dapat membuat perubahan runtime pada setelan kuota di produk API, dan kebijakan kuota yang mereferensikan nilai tersebut akan otomatis memiliki nilai kuota yang diperbarui.

Untuk informasi selengkapnya tentang cara menggunakan setelan kuota dari produk API, lihat "Kuota Dinamis" contoh di atas..

Untuk info tentang cara mengonfigurasi produk API dengan batas kuota, lihat Membuat produk API.

Referensi elemen

Berikut adalah elemen dan atribut yang dapat Anda konfigurasi di kebijakan ini. Perhatikan bahwa beberapa elemen kombinasi keduanya bersifat eksklusif atau tidak wajib. Lihat contoh untuk penggunaan tertentu. Tujuan verifyapikey.VerifyAPIKey.apiproduct.* variabel di bawah tersedia secara default jika kebijakan Verify API Key bernama "VerifyAPIKey" digunakan untuk memeriksa kunci API aplikasi dalam permintaan. Nilai variabel berasal dari setelan kuota pada produk API yang dikaitkan dengan kunci seperti yang dijelaskan dalam Mendapatkan setelan kuota dari produk API konfigurasi.

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">
   <DisplayName>Quota 3</DisplayName>
   <Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/>
   <Allow>
      <Class ref="request.queryparam.time_variable">
        <Allow class="peak_time" count="5000"/>
        <Allow class="off_peak_time" count="1000"/>
      </Class>
   </Allow>
   <Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval> 
   <TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>
   <StartTime>2017-7-16 12:00:00</StartTime> 
   <Distributed>false</Distributed> 
   <Synchronous>false</Synchronous> 
   <AsynchronousConfiguration> 
      <SyncIntervalInSeconds>20</SyncIntervalInSeconds> 
      <SyncMessageCount>5</SyncMessageCount> 
   </AsynchronousConfiguration> 
   <Identifier/> 
   <MessageWeight/> 
</Quota>

<Quota> atribut

<Quota async="false" continueOnError="false" enabled="true" name="Quota-3" type="calendar">

Atribut berikut khusus untuk kebijakan ini.

Tabel berikut menjelaskan atribut yang umum untuk semua elemen induk kebijakan:

<DisplayName> elemen

Gunakan selain atribut name untuk memberi label kebijakan di editor proxy UI dengan nama natural language yang berbeda.

<DisplayName>Policy Display Name</DisplayName>

<Allow> elemen

Menentukan batas jumlah untuk kuota. Jika penghitung untuk kebijakan mencapai batas ini , panggilan berikutnya akan ditolak hingga penghitung direset.

Berikut adalah tiga cara untuk menetapkan elemen <Allow>:

<Allow count="2000"/> 

<Allow countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/> 

<Allow count="2000" countRef="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.limit"/> 

Jika Anda menentukan count dan countRef, maka countRef yang mendapatkan prioritas. Jika countRef tidak di-resolve saat runtime, nilai count digunakan.

Atribut

<Allow>/<Class> elemen

Elemen <Class> memungkinkan Anda mengubah kondisi nilai dari elemen <Allow> berdasarkan nilai variabel flow. Sebagai setiap tag turunan <Allow> yang berbeda dari <Class>, kebijakan tersebut mempertahankan penghitungan yang berbeda.

Untuk menggunakan elemen <Class>, tentukan variabel alur menggunakan elemen ref ke tag <Class>. Edge kemudian menggunakan nilai variabel alur untuk memilih salah satu tag turunan <Allow> guna menentukan tag yang diizinkan penghitungan kebijakan. Edge mencocokkan nilai variabel flow dengan class dari tag <Allow>, seperti yang ditunjukkan di bawah ini:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

Dalam contoh ini, penghitung kuota saat ini ditentukan oleh nilai Parameter kueri time_variable diteruskan dengan setiap permintaan. Variabel itu dapat memiliki nilai dari peak_time atau off_peak_time. Jika parameter kueri berisi nilai yang tidak valid kebijakan akan menampilkan error pelanggaran kuota.

Atribut

<Allow>/<Class>/<Allow> elemen

Elemen <Allow> menentukan batas untuk penghitung kuota ditentukan oleh elemen <Class>. Untuk setiap tag turunan <Allow> yang berbeda dari <Class>, tetapi menghasilkan penghitung yang berbeda.

Contoh:

<Allow>
  <Class ref="request.queryparam.time_variable">
    <Allow class="peak_time" count="5000"/>
    <Allow class="off_peak_time" count="1000"/>
  </Class>
</Allow>

Dalam contoh ini, kebijakan Kuota menyimpan dua penghitung kuota yang bernama dari peak_time dan off_peak_time.

Atribut

<Interval> elemen

Gunakan untuk menentukan bilangan bulat (misalnya, 1, 2, 5, 60, dan seterusnya) yang akan dipasangkan dengan TimeUnit yang Anda tentukan (menit, jam, hari, minggu, atau bulan) untuk menentukan waktu periode saat Edge menghitung penggunaan kuota.

Misalnya, Interval dari 24 dengan TimeUnit dari hour berarti kuota akan dihitung selama 24 jam.

<Interval ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.interval">1</Interval>

Atribut

<TimeUnit> elemen

Gunakan untuk menentukan satuan waktu yang berlaku untuk kuota.

Misalnya, Interval dari 24 dengan TimeUnit dari hour berarti kuota akan dihitung selama 24 jam.

<TimeUnit ref="verifyapikey.VerifyAPIKey.apiproduct.developer.quota.timeunit">month</TimeUnit>

Atribut

<StartTime> elemen

Jika type ditetapkan ke calendar,, Anda akan menentukan tanggal dan waktu saat penghitung kuota akan mulai menghitung, terlepas dari apakah ada permintaan diterima dari aplikasi apa pun.

Anda harus memberikan StartTime eksplisit saat type ditetapkan secara eksplisit ke calendar, Anda tidak dapat menggunakan referensi ke variabel alur, jika menentukan nilai StartTime jika tidak ada nilai type yang ditetapkan, Anda akan menerima {i>error<i}.

Contoh:

<StartTime>2017-7-16 12:00:00</StartTime>

<Terdistribusi> elemen

Penginstalan Edge dapat menggunakan satu atau beberapa Pemroses Pesan untuk memproses permintaan. Setel ini ke true untuk menentukan bahwa kebijakan harus mempertahankan dan terus menyinkronkannya di semua Pemroses Pesan. Pemroses pesan dapat berada di seluruh zona ketersediaan dan/atau region.

Jika menggunakan nilai default false, Anda mungkin akan melebihi kuota karena jumlah untuk setiap Pemroses Pesan tidak dibagikan:

<Distributed>true</Distributed>

Untuk menjamin bahwa penghitung disinkronkan, dan diperbarui pada setiap permintaan, atur <Distributed> dan <Synchronous> ke benar:

<Distributed>true</Distributed>
<Synchronous>true</Synchronous>

&lt;Synchronous&gt; elemen

Tetapkan ke true untuk memperbarui penghitung kuota terdistribusi secara sinkron. Ini berarti bahwa pembaruan pada penghitung dilakukan pada saat yang sama kuota diperiksa pada permintaan ke API. Tetapkan ke true jika Anda tidak mengizinkan API apa pun panggilan melebihi kuota.

Tetapkan ke false untuk memperbarui penghitung kuota secara asinkron. Artinya beberapa panggilan API yang melebihi kuota akan dapat dilakukan, tergantung pada penghitung kuota di repositori pusat diupdate secara asinkron. Namun, Anda tidak akan menghadapi dampak kinerja potensial yang terkait dengan pembaruan sinkron.

Interval update asinkron default adalah 10 detik. Gunakan AsynchronousConfiguration untuk mengonfigurasi perilaku asinkron ini.

<Synchronous>false</Synchronous>

&lt;AsynchronousConfiguration&gt; elemen

Mengonfigurasi interval sinkronisasi di antara penghitung kuota terdistribusi saat kebijakan elemen konfigurasi <Synchronous> tidak ada atau tidak ada dan disetel ke false.

Anda dapat menyinkronkan baik setelah jangka waktu tertentu atau setelah jumlah pesan, menggunakan Elemen turunan SyncIntervalInSeconds atau SyncMessageCount. Keduanya saling eksklusif. Misalnya,

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

atau

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

&lt;AsynchronousConfiguration&gt;/&lt;SyncIntervalInSeconds&gt; elemen

Gunakan ini untuk mengganti perilaku default saat pembaruan asinkron dijalankan setelah dengan interval 10 detik.

<AsynchronousConfiguration>
   <SyncIntervalInSeconds>20</SyncIntervalInSeconds>
</AsynchronousConfiguration>

Interval sinkronisasi harus >= 10 detik seperti yang dijelaskan dalam Membatasi topik.

&lt;AsynchronousConfiguration&gt;/&lt;SyncMessageCount&gt; elemen

Menentukan jumlah permintaan di semua pemroses pesan Apigee di antara kuota pembaruan.

<AsynchronousConfiguration>
   <SyncMessageCount>5</SyncMessageCount>
</AsynchronousConfiguration>

Contoh ini menunjukkan bahwa jumlah kuota diperbarui setiap 5 permintaan di setiap Apigee Pemroses pesan edge.

&lt;Identifier&gt; elemen

Gunakan elemen <Identifier> untuk mengonfigurasi kebijakan agar dapat membuat kode unik penghitung berdasarkan variabel {i>flow<i}.

Jika Anda tidak menggunakan elemen ini, kebijakan akan menggunakan satu penghitung yang diterapkan pada kuota.

Elemen ini juga dibahas dalam Postingan komunitas Apigee berikut: http://community.apigee.com/questions/2807/how-does-the-edge-quota-policy-work-when-no-identi.html.

<Identifier ref="verifyapikey.verify-api-key.client_id"/>

Atribut

&lt;MessageWeight&gt; elemen

Gunakan untuk menetapkan bobot yang ditetapkan pada setiap pesan. Gunakan bobot pesan untuk meningkatkan dampak pesan yang, misalnya, memakai lebih banyak sumber daya komputasi dibandingkan yang lain.

Misalnya, Anda ingin menghitung pesan POST dua kali lebih banyak daripada "berat" atau mahal, seperti GET membuat pesan teks. Oleh karena itu, Anda menetapkan MessageWeight ke 2 untuk POST dan 1 untuk DAPATKAN. Anda bahkan dapat menyetel MessageWeight ke 0 sehingga permintaan tidak akan memengaruhi penghitung. Dalam contoh ini, jika kuotanya adalah 10 pesan per menit dan MessageWeight untuk permintaan POST adalah 2, maka kuota akan mengizinkan 5 permintaan POST dalam setiap interval 10 menit. Setiap permintaan tambahan, seperti POST atau GET, sebelum reset penghitung ditolak.

Nilai yang mewakili MessageWeight harus ditentukan oleh flow variabel, dan dapat diekstrak dari header HTTP, parameter kueri, permintaan XML atau JSON payload, atau variabel alur lainnya. Misalnya, Anda mengaturnya pada {i>header <i}bernama weight:

<MessageWeight ref="message_weight"/>

Variabel flow

Variabel Flow yang telah ditetapkan sebelumnya akan otomatis diisi saat kebijakan Kuota akan dijalankan. Untuk mengetahui informasi selengkapnya tentang variabel Alur, lihat Referensi variabel.

Referensi error

Bagian ini menjelaskan kode kesalahan dan pesan kesalahan yang dikembalikan dan variabel kesalahan yang disetel oleh Edge saat kebijakan ini memicu kesalahan. Informasi ini penting untuk diketahui jika Anda mengembangkan aturan kesalahan untuk menangani kesalahan. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Penanganan kesalahan.

Error runtime

Error ini dapat terjadi saat kebijakan dijalankan.

Error saat deployment

Variabel kesalahan

Variabel ini ditetapkan saat kebijakan ini memicu error. Untuk informasi selengkapnya, lihat Yang perlu Anda ketahui tentang error kebijakan.

Contoh respons error

{  
   "fault":{  
      "detail":{  
         "errorcode":"policies.ratelimit.QuotaViolation"
      },
      "faultstring":"Rate limit quota violation. Quota limit  exceeded. Identifier : _default"
   }
}

Contoh aturan kesalahan

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

Skema

Topik terkait

Kebijakan ResetQuota

SpikeArrest kebijakan

Membandingkan Kebijakan Kuota, Lonjakan, dan Batas Kapasitas Serentak