3秒でわかる
サーバーが正常に動いているかを外部から定期的に確かめる仕組み。異常な機体を振り分け先から自動で外すための材料になります。
もう少し詳しく
どういうものか
ヘルスチェックは、稼働中のサーバーやコンテナが正常かどうかを、外部から定期的に問い合わせて確かめる仕組みになる。多くは専用の URL を用意し、そこへ数秒おきに要求を送って、想定した応答が返るかを見る。ロードバランサやコンテナ基盤がこの結果を使い、応答しない機体を振り分け先から外したり、入れ替えたりする。
なぜ必要か
プロセスが生きていることと、要求を正しく処理できることは同じではない。DB への接続が切れていたり、メモリを使い切って応答が返らなくなっていても、プロセス自体は残る。この状態の機体へ利用者を振り分ければエラーになる。外から実際に確かめて、駄目な機体を自動で切り離す判断材料が要る。
具体例
Express での最小の実装は次のようになる。
app.get("/healthz", async (req, res) => {
try {
await db.query("SELECT 1"); // 依存先まで確認する
res.status(200).json({ status: "ok" });
} catch (e) {
res.status(503).json({ status: "ng" });
}
});Docker から確認する場合の設定も同じ考え方になる。
HEALTHCHECK --interval=10s --timeout=3s --retries=3 CMD curl -f http://localhost:3000/healthz || exit 1つまずきやすいところ
依存先を全部確認する作りにすると、外部 API が一時的に遅いだけで自分の機体が切り離され、障害が広がる。起動可否を見る確認と、要求を受けられるかを見る確認は分け、外部サービスの状態は切り離しの判断に含めない。
確認用の URL に認証やアクセス記録を掛けると、数秒おきの要求でログが埋まり、認証で 401 が返って常に異常と判定される。この経路だけは除外しておく。
間隔と再試行の設定も要注意になる。1 回の失敗で切り離す設定は、瞬間的な遅延で機体を落とし続ける。数回連続で失敗したときに切り離す形が無難になる。
覚え方
生きているかを見るのが稼働の確認、仕事を受けられるかを見るのが受付の確認。この二つを分けて考えると、設定の意味が通る。
似た用語との違い
死活監視は外形から止まっていないかを見る運用寄りの言葉で、ヘルスチェックはその判定を自動化の入口として使う点に重みがある。監視ツールへの通知が目的なのか、振り分けからの切り離しが目的なのかで、確認する内容も間隔も変わってくる。