カオスエンジニアリング：システムレジリエンス

カオスエンジニアリング： システムレジリエンス

1）なぜカオスエンジニアリングなのか

• システム動作に関する仮説をテストし、SLOを検証する。
• 隠されたSPOF、間違ったタイムアウト/リトレイ、カスケード効果を検出します。
• チームを訓練して下さい：ゲーム日、runbooks、コミュニケーションを働かせて下さい；
• 「最善を望む」よりも「デフォルトで持続可能性」文化を形成する。

重要：カオスエンジニアリング≠"すべてを壊す。"これは科学的方法です：定常状態→仮説→実験→結論→改善。

2）基本実験サイクル

1.定常状態（ベースライン）： どのSLIが安定していますか？（例えば、成功≤ 99で500ミリ秒です。95%).

2.仮説： 1つのAZの損失で、p95は<10％増加し、可用性≥ 99です。9%.

3.実験：限られた爆風半径と停止基準でファウルを計画。
4.観察：メトリック/トレイル/ログ、バーンレートSLO、 ビジネスSLI（例えば、成功した預金）。
5.改善：検索を記録し、タイムアウト/制限/ルーティングを変更し、ランブックを更新します。
6.自動化/回帰：スケジュールで繰り返し、CI/CDとゲームデイカレンダーに追加します。

3）安全第一

ブラスト半径：1つのpod/instance/route/namespaceという狭いものから始めます。
ガードレール：SLOバーンレート（高速/遅い）、リトレイ制限、QPS制限、インシデント予算へのアラート。

停止条件： 「エラー率>X％またはp99> Y ms N分-即座に停止してロールバックします。」

Windows：通話労働時間、通知された利害関係者、凍結されたリリース。
コミュニケーション：IC/Techの鉛/Comms、明確なチャネル（戦争部屋）、メッセージテンプレート。

4）失敗のクラスと仮説のアイデア

ネットワーク：遅延/ジッタ/損失、ポートの部分的なドロップ、サービス/PSP間の「フロッピング」通信。
コンピュータ/ノード：プロセスの終了、CPUの過熱、ファイル記述子の枯渇、狭い接続プール。
ストレージとデータベース：レイテンシディスクの増大、遅延レプリカ、ワンシャード/リーダーの停止、スプリットブレイン。
依存関係：外部APIの劣化、プロバイダ制限、5xx/429バースト。
変更管理：失敗したリリース、不良フィーチャーフラグ、部分的なロールアウト。
周囲：CDNの低下、DNS/Anycastのドリフト、WAF/ボット保護の失敗。
地域/AZ：完全な損失または「部分的な」インシデント（わずかに悪化し、予測不可能）。

5）ツールとテクニック

Kubernetes：カオスメッシュ、リトマス、パワフルシール、kube-monkey。
雲：AWSフォルトインジェクションシミュレータ（FIS）、雲の近くのフォルトドメイン。
ネットワーク/プロキシ：Toxiproxy （TCPの毒）、tc/netem、 iptables、 Envoyの欠陥（遅れ/中断）、Istioの欠陥の注入。
プロセス/ノード：'stress-ng'、 cgroups/CPUスロットル、ディスクフィル。
トラフィックルーティング：GSLB/DNSの重み、偽のチェックのためのカナリア/ブルーグリーンのスイッチング。

6）サンプルスクリプト（Kubernetes）

6.1ルートの遅延/中断（Istio VirtualService）

yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }

仮説： クライアントタイムアウト/レトレイとCBはp95 <300ミリ秒とエラーレート<0を保持します。5%.

6.2ポッドキル（カオスメッシュ）

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"

仮説：バランサーとHPAは、p99> 20％の成長なしに1つのインスタンスの損失を補償します。

6.3ネットワーク混乱（データベースへの遅延）

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"

仮説：プール/タイムアウト/キャッシュは影響を減らします；p95の支払いはSLO ≤残ります。

6.4ディスク充填

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"

仮説：ログ/クォータ/アラートの回転は、ルートの劣化の前に動作します。

7） K8s外での実験

7.1 toxiproxy（ローカル/統合）

bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=1000

7.2 Envoy HTTP障害（境界/メッシュ）

yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }

7.3 AWS FIS（アイデア例）

自動スケーリンググループでN％ EC2を「殺す」実験、人工的にEBSレイテンシーを上げ、1つのAZでNAT-GWを無効にします。
CloudWatch SLOメトリックの組み込み停止条件。

8）混乱時の観測可能性の指標

