再試行

概要

再試行は、サービスの信頼性を向上させるための重要なパターンです。失敗した操作を再試行することで、アプリケーションはネットワークやサーバーのグリッチなどの一時的な問題を克服できます。これは、避けられない一時的な障害を処理するために、最新のクラウドアプリケーションにとって不可欠です。

ベストプラクティスとして、アプリケーションは、再試行に適した失敗した操作を理解し、再試行遅延の指数バックオフパラメータを定義し、再試行回数を決定し、再試行メトリクスを監視する必要があります。

gRPCクライアントの再試行の仕組み

gRPCの組み込み再試行ロジックは、潜在的な再試行のために呼び出しの履歴を保存し、RPCイベントを監視します。再試行ポリシーが設定されていない場合でも、gRPCは透明な再試行（後述）を実行する必要がある場合に備えて、呼び出しの履歴を保存します。「再試行」とは、失敗した呼び出しを新しい呼び出しに置き換え、その新しく作成された呼び出しで呼び出しの履歴を再生することを意味します。

特定の条件（RPCが再試行ポリシーの再試行可能なステータスコードに一致する失敗ステータスコードで閉じられ、再試行試行回数制限内にある）を満たすと、gRPCは指数バックオフ遅延の後、新しい再試行ストリームを作成します。

gRPCは、再試行のスロットリングとサーバーからのプッシュバックなどの他の機能もサポートしています。詳細については、クライアント側の再試行に関するgRFCを参照してください。

応答ヘッダーを受信すると、RPCはコミットされます。それ以上の再試行は行われず、gRPCはRPCをアプリケーションに引き渡します。

下の図は、gRPC再試行内部のアーキテクチャの概要を示しています。（図は省略）

sequenceDiagram
  Application ->> gRPC Client: Configure retry policy. <br> Send request to dns:///my-service
  gRPC Client ->> Server: Create retry attempt 1 
  Server -->> gRPC Client : RPC closed with error 
  gRPC Client ->> Server: Create retry attempt 2 
  Server -->> gRPC Client: Successful 
  gRPC Client ->> Application: No more retry. Proceed.

再試行の設定

再試行はデフォルトで有効になっていますが、デフォルトの再試行ポリシーはありません。再試行ポリシーがないと、gRPCはほとんどの場合、RPCを安全に再試行できません。低レベルの競合状態のために失敗したRPCのみが再試行され、gRPCがRPCがサーバーによって処理されていないことを確実に知っている場合のみです。これは「透明な再試行」と呼ばれます。より多くの状況で、より積極的にRPCを再試行できるように、再試行ポリシーを設定できます。チャネルを作成する際に再試行を完全に無効にすることもできます。これにより、透明な再試行と設定された再試行ポリシーの両方が無効になります。

gRPCがサポートする重要な手順と設定に焦点を当てることで、アプリケーションの再試行機能を最適化できます。

• 再試行の最大回数
• 指数バックオフ
• 再試行可能なステータスコードのセット

再試行は、メソッド単位でgRPCサービスコンフィグを介して設定できます。設定には次のノブが含まれています。

"retryPolicy": {
  "maxAttempts": 4,
  "initialBackoff": "0.1s",
  "maxBackoff": "1s",
  "backoffMultiplier": 2,
  "retryableStatusCodes": [
    "UNAVAILABLE"
  ]
}

実際の最初のバックオフ遅延は、上記で設定された`initialBackoff`値内（0〜100ms）のランダムな時間間隔です。

gRPCは、再試行によるサーバーの過負荷を防ぐスロットル制限をサポートしています。以下は、再試行スロットル設定の例です。

"retryThrottling": {
  "maxTokens": 10,
  "tokenRatio": 0.1
}

各サーバーに対して、gRPCクライアントは`token_count`（最初は`maxTokens`に設定）を追跡します。失敗したRPCはカウントを1減らし、成功したRPCは`tokenRatio`だけ増やします。`token_count`が`maxTokens`の半分を下回ると、カウントが回復するまで再試行が一時停止されます。

さらに、ヘッジングは再試行を補完する機能であり、同様に設定できます。詳細については、ヘッジングガイドを参照してください。

再試行の監視

gRPCは、再試行機能が有効になっている場合、OpenCensusとOpenTelemetryメトリクスの公開をサポートしています。以下は、利用可能なOpenTelemetry再試行試行統計の例です。

• grpc.client.attempt.started
• grpc.client.attempt.duration
• grpc.client.attempt.sent_total_compressed_message_size
• grpc.client.attempt.rcvd_total_compressed_message_size

呼び出しレベルごとのメトリクス

• grpc.client.call.duration

そしてサーバー側のメトリクス

• grpc.server.call.started
• grpc.server.call.sent_total_compressed_message_size
• grpc.server.call.rcvd_total_compressed_message_size
• grpc.server.call.duration

詳細なメトリクスとトレース情報、および設定手順については、Otelメトリクスに関するgRFC、再試行ステータスに関するgRFCを参照してください。

各言語のガイドと例

追加情報

• クライアント側の再試行に関するgRFC
• 再試行ステータスに関するgRFC
• ヘッジングガイド
• gRPCサービスコンフィグ
• Otelメトリクスに関するgRFC