ヘルスチェックの仕組み

1）なぜ

ヘルスチェックは、カスケード障害に対する最初の障壁です。ノードを正しく回転から取り除き、嵐の再試行を防ぎ、劣化を簡素化し、回復を加速し、SLOを維持し、MTTRを削減します。

2）基本的なチェックの種類

Liveness-プロセスは「生きている」（デッドロック/リーク/パニックなし）です。エラー→インスタンスの再起動。
準備ができました-サービスはターゲットSLOでトラフィックをサービスすることができます（プールが発生し、キャッシュがウォームアップされ、依存リソースが正常です）。エラー→はバランスから除外されますが、再起動されません。
スタートアップ-サービスはliveness/readiness（長いブートストラップ、移行、ウォームアップ）に行く準備ができています。早期の再起動から保護します。
ディープヘルス（ドメイン固有）：ビジネス不変量（レートはエンドツーエンドを通過し、デポジットはアクティブなPSPによって承認されます）。劣化信号に使用されますが、即時再起動には使用されません。
外部/合成：外部のアクティブピン（APIパス、フロントスクリプト、PSP/KYCエンドポイント）-ユーザーの可用性を測定します。

3）サンプル設計： 一般的な規則

1.安価な生活：外部依存関係に移動しないでください。イベントループ、ヒープ/FD、ウォッチドッグを確認してください。
2.SLOによる準備：メンテナンスに必要なローカルリソース（データベースプール、ウォームキャッシュ、制限）をチェックします。外部依存-ノンブロッキングによる「can-serve？」シグナルです。
3.レイテンシーバジェット：各サンプルには独自のSLAがあります（たとえば、100〜200ミリ秒≤）。超過した場合-「degraded」、しかしlivenessの5xxではない。
4.Backoff&Jitter：サンプル間隔5-15秒、タイムアウト1-2秒、同期的な嵐を避けるためにエラーが指数関数的に遅延します。
5.ヒステリシス：ステータス変更のN成功/エラー応答（例：'successThreshold=2'、 'failureThreshold=3'）。
6.バージョン管理：エンドポイント'/healthz'、'/readyz'、 '/startupz'は安定です。'/health/の下のディープチェック/...'という名前のチェックがあります。
7.秘密とPIIはありません：回答はステータスとショートコードのみです。
8.説明：サブチェックのリストがあるJSON： '{"status"："degraded"、"checks"：［{"name"："db"、" ok"： true、" latencyMs"： 18}、{"name"：" psp。eu、 ""ok"：false、 "reason"：" timeout"}］}'。

4）層によるディープチェックの例

4.1 DB/キャッシュ/ストレージ

DB：レプリカとプールチェックを読むための短いトランザクション'SELECT 1'；レイテンシ/replication-lagしきい値。
キャッシュ：'GET'/'SET'テストキー+ヒット比ガード（low hit→warning）。
オブジェクトストレージ：既存のオブジェクトのHEAD（ダウンロードなし）。

4.2キュー/ストリーミング

ブローカー：ping-topic publish+はローカルパーティション内で消費します。コンシューマラグのしきい値。
DLQ：ウィンドウごとにデッドレターメッセージがスパイクされません。

4.3外部プロバイダ（PSP/KYC/AML）

PSP：軽量認証プローブ（非通貨）、契約/証明書/クォータの検証。安全なサンプルがない場合は、プロキシメトリックを使用します（銀行/GEOによる5〜10分間の承認の成功）。
KYC/AML： health-APIおよびSLAキュー；劣化の場合-代替ストリーム/プロバイダに切り替える。

4.4 API/フロント

合成：EU/LATAM/APACのトランザクションパス（login→deposit-initiation→bet 「in the sand」）。
RUM信号：JS/HTTPとLCP/TTFBエラーの割合-「外部」をトリガーします。

5）プラットホームの統合

5.1 Kubernetes/クラウド

'startupProbe'はブートストラップ（マイグレーション/キャッシュのウォームアップ）を保護します。
'livenessProbe'は最小限です。'readinessProbe'はpools/cache/localキューを考慮します。
'initialDelaySeconds'、 'periodSeconds'、 'timeoutSeconds'、 'failureThreshold'、 'successThreshold'。
PodDisruptionBudgetとmaxUnavailable準備状況を考慮して。
HPA/KEDA： キュースケーリング/SLI；準備はルーティングに影響します。

5.2バランサー/ゲートウェイ/メッシュ

L7レベルのヘルスルーティング（HTTP 200/429/503セマンティクス）。
Outlier detection （envoy/mesh）-エラーレート/レイテンシーパーセンタイルによってプールから出力されます。
回路遮断器：依存性への同時要求/接続、健康信号との統合のための限界。

5.3オートスケーリングと劣化

準備=FALSE→トラフィックは削除されますが、ポッドは生きています（ウォームアップできます）。
Deep-degrade （PSP down）→gracefulモードのフィーチャーフラグ（例えば、支払い方法を一時的に非表示にし、待機室を有効にするなど）。

