AWS環境で高可用性（HA）を担保するうえで欠かせないのが、ALB（Application Load Balancer）のヘルスチェック機能です。
ヘルスチェックが正常（Healthy）に機能していなければ、障害時にトラフィックの切り離しが行われず、冗長化の恩恵を受けられません。本記事では、ALBヘルスチェックの基本仕様から、運用現場で頻発するUnhealthy状態の原因と、効率的なトラブルシューティング手順をまとめます。
ALBヘルスチェックの基本仕様と役割
ALBは、エンドユーザーからのトラフィックを背後のEC2インスタンス（またはコンテナ等）へルーティングする前に、通信先が正常に稼働しているかを定期的に確認します。
ターゲットグループで指定されたエンドポイント（パス）に対して、HTTP、HTTPS、またはTCPリクエストを定期的に送信します。正常な応答があれば Healthy、応答がない、または期待されるステータスコード以外が返れば Unhealthy と判定します。
Unhealthyと判定されたターゲットへのトラフィック転送は自動的に停止され、Healthyなインスタンスのみでサービスを継続します（自動フェイルオーバー）。
豆知識：すべてUnhealthyでもサイトにアクセスできる理由
ターゲットグループ内の全ターゲットがUnhealthyになった場合、ALBは「ヘルスチェックの設定自体が誤っている」と判断し、強制的にすべてのターゲットへトラフィックを流し続けるフェイルオープン機能が働きます。「アクセスできているから」と放置すると、実際の障害時にフェイルオーバーが機能しないため、必ずHealthy状態に修正する必要があります。
Unhealthyになるよくある原因と対策
実務においてUnhealthyが発生する原因は、アプリケーションのエラーよりもネットワークや設定の不一致によるものが大半を占めます。
原因1：Security Group（セキュリティグループ）の設定漏れ
ALB障害で最も多い原因の一つです。ALBからEC2への通信がSecurity Groupで許可されていない場合、ヘルスチェックはタイムアウトし失敗します。
IPアドレスの直接指定ではなく、Security GroupのID（sg-xxxx）を参照する設定がAWSのベストプラクティスです。送信元はALBにアタッチされているSecurity Group、宛先はEC2のSecurity Groupの対象ポート（例：TCP 80）を許可してください。
原因2：ヘルスチェックパスの指定誤り
ALBは指定されたパスへリクエストを送信しますが、アプリケーション側の仕様と一致していないケースが多発します。
ALBのヘルスチェックパスをデフォルトの / に設定している一方、アプリケーションは /health や /api/status でのみ正常レスポンスを返す、といった例があります。実際のサービスは正常でも、ALBはUnhealthyと判定します。ターゲットグループのヘルスチェックパスを正しく修正してください。
原因3：HTTPステータスコードの不一致
ALBはデフォルトでは、HTTP 200 OK のみを正常（Healthy）と判定します。アプリケーションがリダイレクト（301、302）や別の成功コードを返す場合、Unhealthyになります。
ターゲットグループの「成功コード（Matcher）」はカスタマイズ可能です。200-299（すべての成功コード）、200-399（リダイレクト含む）、200,302（特定コードのみ）など、アプリ仕様に合わせて指定してください。
原因4：Webサーバープロセスの停止・ファイル欠損
OSレイヤーでのトラブルです。ApacheやNginxのプロセスが起動していない、ドキュメントルートに index.html がなく 403 や 404 を返している、といった状態でもUnhealthyになります。
トラブルシューティング手順
障害発生時は、次の手順で原因を切り分けます。
ステップ1：CloudWatchメトリクスによる状況把握
AWSコンソールのCloudWatchからALBのメトリクスを確認し、影響範囲を特定します。
UnHealthyHostCount でUnhealthyなターゲット数を把握します。全体のホスト数と一致する場合、SGやパス設定ミスの可能性が高いです。HealthyHostCount は正常稼働ターゲット数、TargetResponseTime は応答時間です。極端に長い場合はアプリケーション側の性能低下が疑われます。
ステップ2：EC2内部からの curl による疎通確認
Security Groupの問題なのか、アプリケーションの問題なのかを切り分けるため、対象EC2にSSH/SSMでログインし、localhost へ直接リクエストを投げます。
ドキュメントルートの確認例です。
curl -I http://localhost/404 Not Found が返る場合、ヘルスチェックパスが / だとUnhealthyになります。
ヘルスチェック用エンドポイントの確認例です。
curl -I http://localhost/health200 OK が返れば、「ALBのヘルスチェックパスを /health に変更すればHealthyになる」と判断できます。
まとめ
ALBのヘルスチェックは、システムの可用性を左右する重要な運用業務です。
Unhealthy障害が発生した場合は、闇雲にサーバーを再起動するのではなく、次の優先順位で確認すると効率的です。
Security Group（ALBからの通信が許可されているか）、Health Check Path（正しいパスか）、HTTPステータスコード（200以外を返していないか）、Webサーバ起動状態（プロセスは起動しているか）。
特にSecurity Groupの参照元設定ミスとHealth Check Pathの設定ミスは、新規構築時や構成変更時に頻発します。この切り分け手順をRunbookに組み込み、迅速な復旧に役立ててください。
クラウドや業務システム、インフラ構成など、ITまわりでお悩みの際は、まずはお気軽にご相談ください。
課題の整理から設計・開発まで、コンサルティングの形で伴走し、サイト構築や業務システム開発にも対応しています。