「返事がある」と「使える」は違う
店舗をいくつも運営していると、開店前に各店へ電話して「今日は開けられる？」と確かめたくなります。電話に出ない店、レジが止まっている店、担当が一部しかいない店。そこへお客さんを案内すれば混乱します。
ヘルスチェックは、サーバーやアプリに定期的に合図を送って、今ちゃんと返事ができるかを確かめる仕組みです。複数のサーバーへアクセスを振り分けるロードバランサーやリバースプロキシは、この結果を見て、どのサーバーに流してよいかを決めています。障害の起きているサーバーを自動で外せるので、利用者が止まったサーバーに当たる時間を減らせます。
ただ、電話に出たからといって、その店が営業できるとは限りません。サーバーも同じで、「ポートが開いていて返事はある」状態でも、裏のデータベースにつながらない、重要な API が壊れている、ということがあります。この場合、ヘルスチェックは合格なのに、利用者の操作は失敗します。何を確かめれば「使える」と言えるのか、業務に合わせて確認の中身を決めておくことが肝心です。
厳しすぎても甘すぎても困る
確認を厳しくすれば、壊れたサーバーを見逃しにくくなります。でも厳しすぎると、一時的に少し遅れただけの正常なサーバーまで外してしまいます。外しすぎれば、残ったサーバーに負荷が集中します。
外す条件と同じくらい大事なのが、戻す条件です。落とす条件しか決めていないと、回復したサーバーがいつまでも戻ってこないことがあります。デプロイの直後に最低限の動作確認を自動で走らせる、といった使い方も、この条件の設計しだいです。
監視とは知らせる相手が違う
似た仕組みに監視がありますが、目的が違います。ヘルスチェックの結果を受け取るのは、振り分け役の機械です。「今この瞬間、このサーバーに流してよいか」を判断して、経路を切り替えます。監視は、異常を人に知らせるのが主な役目です。
ヘルスチェックで自動的に外れたサーバーがあっても、誰かが気づいて直さなければ、台数は減ったままです。両方を組み合わせて、止まっている時間（稼働率を下げる時間）を短くします。