Q24 — AWS SAA-C03 第2章
第 24/65 問 | ← 第2章
Q89. ある会社のHTTPアプリケーションは、Network Load Balancer（NLB）の後ろに配置されています。NLBのターゲットグループは、Webサービスを実行する複数のEC2インスタンスで構成されるAmazon EC2 Auto Scalingグループを使用するように設定されています。この会社は、NLBがアプリケーションのHTTPエラーを検出できていないことに気づきました。その結果、Webサービスを実行するEC2インスタンスを手動で再起動する必要が生じています。この会社は、カスタムスクリプトやコードを記述することなく、アプリケーションの可用性を向上させる必要があります。これらの要件を満たすために、ソリューションアーキテクトは何を行うべきでしょうか？
- A. NLBでHTTPヘルスチェックを有効化し、会社のアプリケーションのURLを指定する
- B. EC2インスタンスにcronジョブを追加して、ローカルアプリケーションのログを1分ごとに確認する。HTTPエラーが検出された場合、アプリケーションを再起動する
- C. NLBをApplication Load Balancer（ALB）に置き換え、会社のアプリケーションのURLを指定してHTTPヘルスチェックを有効化する。また、不健全なインスタンスを自動的に置き換えるようAuto Scalingアクションを設定する ✓
- D. NLBのUnhealthyHostCountメトリクスを監視するAmazon CloudWatchアラームを作成する。アラームがALARM状態になったときに、不健全なインスタンスを自動的に置き換えるようAuto Scalingアクションを設定する
正解: C. NLBをApplication Load Balancer（ALB）に置き換え、会社のアプリケーションのURLを指定してHTTPヘルスチェックを有効化する。また、不健全なインスタンスを自動的に置き換えるようAuto Scalingアクションを設定する
解説
NLBはTCP／UDPレベルのヘルスチェックのみをサポートし、HTTPレベル（例：HTTPステータスコード4xx／5xx）の応答を検証できません。したがって、オプションAは機能しません（NLBにはHTTPヘルスチェックはありません）。オプションBは「カスタムスクリプトやコードを書かない」という要件に反します。オプションDは、UnhealthyHostCountはNLBがヘルスチェックで失敗したホスト数を示す指標ですが、これはNLBのヘルスチェック自体がHTTPエラーを検知できないため、根本的な問題を解決しません。一方、Application Load Balancer（ALB）はHTTP／HTTPSレベルのヘルスチェックをサポートしており、指定したURLへのリクエストに対するHTTPステータスコード（例：200 OK）を検証できます。ALBのヘルスチェックが失敗すると、対象インスタンスは自動的にターゲットグループから除外され、Auto Scalingグループはその不健全なインスタンスを新しい健全なインスタンスで置き換えることができます。これにより、手動介入なしにアプリケーションの可用性が向上します。よって、正解はCです。