再試行の方法

このページでは、Model Armor API への失敗したリクエストを再試行する際のベスト プラクティスについて説明します。

再試行しても安全なリクエストについては、ジッターを伴う切り捨て型指数バックオフを使用することをおすすめします。

切り捨て型指数バックオフの概要

Model Armor API に対するリクエストは、成功する可能性も失敗する可能性もあります。アプリケーションが待機せずに失敗したリクエストを再試行する場合は、短期間に多数の再試行が Model Armor に送信されることがあります。その結果、 Google Cloud プロジェクトのすべての Model Armor リソースに適用される割り当てと上限を超過する場合があります。

この問題がトリガーされないようにするには、ジッターを伴う切り捨て型指数バックオフを使用することを強くおすすめします。これはネットワーク アプリケーション向けの標準エラー処理戦略です。この方法では、クライアントは失敗したリクエストを定期的に再試行し、再試行間の遅延は指数関数的に増加します。再試行間に短いランダムな遅延（ジッター）も追加されます。このランダムな遅延は、複数のクライアントが同時に再試行を行う問題（Thundering Herd の問題）を回避するのに役立ちます。

指数バックオフ アルゴリズム

次のアルゴリズムは、ジッターを伴う切り捨て型指数バックオフを実装しています。

  1. Model Armor にリクエストを送信します。
  2. リクエストが失敗した場合、1 + random-fraction 秒待ってから、リクエストを再試行します。
  3. リクエストが失敗した場合、2 + random-fraction 秒待ってから、リクエストを再試行します。
  4. リクエストが失敗した場合、4 + random-fraction 秒待ってから、リクエストを再試行します。
  5. 再試行のたびに 2n + random-fraction 秒待機します。このパターンを最大で maximum-backoff 時間まで繰り返します。
  6. deadline 秒後に、リクエストの再試行を停止します。

アルゴリズムを実装するときに以下の値を使用します。

  • 各再試行までの待機時間は min((2n + random-fraction), maximum-backoff) です。n は 0 から始まり、再試行のたびに 1 ずつ増えます。
  • random-fraction は、1 以下のランダムな小数値に置き換えます。再試行ごとに異なる値を使用します。このランダム値を追加すると、クライアントが同期されて大量の再試行が同時に送信されることがなくなります。
  • maximum-backoff は、再試行の最大待機時間（秒数）に置き換えます。通常の値は 32 秒または 64 秒（25 または 26）です。ユースケースに適した値を選択してください。
  • deadline は、再試行を持続する最大秒数に置き換えます。ユースケースに適した値を選択してください。たとえば、時間的な制約のない継続的インテグレーション / 継続的デプロイ（CI / CD）パイプラインでは、deadline を 300 秒（5 分）に設定できます。

再試行エラーの種類

この再試行方法は、エラーコード 500、502、503、または 504 を返す Model Armor API に対するすべてのリクエストに使用します。

必要に応じて、エラーコード 429 を返す Model Armor API に対するリクエストにこの再試行戦略を使用できます。