6）タイムアウトとリトリートポリシー

同期依存関係のタイムアウト<SLO予算：'timeout=min （⅓ p99、 1-2s）'。
Idempotence：リトレイのために必須；idempotency-keysを使用します。
指数バックオフ+ジッタ：同期シャフト効果を防止します。
リトレイ予算：リクエスト/テナントごとのキャップ、「リトライ・ストーム」からの保護。

7）状態信号および警報

Green/Yellow/Red：サービスダッシュボードの要約ステータス。
SLOによるバーンレートアラート：高速（1時間）と遅い（6-24時間）。
相関ヒント：リリース/フィーチャーフラグ/プランアクティビティノート。
自動アクション：「赤」ディープチェック-プロバイダのフォールバックをオンにすると、トラックのサンプリングが増加します。

8） iGamingのためのスマートな戦略

支払い対応の準備：賭けサービスの準備は、PSPルータの状態と銀行/GEOの制限を考慮に入れます。
Odds/Linesパブリッシング：パブリッシャーでの準備は、/edgeキャッシュ内の行ソースと配布時間によるサマリラグに依存します。
トーナメントのスパイク：より積極的なアウトリエ検出と待合室の一時的なポリシー。

9） Antipatterns

Liveness、これは、データベース/PSP→外部の問題のために大量の再起動に行きます。
分離の開始/準備/livenessのない1つの「普遍的な」健康エンドポイント。
バックオフ/ジッタ→リトレイストームのないハードタイムアウト。
ヒステリシス→ルーティングフラップなし。
ディープチェック、これは再起動をトリガーします（その目的は診断とルーティングであり、再起動ではありません）。
ヘルスエンドポイントに隠された5xx（実際のステータスをマスキング）。

10）インターフェイステンプレート

/startupz→'200 OK {「uptimeSec」： ……、 「version」：」……」}'

チェック：initスクリプト、migrations completed、 key、 configs loaded。

/healthz （liveness）→'200 OK {「heapOk「： true、 「fdOk「：true、」 eventLoop」：」 ok」}'

チェック：イベントのサイクル、プロセスリソース、パニック/ルームフラグの不在。

/readyz（準備中）→

'200 OK/503 {"canServe"： true、 "db"： {"ok"： true、 "latencyMs'： 12}、" cache"：{"ok"：true}、" queue"：{"ok"：true"、 lag"：0}、" localQuota"：{"ok"：true}}

/健康/支払い（深い）→

'200/206/503 {"psp。eu「： {「ok「：false、 「reason」：」 timeout」}「、psp。alt"：{"ok"： true}、 "routerMode"："failover"}

11）健康回路品質指標（KPI/KRI）

Pod exit time from 'NotReady' to 'Ready' （warmup-SLO）。
サービスごとのフラッピング準備の頻度。
％誤って再起動されたポッド（根本原因-外部依存）。
健康メカニズムが役割を果たした事件のMTTR （before/after）。
オンコールなしで自動フェイルオーバー/機能低下の共有。
合成精度vs RUM（誤検出/ミス）。

12）導入ロードマップ（4〜8週間）

ネッド。1-2：クリティカルパスインベントリ；起動後の/liveness/readiness；サブチェックとヒステリシスでJSONレスポンスを入力します。
ネッド。3-4： add deep-checks： database/cache/broker；2-3 GEOのログイン/預金/賭けのための合成；/meshゲートウェイでoutlier-detectionを有効にします。
ネッド。5-6：支払い対応の準備；PSPフォールバック；前部のための待合室；lag/queuesによる自動スケール；バーンレートによるアラート。
ネッド。7-8：カオスデイ（PSP/データベースレプリカの無効化）、バックオフ/ジッターチェック；タイムアウトの微調整、PDB；KPIレポートと修正。

13）アーティファクト

Health Spec（サービスごとに）：チェックのリスト、時間予算、ヒステリシス、赤いステータスのアクション。
Runbooks： 「Readiness=FALSE： What are we doing？「、「PSP-fallback： steps and return criteria」。
ルーティングポリシー：アウトリエ検出ルール、サーキットブレーカ、パーセンタイルスレッショルド。
合成プレイブック：スクリプトと地理、SLO合成、スケジュール。
Release Gate：赤いディープチェックのキー依存関係を持つリリースブロック。

［結果］

よく設計されたヘルスチェックループは、プロセス実行可能性のための容易な居住性、トラフィックサービス機能の準備状況、安全な起動のためのスタートアップ、管理された劣化とルーティングのためのドメイン固有のディープチェックなど、シグナルの階層化されたシステムです。autoscaling、 outlier-routing、 synthetics、 SLOアラートと併せて、カスケード障害のリスクを低減し、MTTRを削減し、iGamingプラットフォームのビジネス・クリティカルなパスを安定させます。