以下の設定で動いていたターゲットグループのヘルスチェックが、インスタンスの交換 (OS 入れ替えをしていて、動いているWebアプリケーションは同一) によって動かなくなった、というヤツ。

ターゲットグループの設定

/ へのヘルスチェックに合格しなくなった。

このアプリケーションはドメイントップにアクセスすると 302 Redirect で別の画面に連れて行かれる仕組みがあり (ドメイントップはまた別で使う予定があってリダイレクトを書いていた)、将来のメンテナンスも考えて 200-302 で HTTP ステータスコードを広く設定していた。

プロトコル	パス	ポート	正常のしきい値	非正常のしきい値	タイムアウト	間隔	成功コード
HTTP	`/`	トラフィックポート	2 ヘルスチェックの連続的な成功	2 ヘルスチェックの連続的な失敗	5 秒	15 秒	200-302

ちなみに ELB (ALB) を通さずに外部からアクセスする経路を用意してアクセスすると、想定通り / から 302 リダイレクトが発生するので「あぁ〜ん？」となっていた。

原因はわからない

結局原因はわからなかった。なぜならインスタンスに入っている Nginx のログを見た所、 ELB-HealthChecker のログがちゃんと記録されていた。

計画メンテナンスだったので「もう時間がない！」となり、苦肉の策としてパスを /admin/ に設定した。そう、管理画面のログインページである……。そしてちゃんと ELB はこれにもアクセスできた。

上記のようにパスを変更した所、無事にターゲットグループのヘルスチェックに合格した。

結局原因はわからなかったが、人間から見て動いているのに ELB (ALB) のヘルスチェックに合格しない！みたいな時には「天狗じゃ！天狗の仕業じゃ！」と言いながら、別の有効なパス (エンドポイント) を指定してみてください、という当たりさわりのないオチでした。

いやマジでこれなんだったんだろう。

というお声はまあそう、そうね。