Django 向け readiness / liveness 実装例

NOUMIN ENGINEERING TECH GUIDE

💬 くるるちゃんのワンポイント図解解説

【技術背景・解説】
この記事（Django 向け readiness / liveness 実装例）におけるIT技術の基本概念と重要ポイントを、わかりやすく整理・解説しています。

【アイキャッチ図解のポイント】
構成要素とデータフローを視覚的に整理し、初心者でも要点を掴みやすいグラフィック構造で表示しています。

【資格・要点ノート】
シラバス用語、基本概念の理解、実務への応用ポイント

前提は以下で固定します。

Python 3.12 以降
Django 4.x 以上
Kubernetes（Ingress + Service + Deployment）
SRE ＋セキュリティ考慮

― Kubernetes で「安全に生かし続ける」ための実践ガイド ―

はじめに

Kubernetes に Django を載せたとき、
最も多い事故原因はこれです。

「起動していない Django にトラフィックが流れる」

この事故は readiness / liveness を正しく実装するだけで防げます。

本記事では、

Django 4.x
Python 3.12+
本番運用を前提

として、
SRE 視点・セキュリティ考慮込みの実装例を解説します。

readiness / liveness とは何か（超要約）

種類	Kubernetes の判断
liveness	「このアプリ、生きてる？」
readiness	「今、通信していい？」

重要な違い

liveness が死ぬ → Pod 再起動
readiness が死ぬ → 通信停止（再起動しない）

👉 Django では 両方必要です。

なぜ Django では分ける必要があるのか

Django は起動後でも以下が起こります。

DB未接続
migration未完了
外部API未接続
キャッシュ未初期化

これを liveness で落とすと事故になります。

全体構成図（Kubernetes視点）

実装方針（SRE的正解）

チェック内容	liveness	readiness
Django起動	✅	✅
DB接続	❌	✅
Migration完了	❌	✅
外部API	❌	任意

Django 健康チェック設計

エンドポイント設計

URL	用途
`/health/live/`	liveness
`/health/ready/`	readiness

Django 側の実装例

① URL 定義

# project/urls.py
from django.urls import path
from health import views

urlpatterns = [
    path("health/live/", views.liveness),
    path("health/ready/", views.readiness),
]

② View 実装（Python 3.12 / Django 4）

# health/views.py
from django.http import JsonResponse
from django.db import connections
from django.db.utils import OperationalError

def liveness(request):
    return JsonResponse({"status": "alive"}, status=200)


def readiness(request):
    try:
        db_conn = connections["default"]
        db_conn.cursor()
    except OperationalError:
        return JsonResponse(
            {"status": "db not ready"},
            status=503
        )

    return JsonResponse({"status": "ready"}, status=200)

ポイント

例外は必ず捕まえる
timeout や retry は入れない（K8sに任せる）

Kubernetes Deployment 定義例

readiness / liveness 設定

livenessProbe:
  httpGet:
    path: /health/live/
    port: 8000
  initialDelaySeconds: 30
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /health/ready/
    port: 8000
  initialDelaySeconds: 20
  periodSeconds: 5

タイミング設計（重要）

推奨値

liveness：遅め
readiness：早め & 厳しめ

migration との正しい関係

❌ やってはいけない例

Pod起動時に migrate 自動実行

✅ 正解

Job として先行実行
readiness は migration 完了後のみ OK

@startuml
Job(migrate) -> DB
Deployment -> readiness check
readiness -> OK
Ingress -> Traffic
@enduml

セキュリティ観点の注意点

① 認証を付けない

health endpoint は 内部専用
Ingress で外部非公開にする

② 情報を出しすぎない

// NG
{
  "db_host": "xxx",
  "error": "password incorrect"
}

// OK
{
  "status": "not ready"
}

よくある事故パターン

事故	原因
無限再起動	DBチェックを liveness に入れた
503連発	readiness が緩すぎ
全Pod死	migrate自動実行

監視との連携（SRE視点）

readiness NG 回数
Pod Restart 回数
readiness → OK までの時間

👉 「死んだ」より「遅い」を見る

まとめ

Django × Kubernetes では、

liveness = 生存確認
readiness = 業務可能判定

を明確に分けることで、

無停止デプロイ
障害の局所化
セキュリティ事故防止

が実現できます。