Liveness/Readinessサンプル

2）設計原則

1.セマンティクスを分離する。

準備：サービスリクエストに対する外部の能力（重要な依存関係を考慮）。
Liveness：プロセスの「incurable」状態の検出可能性。
2.Fail-fast、しかしfalse-fastではない。タイムアウト/しきい値'failureThreshold'を調整して、短いバーストが不要な再起動につながらないようにします。
3.サンプルの重い操作無し。チェックは高速でなければなりません（≤ 100-200ミリ秒）副作用なし。
4.優雅な劣化。依存関係が部分的に利用できない場合-Readiness=OK、安全なfollback（キャッシュ/粗大化）がある場合。
5.決定論的I/O。ステータスは「ランダム」外部テストではなく、現在の状態にのみ依存します。

3） HEALTHエンドポイントの意味

3.1 HTTPアプローチ（推奨）

「GET/healthz/liveness」→「alive」（イベントループが回転し、GCが立ち往生していない、ウォッチドッグの「heart」が打っている）の場合は200。
インスタンスがクリティカルクラスのトラフィックの準備ができている場合、'GET/healthz/readiness'→200。チェック：接続プール、ローカルキャッシュ、ビジネスロジックカーネルの可用性。
'GET/healthz/startup'→200 （migrations/cache warm-up/loading models）。

• 外部データベース/APIにアクセスすることはできません。これにより、依存関係インシデント中に「自殺」が発生します。
• 準備が整いましたら、重要な依存関係を確認することができますが、タイムアウトと劣化があります。有効なフォールバックがある場合は、それを下にしないでください。

3.2 gRPCヘルスチェック

'grpc'標準を使用します。健康です。v1。Health/Check 'with service-scoped states（'SERVING'、'NOT_SERVING'）。Kubernetesの場合-grpcプローブ（またはhttpプロキシ）。

3.3内部トリガー

watchdog "soft' stop： SIGTERM set Readiness=FAIL→wait for 'terminationGracePeriodSeconds'→end、ワークアウト・キュー。

4）タイミングとしきい値（チューニング）

• 'initialDelaySeconds'、 'periodSeconds'、 'timeoutSeconds'、 'successThreshold'、 'failureThreshold'。

• readiness： 'period=5s、 timeout=0。2–0.5sの失敗=2'
• liveness： 'period=10s、 timeout=0。2–0.5sの失敗=3'

• 起動：'period=5s、 failure=60'（最大5分~）
• スタートアップ成功後に活性化された準備/活性

• 準備は処理の準備状況（ブローカーへの接続、DLQの劣化があるかどうか）を反映します),
• liveness-内部のハートビートループ。

障害のバックアップ：アプリケーションでは、指数関数バックオフを使用して依存関係に再接続します。そうでなければ準備は「見た」になります。

5）構成（断片）

5.1 Kubernetes、 HTTPプローブ

yaml livenessProbe:
httpGet: { path: /healthz/liveness, port: 8080 }
periodSeconds: 10 timeoutSeconds: 1 failureThreshold: 3

readinessProbe:
httpGet: { path: /healthz/readiness, port: 8080 }
periodSeconds: 5 timeoutSeconds: 1 failureThreshold: 2

startupProbe:
httpGet: { path: /healthz/startup, port: 8080 }
periodSeconds: 5 failureThreshold: 60

5.2 Kubernetes、 gRPCサンプル

yaml readinessProbe:
grpc:
port: 9090 service: my. app. Service periodSeconds: 5 timeoutSeconds: 1

5.3優雅なシャットダウン

yaml terminationGracePeriodSeconds: 30 lifecycle:
preStop:
exec:
command: ["/bin/sh","-c","curl -s localhost:8080/healthz/drain && sleep 5"]

サービス内の'/healthz/drain'はReadiness=FAIL （stop-accepting）を翻訳し、アクティブなリクエストを完了する時間を与えます。

6）依存関係と劣化

Critical（サービスなしでは利用できません）：'/login'の認可データベース、'/pay'の支払いゲートウェイ。「timeoutSeconds」サンプルの80％ ≤タイムアウトで準備ができていることを確認できます。
非クリティカル：負荷がある場合、分析、電子メール、キャッシュレイヤー。準備ができてそれらを含まないで下さい；follbeckを使用してください。
Feature-flags：部分的に劣化した場合、Readiness=OKを維持しながら依存フィーチャーを無効にします。

7）キューとバックグラウンドハンドラ

• 準備=ブローカーへのサブスクリプション/接続がインストールされ、処理するリソースがある場合はOK。
• DLQ/lag overflow→ReadinessがOKのままである場合（私たちが受け入れて追加する場合）、SLI 「freshness/lag」が点灯します-データに従って警告します。
• Liveness：世論調査の周期/ハートビート、deathdetectorを制御して下さい。

Idempotence：再起動生活からの回復を加速します。

8）サイドカー/網/進入

