【AWS】ALBのヘルスチェックが失敗する
Skrumエンジニアの根岸です。
弊社ではAWSでロードバランサーを構築することが頻繁にあるのですが、ある設定を忘れてしまいヘルスチェックが失敗することがたびたびあったので記事にします。
ターゲットグループに1つだけEC2インスタンスを設定し、そのターゲットグループにALB（Application Load Balancer）を設定しました。
EC2で稼働しているWebサーバは nginx です。
ターゲットグループのヘルスチェックは下記のように設定しています。
nginx のドキュメントルートには health.html （空ファイル）を格納しました。
ターゲットグループのヘルスチェックステータスを確認してみると、ステータスは unhealthy となっておりヘルスチェックに失敗していました。
404となっているのでどうやら health.html が読み取られていないようです。
Health checks failed with these codes: [404]
しかし、nginx のドキュメントルート直下には health.html を設置しているため、その前の段階でこけているのではないかと思いました。
手掛かりは無いかと早速 nginx の設定ファイル（ /etc/nginx/conf.d/default.conf ）を確認してみました。
server {
listen 80;
listen [::]:80;
hoge.com;
root /usr/share/nginx/html/public;
--- 以下略上記の設定では、hoge.comからのアクセスのみを許可しています。弊社では、IPアドレスやAWSロードバランサーのDNS名でのアクセスを弾くためにこのような制御を行なっています。
これでは当然AWSのヘルスチェックアクセスも弾かれてしまいますね。
よって、下記のように hoge.com に続けてEC2インスタンスの内部IP（下記の 172.31.6.159 は例）を記載し、AWSのヘルスチェックによるアクセスも許可するようにしました。
server {
listen 80;
listen [::]:80;
hoge.com 172.31.6.159;
root /usr/share/nginx/html/public;
--- 以下略EC2インスタンスの内部IP（プライベート IPv4 アドレス）は下記の赤枠のところに記載されています。
nginx を再起動すると、ヘルスチェックステータスは healthy になりました。
（nginx を再起動してからヘルスチェックステータスが healthy になるまで2分程度かかりました。ラグがあるので注意してください。）