LinuCレベル4 システムアーキテクト 可用性の設計 問6
可用性の設計／負荷分散と障害の局所化ECサイトの注文サービスは在庫サービスを同期的に呼び出している。在庫サービスが過負荷で応答の遅延と失敗を続けた際、注文サービスのスレッドが応答待ちで埋まり、在庫と無関係な機能まで停止した。在庫サービスの障害が続いている間は注文サービスの資源をその呼び出しに浪費せず、在庫サービスが回復したら人手を介さずに通常の呼び出しへ戻したい。この要件に対する設計として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「可用性の設計」に対応。実際の試験問題ではありません）
- A呼び出しのタイムアウトを長めに設定し、遅延している在庫サービスの応答も最後まで待ち切って処理を完了させる
- B失敗した呼び出しを間を置かずに数回再試行させ、在庫サービスの一時的な失敗を注文サービス側で吸収して成功率を上げる
- C失敗率が閾値を超えたら在庫サービスの呼び出しを遮断して即座に失敗させ、一定時間後に一部の呼び出しで回復を確かめる
- D注文サービスの入口で流入量を一律に制限し、単位時間あたりに受け付けるリクエスト数を処理能力の範囲内に抑える
正解：C
解説
要件は、下流の障害が続く間は呼び出し側の資源を守り、回復したら自動的に元へ戻すことで、これに合うのはサーキットブレーカーです。失敗率が閾値を超えると回路を「開いた」状態にして呼び出しを即座に失敗させるため、応答しない下流を待つスレッドや接続が積み上がらず、障害の影響を在庫機能に局所化できます。一定時間後に「半開き」の状態で一部の呼び出しを試し、成功すれば通常の状態に戻るため、回復時に人手は要りません。タイムアウトを長くしたり即座の再試行を増やしたりすると、待ち状態の資源や過負荷の下流への負荷がかえって増えます。入口での流量制限（スロットリング）は流入の制御には有効ですが、特定の下流の障害から呼び出し側を切り離す仕組みではありません。
選択肢ごとの解説
- A誤り。タイムアウトを長くすると応答待ちのスレッドがより長く占有されるため、呼び出し側の資源の枯渇が早まります。
- B誤り。過負荷の下流に間を置かず再試行を重ねると負荷がさらに増え、回復を遅らせて障害を拡大させます。
- C正しい。サーキットブレーカーの動作で、障害が続く間は呼び出しを即座に失敗させて資源を守り、半開きの状態での試行によって回復後は自動的に通常の呼び出しへ戻ります。
- D誤り。スロットリングは流入量の制御には有効ですが、無関係な機能まで一律に絞られるうえ、在庫サービスへの呼び出しが応答待ちで資源を占有する問題は残ります。