SAA弾力性に優れたアーキテクチャの設計
ある企業が、Web アプリケーションを Auto Scaling グループ（複数AZ）配下の Amazon EC2 上で稼働させ、Application Load Balancer で負荷分散しています。最近、一部インスタンスでアプリプロセスがハングして HTTP 500 を返すものの、EC2 インスタンス自体は正常稼働しているため、Auto Scaling がこれらを置き換えないという問題が発生しています。最小の運用負荷で、アプリレベルで異常なインスタンスを自動的に置き換えるにはどうすればよいですか。
AAuto Scaling グループのヘルスチェックタイプを ELB に変更し、ALB のターゲットグループで HTTP 応答を確認する
✓ 正解
ヘルスチェックタイプを ELB にすると Auto Scaling が ALB の HTTP ヘルスチェック結果を参照し、500 を返すアプリ異常インスタンスを Unhealthy と判定して自動置換できる。設定変更のみで運用負荷も最小であり要件に合致する。
BEC2 ステータスチェック失敗時にインスタンスを再起動する CloudWatch アラームを各インスタンスに設定する
EC2 ステータスチェックは OS・ハードウェアの正常性のみを見るため、インスタンスが正常でアプリのみハングするケースを検知できず、本問の HTTP 500 を返す異常インスタンスを置き換えられない。
CAuto Scaling グループのヘルスチェック猶予期間を短縮し、チェックの実行頻度を引き上げる
猶予期間の短縮や頻度変更を行っても、ヘルスチェックタイプが EC2 のままではアプリ層の応答を評価しないため、ハングしたインスタンスは依然として正常と判定され問題は解決しない。
DALB のアイドルタイムアウトを短く設定し、応答しないインスタンスへの接続を強制的に切断する
ALB のアイドルタイムアウトは接続の維持時間を制御するだけで、インスタンスの正常性判定や Auto Scaling による置き換えには関与しないため、異常インスタンスの自動置換という要件を満たさない。
解説
Auto Scaling グループのヘルスチェックタイプは既定で EC2（インスタンスのシステム/ステータスチェック）のみのため、OS が正常ならアプリがハングしても異常と判定されません。ヘルスチェックタイプを ELB に変更すると、ALB ターゲットグループの HTTP ヘルスチェック（特定パスへの 200 応答確認）結果を Auto Scaling が利用し、アプリレベルの異常インスタンスを自動的に置き換えられます。設定変更のみで実現でき運用負荷も最小です。
選択肢Bの再起動アラームは EC2 ステータスチェックを基準とするため、OS 正常でアプリのみ異常なケースを検知できない。
選択肢Cの猶予期間短縮や頻度変更は、そもそも EC2 ヘルスチェックがアプリ層の異常を見ないため問題を解決しない。
選択肢Dのアイドルタイムアウト変更は接続のタイムアウト挙動を変えるだけで、異常インスタンスの検知・置き換えには寄与しない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →