前回記事にしたALBのコストが跳ね上がった原因を調査するべく、ログを調べてみました。
ALBのログを取れればいいけども、ALBのログはS3（ストレージ）が必要で、またお金がかかるとのことなので、とりあえずEC2のアクセスログを確認してみた。
EC2のSSHでアクセスして、
sudo tail -n 20000 /var/log/httpd/access_logでログを見たところ。
"GET / HTTP/1.1" 301 "-" "ELB-HealthChecker/2.0"ん？ヘルスチェックのアクセスだろうけど、301って…。
HTTP 301（Moved Permanently）は、要求されたページやリソースが新しいURLに「恒久的に移動した」ことを示すステータスコードです。
ということは…正常（200）ではない。
AWSにログインしてターゲットグループを確認すると「異常」になってました。
原因：HTTPS強制リダイレクトとヘルスチェックの衝突
構成はよくあるパターン。
- ALB → EC2（Apache + WordPress）
- サイトは HTTPS 強制
- ALBのヘルスチェックは HTTP で / をチェック
この結果どうなっていたかというと、
- ALBが / を HTTP で叩く
- Apache / WordPress が HTTPS にリダイレクト
- ヘルスチェックは 301を受け取る
- 成功条件（200）を満たさず Unhealthy
- ターゲットの状態が不安定になる
ということのようです。（チャッピー曰く）
これがLCU増に関係あるかはまだわからないですが、とりあえず直します。
対策：ヘルスチェック専用の200エンドポイントを作る
やったことはとてもシンプル。
① ヘルスチェック専用ファイルを作成
Apacheの DocumentRoot に、静的なファイルを置く。下がコマンド。
echo ok | sudo tee /var/www/html/healthz.html② ターゲットグループのヘルスチェック設定を変更
- Protocol：HTTP
- Path：/healthz.html
- Success codes：200
WordPressもリダイレクトも通らない純粋な生存確認用エンドポイントにした。
結果：挙動は安定。LCUが下がるかは様子見。
修正後、Apacheのログはこうなった。
"GET /healthz.html HTTP/1.1" 200 "ELB-HealthChecker/2.0"200が返ってOK。AWSコンソールでも異常が消えました。
ただ、ヘルスチェックが異常だったとはいえ、リクエストの数は変わっていないはず。なのでこれでLCUが減るかは不明です。直さなければいけないポイントではあったけども、コスト減に繋がるのかは疑問が残ります。もしこれが原因だったらLCUは高止まりしてそうだし。実際は時間によって高かったり収まったりなので、常時のヘルスチェックが原因ではない気がしています。
まぁ、そもそも１ヶ月もヘルスチェックがエラーを起こしていたことに気づかないのが問題ですね…。CloudWatchやAmazon SNSを利用して異常時に通知する方法があるようですが、そこはもうちょっとアクセス数が増えて安定稼働が必要になったら考えます！
次回は、ログをみていたところwp-cron.phpへのアクセスも多い模様なので、wp-cron がALBやサーバー負荷に与える影響について検証してみます。