API のスロットリングを管理する方法

API のスロットリング は、クラウド API に依存するアプリケーションを構築する場合の一般的な課題です。 これを処理するために使用できる手法を次に示します。

• レート制限を使用します。 使用する API が レート制限をサポートしている場合は、API が送信するレート制限情報を使用して、アプリケーションが API の制限を超えないようにします。
• Retry-After ヘッダーを処理します。 一部の API は、要求がスロットルされたときに応答で Retry-After ヘッダーを送信します。 スロットルされた場合、応答に Retry-After ヘッダーがあるときは、別の要求を送信する前に指定された時間だけ待機してください。
• 指数バックオフを実装します。 使用する API が Retry-After ヘッダーを送信しない場合は、ランダム ジッターを使用して指数バックオフ アルゴリズムを実装してください。 要求が失敗するたびに、再試行するまでの待機時間を 2 倍にし、数回試行した後に停止します。 長く待つと、API の負荷が軽減され、次の要求が成功する可能性が高くなります。
• 再試行しないほうがよい場合を理解します。 スロットリングのようなエラーの中には、クォータやクレジットを使い切ったことを意味するものもあります（OpenAI の credit_balance_exhausted など）。 再試行しても役に立たないので、停止してユーザーに伝えてください。
• 以前に受信したデータをキャッシュします。 API からの応答をキャッシュします(特に、同じデータを返す可能性が高い要求の場合)。 キャッシュを 使用すると、API に対する呼び出しの数を減らし、レート制限内に留めるのに役立ちます。
• 要求をキューに追加します。 送信 API 要求のキューを実装して要求レートを管理し、API のレート制限を超えないようにします。
• API 呼び出しを最適化します。 必要なデータのみをフェッチし、API でサポートされている場合はバッチ要求を使用します。 最適化により、要求の数を減らし、レート制限内に留まるのに役立ちます。
• ユーザーに何が起こっているのかを表示します。 「ビジー、5 秒で再試行」は、決して終了しないスピナーよりましです。

これらの手法をアプリケーションに実装した後、スロットリングが適切に処理されることをテストします。 実際に動作しているのを見たことがない再試行ロジックは、動作するか分からない再試行ロジックです。 テストする方法の比較については、「アプリがスロットリングに対応することをテストする方法」を参照してください。

アプリで試す

Dev Proxy は、選択した API に対してスロットリング応答を返しますが、アプリは実際の URL を呼び出し続け、Retry-After の時間が切れる前にアプリが再試行するタイミングを通知します。 プリセットは、GitHub (github-rate-limiting)、OpenAI (openai-throttling)、Anthropic (anthropic-throttling)、および Microsoft Graph の OneDrive および SharePoint のエンドポイント (microsoft-graph-rate-limiting) で使用できます。

devproxy config get openai-throttling
devproxy --config-file "~dataFolder/configs/openai-throttling/.devproxy/devproxyrc.json"

Dev Proxy をインストールするには、「Dev Proxy をセットアップする」を参照してください。

次のステップ