負荷分散と可用性

ヘルスチェックへるすちぇっく

死活監視ロードバランサー可用性フェイルオーバー監視サーバー冗長化

ヘルスチェックって何？

簡単に言うとこんな感じ！

サーバーが「ちゃんと動いてる？」って定期的に確認する仕組みだよ。お店の開店前に「電気つく？レジ動く？」ってチェックするイメージで、問題があるサーバーには仕事を回さないようにしてくれるんだ！

ヘルスチェックとは

ヘルスチェックとは、サーバーやサービスが正常に動作しているかどうかを定期的に自動確認する仕組みのことです。人間の健康診断と同じように、「異常がないか」を繰り返しチェックして、問題が見つかったら即座に対処できるようにします。

ロードバランサー（複数のサーバーに処理を振り分ける機器やソフトウェア）は、ヘルスチェックの結果をもとに「どのサーバーにアクセスを流すか」を判断しています。チェックに失敗したサーバーは自動的に振り分け対象から外され（切り離し）、復旧すれば再び戻ります。これにより、ユーザーは障害を意識することなくサービスを使い続けられます。

システム発注の現場では「冗長化してあるから安心」と言われることがありますが、ヘルスチェックなしの冗長化は「壊れたサーバーにも仕事を送り続ける」状態になりかねません。可用性（システムが使える状態にある割合） を本当に高めるには、ヘルスチェックと冗長化がセットで必要です。

ヘルスチェックの種類と仕組み

ヘルスチェックには、チェックの「深さ」によっていくつかの種類があります。

種類	チェック内容	精度	負荷
pingチェック（L3）	サーバーが生きているか（IPレベル）	低	最小
TCPチェック（L4）	ポートが開いているか（接続できるか）	中	小
HTTPチェック（L7）	特定URLへのリクエストが正常に返るか	高	中
アプリケーションチェック	DB接続・外部API連携など業務処理が動くか	最高	大

チェックの流れ

ロードバランサー ──[GET /health]──▶ サーバーA  ✅ 200 OK  → 振り分け継続
                                 ▶ サーバーB  ❌ タイムアウト → 切り離し
                                 ▶ サーバーC  ✅ 200 OK  → 振り分け継続

よく使われるヘルスチェック用エンドポイント

アプリケーション側に専用のURLを用意するのが一般的です。

エンドポイント例	意味
`GET /health`	基本的な死活確認
`GET /healthz`	Kubernetes環境でよく使われる
`GET /ready`	「リクエストを受け付けられる状態か」の確認
`GET /live`	「プロセスが生きているか」の確認

判定パラメーターの例

パラメーター	説明	典型的な設定値
チェック間隔	何秒おきに確認するか	10〜30秒
タイムアウト	何秒待って無応答なら失敗とするか	5秒
失敗しきい値	何回連続失敗で切り離すか	2〜3回
成功しきい値	何回連続成功で復帰とするか	2〜3回

歴史と背景

1990年代: 初期のWebシステムは単一サーバーが主流で、障害時は手動での復旧が当たり前だった
2000年代前半: ECサイトや金融系サービスの普及とともに、複数サーバーの負荷分散（ロードバランシング）が普及し始める。ハードウェア製品（F5 BIG-IPなど）でのヘルスチェック機能が定着
2000年代後半: AWS ELB（Elastic Load Balancing、2009年）などクラウドのロードバランサーが登場し、ヘルスチェックが標準機能として提供されるように
2010年代: マイクロサービス（機能を小さなサービスに分割するアーキテクチャ）の広まりとともに、サービス単位のヘルスチェックが重要性を増す
2014年〜: Kubernetes（コンテナ管理プラットフォーム）がliveness probe・readiness probe・startup probeという3種類のヘルスチェックを定義し、業界標準的な概念として普及
2020年代: SRE（Site Reliability Engineering） の考え方が広まり、ヘルスチェックは「可観測性（Observability）」の基礎として体系的に位置づけられている

ロードバランサーとの連携・フェイルオーバーの全体像

ヘルスチェックは単体で機能するのではなく、ロードバランサーやフェイルオーバーの仕組みと組み合わさって初めて効果を発揮します。

Kubernetesの3種類のProbe（ヘルスチェック）

Kubernetesでは、ヘルスチェックを目的別に3種類定義しています。

Probe名	確認すること	失敗時の動作
Liveness Probe	コンテナが生きているか（デッドロックしていないか）	コンテナを再起動する
Readiness Probe	リクエストを受け付けられる状態か（起動完了・DB接続済み等）	一時的に振り分けから除外
Startup Probe	起動処理が完了したか（重いアプリの起動待ち用）	完了まで他のProbeを待機

比較：監視ツールのヘルスチェックとの違い

観点	ロードバランサーのヘルスチェック	監視ツール（Zabbixなど）のヘルスチェック
主な目的	振り分け先の自動制御	アラート通知・障害記録
失敗時の自動対処	自動で切り離し・復帰	通知のみ（人が判断）
チェック間隔	数秒〜30秒	1〜5分程度
対象	同一サービス内のサーバー群	広範なシステム全体

規格・RFC番号	内容
RFC 9110	HTTP Semantics（ヘルスチェックで使われるHTTPの基礎仕様）
RFC 8615	Well-Known URIs（`/.well-known/` パスの標準化。ヘルスエンドポイントのパス設計に関連）