AIのAPIを利用する際のExponential Backoffの活用

はじめに

Studioではさまざまな場面でAIを活用していますが、大量のAI APIコールが必要な場合、Rate Limitに達してしまい、429エラー（Too Many Requests）が返されることがあります。

このようなケースに対応するための対策について解説します。

Exponential Backoffとは？

Exponential Backoffは、再試行時の待機時間を指数関数的に増加させるリトライアルゴリズムの一つです。ネットワークエラーや一時的な障害に対処する際に広く使われています。

このアルゴリズムでは、再試行を繰り返すたびに待機時間が倍増していきます。例えば、以下のように動作します：

1. 初回失敗: 再試行をすぐに行う。
2. 2回目の失敗: 2秒待機後に再試行。
3. 3回目の失敗: 4秒待機後に再試行。
4. 4回目の失敗: 8秒待機後に再試行。

このように、待機時間は 1秒、2秒、4秒、8秒… と倍増していきます。ただし、待機時間が無限に増加しないように上限（最大待機時間）を設定するのが一般的です。

こうした対策をすることで、

• 負荷の軽減: 短時間に再試行が集中するのを防ぎ、システムへの負担を軽減します。
• 効率的なリソース利用: サーバーが一時的に使用不可の場合に、一定の間隔を空けることで無駄なリクエストを減らします。

実際にどうやっているか

StudioではGoogle Cloud Tasksを基盤としてExponential Backoffを利用しています。Cloud Tasksの公式ドキュメントにあるように、

タスクが正常に完了しない場合、Cloud Tasks は設定されたパラメータに従い、指数バックオフを使用してタスクを再試行します。失敗したタスクを再試行する最大回数をキュー内で指定したり、再試行の試行時間制限を設定したり、試行間隔を制御することができます。

といった制御が、負荷が増えた場合のスケーラビリティも担保した上で、Cloud TasksのQueueを作成し、そこに上記の設定をほどこすだけで実現できます。

例えば、以下のエンドポイントを作成したとします。

エンドポイント	内容
/ai/create_tasks	Cloud Tasksへのキューを詰めるのと、Exponential Backoffの設定を行うエンドポイント
/ai/process_task	実際のAI処理を行うエンドポイント

処理シーケンスとしては以下のような流れになります。

ポイント

• 正常処理時: 一回でAIの処理が正しく終了した場合は、キューが消費され、処理終了
• AI APIからのレスポンスステータスコードで、429受信時: AIのAPIからのレスポンスが429(Too Many Requests)のステータスで返却されてきた場合、/ai/process_task で4xx系のステータスコードを返却すると、キューに設定されたExponential Backoffに従って同じ処理が再度キューにセットされ、成功するまでアクセスが繰り返される。

まとめ

以下にポイントをまとめます。

1. Exponential Backoffでシステム負荷を軽減し、効率的なリトライを実現します
2. Cloud Tasksを利用した柔軟なリトライ設定が可能です
   StudioではGoogle Cloud Tasksを基盤として利用し、タスクの再試行回数や間隔、最大待機時間を細かく設定しています。これにより、スケーラビリティと安定性を確保しています。
3. AI APIのRate Limit（429エラー）に対応するため、キューにタスクを追加してアクセスを管理し、エラー時にはExponential Backoffに従って再試行し、正常終了時にはタスクを消費して効率的に処理します。

AIのRate Limitをうまくハンドルするのにもっとこういう方法もあるよ！というのがあれば是非コメントなどで教えていただけたら嬉しいです！