さまざまなクライアント アプリが使用される環境でパフォーマンスと可用性を維持するには、API とバックエンド サービスの容量制限の範囲内でアプリのトラフィックを維持することが非常に重要となります。またアプリが許容される量を超えてリソースを消費しないようにすることも重要です。
Apigee Edge には、バックエンド サービスの正常性を維持しながら、トラフィック管理を改善し、アプリのレイテンシを最小限に抑えられる 3 つのメカニズムがあります。各ポリシータイプは、トラフィック管理の個別の分野に対応します。状況によっては、1 つの API プロキシで、3 つすべてのポリシータイプを使用することもあります。
API トラフィック管理ポリシーについて紹介している動画をご覧ください。
Spike Arrest
このポリシーは、ユーザーが定義する制限をより短い間隔に分割することで、トラフィックの急増を抑制します。たとえば、1 秒あたり 100 メッセージという制限を定義すると、Spike Arrest ポリシーによって 10 ミリ秒(1000 / 100)あたり約 1 リクエストの制限が適用されます。1 分あたり 30 メッセージの制限を定義した場合は、2 秒(60 / 30)あたり約 1 リクエストに抑制されます。Spike Arrest 制限は、バックエンド サービスまたは API プロキシ自体のいずれかを対象に算出された容量に近づける必要があります。また、この制限はより短い時間間隔(秒単位や分単位など)に対して構成する必要があります。悪意のある攻撃者がサービスを妨害するために使用する DOS(Denial-of-Service)攻撃や、バグの多いクライアント アプリケーションによって発生するトラフィック急増を防ぐためには、このポリシーを使用してください。
Spike Arrest ポリシーをご覧ください。
Quota
このポリシーは、クライアント アプリに使用制限を適用するために、受信リクエストを集計する分散型「カウンタ」を保持します。このカウンタで、識別可能な任意のエンティティ(アプリ、デベロッパー、API キー、アクセス トークンなど)の API 呼び出しを集計できます。通常、クライアント アプリを識別するには API キーが使用されます。このポリシーは計算リソースを大量に消費するため、トラフィックが多い API については、1 日または 1 か月など、より長い期間に対して構成する必要があります。このポリシーは、運用上のトラフィックを管理するためではなく、デベロッパーやパートナーとの業務契約または SLA を適用するために使用します。
Quota ポリシーをご覧ください。
ConcurrentRateLimiting
このポリシーを使用して、API サービスとバックエンド サービス間のトラフィックを管理できます。一部のバックエンド サービス(レガシー アプリケーションなど)には、サポートできる同時接続数に対して厳しい制限が課せられている場合があります。このポリシーは常に、API サービスからバックエンド サービスへ一定時間内に送信できるリクエスト数に制限を適用します。このリクエスト数は、バックエンド サービスを呼び出す可能性がある API サービスのすべての分散インスタンスを対象にカウントされます。ポリシーの制限と適用期間は、バックエンド サービスで使用可能な容量と一致するように構成してください。
Concurrent Rate Limiting ポリシーをご覧ください。