• 「readinessGate」 （K8s）を有効にしてサイドカーのステータスを確認し、
• サンプルがmTLS障壁内に収まらないようにしてください（または例外を追加してください）。
• Ingress/Envoy/Nginx： Prox '/healthz/'ローカルでは、内部部品を「持ち出す」ことはありません。

9）セキュリティとプライバシー

Healthエンドポイントは、configs、 library version、 error strings （「OK/FAIL」+最小原因コードのみ）を開示しないでください。
外部アクセス（NetworkPolicy/ACL）を制限します。公共のために-ちょうど詳細なしでliveness-pingをしましょう。
ヘルスチェックのログ-DEBUGレベルで、スロットル付き。

10）観察可能性およびSLO

エクスポートのメトリック：'health_readiness {status}'、 'health_liveness {status}'、サンプル処理時間。
準備フラグを可用性SLOに関連付けます（エンドポイントからドロップ→5xx/接続リセット）。

• 「生活によって頻繁に再起動>N/時間」-デッドロック/リークの症状。
• 「Flap Readiness> X/15 min」-中毒/ネットワーク問題の症状。
• deploy （'service。バージョン'）。

11）テスト

Unit/Contract：各依存関係が無効になっている場合、エンドポイント'/healthz/'は正しいステータスを返します。
Chaos： database/cache/brokerを無効にする：モデルに従ってfollbackを有効または無効にする必要があります。Liveness-プロセスが「生きている」場合はトリガーされません。
Load/Soak：ロード中は、ヘルスエンドポイントを高速に保つ必要があります（コンテンツをプッシュしないでください）。
カナリア：トラフィックを増やす前に準備の安定性を確認してください。

12）頻繁な間違いとそれらを回避する方法

Livenessはデータベース/外部APIをチェックします。結果は、インシデントのための無限の再起動です。解決策：生活を「プロセス寿命」に制限します。
サンプルの重い点検。誤った失敗につながります。ソリューション：ライトチェック+個々のバックグラウンドヘルスモニター。
スタートアッププローブがありません。スロースタートは活発さによって「殺される」。解決策：広いウィンドウで起動を追加します。
優雅なシャットダウンはありません。deplaのまれな5xx。解決策：preStop+アンバランス。
フラップ・ストーム。攻撃的すぎるしきい値。解決策：'failureThreshold'を上げ、'timeoutSeconds'を増やし、バックオフを追加します。
すべてのための同じエンドポイント。セマンティクスのミキシング。ソリューション：個々の'liveness/readiness/startup'。

13）ミニ実装パターン

python
@app. get("/healthz/liveness")
def liveness():
return 200

@app. get("/healthz/readiness")
def readiness():
ok_core = core_is_ready () # local pools/caches/initialization ok_db = db. ping (timeout = 50 _ ms) # only if the DB is critical return 200 if (ok_core and ok_db) else 503

@app. get("/healthz/startup")
def startup():
return 200 if INIT_DONE else 503

@app. post("/healthz/drain")
def drain():
set_readiness(False); return 200

go
// use google. golang. org/grpc/health/grpc_health_v1 healthServer. SetServingStatus("my. app. Service", SERVING) // or NOT_SERVING

yaml spec:
readinessGates:
- conditionType: "proxy. istio. io/ready"

14）チェックリスト

販売する前に

• Liveness/readiness/startupエンドポイントが分離され、その意味が記述されます。
• Livenessは外部依存関係に触れない。準備はタイムアウトとfollbeckで重要なテストのみを行います。
• サービスプロファイルの'initialDelay/period/timeout/failureThreshold'を設定。
• graceful shutdown有効：'preStop'+unbalance。
• 健康指標/ログが接続されています。再起動/フラップへのアラート。
• 依存性の失敗とスロースタートテストが渡されました。

操作

• 再起動と準備フラグに関する毎週のレポート。
• インシデント後のスレッショルドのチューニング；リリースとの接続。
• 依存関係を無効にする定期的なカオステスト。
• 依存性の批評性が変化したときの意味論の関連性。

15） FAQ

Q： 1つの故障ですべてを閉じることは可能ですか？
A：望ましくない。'startup'、 'readiness'、 'liveness'を分離すると、誤検出が減り、RCAが高速化されます。

Q：キャッシュの確認はできますか？
A：キャッシュなしで正しい（遅い）モードがある場合は、準備をしないでください。劣化をオンにしてください。

Q：生活のために頻繁に再起動することは何ですか？
A：最初にdektor/leakを除外して下さい；しきい値を緩め、アプリケーションにウォッチドッグを追加します。

Q：マルチテナンシーをどのように考慮しますか？
A：準備はレンタル交通を提供する機能を反映するべきです。特定のテナントのプライベートな問題については、準備を変更するのではなく、個別のSLI/アラートで信号を送信します。

• 「Observability：ログ、メトリクス、トレース」
• 「分散トレース」
• 「SLO/SLAとメトリクス」
• 「Webhook配信保証」
• 「In Transit Encryption」
• 「秘密管理」