レート制限 は、特定の期間にサービスに対して実行できる要求の数を管理するために API プロバイダーによって使用される一般的な手法です。 API プロバイダーは、レート制限を使用して、すべてのユーザーがサービスを確実に利用でき、応答性を維持し、サービスの不正使用や過剰使用を防ぎます。
アプリケーションでクラウド API を使用する場合は、そのレート制限を理解する必要があります。 次の手法は、アプリケーションでレート制限を処理するのに役立ちます。
- レート制限について説明します。 レート制限を理解するために使用する API のドキュメントを確認してください。 レート制限は、使用する API プロバイダーまたはサービス プランによって異なります。 たとえば、一部の API では、無料プランと有料プランのレート制限が異なる場合があります。
- レート制限情報を使用します。 通常、レート制限を使用する API は、応答ヘッダーの現在のレート制限を伝えます。 たとえば、
RateLimit-Remainingヘッダーは、現在のウィンドウに残っている要求の数を示します。 このヘッダーが 0 に設定された応答を受け取った場合は、レート制限に達し、別の要求を送信する前に次のウィンドウを待つ必要があることがわかります。RateLimit-Resetヘッダーは、レート制限がリセットされた時刻を示します。 一部の API は、しきい値に達した後にのみRateLimit-...ヘッダーを送信します。 たとえば、要求の 10% が残っている場合です。 - API の使用を最適化します。 一部のサービスでは、複雑さに基づいて異なる要求に異なるコストが割り当てられます。 たとえば、一部の API では、より多くのデータを返す要求に対して課金される場合があります。 アプリケーションのコストを削減するには、必要なデータのみをフェッチして API の使用を最適化します。 API でサポートされている場合は、バッチ要求を使用します。 応答の処理に必要なリソースの数を減らし、レート制限内に留まるのに役立ちます。
- ローカル レートリミッターを実装します。 特定の期間内に API に対して実行できる要求の数を制限するために、アプリケーション自体にレートリミッターを実装します。 これを行うには、トークン バケットやリークバケット アルゴリズムなどの手法を使用します。これにより、アプリケーションは期間ごとに多くの要求を行うことができます。 追加のリクエストはキューに格納されるか、破棄されます。
- レート制限を超えないようにします。 レート制限を超えると、API は、通常 HTTP 状態コードを返す後続のすべての要求を
429 Too Many Requests。 通常、調整は、レート制限よりもアプリケーションのスループットに影響します。 レート制限応答ヘッダーで公開されている情報を使用して、レート制限の範囲内に留まり、制限を受けないようにします。
これらの手法を使用すると、レート制限に対する回復性があり、API の負荷が高い場合でも引き続き機能できるアプリケーションを構築できます。
次のステップ
GitHub で Microsoft と共同作業する
このコンテンツのソースは GitHub にあります。そこで、issue や pull request を作成および確認することもできます。 詳細については、共同作成者ガイドを参照してください。
Dev Proxy