無限ノック › SOA 練習問題一覧 › 問題SOA 信頼性とビジネス継続性
ある企業のWebサービスはEC2 Auto Scalingグループ（ALBのターゲットグループに登録）で稼働しています。あるインシデントで、一部インスタンスのアプリケーションプロセスがデッドロックしHTTP 503を返し続けましたが、EC2のシステムステータスチェックとインスタンスステータスチェックは正常のままでした。ALBは異常ターゲットへのルーティングを停止したものの、Auto Scalingグループはこれらのインスタンスを異常と見なさず置換しませんでした。今後アプリレベルの異常を検知して自動で置換されるようにする、最小の運用負荷の方法はどれですか。
A Auto ScalingグループのヘルスチェックタイプをELBに設定し、ALBターゲットグループのヘルスチェック結果を用いて異常と判定されたインスタンスを自動的に終了・置換する
✓ 正解
ヘルスチェックタイプにELBを追加するとAuto ScalingがALBターゲットグループのアプリレベルのヘルスチェック結果を参照するようになり、OSは正常でもHTTP異常を返すインスタンスを自動で終了・置換できる。設定変更のみで運用負荷も最小。
B EC2インスタンスのステータスチェック失敗を監視するCloudWatchアラームを作成し、アラームからLambda関数を起動して該当インスタンスを検出・再起動する仕組みを構築する
CloudWatchアラームからLambdaで置換する方式は実現可能だが、アプリ異常を検知する監視とLambda関数の実装・保守が必要で運用負荷が高く、設定変更だけで済む方法に比べて劣る。
C Auto Scalingグループのヘルスチェック猶予期間（グレースピリオド）を延長し、アプリケーションが応答を回復するまで十分な時間だけインスタンスの置換を待機させる
猶予期間の延長はインスタンス起動後にヘルスチェックを開始するまでの待機時間を延ばすだけで、Auto ScalingがEC2ステータスチェックしか参照していない根本原因を解決せず、アプリ異常は検知できない。
D ALBのターゲットグループで登録解除の遅延（Deregistration Delay）の値を短縮し、異常と判定されたターゲットをより速やかに切り離してから置換されるようにする
登録解除の遅延はターゲット切り離し時に既存コネクションをドレインする時間を制御する設定で、インスタンスを異常と判定して置換するかどうかとは無関係であり、この問題は解決しない。
解説 Auto ScalingグループのヘルスチェックタイプはデフォルトでEC2のみが有効で、これはハイパーバイザやOSレベルのステータスチェックしか見ません。そのため、OSは正常だがアプリケーションプロセスがデッドロックしてHTTP異常を返すようなケースでは、Auto Scalingはインスタンスを異常と判定せず置換しません。ヘルスチェックタイプにELBを追加すると、ALBターゲットグループのアプリケーションレベルのヘルスチェック（例: /healthへのHTTP応答）結果をAuto Scalingが参照し、異常ターゲットを自動的に終了・置換します。設定変更のみで実現でき運用負荷が最小です。
選択肢BのCloudWatchアラーム＋Lambdaはアプリ異常の検知ロジックやLambdaの実装・維持が必要で運用負荷が高くなります。
選択肢Cの猶予期間延長はヘルスチェック開始を遅らせるだけで、そもそもEC2チェックしか見ていない問題を解決しません。
選択肢Dの登録解除の遅延は正常な切り離し時のコネクションドレイン時間を制御する設定で、インスタンスの置換判定とは無関係です。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →