このページでは、失敗した Identity and Access Management（IAM）API へのリクエストを再試行する際のベスト プラクティスについて説明します。
再試行しても安全なリクエストについては、ジッターを伴う切り捨て型指数バックオフを使用することをおすすめします。
切り捨て型指数バックオフの概要
IAM API に対するリクエストは、成功する可能性も失敗する可能性もあります。アプリケーションが待機せずに失敗したリクエストを再試行する場合は、短期間に多数の再試行が IAM に送信されることがあります。その結果、Google Cloud プロジェクトのすべての IAM リソースに適用される割り当てと上限を超過する場合があります。
この問題がトリガーされないようにするには、ジッターを伴う切り捨て型指数バックオフを使用することを強くおすすめします。これはネットワーク アプリケーション向けの標準エラー処理戦略です。この方法では、クライアントは失敗したリクエストを定期的に再試行し、再試行間の遅延は指数関数的に増加します。再試行間に短いランダムな遅延（ジッター）も追加されます。このランダムな遅延は、複数のクライアントが同時に再試行を行う問題（Thundering Herd の問題）を回避するのに役立ちます。
指数バックオフ アルゴリズム
次のアルゴリズムは、ジッターを伴う切り捨て型指数バックオフを実装しています。
- IAM にリクエストを送信します。
- リクエストが失敗した場合、1 +
random-fraction秒待ってから、リクエストを再試行します。 - リクエストが失敗した場合、2 +
random-fraction秒待ってから、リクエストを再試行します。 - リクエストが失敗した場合、4 +
random-fraction秒待ってから、リクエストを再試行します。 -
再試行のたびに 2n +
random-fraction秒待機します。このパターンを最大でmaximum-backoff時間まで繰り返します。 -
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 を返す IAM API に対するすべてのリクエストに使用します。
必要であれば、エラーコード 404 を返す IAM API に対するリクエストに使用することもできます。IAM の読み取りは結果整合性が維持されます。このため、リソースを作成した直後にリソースが表示されず、404 エラーが発生する可能性があります。
エラーコード 409 とステータス ABORTED を返す IAM API に対するすべてのリクエストには、この再試行方法を修正して使用します。この種類のエラーは同時実行の問題を示しています。たとえば、別のクライアントによってすでに上書きされている許可ポリシーを更新しようとしている可能性があります。このようなエラーの場合は、切り捨て型指数バックオフとジッターを使用して、常にリクエストの read-modify-write の全体を再試行する必要があります。書き込みオペレーションのみを再試行すると、リクエストは失敗し続けます。
次のステップ
- 許可ポリシーでの同時実行の問題を管理する方法について学習する。
- 許可ポリシーを更新するために、read-modify-write パターンの実装方法を確認する。