分散システムでは、1つのサービスの遅延や障害が、それを呼び出す上流のサービスにまで連鎖的に波及することがあります。本記事ではこれを防ぐ2つの代表的なパターンを解説します。

SAA レベル：基礎概念

リトライと指数バックオフ

一時的な障害（ネットワークの瞬断等）に対しては、即座にリトライすることで成功する場合がある
ただし、単純に即座にリトライし続けると、障害が長引いている場合にリクエストが集中し、状況を悪化させる

SAA 試験のポイント

AWS SDKには標準で指数バックオフ（Exponential Backoff）とジッターを用いたリトライ機構が組み込まれています。リトライの間隔を「1秒→2秒→4秒→8秒」のように指数関数的に増やし、さらにランダムな揺らぎ（ジッター）を加えることで、多数のクライアントが同時に再試行して障害を悪化させる「リトライの雪崩」を防ぎます。

サーキットブレーカーの基本概念

電気回路のブレーカーのように、下流サービスへの呼び出しが一定回数以上失敗すると、一時的に呼び出し自体を遮断し、下流サービスへの負荷をさらに与えないようにする仕組み

SAP レベル：高度な設計シナリオ

サーキットブレーカーの3つの状態

SAP 試験のポイント

サーキットブレーカーは一般的に3つの状態を遷移します。Closed（正常時、通常通り呼び出す）、Open（一定回数以上失敗すると遷移、呼び出しを遮断し即座にエラーを返す）、**Half-Open（一定時間経過後、試験的に少数のリクエストを通し、成功すればClosedに復帰）**という状態機械の理解がSAPレベルで問われます。

過負荷時の連鎖障害防止

SAP 試験のポイント

サーキットブレーカーがない場合、下流サービスが応答不能になっていても、上流サービスはタイムアウトまで待ち続けてリソース（スレッド、コネクション）を占有し続けます。これが積み重なると、上流サービス自体もリソース枯渇で機能しなくなり、障害が連鎖的に上流へ伝播します。サーキットブレーカーは、下流の障害を検知した時点で即座に失敗を返すことで、上流サービスのリソースを保護し、障害の連鎖を断ち切る役割を果たします。

設計上の落とし穴

「リトライを増やせば信頼性が上がる」という単純な理解は危険です。サーキットブレーカーがない状態で過度にリトライを行うと、すでに過負荷状態の下流サービスに追い打ちをかけ、障害からの回復をさらに遅らせることになります。SAPでは、リトライとサーキットブレーカーを組み合わせて設計することの重要性が問われます（リトライは一時的な障害向け、サーキットブレーカーは継続的な障害向け）。

べき等性の確保との関係

リトライを安全に行うためには、同じリクエストが複数回処理されても結果が変わらないべき等性が前提となる（2-2のマイクロサービス通信パターン記事とも関連）
冪等性キー（Idempotency Key）をリクエストに含め、サーバー側で重複リクエストを検出・排除する設計が実務で使われる

AWSサービスにおける実装例

Lambda同士の呼び出しやStep Functionsでは、リトライポリシーとタイムアウト設定を組み合わせて構成できる
Application Load Balancerのヘルスチェックと組み合わせ、異常なターゲットを自動的に切り離すことも、広い意味でのサーキットブレーカー的な設計と言える

まとめ

SAA: 指数バックオフとジッターによるリトライ設計、サーキットブレーカーの基本概念を理解する。
SAP: サーキットブレーカーの状態遷移、過負荷時の連鎖障害防止の仕組み、べき等性を前提としたリトライ設計ができる。

ここまでで 3-3 信頼性改善戦略 の全3記事が完了しました。次は 3-4 パフォーマンス改善戦略 に進みます。