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 ポリシー