Docker のヘルスチェックはどのように機能し、なぜ重要なのですか?

Question

Accepted Answer

**ヘルスチェック**は、コンテナのアプリケーションが単に実行されているだけでなく実際に**動作している**かどうかを Docker(またはオーケストレーター)がどう判断するかを伝えます。コンテナのプロセスは起動していてもアプリが壊れている(ハングしている、データベースに到達できない)ことがあり得ます。ヘルスチェックはこれを検出し、プラットフォームが対応できるようにします。

## ヘルスチェックの定義

```dockerfile
# in a Dockerfile
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1
# → Docker runs this command periodically; exit 0 = healthy, non-zero = unhealthy
```

```yaml
# in docker-compose.yml
healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
  interval: 30s
  timeout: 3s
  retries: 3
  start_period: 10s    # grace period on startup before failures count
```

Docker はヘルスチェックコマンドを定期的に実行し、その結果に基づいてコンテナのステータスが `healthy` または `unhealthy` になります(`docker ps` で確認できます)。

## 実行中 vs 正常(重要な区別)

```text
RUNNING → the container's process is alive (but the APP might be hung/broken)
HEALTHY → the health check confirms the app actually WORKS (responds correctly)
→ A container can be RUNNING but NOT HEALTHY (e.g. the app deadlocked, lost its DB).
  Without a health check, the platform only knows "running" — and keeps sending traffic
  to a broken container.
```

## ヘルスチェックが運用上重要な理由

```text
✓ ORCHESTRATORS use them: restart unhealthy containers; route traffic only to healthy ones
✓ Compose depends_on: condition: service_healthy → wait for real readiness
✓ LIVENESS (is it alive? restart if not) vs READINESS (ready for traffic? hold traffic if not)
  → Kubernetes uses liveness + readiness probes (the same concept, more granular)
✓ Prevents serving requests from broken-but-running containers
```

## なぜ重要なのか

Docker のヘルスチェックを理解することは、**信頼性の高いコンテナ化アプリケーションを運用する**ために重要であり、価値ある運用知識です。

決定的に重要な洞察は、**実行中と正常の区別**です。コンテナのプロセスは**起動していてもアプリケーションが実際には壊れている**(ハング、デッドロック、データベースに到達できない)ことがあり得ます。ヘルスチェックがなければ、プラットフォームはコンテナが「実行中」であることしか分からず、**壊れたコンテナにトラフィックを送り続け**、障害を引き起こします。

ヘルスチェックは、アプリケーションが**実際に動作している**ことを検証する方法(例えば `/health` エンドポイントへのアクセス)を定義することでこれを解決し、コンテナのステータスが単なるプロセスの生存ではなく実際の健全性を反映するようにします。

これは**運用上**重要です。オーケストレーターやツールがこれに基づいて動作するためです。それらは**unhealthy なコンテナを再起動し**(ハングやデッドロックからの自動復旧)、**healthy なコンテナにのみトラフィックをルーティングします**(壊れたインスタンスへのリクエスト送信を回避)。また Compose の `depends_on: condition: service_healthy` はヘルスチェックを使って本当の準備完了を待ちます(起動競合を解決)。

関連する **liveness と readiness** の区別(生きているか、再起動すべきか —— vs トラフィックを受け付ける準備ができているか)を理解することも重要です。**Kubernetes はこの同じ概念に基づく liveness プローブと readiness プローブを使う**ため、Docker のヘルスチェックを理解することはオーケストレーション環境に直接応用できます。

信頼性の高い運用には「実行中」と「実際に動作している」を区別し、壊れているが実行中のコンテナに対応する(再起動する、トラフィックを差し控える)ことが必要であり、ヘルスチェックがそれを可能にする仕組み —— オーケストレーターが自己修復やトラフィックルーティングに使う —— であることから、Docker のヘルスチェックを理解することはコンテナを信頼性高く運用するための価値ある実務上重要な知識です。これは壊れたコンテナが密かにトラフィックを受け取り続けるというよくある問題を防ぐ、本番環境の回復力にとって重要なプラクティスであり、オーケストレーターがアプリケーションの健全性をどう維持するかの基礎となる概念です。