PSP-Xのレイテンシと損失

（セクション： 技術とインフラ）

概要

カオスエンジニアリングは、生産のための科学的方法です。安定性仮説を策定し、制御された方法で環境を混乱させ、ユーザー値（SLO/ビジネスメトリック）が保存されていることを証明します。iGamingの場合、これらは支払いチェック（PSP）、ゲームの初期化、リードキュー、マルチリージョン、ピーク負荷（遅延、故障、リトレイの「嵐」の状態）です。

1）カオスエンジニアリングの原則

1.定常状態から仮説へ。料金を決定します：空室状況、p95/p99、 TTW、支払い変換。
2.ブラスト半径が小さい。ステージング/カナリア、1-5％トラフィック/1-2ポーダ/1領域で最初の実験。
3.最初に観測可能性。メトリック/ログ/トレイル+実験注釈。
4.ガードレールアボート。自動シャットダウンのためのHard SLO/business KPIしきい値。
5.再現性と自動化。実験コード（IaC/GitOps）、ゲームデー計画。
6.責任のない文化。実験は責任の探求ではなく、弱点の探索です。

2）安定した状態と成功の指標

TexSLI： p95/p99 API、エラー・レート、飽和（CPU/IO）、キューラグ（出金/入金）、レイテンシ・プロバイダ。
ビジネスSLI：「試み→成功」の変換、TTW p95、 「ゲームinit」の成功、コードによるPSP障害の共有。

3）実験の授業（「ブレイク」とは）

ネットワーク：レイテンシ/ジッタ/パケット損失/ブラックホール、DNS障害、MTU異常。
CPUスロットル、メモリ圧力/OOM、 ディスクIOPS/スペース、ファイル記述子の枯渇。
プロセスとサイト：kill/evict pod、 node failure、 zone/region failure。
依存関係：PSPタイムアウト/エラー、利用できないゲームプロバイダ、CDN/キャッシュの劣化。
キュー/ストリーミング：カフカラグの増加、消費者の一時停止、パーティー/リーダーのギャップ。
Data/DB：レプリケーションの遅延、インデックスの劣化、読み取り専用モード。
Releases/ficheflags： migration misses、 erroneous configs、 kill-switch。
前部/RUM： LCP/INPの低下、顧客はピーク時にクラッシュします。
データ/ML：エージング機能、レイテンシモデルの増加、トークン/秒の低下、品質の低下。

4）プロセス： 仮説から改善へ

1.仮説（特定のSLO/ビジネス KPI+保護の期待される動作）を策定する。
2.実験の設計：タイプの失敗、持続期間、送風半径、ガードレール/中止。
3.観測可能性を準備する：リリース/実験比較ダッシュボード、注釈。
4.IM/TL制御下で実行し、（影響を受けた場合）オンコール/ビジネスに通知します。
5.測定結果：SLO、 p95/p99、 TTW、変換、ラグ、レトレイ。
6.フォームアクションアイテム：リミット、タイムアウト、ジッタ付きリトレイ、アウトリアイジェクション、PDB/HPA/KEDA、プルバックフロー。
7.自動化（ゲームデイレグパッケージ/CIインフラストラクチャチェックに含まれる）。

5）ガードレールと停止基準

• SLOファストバーンアクティベート（例：14 × 1時間あたりの予算）、
• お支払いのコンバージョンは0以上です。3 p。p。、
• TTW p95>行の3分10-15分、
• error-rate> 1。5％と2つのウィンドウで成長。
• コミュニケーション：ChatOps （'/experiment abort'）で事前承認されたチャンネル/ステータステータステンプレート、「赤いボタン」。

6）実験例（Kubernetes/cloud）

6.1 PSP（カナリアうつ病）へのネットワーク遅延)

目的：リトレイ/タイムアウト/ルーティングをチェックする。
注入：'payment-api'→'pspX'のみの場合、+200ms RTTと3％のパケット損失。

yaml apiVersion: chaos/v1 kind: NetworkChaos metadata: { name: psp-latency-canary }
spec:
selector: { labelSelectors: { app: payments-api, track: canary } }
direction: to target:
selector: { namespace: prod, ipBlocks: ["10. 23. 0. 0/16"]} # addresses pspX egress action: delay delay:
latency: "200ms"
jitter: "50ms"
correlation: "0. 5"
loss:
loss: "3"
correlation: "0. 3"
duration: "10m"
mode: one # minimum blast radius

期待される：p95 '/deposit '<250ms、エラー率<1％、変換≥ベースライン− 0。3 pp；劣化した場合、PSPルートオートスイッチ。

6.2ノードとPDBの障害

目的：PDB/反親和 性/HPAを点検して下さい。
注入：'games-api'ポッドで1つのノードをドレイン/終了します。

待機中：可用性の損失はなく、ピークp99はSLOを超えず、オートスケーラーはキューを取得し、PDBは「ダブルワミー」を防ぎます。

6.3 Kafka lag〜KEDA