SLO/SLI：良いリクエストの割合、p95/p99、バーンレート。
重要なルートのREDモデル（レート、エラー、期間）。
プール：p95接続、使用率を待っています。
DB：遅延レプリカ、ロック、ドリフトp 95要求。
ネットワーク：retransmitts、 RTT、 dscp/ecnの動作。
ビジネスSLI：トランザクションの成功（預金/小切手）、％リターン/エラー。
トレース：選択的なトレイル（例）、リリース注釈の相関。

9） SLO/Error-Budgetとの統合

ミスの予算内での実験を計画する：カオスは四半期ごとの目標を「混乱させる」べきではありません。
自動キルスイッチとしてのバーンレートアラート。
報告：「どれだけの予算が燃えたか」、「どのような偏差が安定しているか」。

10）ゲーム日（運動）

シナリオ：簡単な凡例（例：「region-East lost」）、注入ステップ、SLO目標、役割、時間。
評価：RTO/RPOの実際、コミュニケーションの質、runbookの正しさ。
Retro：所有者と期限の改善のリスト、ドキュメント/ダッシュボードの更新。

11）オートメーションおよびCI/CD

スモークカオス：各リリースの短いステージングテスト（例：1ポッドキル+ルートあたり200msの遅延）。
Nightly/Weekly：レポート付きのより重いシナリオ（5-15分）。
プロモーションゲート：カナリアのp95/errors>しきい値-自動ロールバック。
実験のカタログを持つリポジトリ（YAML+runbook+SLO-thresholds）。

12）アンチパターン

「手すりなしで食べ物を壊す」：停止基準なし、電話なし→実際の事件のリスク。
プロセスの代わりにワンタイムアクション。
定常状態のない混乱：成功/失敗として何が重要かは明らかではありません。
遅延を注入するときの過剰なリトレイ→自己DDoS。
ビジネスのSLIを無視する：支払い/注文が失敗したときの「Technarian」成功。
分析後および改善の所有者の欠如。

13）実装チェックリスト（0-45日）

0-10日

定常状態SLI （user+business）を定義します。
ツール（Chaos Mesh/Litmus/Toxiproxy/FIS）を選択します。
手すりの説明：ブラスト半径、停止条件、ウィンドウ、役割。

11-25日

最初の実験を実行します：ポッドキル、クリティカルなアップストリームあたり100-200msの遅延、パケットの1％をドロップします。
バーンレートのアラートを設定し、kill-switchをstop-criteriaに関連付けます。
最初のゲームの日を過ごし、レトロと修正を収集します。

26-45日

AZレベル/依存関係スクリプト（外部PSP、 DB-lag）を追加します。
ステージングで夜間のカオスを自動化する。「季節」シナリオ（ピーク）を準備します。
管理/SREのための実験および定期的なレポートのカタログ。

14）成熟度の指標

クリティカルルートの80％ ≥、記述された実験と定常状態の指標を持っています。
p99/error-rateスレッショルドを超えると自動キルスイッチがトリガーされます。
四半期ごとに-ゲーム日レベルAZ/リージョン； ≥ 1回/月-依存関係の目標シナリオ。
MTTRは改善サイクル後に減少し「、インシデント↔解放」相関は減少する。
「予期しない」の割合が実際の失敗で低下する→ゼロになる傾向があります。
ダッシュボードには、KPI（バーンレート、リカバリ時間、成功したDRアクションの割合）として「回復力」が表示されます。

15）ガードレールとストップトリガーの例

停止： 'http_req_failed> 1％'3分、'p99> 1000 ms' 3 windows、 'deposit_success <99。5%`.

ブラスト半径の削減：マニフェストの自動ロールバック、GSLBウェイトのリターン、フォルト注入の無効化。
Stopコマンド：原因のログを含む単一ボタン/スクリプト。

16）文化とプロセス

カオスはSREのリズムの一部であり「、極端」ではない。
透明なレポート、脆弱性認識、是正措置。
顧客/パートナーとのコミュニケーションをシミュレーションする、通話中のトレーニング。
SLA/SLOおよび予算とのリンク：カオスは、信頼性を損なうのではなく、高めるべきです。

17）結論

カオスエンジニアリングは「、ナインの希望」を証明可能な持続可能性に変えます。定常状態を作り出し、手すりを置き、小さく壊し、制御し、SLOおよびビジネスSLIを観察し、改善を記録し、そして自動化して下さい。予測可能なRTO、保護されたエラー予算、チームのパニックなく行動する意欲など、実際の失敗は制御されたイベントになります。