DOP弾力性に優れたクラウドソリューション複数選択
あるバッチ処理アプリケーションはAuto ScalingグループのEC2スポットインスタンスでSQSキューからジョブを取得して実行しています。各ジョブの処理時間は3〜8分です。スポットインスタンスが中断される場合、EC2は終了の2分前に中断通知（Spot Instance Interruption Notice）を発行しますが、現在は処理中のジョブが失われてしまい再処理が必要になっています。
スポットインスタンス中断時にジョブが確実に失われないようにするための正しいアプローチを2つ選択してください。
Aインスタンスメタデータサービス（IMDS: Instance Metadata Service）の /latest/meta-data/spot/instance-action エンドポイントを定期的にポーリングし、中断通知を検知した際にSQSメッセージの可視性タイムアウト（Visibility Timeout）を0秒に変更してキューに即時返却する
✓ 正解
IMDSの/latest/meta-data/spot/instance-actionエンドポイントをポーリングし、中断通知検知時にSQSメッセージの可視性タイムアウトを0に変更すれば、メッセージがキューに即時返却され、別インスタンスが2分以内に処理を引き継げます。
BAuto Scalingグループのヘルスチェック猶予期間（Health Check Grace Period）を600秒に延長し、スポットインスタンス中断後に代替インスタンスが起動するまでの時間を確保する
ヘルスチェック猶予期間はジョブロス防止と無関係です。可視性タイムアウト設定が本質的な改善策です。
CSQSキューのメッセージ可視性タイムアウトを最大ジョブ処理時間（8分）より長い10分に設定し、ジョブ完了時にDeleteMessage APIを明示的に呼び出してメッセージを削除する
✓ 正解
可視性タイムアウトを最大ジョブ時間（8分）より長く（10分）設定し、完了時にDeleteMessage APIで明示的に削除すれば、インスタンス中断時はタイムアウト後自動的にキューへ戻り、他インスタンスが処理できます。
DEventBridgeでEC2 Spot Instance Interruption Warningイベントをキャプチャし、Lambdaを起動してDead Letter Queue（DLQ: 処理失敗メッセージの隔離キュー）にジョブIDを記録する
DLQへのジョブID記録は失敗メッセージの追跡になりますが、メッセージの自動再処理機能は提供しません。
EスポットインスタンスでEC2 Hibernateを有効化し、中断時にメモリ状態をEBSボリュームに保存して再起動時にジョブを再開する
EC2 Hibernationはスポット中断からの確実な再開を保証しておらず、メッセージロス防止には不十分です。
解説
スポットインスタンスは終了の 2 分前に中断通知が発行されます。この猶予時間を活用して SQS メッセージをキューへ返却することで、別インスタンスがジョブを引き継ぐことができます。
選択肢 A は IMDS の /latest/meta-data/spot/instance-action エンドポイントをポーリングして中断を検知し、ChangeMessageVisibility API で可視性タイムアウトを 0 秒に変更してメッセージをキューへ即時返却します。2 分の猶予内に他インスタンスがジョブを取得して処理を引き継ぐことができます。
選択肢 C は SQS 可視性タイムアウトをジョブ最大処理時間（8 分）より長い 10 分に設定することで、処理中のメッセージが他インスタンスから不可視となり二重処理を防ぎます。インスタンス中断時はタイムアウト後にメッセージが自動的にキューへ戻り、別インスタンスが再処理できます。
選択肢 B のヘルスチェックグレースピリオドは ASG が新規インスタンスのヘルスチェックを待機する設定であり、処理中ジョブの損失防止には直接寄与しません。
選択肢 D は EventBridge と Lambda で DLQ にジョブ ID を記録する手法ですが、SQS メッセージ自体をキューへ返却する機能ではなく、ジョブの自動再処理は実現できません。
選択肢 E の EC2 Hibernate はメモリ状態を EBS に保存して再開する機能ですが、スポットキャパシティが再利用可能になるまで再開できないため確実なジョブ継続を保証しません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →