ELB ヘルスチェック失敗時の切り分け！バックエンド EC2 への直接アクセスを検証してみた

アノテーション テクニカルサポートの Shimizu です。

ELB（Elastic Load Balancer）を構築中のユーザー様から、ターゲットグループのヘルスチェック失敗（Unhealthy）が解消しないため、原因を調査したいというお問い合わせを多くいただきます。

このような場合はまず「ELB を経由せず、バックエンドのサーバー（EC2 や ECS）に対して直接アクセスができるかを検証する」という方法がトラブルシューティングとして有効ですが、この手順がわかりにくいという方も多いかと思います。

そこで今回は ELB ヘルスチェックの基本的な仕組みと、バックエンド EC2 インスタンスへ直接アクセスして検証する手順をご紹介します！

ELB ヘルスチェックの仕組み

ELB のターゲットグループ毎に「ヘルスチェック設定」があり、この条件に合格すれば Healthy、違反すれば Unhealthy となります。以下の例を見てみましょう。

上記設定の場合は「ターゲット EC2 内部のパス "/" に対して HTTP:80 でリクエストを送信した際に、ステータスコード 200 が返される」ということがヘルスチェック合格の条件となります。
この条件が満たされていれば Healthy になりますが、違反した状態（例えば 200 以外のステータスが返る等）が 2 回連続すると Unhealthy となります。

従って Unhealthy となる原因を特定するには、まず ELB を経由せずにターゲット EC2 に対して直接 HTTP:80 でアクセスしてみて、正常な応答が返されるかを検証することが重要になります。

やってみた

ここではバックエンド EC2 インスタンスがプライベートサブネットに配置されている前提で、最も近いロケーション（同じプライベートサブネット内）に踏み台 EC2 インスタンスを構築して、そこからバックエンド EC2 インスタンスへの直接アクセスを検証してみます。

手順1. SSM 接続するための前準備

以下の記事を参考にして、SSM マネージドノードを起動する前準備をします。
インスタンスにアタッチする IAM ロール、および SSM 接続に必要な VPC エンドポイントの設定を行いましょう。

参考：プライベートサブネットにあるEC2インスタンスを Systems Manager で管理する | DevelopersIO

すでに対象の VPC 環境で SSM 接続の準備ができている（SSM マネージドノードが存在する）場合は本手順をスキップして「手順2. 踏み台 EC2 インスタンスの作成」に進みましょう。

※ VPC エンドポイントの使用には料金がかかります。
下記の記事では CloudFormation テンプレートを利用して踏み台 EC2 と VPC エンドポイントを一括で作成・削除する方法をご紹介していますので、検証後にすぐに削除したい方はこちらを参考にしてください。

参考：SSM アクセスOK！踏み台 EC2 インスタンスを一括で作成してみた（CloudFormation 利用）

SSM 接続の前準備ができたら、次の手順に進みます。

手順2. 踏み台 EC2 インスタンスの作成

以下の条件で踏み台 EC2 インスタンスを新規で起動します。
（前項で CloudFormation テンプレートを利用してインスタンスを起動している場合は、この手順もスキップしてください）

• [Amazon マシンイメージ (AMI)]
  任意で構いませんが、ブラウザでの画面確認を行うことも想定して Windows を選択します。ここでは SSM エージェントがプリインストールされている Microsoft Windows 2022 Datacenter edition にしました。
• [インスタンスタイプ]
  起動と接続さえできればスペックは問わないため、ここでは「t2.nano」を選択します。
• [キーペア (ログイン)]
  フリートマネージャで接続するため、キーペアは紐づけておきます。
• [IAM インスタンスプロフィール]
  前準備で作成した、SSM の権限が付与された IAM ロールをアタッチします。
• [セキュリティグループ]
  適当で構いませんが、最低限アウトバウンドルールでポート 443 の通信は空けておきましょう。

上記の条件で踏み台 EC2 インスタンスを起動したら、数分待って SSM フリートマネージャの画面を確認しましょう。SSM マネージドノードとしてオンラインになっていれば準備完了なので、次の手順に進みましょう。

手順3. バックエンド EC2 側で、踏み台 EC2 からのアクセスを許可する

次に調査対象のバックエンド EC2 インスタンスに対して、先ほど起動した踏み台 EC2 からのアクセスを許可するようセキュリティグループを設定します。

踏み台 EC2 にアタッチしたセキュリティグループの ID から、目的のポート（例えば HTTP:80）へのアクセスを許可するインバウンドルールを追加します。

以上で踏み台 EC2 からのアクセスを許可する設定は完了です。

バックエンド EC2 へ直接のアクセスを検証してみる

まずは SSM フリートマネージャの画面から、あらかじめ紐づけておいたキーペアを使用して踏み台 EC2 インスタンスへ RDP 接続します。

インスタンスに接続できたら Edge ブラウザを起動します。初回起動時はサインインを促されますが、特に不要なのでスキップしましょう。

Edge ブラウザのアドレスバーに http://バックエンド EC2 のプライベートIPアドレス：ポート番号 を入力して直接アクセスしてみます。
意図したWebページが正常に表示されればOKですが、もしエラーが表示される場合はバックエンド EC2 の内部設定に問題があると切り分けられるので、EC2 内部のwebサーバーの設定等を見直しましょう。

※ EC2 内部エラーの原因や解消法はその都度異なるため、ここでは割愛します。

次はコマンドラインからも確認してみます。
Windows PowerShell 版の curl コマンド Invoke-WebRequest を用いて、以下のように実行します。

Invoke-WebRequest http://バックエンド EC2 のプライベートIPアドレス：ポート番号

これも正常なら 200 のステータスコードが返りますが、エラーステータス（400系や500系）が返されたりタイムアウトする場合は、バックエンド EC2 内部設定に問題があるため、設定を見直しましょう。

これでバックエンド EC2 インスタンスへ、同一サブネットからの直接アクセスを検証できました！

おわりに

いかがでしたでしょうか。

弊社ヘルプデスクへのお問い合わせで ELB のヘルスチェックが合格しない、もしくは他ネットワークからの接続がうまくいかないといったお問い合わせをよくいただきます。

そのような場合はまず「末端にあるバックエンドサーバーに最も近い、同サブネット内からの直接アクセスができるか」を確認することで解決につながるケースも多いため、今回その手順を記事にしました。

なお検証用の踏み台 EC2 インスタンスと VPC エンドポイントを普段は使用しないため、頻繁に作成・削除をするといったケースでは以下記事で紹介している CloudFormation テンプレートがお役に立つと思います。ぜひご検討ください。

参考：SSM アクセスOK！踏み台 EC2 インスタンスを一括で作成してみた（CloudFormation 利用）

この記事がご参考になりましたら幸いです！

参考資料

• 参考1: ALB のヘルスチェックが “Health checks failed with these codes:[XXX]” で失敗する原因と対処法を教えてください | DevelopersIO
• 参考2: プライベートサブネットにあるEC2インスタンスを Systems Manager で管理する | DevelopersIO
• 参考3: curl/PowerShellでHTTPアクセスいろいろ #PowerShell - Qiita

アノテーション株式会社について

アノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。当社は様々な職種でメンバーを募集しています。「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社 採用サイトをぜひご覧ください。