このページでは、C++ クライアント ライブラリで使用される再試行モデルについて説明します。
クライアント ライブラリは、RPC(リモート プロシージャ コール)を代理で発行します。これらの RPC は、一時的なエラーにより失敗する可能性があります。サーバーの再起動、ロードバランサの過負荷状態またはアイドル状態の接続の終了、レート制限を有効にできますが、これらは一時的な障害の一部の例にすぎません。
ライブラリはこれらのエラーをアプリケーションに返すことができます。ただし、これらのエラーの多くはライブラリで簡単に処理できるため、アプリケーション コードが簡素化されます。
再試行可能なエラーと再試行可能なオペレーション
一時的なエラーのみ再試行できます。たとえば、kUnavailable は、リクエストの進行中にクライアントが接続できなかったか、サービスへの接続を失ったことを示します。これはほとんどの場合は一時的な状態ですが、復元に長い時間がかかる場合があります。これらのエラーは常に再試行可能です(オペレーション自体が安全に再試行できると仮定した場合)。対照的に、kPermissionDenied エラーを解決するには、追加の介入(通常は人による介入)が必要です。このようなエラーは「一時的」とはみなされません。少なくとも、クライアント ライブラリの再試行ループで考慮されるタイムスケールでは一時的ではありません。
同様に、エラーの性質に関係なく、再試行が安全でないオペレーションもあります。これには、増分変更を行うオペレーションが含まれます。たとえば、「X」というリソースの複数のバージョンが存在する場合のある「X の最新バージョン」を削除するオペレーションを再試行することは安全ではありません。これは、呼び出し元はおそらく単一のバージョンを削除することを意図していたためであり、このようなリクエストを再試行するとすべてのバージョンが削除される可能性があります。
再試行ループを構成する
クライアント ライブラリは、再試行ループを制御するために 3 つの異なる構成パラメータを受け入れます。
*IdempotencyPolicyは、特定のリクエストがべき等かどうかを判断します。このようなリクエストのみが再試行されます。*RetryPolicyは、(a)エラーを一時的な障害とみなすかどうか、(b)クライアント ライブラリがリクエストを再試行する時間(回数)を決定します。*BackoffPolicyは、クライアント ライブラリがリクエストを再発行するまでの待機時間を決定します。
デフォルトのべき等ポリシー
一般に、複数回の関数の呼び出しが成功して、システムを 1 回の関数の呼び出しが成功したのと同じ状態にすると、オペレーションはべき等になります。べき等オペレーションのみ安全に再試行できます。べき等オペレーションの例としては、読み取り専用オペレーションや、1 回しか成功しないオペレーションなどがあります。
デフォルトでは、クライアント ライブラリは GET または PUT 動詞を介して実装された RPC のみをべき等として扱います。これは、一部のサービスでは、一部の POST リクエストがべき等であっても、保守的すぎるかもしれません。デフォルトのべき等ポリシーは、必要に応じていつでもオーバーライドできます。
一部のオペレーションは、前提条件が含まれている場合にのみべき等になります。たとえば、「最新バージョンが Y の場合は最新バージョンを削除」は、1 回しか成功できないため、べき等です。
随時、クライアント ライブラリでは、より多くのオペレーションがべき等として扱われるように改善が行われています。Google ではこれらの改善によるバグ修正を考慮しているため、もしクライアント ライブラリの動作を変更しても、停止しません。
オペレーションを再試行しても安全ですが、オペレーションが 2 回目の試行と 1 回目の成功した試行で同じ結果になるわけではないことに留意してください。たとえば、一意に識別されたリソースを作成すると、2 回目の連続の試行が失敗してシステムが同じ状態のままになるため、再試行しても安全になります。ただし、クライアントは再試行時に「すでに存在する」エラーを受け取る場合があります。
デフォルトの再試行ポリシー
aip/194 で概説されているガイドラインに従い、ほとんどの C++ クライアント ライブラリは UNAVAILABLE gRPC エラーのみを再試行します。これらは StatusCode::kUnavailable にマッピングされます。デフォルトのポリシーでは、リクエストは 30 分間再試行されます。
kUnavailable エラーは、サーバーがリクエストを受信できなかったことを示していないことに留意してください。このエラーコードは、リクエストを送信できない場合に使用されますが、リクエストが正常に送信され、サービスによって受信され、レスポンスをクライアントが受信する前に接続が失われる場合にも使用されます。さらに、リクエストが正常に受信されたかどうかを判断できる場合は、よく知られている分散システムでのありえない結果である二人の将軍問題を解決できます。
したがって、kUnavailable で失敗したすべてのオペレーションを再試行することは安全ではありません。オペレーションのべき等性も重要です。
デフォルトのバックオフ ポリシー
デフォルトでは、ほとんどのライブラリでは、ジッター付きで切り捨て型指数バックオフ戦略が使用されています。初期バックオフは 1 秒、最大バックオフは 5 分で、再試行ごとにバックオフが 2 倍になります。
デフォルトの再試行とバックオフに関するポリシーを変更する
各ライブラリでは、これらのポリシーを構成する *Option 構造体を定義します。これらのオプションは、*Client クラスの作成時、またはリクエストごとに指定できます。
たとえば、Cloud Pub/Sub クライアントの再試行ポリシーとバックオフ ポリシーを変更する方法を次に示します。
そのライブラリの具体的な名前と例を知るには、各ライブラリのドキュメントをご覧ください。
次のステップ
- 一般的なライブラリ構成オプションの詳細については、クライアント ライブラリの構成をご覧ください。