インフラでいうヘルスチェックとは？初心者向けに死活監視との違いやロードバランサーでの役割をわかりやすく解説
結論
インフラでいうヘルスチェック（Health Check）とは、サーバーやアプリケーションが正常にサービスを提供できる状態かを定期的に確認する仕組みです。
単にサーバーが起動しているかを確認するだけではなく、実際にサービスが正常に利用できるかを確認する点が、死活監視との大きな違いです。
ヘルスチェックとは？
ヘルスチェックとは、サーバーやアプリケーションに定期的にアクセスし、正常な応答が返ってくるかを確認する機能です。
例えば、Webサーバーに対してHTTPリクエストを送り、「HTTP 200 OK」が返ってくれば正常、「HTTP 500 Internal Server Error」や応答がない場合は異常と判断します。
つまり、「サービスとして正常に動作しているか」を確認する仕組みがヘルスチェックです。
どんな場面で使われる？
ヘルスチェックは、高可用性を実現するさまざまなシステムで利用されています。
| 利用場面 | ヘルスチェック内容 |
|---|---|
| ロードバランサー | 正常なサーバーだけへ通信を振り分ける |
| Kubernetes | Podが正常に動作しているか確認する |
| Webサーバー | HTTPやHTTPSの応答を確認する |
| クラウド環境 | インスタンスやサービスの状態を確認する |
| 監視システム | アプリケーションの正常性を確認する |
なぜ重要なのか
サーバーが起動していても、Webサービスやデータベースが停止していれば、利用者はサービスを利用できません。
ヘルスチェックでは、実際にサービスが利用可能かどうかを確認できるため、障害の早期検知や適切な負荷分散に役立ちます。
ヘルスチェックの仕組み
- ロードバランサーや監視サーバーが定期的にアクセスする
- 対象サーバーが応答する
- 正常な応答なら「Healthy（正常）」と判断する
- 異常な応答や応答なしなら「Unhealthy（異常）」と判断する
- 異常なサーバーへの通信を停止したり、管理者へ通知したりする
一定回数連続で異常と判定された場合にのみ切り離す設定が一般的で、一時的な通信遅延による誤判定を防いでいます。
ヘルスチェックと死活監視の違い
| 項目 | ヘルスチェック | 死活監視 |
|---|---|---|
| 目的 | サービスが正常に利用できるか確認する | サーバーが応答しているか確認する |
| 確認内容 | アプリケーションやサービスの状態 | 通信の応答有無 |
| 利用例 | HTTP 200の確認 | Ping応答の確認 |
| 利用場所 | ロードバランサー、Kubernetesなど | 監視システム |
初心者は、「死活監視はサーバーが生きているか」「ヘルスチェックはサービスが正常に動いているか」と覚えると理解しやすくなります。
ヘルスチェックでよく使われる方法
| 方式 | 内容 |
|---|---|
| HTTP/HTTPS | WebページやAPIへアクセスする |
| TCP | 指定ポートへ接続できるか確認する |
| HTTPS + URL指定 | 専用のヘルスチェック用ページを確認する |
| アプリケーション専用 | アプリケーション内部の状態を確認する |
実際のIT現場での利用例
ロードバランサー
Webサーバー3台を監視し、異常なサーバーにはアクセスを振り分けないようにします。
Kubernetes
Liveness ProbeやReadiness Probeを利用して、異常なPodを自動で再起動したり、通信対象から除外したりします。
AWS・Azure
Application Load BalancerやAzure Load Balancerでは、ヘルスチェックの結果をもとに正常なインスタンスだけへ通信を転送します。
業務でよくあるトラブル例
サーバーは起動しているのに通信されない
主な原因
- ヘルスチェックに失敗している
- Webサービスが停止している
- ヘルスチェックURLの設定ミス
- ファイアウォール設定
正常なのに異常判定される
主な原因
- タイムアウト時間が短すぎる
- 一時的な高負荷
- HTTPステータスコード設定ミス
- SSL/TLS設定の不一致
障害発生時の確認する順番
- 影響範囲を確認する
- サーバーへログインできるか確認する
- Webサービスやアプリケーションが起動しているか確認する
- ヘルスチェックURLへアクセスする
- イベントログやアプリケーションログを確認する
- ロードバランサーの状態を確認する
サーバー自体が正常でも、ヘルスチェック対象のサービスだけが停止していることは珍しくありません。
GUIでの確認方法
Windows環境では、次のツールを利用します。
- サーバーマネージャー
- イベントビューアー
- サービス管理ツール
- IISマネージャー（Webサーバーの場合）
クラウド環境では、AWS Management ConsoleやAzure Portalからヘルスチェック結果を確認できます。
CUI（コマンド）での確認方法
Windowsでは、次のようなコマンドが利用されます。
- ping（通信確認）
- Test-NetConnection（ポート確認）
- curl http://サーバー名/health（ヘルスチェックURL確認）
- Get-Service（サービス状態確認）
- Get-WinEvent（イベントログ確認）
Linuxでは、curl、wget、systemctl、ssなどを利用してサービス状態を確認します。
確認結果の見方
- Healthyと表示されているか
- HTTP 200が返っているか
- サービスが実行中になっているか
- イベントログに異常がないか
- ロードバランサーから通信対象になっているか
原因の切り分け
| 確認項目 | 確認内容 |
|---|---|
| サーバー | OSは正常に稼働しているか |
| アプリケーション | サービスは起動しているか |
| ロードバランサー | 異常判定されていないか |
| ネットワーク | 通信経路に問題はないか |
| 設定 | ヘルスチェックURLやポートは正しいか |
初心者がやりがちなミス
- Pingが返るので問題ないと思う
- ヘルスチェックと死活監視を同じものだと考える
- ヘルスチェック用URLを削除してしまう
- 異常判定の条件を確認しない
- イベントログを確認せず再起動する
上司へ報告するポイント
- 異常判定が発生した時刻
- 対象サーバー
- ヘルスチェック結果
- HTTPステータスコード
- イベントログの内容
- 実施した対応
- 現在の稼働状況
エスカレーションするタイミング
- ヘルスチェックが継続して失敗する
- ロードバランサーが全サーバーを異常判定している
- サービスが起動しない
- アプリケーションログに重大なエラーがある
- 原因が特定できない
応用知識
Kubernetesでは、ヘルスチェックをさらに細かく管理するために「Liveness Probe」「Readiness Probe」「Startup Probe」の3種類が利用されます。Liveness Probeはアプリケーションが正常に動作しているか、Readiness Probeはリクエストを受け付けられる状態か、Startup Probeは起動処理が完了したかを確認します。このように、現代のインフラでは単にサーバーの応答を見るだけではなく、アプリケーションの状態まで確認することが一般的になっています。
関連するIT用語
- 死活監視
- ロードバランサー
- 負荷分散
- フェールオーバー
- 高可用性（HA）
- HTTPステータスコード
- Kubernetes
- Liveness Probe
- Readiness Probe
よくある質問（FAQ）
ヘルスチェックとは簡単に言うと何ですか？
サーバーやアプリケーションが正常にサービスを提供できる状態かを定期的に確認する仕組みです。
死活監視との違いは何ですか？
死活監視はサーバーが応答しているかを確認する監視です。ヘルスチェックは、Webサービスやアプリケーションが正常に利用できるかまで確認します。
ヘルスチェックに失敗するとどうなりますか？
ロードバランサーでは異常と判断されたサーバーへの通信を停止します。KubernetesではPodの再起動や通信対象からの除外が行われることがあります。
Pingが返ってくるのにヘルスチェックで異常になるのはなぜですか？
サーバー自体は起動していても、Webサービスやアプリケーションが停止している可能性があります。ヘルスチェックはサービスの利用可否を確認するため、このような違いが発生します。
まとめ
ヘルスチェックとは、サーバーやアプリケーションが正常にサービスを提供できる状態かを確認する仕組みです。ロードバランサーやKubernetesなどでは、ヘルスチェックの結果をもとに正常なサーバーだけへ通信を振り分けるため、高可用性を実現するうえで重要な役割を担っています。
また、「死活監視はサーバーが応答しているかを確認する」「ヘルスチェックはサービスが正常に利用できるかを確認する」という違いを理解しておくことが重要です。IT現場では、死活監視・ヘルスチェック・ログ監視・リソース監視を組み合わせることで、障害を早期に発見し、安定したシステム運用を実現しています。
コメント