🔁

Step Functionsにおけるリトライ(指数バックオフ)の実装

に公開
Step Functions
Vertex AI
Gemini API
指数バックオフ
tech

はじめに

  • AWS Step FunctionsでVertex AI APIを用いた開発を行っていたのですが、429エラーが多発するため、再試行方法を検討していたところ、指数バックオフという再試行手法を知ったため、Step Functionsでの実装方法をメモに残しています。
  • ジッターについては今回の実装上、並行して同時に再試行が実行されることがないことから不要と判断したため、本記事で取り扱っていません。
  • もし記事の内容に誤りがございましたら、優しく教えていただけますと幸いです。

Vertex AI APIの429エラーについて

公式ドキュメントによると、Vertex AI APIでは以下のような場合に429エラーが発生すると記載があります。

リクエスト数がリクエストの処理に割り当てられた容量を超えると、エラーコード 429 が返されます。次の表に、各タイプの割り当てフレームワークによって生成されるエラー メッセージを示します。

私の場合は従量課金制の割り当てフレームワークでしたので、エラーメッセージ（Resource exhausted, please try again later.）から単純に一定時間（2秒）待機した後に複数回再試行を行うように設定を行っていたのですが、再試行も同じエラーで失敗することが多い状況でした。
ここで公式ドキュメントを見てみると、「切り捨て型指数バックオフを使用して再試行方法を実装する。」という解消方法が紹介されていたため、指数バックオフを調べた後にStep Functionsで指数バックオフを実装しました。

指数バックオフとは何か

指数バックオフについて公式ドキュメントでは以下のように説明がされています。

指数バックオフのアルゴリズムは、リクエスト間の待ち時間の間隔を最大バックオフ時間まで増加させながら、指数関数的にリクエストを再試行します。

上記について実際に数式で見た方が理解しやすかったため、以下に表現します。


指数バックオフを表す数式

再試行を繰り返すごとにリクエスト間の待ち時間が指数関数的に増加していくことが分かるかと思います。

なぜ指数バックオフが必要なのか

これについても公式ドキュメントに記載がありました。

リクエストをすぐに再試行したり、非常に短い遅延で再試行したりすると、カスケード障害（他の障害を引き起こす可能性のある障害）が発生する可能性があります。

より具体的に考えると、例えばAPIの実行上限回数が分単位で決まっており、上限を超えるとエラーを返すようなAPIがあったとします（例：API実行回数上限：1000回/分）。
このAPIに対して実行回数上限に達してしまいエラーとなった後も、同じ待機時間（例：2秒間隔で再試行）で再試行を行う場合、多くの無駄なリクエストをサーバ側に送信することになり、サーバ側の負荷上昇・クライアント側の再実行のための無駄なリソース消費につながることが懸念されます。
そこで指数関数的に待機時間を増加させることで無駄なリクエストを抑え、再試行の影響を抑えることができるということだそうです。

切り捨て型指数バックオフは、上記に加え再試行の上限回数を定めたものになるので、より安全に再試行を実装できます。

Step Functionsでの切り捨て型指数バックオフの実装方法

※ 以下ではコンソール画面からの実装方法を記載いたしますが、もちろんコードベースでも実装可能です。

  • まず指数バックオフを実装したいステートの「エラー処理」タブを開きます。

    エラー処理タブ
  • 「新しい再試行者を追加」をクリックし、再実行を行う対象のエラーを指定します。
  • 各種パラメータを設定する
    • 各種パラメータは先ほどの数式に当てはめると以下になります。
      • interval=最初の再試行までの秒数
      • Max Attempt=数式には出てきませんが、最大試行回数です。
      • Backoff Rate=バックオフレート
      • 最大遅延秒数、ジッターについては今回は設定していません。

        各種パラメータの設定

参考にさせていただいた資料

記事内でリンクを貼っていない資料を記載させていただいております。
大変参考にさせていただきました。ありがとうございます🙇‍♂️

Discussion