A不正解
ALB にリスナールールを追加する。/health へのリクエストには固定レスポンスを返す。
リスナールールの固定レスポンスは、ALB 自身がその場で応答を返す設定です。リクエストは EC2 インスタンスまで届かないため、データベースへ接続できるかどうかは応答に現れません。
またリスナールールが決めるのは、受け取ったリクエストをどう扱うかです。ターゲットごとに正常か異常かを判定する仕組みではありません。接続できないインスタンスへリクエストが届く状態は変わりません。
QUESTION
ある企業は、Application Load Balancer (ALB) の後ろの Amazon EC2 インスタンスでウェブアプリケーションを実行しています。アプリケーションには、データベースへ接続できたときだけ 200 を返す /health パスがあります。CloudOps エンジニアは、データベースへ接続できるインスタンスだけに ALB がリクエストを送るようにする必要があります。 これらの要件を満たすソリューションはどれですか。
1 / 1
回答を選択してください
正解D
解説
依存先まで含めた状態でターゲットを判定する ALB ヘルスチェックの設定を選ぶ
- 1「データベースへ接続できたときだけ 200 を返す /health パス」依存先まで含めた状態が、このパスの応答コードに現れるという意味です。デフォルトのパス
/では、接続できない状態でも 200 が返ります。 - 2「データベースへ接続できるインスタンスだけに ALB がリクエストを送るようにする」ALB がターゲットごとに正常か異常かを判定し、異常なターゲットを送信先から外すという意味です。通知では送信先は変わりません。Auto Scaling のヘルスチェックも、ALB のヘルスチェックとは別の判定です。
B不正解
Amazon CloudWatch Synthetics のカナリアで /health を監視する。失敗を通知する。
カナリアは /health を定期的に呼び出すため、接続できない状態に気づく手段としては動きます。
ただしカナリアの結果が現れるのは通知と CloudWatch のメトリクスだけで、ALB のリクエストの振り分けには使われません。ALB のエンドポイントを呼ぶ構成なら、どのインスタンスが接続できないかも分かりません。接続できないインスタンスへリクエストが届き続けます。
C不正解
Auto Scaling グループのヘルスチェックの種類を、EC2 に設定する。
この種類にすると、Auto Scaling は EC2 のステータスチェックとスケジュールされたイベントでインスタンスを置き換えるかどうかを判断します。ハードウェアや OS の異常は拾えますが、この設定だけでは、データベースへ接続できるかどうかは判定に加わりません。
インスタンス自体は動き続けるため置き換えは起きず、ALB がどのインスタンスへリクエストを送るかも変わりません。
D正解
ターゲットグループのヘルスチェックで、パスに /health を指定する。
パスに /health を指定すると、データベースへ接続できたインスタンスだけが 200 を返します。接続できないインスタンスは連続して失敗し、異常と判定されて送信先から外れます。ヘルスチェックのパスのデフォルト値は / なので、依存先まで含めて確認したいときはパスを指定します。
ポイント
ALB はターゲットグループのヘルスチェックで、指定したパスへ HTTP リクエストを送り、応答コードが成功コード (Matcher) に一致するかでターゲットごとの正常・異常を判定します。異常と判定されたターゲットは、原則としてリクエストの送信先から外れます。
・ヘルスチェックのパスが、何を確認するかを決めます。デフォルトは / です。依存先を確認しないパスでは、インスタンスに到達できることしか確認できません。データベースなどの依存先まで含めて見たいときは、その結果が応答に現れるパスを指定します。
・判定に使われるのはヘルスチェックの応答だけです。外部の監視で異常を検知して通知しても、ALB の振り分けは変わりません。
「処理できる状態のインスタンスにだけリクエストを送る」という要件では、ヘルスチェックのパスが依存先まで確認するものになっているかを見直します。