Quota ポリシーと SpikeArrest ポリシーの比較

このページの内容は Apigee と Apigee ハイブリッドに該当します。

Apigee Edge のドキュメントを表示します。

下記の比較表を使用すると、レート制限のユースケースに使用するポリシーを決定する際に役立ちます。

Quota SpikeArrest
適した用途: デベロッパー アプリまたはデベロッパーが特定の期間内に実行できる API プロキシ呼び出しの回数を制限します。秒または分などの比較的短い時間間隔でレート制限を行う場合は、SpikeArrest ポリシーのほうが適しています。Quota は、正確なカウントが必要な場合に検討してください。 特定の期間（通常は短い期間）にすべての消費者が API プロキシに対して実行できる API 呼び出しの回数を制限します。日、週、月、年などの比較的長い時間間隔の制限を設定する場合は、Quota ポリシーのほうが適しています。
適さない用途:

API プロキシのターゲット バックエンドをトラフィックの急増から保護する目的では使用しないでください。

その場合は SpikeArrest ポリシーを使用します。

アプリが所定の期間内に API プロキシのターゲット バックエンドに対して作成できる接続数をカウントして制限する目的では使用しないでください。注: 正確なカウントが必要なユースケースでは、Quota ポリシーを使用してください。
カウント保存の可否: 可能 不可
ポリシーを接続するためのベストプラクティス:

一般にはユーザー認証の後で、ProxyEndpoint Request PreFlow に接続します。

これにより、ポリシーは API プロキシのエントリ ポイントで割り当てカウンタを確認できます。

一般にはフローの最初に、ProxyEndpoint Request PreFlow に接続します。

これにより、API プロキシのエントリ ポイントで急増からの保護を行えます。
制限に達したときの HTTP ステータス コード:

429（サービス利用不可）

429（サービス利用不可）
追加情報:
  • 割り当てカウンタは Cassandra に保存されます。
  • リソースを節約するため、カウンタを非同期的に同期するようにポリシーを構成してください。
  • 非同期的なカウンタの同期によってレート制限のレスポンスが遅れ、設定されている制限を呼び出しが少しだけオーバーする場合があります。
 「平滑化」アルゴリズムまたは有効カウント アルゴリズムを選択できます。前者は、指定された期間内で実行できるリクエスト数を平滑化します。後者は、リクエストが連続して送信されるスピードに関係なく、指定された期間内に実行できるリクエストの総数を制限できます。また、平滑化は Message Processor 間で調整されません。
詳細情報: Quota ポリシー SpikeArrest ポリシー