一時的な障害（例：瞬断によるネットワーク障害、一時的なサービス過負荷、接続のリセットなど）は、バックエンドサービスが正常に稼働している場合でも、個々のリクエストを失敗させることがあります。クラウドネイティブゲートウェイにリトライポリシーを設定すると、失敗したリクエストを自動的に再送信するため、クライアント側の変更を伴わずアプリケーションが回復します。Microservices Engine (MSE) では、ルート単位でリトライポリシーを設定できます。
リトライにより、バックエンドサービスへの総リクエスト数が増加します。すでに劣化しているサービスへの過負荷を回避するため、リトライ回数の上限は控えめに設定してください（推奨値：0、1、または 2）。
仕組み
リクエストがリトライ条件に一致すると、ゲートウェイは設定された最大回数までそのリクエストを再送信します。
デフォルト動作（カスタムポリシー未設定時）： ゲートウェイは、connect-failure、refused-stream、unavailable、cancelled、および retriable-status-codes の各条件に基づき、失敗したリクエストを最大2 回リトライします。このデフォルト動作は、カスタムリトライポリシーが無効化されている場合でも適用されます。
カスタムリトライポリシーを無効化しても、すべてのリトライが停止するわけではありません。ゲートウェイは上記のデフォルト動作へフォールバックします。リトライを完全に停止するには、カスタムポリシーを有効化し、リトライ回数 を 0 に設定してください。
リトライ条件
ゲートウェイは、HTTP トラフィックと gRPC トラフィックに対してそれぞれ独立したリトライ条件をサポートしています。
HTTP リトライ条件
| 条件 | リトライが発生する状況 |
|---|---|
5xx | バックエンドが任意の 5xx ステータスコードを返す場合、または切断・リセット・読み取りタイムアウトが発生した場合。これは connect-failure および refused-stream を含む上位集合です。 |
reset | 切断・リセット・読み取りタイムアウトが発生した場合（バックエンドからの応答がない状態）。 |
connect-failure | リクエストが切断により失敗した場合。 |
refused-stream | バックエンドが REFUSED_STREAM エラーコードを返した場合。 |
retriable-status-codes | バックエンドは、[再試行ステータスコード] で指定された状態コードのいずれかを返します。 |
retriable-status-codes をリトライ条件として選択した場合のみ、リトライステータスコード にステータスコードを指定してください。
gRPC リトライ条件
| 条件 | gRPC ステータスコード | 主な原因 |
|---|---|---|
cancelled | CANCELLED（1） | 呼び出し元が操作をキャンセルしました。 |
deadline-exceeded | DEADLINE_EXCEEDED（4） | 操作がタイムアウトしました。 |
internal | INTERNAL（13） | 内部サーバーエラーが発生しました。 |
resource-exhausted | RESOURCE_EXHAUSTED（8） | リソース制限に達した場合（例：レート制限）。 |
unavailable | UNAVAILABLE（14） | サービスは一時的に利用できません。 |
トラフィックタイプ別推奨条件
| トラフィックタイプ | 推奨される条件 | 利用シーン |
|---|---|---|
| HTTP | 5xx | サーバーエラーおよび接続障害に対する汎用的なリトライ。 connect-failure および refused-stream をカバーします。 |
| HTTP | connect-failure、refused-stream | 接続レベルの障害のみでリトライを実行し、5xx 応答ではリトライを行わない場合。 |
| HTTP | retriable-status-codes | 特定のステータスコード（例：429（レート制限）、503（サービス利用不可））に対してリトライを実行する場合。 |
| gRPC | cancelled、unavailable | gRPC サービスにおける標準的なリトライペア。 |
前提条件
開始する前に、以下の条件を満たしていることを確認してください。
MSE で作成済みのクラウドネイティブゲートウェイ
ゲートウェイ上で少なくとも 1 つのルートが設定済みであること
リトライポリシーの設定
MSE コンソールにログインします。画面上部のナビゲーションバーからリージョンを選択します。
左側のナビゲーションウィンドウで、クラウドネイティブゲートウェイ > ゲートウェイ を選択します。対象のゲートウェイ名をクリックします。
左側のナビゲーションウィンドウで、ルート をクリックし、その後 ルート タブをクリックします。
変更対象のルートを見つけ、 Policies を Actions 列でクリックします。
Retry タブをクリックします。
以下のパラメーターを設定し、OK をクリックします。
パラメーター 説明 Retry Times 最大リトライ試行回数。有効範囲：0～10。推奨値：0、1、または 2。 0を指定すると、リトライが完全に無効化されます。Retry Condition リトライをトリガーする 1 つ以上の条件。詳細については、「リトライ条件」をご参照ください。 Retry Status Code リトライをトリガーする 1 つ以上の HTTP ステータスコード。 Retry Condition として retriable-status-codes有効 スイッチをオンにしてリトライポリシーを有効化します。スイッチをオフにすると無効化されます。
リトライポリシーの検証
リトライポリシーを有効化した後、期待通りに機能することを検証してください。
設定したリトライ条件に合致するバックエンド障害をシミュレートします（例：
503応答を返す、または接続を切断する）。影響を受けるルートに対して、ゲートウェイ経由でリクエストを送信します。
バックエンドのアクセスログを確認し、ゲートウェイが想定通りの回数だけリクエストをリトライしたことを確認します。
冪等性とリトライストーム
冪等性： 冪等な操作（同一の結果をもたらす繰り返し可能なリクエスト）に対してのみリトライを有効化してください。支払い処理などの冪等でない操作をリトライすると、重複した副作用が発生する可能性があります。
リトライストーム: 高トラフィックシナリオでは、アグレッシブなリトライ設定が、劣化したバックエンドサービスへのロードを増幅させる可能性があります。バックエンドサービスを保護するために、リトライポリシーをサーキットブレーカーまたはレート制限ポリシーと組み合わせてください。
関連操作
タイムアウトポリシーを設定する：ゲートウェイがバックエンドの応答を待機する最大時間を制御します。
サーキットブレーカーポリシーを設定する -- 異常なバックエンドサービスへのリクエストの転送を自動的に停止します。