ヘルスチェックパターン
サービスの稼働状態を定期的に確認し、異常を検知したらトラフィックを切り離す仕組み
ヘルスチェックパターンとは
ヘルスチェックパターンは、ロードバランサーやオーケストレーターがサービスの稼働状態を定期的に確認し、異常なインスタンスをトラフィックから自動的に切り離す仕組みである。手動での障害検知・対応を排除し、システムの可用性を向上させる。
シャローとディープの使い分け
シャローとディープの使い分けを以下にまとめる。
| 種類 | チェック内容 | 用途 | リスク |
|---|---|---|---|
| シャロー (浅い) | プロセスが生きているか | ALB のターゲットヘルスチェック | 依存先の障害を検知できない |
| ディープ (深い) | DB、キャッシュ、外部 API への疎通 | 監視・アラート | カスケード障害のリスク |
// シャローヘルスチェック: プロセスが生きていれば 200
app.get('/health', (req, res) => {
res.status(200).json({ status: 'ok' });
});
// ディープヘルスチェック: 全依存先の状態を確認
app.get('/health/deep', async (req, res) => {
const checks = {
db: await checkWithTimeout(() => db.query('SELECT 1'), 3000),
cache: await checkWithTimeout(() => redis.ping(), 1000),
s3: await checkWithTimeout(() => s3.headBucket({ Bucket: 'my-bucket' }), 2000),
};
const allHealthy = Object.values(checks).every(c => c.ok);
res.status(allHealthy ? 200 : 503).json(checks);
});
async function checkWithTimeout(fn: () => Promise<any>, ms: number) {
try {
await Promise.race([fn(), new Promise((_, reject) => setTimeout(() => reject('timeout'), ms))]);
return { ok: true };
} catch (err) {
return { ok: false, error: String(err) };
}
}
AWS でのヘルスチェック
ALB ターゲットグループ
ALB はターゲットグループに設定したヘルスチェックパスに定期的にリクエストを送り、異常なターゲットを自動的に切り離す。チェック間隔、連続失敗回数 (即切り離しを防ぐ)、復帰に必要な連続成功回数を設定する。
Route 53 ヘルスチェック
Route 53 のヘルスチェックは、エンドポイントの障害を検知して DNS フェイルオーバーを実行する。プライマリリージョンが障害の場合、セカンダリリージョンに自動切り替えする。
ECS タスクヘルスチェック
ECS はタスク定義にヘルスチェックコマンドを設定でき、異常なタスクを自動的に停止・再起動する。
カスケード障害の防止
ディープヘルスチェックの最大のリスクは、依存先の障害が自サービスの障害に波及するカスケード障害だ。
DB 一時障害 → ディープヘルスチェック失敗 → ALB がインスタンスを切り離し
→ 残りのインスタンスに負荷集中 → さらにヘルスチェック失敗 → 全インスタンス切り離し
対策:
- ALB にはシャローヘルスチェックを使う (プロセスの生存確認のみ)
- ディープヘルスチェックは監視・アラート用に別エンドポイントで提供
- ヘルスチェックにタイムアウトを設定し、依存先の遅延で自身が遅延しない
ヘルスチェックのレスポンス設計
ヘルスチェックのレスポンス設計の例を示す。
{
"status": "degraded",
"checks": {
"database": { "status": "healthy", "latency_ms": 12 },
"cache": { "status": "unhealthy", "error": "connection refused" },
"disk": { "status": "healthy", "free_gb": 45.2 }
}
}
healthy / degraded / unhealthy の 3 段階で表現する。一部の依存先が障害でも、コア機能が動作する場合は degraded として、トラフィックは受け続ける。
ヘルスチェックの種類
ヘルスチェックの種類を以下にまとめる。
| 種類 | 確認対象 | 用途 |
|---|---|---|
| Shallow | プロセスの応答 | ALB のルーティング |
| Deep | DB, 外部 API の接続 | 監視アラート |
| Liveness | プロセスが生きているか | K8s の再起動判定 |
| Readiness | リクエスト受付可能か | K8s のルーティング |
ヘルスチェックパターンの背景や設計思想は関連書籍に詳しい。
この記事は役に立ちましたか?
関連用語
ロードバランシング
複数のサーバーにトラフィックを分散し、可用性とスケーラビリティを向上させる仕組み
フェイルオーバー
障害発生時にスタンバイシステムへ自動的に切り替え、サービスの継続性を確保する仕組み
オートスケーリング
トラフィックや負荷に応じてコンピュートリソースを自動的に増減させる仕組み
Liveness/Readiness プローブ
Kubernetes がコンテナの生存状態と受信準備状態を判定するためのヘルスチェック機構
ガード節
関数の先頭で異常条件を早期にチェックし、ネストを浅く保つプログラミングパターン
Null Object パターン
null チェックの代わりに、何もしないオブジェクトを使って条件分岐を排除するデザインパターン
関連する記事
障害対応の夜に思い出す、あの本の 1 ページ
本番障害の緊迫した場面で、過去に読んだ技術書の知識が助けてくれた経験はありませんか。「いつか役立つ」知識が「今この瞬間」に変わる読書の価値を考えます。
深夜 3 時のデプロイ前に読み返したい 1 ページ
本番デプロイの直前、最終確認のチェックリストとして技術書の特定のページが役立つことがあります。緊張の場面で頼りになる「お守りの 1 ページ」の見つけ方と活用法。
バグを生むのは知識不足ではなく想像力不足である
バグの多くは、コードを書いた時点で「こういうケースもありうる」と想像できなかったことが原因です。想像力を鍛える読書法と、エッジケースへの感度を高める方法を解説します。