サイトアイコン 協栄情報ブログ

ALBのヘルスチェックが失敗する時の対応方法と解決策


この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。

はじめに

高可用性なマルチAZWordpressサイトを構築をする中で、ALBのヘルスチェックが失敗し、504エラーが出ました。調査する中で解決方法がわかりましたので共有します。

ALBとは

ALB(Application Load Balancer)は、レイヤー7(アプリケーション層)で負荷分散を行うロードバランサーになります。リスナーで定義したプロトコルに対し、インターネットからのトラフィックをターゲットに登録したEC2インスタンスなどにルーティングします。

AWSのロードバランサーは、負荷分散を行う対象のプロトコルによって、ALB、NLB(Network Load Balancer)、GWLB(Gateway Load Balancer)、CLB(Classic Load Balancer)から選択することができ、それらをまとめたELB(Elastic Load Balancing)というサービスの中に存在します。ALB以外のサービスについては、下記を参照してください。

Elastic Load Balancing の特徴

今回問題の起きた構成

可用性を高めるためにマルチAZ構成にし、ALBが各EC2インスタンスにルーティングを行いますが、ALBからEC2のヘルスチェックで失敗が起きました。

ヘルスチェック失敗時に検証したこと

今回、構築後にALB経由で一度接続が成功しました。しかしワードプレスをインストールしようとした際にインストールができず、通信ができなくなりました。そのためALBのターゲットグループを確認してみると、ヘルスチェックのステータスが「Unhealthy」になっていました。ALBからEC2インスタンス間に問題が発生していることがわかります。

 失敗理由の確認

ターゲットグループの「Health status details」にエラー内容が記載されます。下記のドキュメントにヘルスチェック失敗時のエラーコードの内容について記載されていますので、参照します。今回は、「Request timed out」と表示されていますので、実機からHTTPエラーコードを確認してみます。

ロードバランサーが HTTP エラーを生成する

 インスタンス間の疎通によるHTTPエラーコードの確認

送信元インスタンスから送信先インスタンスへヘッダ情報をリクエストし、HTTPエラーコードを表示することで確認します。

コマンド
curl:データの送受信を行う。
-s:送受信の進捗データなどを非表示にするcurlコマンドのオプション。
–head:リクエストヘッダ情報を指定するcurlコマンドのオプション。
|:コマンドの標準出力を、次のコマンドの標準入力につなげる。
grep:ファイルから指定した文字列を検索して表示。
HTTP:HTTPを指定する。

curl -s --head http://送信先のプライベートIP | grep HTTP

EC2-Wordpress01-2-yoshimiからEC2-Wordpress01-1-yoshimiへの確認にて、504エラーと表示されました。

[ec2-user@ip-10-0-1-152 ~]$ curl -s --head http://10.0.2.228 | grep HTTP
HTTP/1.1 504 Gateway Timeout

EC2-Wordpress01-2-yoshimiからEC2-Wordpress01-1-yoshimiへの確認にて、504エラーと表示されました。

[ec2-user@ip-10-0-2-228 ~]$ curl -s --head http://10.0.1.152 | grep HTTP
HTTP/1.1 504 Gateway Timeout

以上から何らかの要因でリクエストが処理できず、タイムアウトしていることがわかりました。

 EFSマウントの確認

今回、EC2インスタンス作成時にEFSがマウントされるようにしていますが、マウントが正常に実行されていない場合、インスタンス間でファイルが共有されないため、EFSマウントの確認も行います。

コマンド
df:ディスクの空き領域を表示。
ーh:表示単位を調整するdfコマンドのオプション。

df -h

EC2-Wordpress01-1-yoshimiのEFSマウントを確認。8.0Eのディスクが表示されているため、EFSがマウントされています。

[ec2-user@ip-10-0-1-152 ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        474M     0  474M   0% /dev
tmpfs           483M     0  483M   0% /dev/shm
tmpfs           483M  496K  482M   1% /run
tmpfs           483M     0  483M   0% /sys/fs/cgroup
/dev/xvda1      8.0G  2.0G  6.1G  25% /
127.0.0.1:/     8.0E   84M  8.0E   1% /var/www/html
tmpfs            97M     0   97M   0% /run/user/1000

EC2-Wordpress01-2-yoshimiにおいても8.0Eのディスクが表示されているため、EFSがマウントされています。

[ec2-user@ip-10-0-2-228 ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        474M     0  474M   0% /dev
tmpfs           483M     0  483M   0% /dev/shm
tmpfs           483M  496K  482M   1% /run
tmpfs           483M     0  483M   0% /sys/fs/cgroup
/dev/xvda1      8.0G  2.0G  6.1G  25% /
127.0.0.1:/     8.0E   84M  8.0E   1% /var/www/html
tmpfs            97M     0   97M   0% /run/user/1000

以上からEFSのマウントは問題ないとわかりました。

問題を解決した方法

今回の構成では、ワードプレスがデータベース(RDS)を使用しています。RDSはセキュリティグループにて、EC2インスタンスにアタッチしているセキュリティグループを許可する構成にしています。こうすることでEC2からの通信を許可しています。しかしRDSのセキュリティグループを確認してみると、インバウンドルールにてEC2ではなくRDSのセキュリティグループを許可していることがわかりました。

インバウンドルールからRDSのセキュリティグループを削除し、EC2のセキュリティグループを追加します。こうすることでEC2からRDSへの通信を許可し、ワードプレスがデータベースを使用することができます。

想定通り、ALBのヘルスチェックを確認し、「Unhealthy」が「healthy」に変わりましたので、成功です。

まとめ

構築する上で作成したリソースが正常に機能しているかどうかを、1つずつ確認していくことが問題解決に繋がるということを学べました。各リソースを作成した後に、EFSマウント確認など単体テストを行うことで、最後まで構築する前に確認することができます。

モバイルバージョンを終了