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 となります。

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

やってみた

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

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

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

まだの場合は、以下の記事を参考にしてインスタンスにアタッチする IAM ロールの作成、および SSM 接続に必要な VPC エンドポイントの設定を行いましょう。

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

※ VPC エンドポイントの使用には料金がかかります。
もし今回の検証のために新たに VPC エンドポイントを作成する場合は、作業が終わったあとに削除することを検討しましょう。

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

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

以下の条件で踏み台 EC2 インスタンスを新規で起動します。

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

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

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

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

起動した踏み台 EC2 にアタッチしたセキュリティグループの ID からアクセスを許可するインバウンドルールを追加します。

以上で踏み台 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 テンプレートとして作成しておき、毎回検証時に作成/削除をするといった運用も良いでしょう。（この手順も機会があれば記事にしたいと思います）

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

参考資料

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

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

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