今日学んだこと：ヘルスチェックに関して

ヘルスチェックとは、ロードバランサーが「このサーバー、ちゃんと生きてる？」と定期的に確認する仕組みだ。

なぜ必要なのか

複数台のサーバーにリクエストを振り分けるロードバランサーは、振り分け先が正常に動いているかを知る必要がある。サーバーがクラッシュしたり、アプリが応答しなくなったりしていても、ロードバランサーが気づかなければユーザーにエラーが届き続ける。

ヘルスチェックはこの問題を解決する。ロードバランサーが定期的にサーバーへリクエストを送り、正常なレスポンスが返ってくるかどうかを確認する。返ってこなければ「このサーバーは死んでいる」と判断して振り分けを止める。

クライアント
    ↓
ロードバランサー（ALB）
    ├── サーバーA ← ヘルスチェックOK → 振り分け対象
    ├── サーバーB ← ヘルスチェックOK → 振り分け対象
    └── サーバーC ← ヘルスチェックNG → 振り分けから除外

ヘルスチェックを受け取るサーバー側は、/health のようなエンドポイントを用意して 200 OK を返すだけでいい。

Railsなら数行で書ける：

# config/routes.rb
get '/health', to: proc { [200, {}, ['ok']] }

このエンドポイントはシンプルでいい。「アプリプロセスが起動していて、リクエストを受け付けられる状態か」を確認するのが目的なので、余計な処理は入れない。

DBへの疎通確認を含める場合は注意が必要だ。DBが一時的に重い場合にヘルスチェックが失敗し、正常に動いているアプリサーバーが切り離されてしまう。用途に合わせて判断する。

失敗しきい値を2回にすれば、一時的なネットワークの揺れで即座に切り離されるのを防げる。1回の失敗ですぐアウトにすると、ネットワークのゆらぎで健全なサーバーが誤って除外されるリスクが上がる。

成功しきい値を3回にすれば、再起動直後の不安定なサーバーが早まって復旧判定されるのを防げる。ある程度安定してから振り分けに戻すことで、ユーザーへの影響を減らせる。

ECS Fargateを使っている場合、ALBのヘルスチェックに加えてECS自体にもヘルスチェックが設定できる。

ALBのヘルスチェックが失敗するとタスクが振り分け対象から外れ、ECSのヘルスチェックが失敗するとタスク自体が再起動される。両方設定しておくと、異なるレイヤーの障害に対応できる。