LinuCレベル4 システムアーキテクト 可用性の設計 問27
可用性の設計／負荷分散と障害の局所化メッセージキューを使った非同期処理で、コンシューマが処理に失敗した場合のリトライ設計について、適切でないものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「可用性の設計」に対応。実際の試験問題ではありません）
- A一定回数のリトライ後も処理できなかったメッセージをデッドレターキューへ転送することで、問題のあるメッセージを通常フローから分離して個別に調査・再処理できる
- B指数バックオフで再試行間隔を延ばすと失敗が続くバックエンドへの再試行の頻度が自然に下がるため、バックエンドの回復を待つ間の負荷を抑えられる
- Cバックオフの待ち時間が際限なく伸びないよう上限（キャップ）を設けることで、必要な再試行がいつまでも延期されるのを防ぐことができる
- D指数バックオフにジッター（乱数による揺らぎ）を加えると、複数のコンシューマが同じタイムスロットで一斉にリトライすることが促進され、短時間で集中的に処理できる
正解：D
解説
ジッターの目的は複数のコンシューマのリトライが同時に集中する「リトライストーム」を防ぐことです。乱数で再試行タイミングをばらつかせることで、同時期にリトライが集中してバックエンドへの負荷が急増する状況を避けます。「一斉に集中的に処理できる」という記述はジッターの目的と正反対であり、誤りです。デッドレターキューへの転送やバックオフの上限設定はいずれも適切な設計です。
選択肢ごとの解説
- A誤り（正しい記述）。デッドレターキューへの転送は問題のあるメッセージを分離して運用上の視認性を確保する有効な手法です。
- B誤り（正しい記述）。指数バックオフで再試行間隔を延ばすことで、障害中のバックエンドへの再試行頻度を下げ、回復の余裕を与えられます。
- C誤り（正しい記述）。バックオフに上限を設けることで再試行が無期限に延期されることを防ぎ、適切な頻度での処理継続を維持できます。
- D正しい（誤っている記述）。ジッターの目的は複数コンシューマのリトライが同時に集中することを防ぐことであり、「一斉に集中的に処理できる」は正反対の説明です。