【正解】D
【0からの解説】
①前提知識：Memorystore for Redis Cluster は、Google Cloud が運用するフルマネージドの Redis（インメモリ キー・バリュー ストア）で、複数のシャードにデータを分散して高いスループットを得るサービスです。マネージド サービスであってもメンテナンス、フェイルオーバー、スケーリング、ネットワークの一時的な瞬断などで、クライアントとの接続が切れることは避けられません。そのため「接続が切れたときにアプリ側でどう振る舞うか」はアプリケーション開発者の責任範囲です。
・指数バックオフ（exponential backoff）：再試行の待ち時間を 1 秒、2 秒、4 秒…と失敗のたびに倍々で延ばしていく方式です。障害直後にサーバーへ再接続要求が殺到するのを防ぎます。
・ジッター（jitter）：待ち時間にランダムな揺らぎを加えることです。多数のクライアントが同じタイミングで一斉に再接続する「サンダリング ハード（thundering herd）」を防ぎます。Google Cloud は API 呼び出しやデータストアへの接続の再試行で、ジッター付き指数バックオフを推奨しています。
・クライアントサイド キャッシュ：アプリケーション プロセス内のメモリに、直近に読んだ値を短時間保持しておく仕組みです。Redis に一時的に届かない間も、ローカルにある値で読み取りに応答できます。
②要件の整理：「ネットワークの問題に対して回復性がある」「クライアントの切断を適切に（gracefully）処理する」「中断を最小限に」「アプリの安定性を確保」。つまり、アプリ側で自動的かつ過負荷を起こさない形で再接続し、その間もサービスをできるだけ継続することが求められています。
③正解の理由：D は、(1) ジッター付き指数バックオフで、瞬断なら素早く、長引く障害ならサーバーを圧迫しないペースで自動再接続し、(2) クライアントサイド キャッシュで再接続を待つ短い間も読み取りに応答できるため、ユーザーへの影響（中断）を最小化できます。これは Google Cloud のドキュメントが再試行のベスト プラクティスとして示す考え方そのものであり、要件をすべて満たします。
【誤りの選択肢】
A：切断を検出するたびにアプリケーション インスタンスを終了・再起動するのは、一時的な瞬断を「アプリの停止」という大きな障害に拡大させる対応です。再起動中はリクエストを処理できず、多数のインスタンスが同時に再起動すると再接続の集中も起こります。「中断を最小限に」「安定性を確保」という要件に真っ向から反します。
B：固定 60 秒の遅延は、数百ミリ秒〜数秒で回復する瞬断でも必ず 60 秒待つため、不必要に長い中断を生みます。また全クライアントが同じ間隔で再試行するため、ジッターがなく一斉再接続（thundering herd）を防げません。指数バックオフ＋ジッターに比べて応答性・安定性の両面で劣ります。
C：自動フェイルオーバー（レプリカを使ったゾーン障害時の切り替え）はサーバー側の可用性を高める機能で、それ自体は有用です。しかし、フェイルオーバーの最中やネットワークの瞬断時にはクライアントの接続はやはり切断されるため、「クライアントの切断をアプリケーションが適切に処理する」という問われている課題の解決策になっていません。アプリ側の再接続ロジックは別途必要です。
【参考】
Memorystore for Redis の高可用性再試行の方法 | Cloud Storage