この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。
はじめに
高可用性なマルチAZWordpressサイトを構築をする中で、ALBのヘルスチェックが失敗し、504エラーが出ました。調査する中で解決方法がわかりましたので共有します。
ALBとは
ALB（Application Load Balancer）は、レイヤー7（アプリケーション層）で負荷分散を行うロードバランサーになります。リスナーで定義したプロトコルに対し、インターネットからのトラフィックをターゲットに登録したEC2インスタンスなどにルーティングします。
AWSのロードバランサーは、負荷分散を行う対象のプロトコルによって、ALB、NLB（Network Load Balancer）、GＷLB（Gateway Load Balancer）、CLB（Classic Load Balancer）から選択することができ、それらをまとめたELB（Elastic Load Balancing）というサービスの中に存在します。ALB以外のサービスについては、下記を参照してください。
今回問題の起きた構成
可用性を高めるためにマルチAZ構成にし、ALBが各EC2インスタンスにルーティングを行いますが、ALBからEC2のヘルスチェックで失敗が起きました。
ヘルスチェック失敗時に検証したこと
今回、構築後にALB経由で一度接続が成功しました。しかしワードプレスをインストールしようとした際にインストールができず、通信ができなくなりました。そのためALBのターゲットグループを確認してみると、ヘルスチェックのステータスが「Unhealthy」になっていました。ALBからEC2インスタンス間に問題が発生していることがわかります。
失敗理由の確認
ターゲットグループの「Health status details」にエラー内容が記載されます。下記のドキュメントにヘルスチェック失敗時のエラーコードの内容について記載されていますので、参照します。今回は、「Request timed out」と表示されていますので、実機から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マウント確認など単体テストを行うことで、最後まで構築する前に確認することができます。