ヘルスチェック

GET /api/v1/health は、オーケストレーターやロードバランサーが、そのバックエンドにトラフィックを流してよいかを判断するために叩くエンドポイントです。認証は要らず、いつもの {meta, data, error} の封筒ではなく素のオブジェクトを返します。

条件	ステータス	ボディ
データベースが簡単なクエリに応答した	200	{"status": "ok"}
応答しなかった	503	{"status": "unavailable"}

チェックの内容はこれだけです。失敗をエラーページではなく明確なステータスコードとして返し、アクセスログからも除外されているので、数秒おきに叩いてもコストはなく、ログも汚しません。

liveness と readiness の両方に使ってください。 データベースに到達できないバックエンドは何の役にも立ちませんし、新しいインスタンスが 200 を返すのは起動処理が終わってからです。それはマイグレーションが適用し終えた時点でもあります。ロールアウトをこのエンドポイントで制御することが、スキーマの作業がまだ走っているインスタンスにローリングデプロイがトラフィックを送らないようにする方法です。

Docker Compose はすでにそうしています(compose.yml)。

healthcheck:
  test: ["CMD-SHELL", "curl -sf http://localhost:8000/api/v1/health || exit 1"]
  interval: 10s
  timeout: 5s
  retries: 5
  start_period: 10s

どこで設定する場合も、起動の猶予時間を与えてください。最初の起動ではマイグレーションの適用と初期ユーザーの投入が走るので、平常時の再起動より応答が遅れるのは正常です。

フロントエンドに専用のヘルスルートはありません。状態を持たず、依存先もバックエンドだけなので、ルートへの通常の HTTP リクエストで十分です。

稼働中のデプロイの数字(承認の滞留、実行の件数、失敗、リードタイム、メールキューの深さ)については運用メトリクスを参照してください。