【ITニュース解説】Reason of unhealthy but seems fine instance detected by ELB

ELB（Elastic Load Balancing）は、インターネットからの大量のアクセスを複数のサーバー（インスタンスと呼ぶ）に効率よく振り分ける役割を持つ。このELBの重要な機能の一つが「ヘルスチェック」である。ELBは常に各インスタンスが正常に動作しているか監視しており、正常に動作していないと判断したインスタンスは、利用者にサービスを提供できない「不健康」な状態と見なし、リクエストの振り分け対象から外す。しかし、実際にインスタンス自体は問題なく動いているように見えるのに、ELBが不健康と判断してしまうことがある。これは、システムエンジニアとして原因を特定し、対処する必要がある典型的なシナリオである。

ELBがインスタンスを不健康と判断する最も一般的な原因の一つは、ヘルスチェックの「パス」がインスタンス側のアプリケーションと合致していないことである。ELBは、特定のURLパス、例えば「/health」にアクセスしてインスタンスの応答を確認する。ところが、インスタンス上で動作するアプリケーションがそのパスを提供していなかったり、異なるパス（例えば「/status」）で応答するように設定されていたりする場合がある。また、ヘルスチェックのURLにアクセスする際に認証情報が必要な場合も、ELBは正しい応答を得られない。インスタンスが「ページが見つかりません（HTTP 404エラー）」や「アクセスが拒否されました（HTTP 403エラー）」、あるいは「サーバー内部エラー（HTTP 500エラー）」などを返すと、ELBはそのインスタンスを不健康と見なす。

次に、ELBが想定する通信の「ポート番号」や「プロトコル」が、インスタンス側の設定と一致していないケースもよく見られる。例えば、ELBが標準的なWeb通信であるHTTPプロトコルでポート80番をチェックするように設定されているにもかかわらず、インスタンス上のアプリケーションがポート8080番で待機していたり、HTTPではなくHTTPS（暗号化された通信）のみに応答するように設定されていたりする場合である。このような状況では、ELBはインスタンスとの間に接続を確立できず、「接続拒否」や「タイムアウト」といったエラーを検出する。

セキュリティ設定がヘルスチェック通信をブロックしている可能性も高い。AWS環境では、「セキュリティグループ」や「ネットワークACL (NACL)」といった機能が、インスタンスへの通信を制御するファイアウォールの役割を果たす。ELBからのヘルスチェック通信が、これらのセキュリティ設定によってインスタンスに到達できないことがある。具体的には、インスタンスのセキュリティグループが、ELBからのヘルスチェックに使用されるポートへのインバウンド（受信）トラフィックを許可していない場合、ヘルスチェックのパケットはインスタンスに届く前に破棄されてしまう。

インスタンス上で動作するアプリケーション自体に一時的または永続的な問題がある場合も、ヘルスチェックは失敗する。アプリケーションの応答がELBのヘルスチェックで設定されたタイムアウト時間よりも遅い場合や、断続的にサーバーエラー（HTTP 5xxエラー）を返す場合がこれに該当する。これは、アプリケーションのプログラムにバグがあったり、メモリリークを起こしていたり、データベースとの接続に問題があったり、あるいはインスタンスが高負荷状態になった際に性能が低下したりすることが原因で発生する。他のインスタンスは問題なく稼働しているのに、特定のインスタンスだけがこのような状態に陥ることがある。

特定のインスタンスに固有の設定ミスがある場合も考えられる。例えば、問題のあるインスタンスにだけ古いバージョンのアプリケーションがデプロイされてしまっていたり、アプリケーションが動作するために必要なソフトウェアの依存関係（ライブラリなど）が不足していたり、設定ファイルが誤ったデータベースを指していたりする可能性がある。さらに、インスタンスのOS（例: Linux）に導入されているローカルファイアウォール（iptablesやufwなど）が、ELBからのヘルスチェック通信を意図せずブロックしている場合もある。これにより、その特定のインスタンスだけがヘルスチェックに失敗するという事態が発生する。

ELBのヘルスチェックには「しきい値」が設定されている。これは、ELBがインスタンスを「正常」と判断するために、連続して何回成功の応答を得る必要があるかという基準である。例えば、ELBが3回連続の成功応答を求めているのに、インスタンスのアプリケーションが不安定で、3回のヘルスチェックのうち2回しか成功しないような場合、ELBはそのインスタンスを「不健康」な状態と判断し続ける。たとえ時々成功応答を返していたとしても、設定されたしきい値を満たせなければ、正常とは認められないのである。

最後に、インスタンスのOSやネットワーク基盤自体に根本的な問題がある場合も考えられる。インスタンスのCPU使用率が異常に高かったり、ネットワークインターフェースに物理的または論理的な問題が発生していたり、あるいはルーティングテーブル（通信の経路を決定する設定）が正しく設定されていなかったりする場合などである。このような状況では、ELBは他の正常なインスタンスには問題なく接続できるのに、特定のインスタンスにだけ接続できないという状況が発生する。

ELBがインスタンスを「不健康」と判断しているが、システム管理者から見ると「問題がないように見える」インスタンスに対処する場合、システムエンジニアは以下の手順で調査を進めることが重要である。まず、ELBに設定されているヘルスチェックの具体的な構成、すなわちチェックするパス、ポート番号、通信プロトコルが、インスタンス上で動作しているアプリケーションの設定と完全に一致しているかを詳細に確認する。次に、ELBからのヘルスチェック通信がインスタンスに物理的・論理的に到達しているか、セキュリティグループ、NACL、そしてインスタンス内部のローカルファイアウォールといったネットワークセキュリティ設定が通信を妨げていないかを確認する。そして最後に、その「不健康」と判断された特定のインスタンスに直接ログインし、アプリケーションのログファイルを徹底的に調査する。ログには、発生したエラーメッセージ、応答の遅延に関する情報、アクセスされたパスの記録など、問題解決に直結する重要な手がかりが含まれている。これらの段階的な調査を通じて、ELBとインスタンスの間に隠れた問題を特定し、適切な対策を講じることが可能となる。