ひとことで言うと
ヘルスチェックは、サーバーやアプリに定期的に合図を送り、「今ちゃんと返事できるか」を確認する仕組みです。
たとえ話でもう少し詳しく
複数店舗を運営していると、営業開始前に各店へ連絡して「今日は開けられるか」を確認したくなります。
- 電話に出ない
- レジが止まっている
- 一部の担当しか動けない
こうした状態の店にお客さんを案内すると混乱します。 Webサービスでも同じで、ロードバランサー や リバースプロキシ は、裏側サーバーが本当に応答できるかを見てから流す先を決めます。
よく出る場面・使いどころ
- 複数台のサーバーにアクセスを振り分けるとき
- 障害中のアプリへ誤って流したくないとき
- デプロイ直後に最低限の動作確認を自動化したいとき
- 稼働率 を下げる停止時間を減らしたいとき
似た言葉との違い
- 稼働率
- 稼働率は「どれだけ止まらなかったか」を見る結果の指標
- ヘルスチェックは「今この瞬間に流してよいか」を確かめる確認方法
- ロードバランサー
- ロードバランサーは振り分け役そのもの
- ヘルスチェックは、その振り分け先を安全に選ぶための判断材料
- リバースプロキシ
- リバースプロキシは受付や中継の役割
- ヘルスチェックは、どの受付先が生きているかを確かめる補助機能
実務で気にするポイント
- 「ポートが開いているだけ」で合格にするか、「アプリの主要機能まで返るか」を見るかを決める
- 厳しすぎる設定にすると、一時的な遅延だけで正常サーバーまで外しやすい
- 復帰判定も設計する。落とす条件だけ決めると、戻せるのに戻らないことがある
- 監視通知と分けて考える。ヘルスチェックは経路制御、監視は人への通知が主目的
注意: ヘルスチェックは万能ではありません。簡単な応答だけ返せても、DB 接続や重要APIが壊れていれば実利用では失敗するため、確認内容は業務に合わせて設計してください。