スロットリングは、クラウド API が特定の期間に実行できるリクエストの数を制限するために使用する手法です。 スロットルにより、API はすべてのユーザーに対して引き続き利用可能で応答性に優れた状態になります。 また、1 人のユーザーがリソースを過剰に消費するのを防ぎます。
スロットリングは、いくつかの方法で体験できます。 一般的な方法の 1 つは、HTTP ステータス コードを使用することです。 たとえば、許可された要求数を超えると、API は 429 Too Many Requests 状態コードを返す可能性があります。 この応答は、特定の期間に多数のリクエストを送信したため、送信頻度を下げる必要があることを示します。 すべての API が429を使用しているわけではありません。GitHubは403でも応答でき、Anthropicは API 全体がオーバーロードされたときに529を使用します。
一部の API では、状態コードに加えて、応答ヘッダーまたは本文に詳細な情報が提供されます。 たとえば、 Retry-After ヘッダーを使用して、別の要求を行う前に待機する必要がある時間を示します。
API の負荷が高いときに応答性と信頼性を維持するために、使用する API のスロットリング制限に注意し、アプリで スロットリングに対処する 方法を理解する必要があります。
スロットリングがアプリに与える影響
API によってアプリがスロットリングされ、アプリがそれに対処できないと、アプリがクラッシュし、一般的なエラーが表示され、再試行が速すぎてスロットリングされた状態が続くか、データが何も知らせずに破棄されます。 API が高速であり、自身が唯一のユーザーであり、テスト データが小さいため、開発中にこうしたことが表示されることはほとんどありません。
アプリがスロットリングを処理することをテストする方法
| Approach | 見つけたもの | 欠落しているもの |
|---|---|---|
| 運用環境の待機 | 実際のスロットリング | すべて、ユーザーがクリックするまで |
| テストで API をモックするか、コーディング エージェントにモックを記述させる | 再試行ブランチを実行するかどうか | API の実際の状態コード、Retry-After ヘッダー、エラーボディ、および SDK の再試行ポリシー。 アプリでは、モックに到達するためにテスト専用のスイッチも必要です。 |
| レート制限されるまで実際の API を呼び出す | 実際の動作 | オンデマンドでスロットリングをトリガーすることはできません。実際のクォータを使い切ってしまいます |
| アプリの実際のトラフィックをインターセプトし、スロットリングをシミュレートする | 実際の URL、実際の SDK と再試行ポリシー、アプリが Retry-After が示す時間だけ待機するかどうか |
お使いのコードは孤立しています。 それ用に単体テストを取っておいてください。 |
あなたのアプリで試す
Dev Proxy は、選択した API のスロットリング応答を返しますが、アプリは実際の URL を呼び出し続けます。 また、Retry-After の時間が終わる前にアプリが API を再度呼び出すタイミングも通知されます。
アプリが呼び出す API のプリセットをダウンロードし、それを使用して Dev Proxy を開始します。
devproxy config get microsoft-graph-rate-limiting
devproxy --config-file "~dataFolder/configs/microsoft-graph-rate-limiting/.devproxy/devproxyrc.json"
| API | Preset |
|---|---|
Microsoft Graph (OneDriveとSharePoint: /drive、/shares、/sites) |
microsoft-graph-rate-limiting |
| GitHub | github-rate-limiting |
| OpenAI | openai-throttling |
| Anthropic | anthropic-throttling |
その他の API については、「使用しているアプリケーションがスロットリングを適切に処理することをテストする」を参照してください。 Dev Proxy をインストールするには、「Dev Proxy の設定」を参照してください。
次のステップ
Dev Proxy