目的：メッセージを蓄積する際の資金の安定的な引き出し。
注入：5-10分のための消費者を凍らせて下さい、そしてつけて下さい。

待っています：KEDAは労働者をスケールし、TTW p95は再吸収の後3分の≤に残ります、重複はありません（idempotence、キー）。

6.4ゲームプロバイダーDNSグリッチ

目的：フォールバック/キャッシュ/リトレイ。
注入：NXDOMAIN/ドメイン 'providerAのタイムアウト。例'。

待機中： UIで'providerB'の高速フォールバック-劣化モードとステータスバナー；'game init success' ≥ 99。5%.

6.読み取り専用DB×5

目的：書き込み損失の動作。
注入：10-15分のための読まれただけにキューを転換して下さい。

待機中：コードはエラーを正しく処理し、重要なルートは制限され、キューはリクエストを保持し、損失/二重書き込みがありません。

7）オートメーションとGitOps

コードとしての実験：Gitでスクリプト/パラメータ/ガードレールを保存し、PRでレビューします。
ゲーム日プラン：スケジュール、所有者、指標、中止条件、通信チェックリスト。
Grafanaの注釈：実験の開始/終了、構成、最終SLO。

8）混沌の間の観察可能性

例：p95/p99から特定の'trace_id'まで。
"experiment_id"、 "fault_type"、 "retry_attempt'、" degrade_mode=true"。
トレース：外部コールは'fault'とマークされます。injected=true'、retras/timeoutsが表示されます。
ダッシュボード：「SLOカード」、リリース/実験比較、支払い/ゲームのinit/キュー。

9） iGamingの詳細： 最初にチェックするもの

1.支払いとTTW： PSPタイムアウト、ルートフォールバック、idempotency。
2.ゲームの初期化：スタジオのアクセス不能/遅さ、CDN障害。
3.リード/ボーナスキュー：ラグの増加、再処理。
4.複数の領域：ゾーン障害/POP、リーダーの変更、データベースのレプリケーション。
5.ピーク：自動スケール、レート制限、サーキットブレーカー、ウォームアップキャッシュ。
6.RG/コンプライアンス：障害が発生した場合の正しいログイン、テレメトリーのPIIなし。

10）ガバナンス

カレンダーとウィンドウ：ピークトーナメントの外の実験、ビジネスとの調整。
実験リード、オブザーバー（SRE）、ビジネス担当；ホットラインのIM。
データポリシー：アーティファクトにPIIはありません。監査のためのWORM店。
法的境界：契約なしでSLAに違反するシナリオを除外します。

11）ゲームデー： スクリプトテンプレート

12）典型的な発見と行動

あまりにも攻撃的なリトレイ→ストームリクエスト→タイムアウト/ジッター/リミットを追加します。
outlier ejection→poison instanceはp99→enable cullingを台無しにしない。
脆弱な移行→読み取り専用で、→expand→migrate→contract+phicheflagsのフローが壊れます。
間違ったHPA信号は→スケール遅れ→RPS/lagメトリックに切り替わります。
バージョン→ロールバックで一般的なキャッシュは、データ→バージョンキーを台無しにします。

13）カオス練習成熟度チェックリスト

1.定常状態とSLOが記述され、ダッシュボードが準備されています。
2.コードとしての実験、Gitでのレビュー/監査。
3.ガードレール/中止自動化（Alertmanager/ChatOps）。
4.観測性：例示、トレース/ログの相関、注釈。
5.ゲームデーの四半期ごとに、シナリオは支払い/ゲーム/キュー/マルチリージョンをカバーします。
6.実験後の行動項目は、スプリント計画の一部です。パフォーマンスモニタリング。
7.設定リポジトリのリトレイ/タイムアウト/サーキットブレーカのしきい値ポリシー。
8.セキュリティ/PIIポリシーが適用され、機密データのないアーティファクト。
9.SLOによる自動修復（ロールバック/スケール/再ルーティング）がカオスをテストしました。
10.プロセスメトリック：中断せずに完了した％、運動中のMTTR、クラスインシデントの削減。

14）アンチパターン

SLO/ガードレール/観察可能性なしで「prodのすべてを壊す」。
仮説と測定可能なターゲットのない実験。
最初の打ち上げ時に大きな爆風半径。
タイムアウト/ジッタ→カスケードされたフォールトトレランスのないリトレイ。
予防の代わりに混乱：症状を治療し、根本原因を無視します。
練習の後のRCA/行為項目の不在。
ビジネス承認なしのピーク時の実験。

概要

カオスエンジニアリングは、リアルな障害を事前に再現し、SLOやビジネスメトリクスへの影響を測定し、リトレイやサーキットブレーカーからマルチリージョナルオーケストレーションや自動修復まで、アーキテクチャを強化する方法的なレジリエンスの証明です。通常のゲームデーとガードレールの規律により、iGamingプラットフォームは最も暑い時期でもp95/p99、変換、TTWを保持します。