0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@0h-n0

LitmusChaos・Chaos MeshでKubernetesカオスエンジニアリングを始める実践ガイド

0
Last updated at Posted at 2026-03-10

LitmusChaos・Chaos MeshでKubernetesカオスエンジニアリングを始める実践ガイド

カオスエンジニアリングは「本番環境で意図的に障害を注入し、システムの弱点を事前に発見する」手法です。50組織を24ヶ月追跡した調査では、MTTR（平均復旧時間）が31.5%改善し、本番インシデントが42.8%削減されたと報告されています。本記事では、CNCF公式プロジェクトのLitmusChaosとChaos Meshを使って、Kubernetes上でカオス実験を実践する方法を解説します。

この記事でわかること

  • カオスエンジニアリングの5つの原則と定常状態仮説（Steady-State Hypothesis）の設計方法
  • LitmusChaos 3.0とChaos MeshのKubernetesへのインストールと基本的な実験の実行手順
  • Pod障害・ネットワーク遅延・リソース枯渇の3つの代表的な障害注入パターンの実装
  • カオス実験をCI/CDパイプラインに統合して継続的に信頼性を検証する方法
  • 導入時のよくあるハマりポイントと、段階的にブラストレディウスを拡大する戦略

対象読者

  • 想定読者: Kubernetesでマイクロサービスを運用しているMLEやSRE、DevOpsエンジニア
  • 必要な前提知識:
    • Kubernetesの基本操作（kubectl、Deployment、Service）
    • Helmパッケージマネージャの使い方
    • Prometheus/Grafanaによる監視の基礎知識

結論・成果

カオスエンジニアリングを導入した組織では、以下の改善が報告されています。

  • MTTR（平均復旧時間）: 31.5%改善（50組織24ヶ月追跡、R Systems調査）
  • 本番インシデント: 42.8%削減
  • 障害検知時間（MTTD）: 平均41.6%短縮（導入初年度、50マイクロサービス以上の環境で顕著）
  • インシデント解決速度: カオス実験を実施するチームは従来手法の2.1倍速く解決

Gartner社は2025年までに40%の組織がSREプラクティスの一環としてカオスエンジニアリングを採用すると予測しています（Gartner Peer Insights）。

カオスエンジニアリングの原則と定常状態仮説を理解する

カオスエンジニアリングはNetflixが2011年に開発したChaos Monkeyに端を発します。Netflixは「Simian Army」と呼ばれるツール群を構築し、AWSのリージョン障害（Chaos Kong）やアベイラビリティゾーン障害（Chaos Gorilla）、ネットワーク遅延（Latency Monkey）をシミュレートしました（Wikipedia - Chaos engineering）。

カオスエンジニアリングの5つの原則

principlesofchaos.orgで定義されている5つの原則を見ていきましょう。

原則 説明 MLでの類推
定常状態の仮説を立てる 正常な状態を定量的に定義する ベースラインモデルの精度を定義するのと同じ
現実世界のイベントを反映する サーバダウン、ネットワーク遅延など実際に起こりうる障害 実際のデータ分布でモデルをテストすること
本番環境で実験する ステージングだけでなく本番でも検証 A/Bテストを本番トラフィックで行うこと
自動化して継続実行する 手動ではなくCI/CDに組み込む モデルの継続的な再学習パイプライン
ブラストレディウスを最小化する 影響範囲を段階的に拡大する カナリアデプロイでリスクを限定すること

定常状態仮説（Steady-State Hypothesis）を設計する

カオス実験の核心は「定常状態仮説」です。これはMLにおけるベースラインメトリクスの定義に相当します。SLI（Service Level Indicators）とSLO（Service Level Objectives）をベースに、システムが「正常」であることを定量的に表現します。

# 定常状態仮説の例
steady_state_hypothesis:
  title: "APIサービスの定常状態"
  probes:
    - name: "レスポンスタイム"
      type: "http"
      url: "http://api-service/health"
      timeout: 3
      expected:
        status: 200
        response_time_ms: "<200"
    - name: "エラーレート"
      type: "prometheus"
      query: "rate(http_requests_total{status=~'5..'}[5m]) / rate(http_requests_total[5m])"
      expected:
        value: "<0.001"  # 0.1%未満
    - name: "Pod可用性"
      type: "kubernetes"
      resource: "deployment/api-service"
      expected:
        available_replicas: ">=3"

なぜSLI/SLOベースで定義するか:

  • ユーザー体験に直結する指標を使うことで、内部メトリクスの「グリーン表示」だけでは見逃す問題を検出できます
  • SLOで「p95レイテンシ200ms以下」と定義すれば、カオス実験後もこの基準を維持できているか機械的に判定可能です

注意: 定常状態仮説を定義せずにカオス実験を実行するのはよくある間違いです。仮説なしでは「何が壊れたか」は分かっても「許容範囲内か」の判断ができません。

LitmusChaos 3.0でKubernetesカオス実験を実行する

LitmusChaosはCNCFがホストするオープンソースのカオスエンジニアリングプラットフォームです。バージョン3.0でChaos Studio、Resilience Probes、環境管理機能が導入され、実験の作成・スケジュール・実行が大幅に簡素化されました（CNCF Blog）。

LitmusChaosをインストールする

# Helmリポジトリを追加
helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm repo update

# litmus名前空間を作成してインストール
kubectl create namespace litmus
helm install litmus litmuschaos/litmus \
  --namespace litmus \
  --set portal.frontend.service.type=NodePort

# インストール確認
kubectl get pods -n litmus

インストールが完了すると、ChaosCenter（Web UI）にアクセスできます。デフォルトのユーザー名は admin、パスワードは litmus です。

LitmusChaos 3.0のアーキテクチャ

LitmusChaos 3.0では用語が整理されました。旧「Chaos Agent」は「Chaos Infrastructure」に、旧「Chaos Workflow」は「Chaos Experiment」に、旧「Chaos Experiment」は「Chaos Fault」に名称変更されています。

Pod削除実験を実行する

実際にPod削除（Pod Kill）のカオス実験を作成してみましょう。以下はChaosEngine CRDを使った定義例です。

# litmus-pod-delete.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: api-pod-delete
  namespace: default
spec:
  appinfo:
    appns: default
    applabel: "app=api-service"
    appkind: deployment
  engineState: active
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        probe:
          - name: "healthcheck"
            type: "httpProbe"
            httpProbe/inputs:
              url: "http://api-service:8080/health"
              method:
                get:
                  criteria: "=="
                  responseCode: "200"
            mode: "Continuous"
            runProperties:
              probeTimeout: 5s
              interval: 2s
              retry: 3
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "30"
            - name: CHAOS_INTERVAL
              value: "10"
            - name: FORCE
              value: "false"

# 実験を適用
kubectl apply -f litmus-pod-delete.yaml

# 実験の進行状況を確認
kubectl get chaosengine api-pod-delete -n default -o yaml

# ChaosResultで結果を確認
kubectl get chaosresult -n default

なぜPod削除から始めるか:

  • Pod削除はブラストレディウスが限定的で、Kubernetesの自動復旧（ReplicaSet）で回復が保証されるため、安全に始められます
  • 代替案としてPod Failure（一時停止）もありますが、Pod Deleteの方がKubernetesの復旧メカニズム自体を検証できます

ハマりポイント:

TOTAL_CHAOS_DURATION（実験の合計時間）とCHAOS_INTERVAL（障害注入の間隔）の設定を間違えると、実験が意図しない長時間に及ぶことがあります。初回は TOTAL_CHAOS_DURATION=30（30秒）、CHAOS_INTERVAL=10（10秒間隔）のように短めに設定してください。

Resilience Probeでヘルスチェックを自動化する

LitmusChaos 3.0ではResilience Probeがファーストクラスの機能として扱われます。プローブは実験間で再利用でき、以下の4種類が利用可能です。

プローブ種類 用途 実行例
httpProbe APIエンドポイントの応答確認 ヘルスチェックAPI（200応答）
cmdProbe シェルコマンド実行で状態確認 kubectl get pods のPod数確認
k8sProbe Kubernetesリソースの状態確認 Deploymentのreplica数確認
promProbe Prometheusクエリでメトリクス確認 エラーレート < 0.1%を検証 
# Prometheusプローブの例
probe:
  - name: "error-rate-check"
    type: "promProbe"
    promProbe/inputs:
      endpoint: "http://prometheus:9090"
      query: "rate(http_requests_total{status=~'5..'}[1m])"
      comparator:
        type: "float"
        criteria: "<="
        value: "0.01"
    mode: "Edge"
    runProperties:
      probeTimeout: 10s
      interval: 5s

Chaos MeshでネットワークとI/Oの障害を注入する

Chaos MeshはKubernetes-nativeなカオスエンジニアリングプラットフォームで、Pod・ネットワーク・I/O・カーネルレベルの障害注入をサポートします。LitmusChaosがChaosHubによる実験ライブラリの共有に強みがある一方、Chaos MeshはWorkflow機能による複合実験のオーケストレーションに優れています。

Chaos Meshをインストールする

# Helmでインストール
helm repo add chaos-mesh https://charts.chaos-mesh.org
helm repo update

kubectl create namespace chaos-mesh
helm install chaos-mesh chaos-mesh/chaos-mesh \
  --namespace chaos-mesh \
  --set chaosDaemon.runtime=containerd \
  --set chaosDaemon.socketPath=/run/containerd/containerd.sock \
  --version 2.7.0

# インストール確認
kubectl get pods -n chaos-mesh

注意: chaosDaemon.runtime と chaosDaemon.socketPath はコンテナランタイムに応じて変更が必要です。Docker環境では docker と /var/run/docker.sock を指定してください。containerd環境では上記の設定を使います。

ネットワーク遅延を注入する

マイクロサービス間の通信に200msの遅延を追加し、タイムアウトやリトライの動作を検証してみましょう。

# chaos-mesh-network-delay.yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: api-network-delay
  namespace: default
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - default
    labelSelectors:
      app: api-service
  delay:
    latency: "200ms"
    correlation: "80"
    jitter: "50ms"
  duration: "60s"
  direction: to
  target:
    selector:
      namespaces:
        - default
      labelSelectors:
        app: database
    mode: all

# 実験を適用
kubectl apply -f chaos-mesh-network-delay.yaml

# 実験状態を確認
kubectl get networkchaos -n default

# 60秒後に自動終了。手動で停止する場合:
kubectl delete networkchaos api-network-delay -n default

この実験で検証できること:

  • サービス間のタイムアウト設定が適切か（例: 200ms遅延追加時に500msタイムアウトで耐えられるか）
  • リトライロジックが正しく動作するか（指数バックオフが設定されているか）
  • サーキットブレーカーが正しく開閉するか

Pod障害と遅延を組み合わせたWorkflowを作成する

Chaos MeshのWorkflow機能を使うと、複数の障害を順序立てて注入できます。

# chaos-mesh-workflow.yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: Workflow
metadata:
  name: resilience-test-workflow
  namespace: default
spec:
  entry: entry
  templates:
    - name: entry
      templateType: Serial
      deadline: 10m
      children:
        - network-delay-phase
        - pod-failure-phase
    - name: network-delay-phase
      templateType: NetworkChaos
      deadline: 3m
      networkChaos:
        action: delay
        mode: all
        selector:
          namespaces:
            - default
          labelSelectors:
            app: api-service
        delay:
          latency: "200ms"
          jitter: "50ms"
    - name: pod-failure-phase
      templateType: PodChaos
      deadline: 3m
      podChaos:
        action: pod-kill
        mode: one
        selector:
          namespaces:
            - default
          labelSelectors:
            app: api-service

トレードオフ:

Serial（直列）実行は因果関係を明確にできますが、実験時間が長くなります。Parallel（並列）実行は実験時間を短縮できますが、複合障害の影響を切り分けにくくなります。初期段階ではSerial実行を推奨します。

LitmusChaosとChaos Meshの選定基準

両ツールは異なる強みを持っています。チームの状況に応じて選択してください。

比較項目 LitmusChaos 3.0 Chaos Mesh 2.7
CNCF段階 Incubating Incubating
Web UI ChaosCenter（充実） Dashboard（シンプル）
実験ライブラリ ChaosHub（コミュニティ共有） 組み込みのみ
プローブ機能 4種類（http/cmd/k8s/prom） StatusCheck（基本）
Workflow 基本的 充実（Serial/Parallel/条件分岐）
対象範囲 K8s + AWS/Azure/GCP K8sのみ
学習コスト やや高い（概念が多い） 中程度（YAMLベース）
GitOps統合 対応 対応（Argo CD連携実績あり）

制約条件:

  • LitmusChaosはMongoDBが必要なため、運用コストがChaos Meshより高くなります
  • Chaos MeshはKubernetes外の環境（VM、クラウドサービス）には対応していません
  • どちらも権限の誤設定により意図しないNamespaceに障害を注入するリスクがあります。RBAC設定を慎重に行ってください

カオス実験をCI/CDパイプラインに統合する

カオスエンジニアリングの効果を持続させるには、実験を自動化してCI/CDに組み込むことが重要です。GitHub Actionsを使った統合例を紹介します。

GitHub Actionsでカオス実験を自動実行する

# .github/workflows/chaos-test.yaml
name: Chaos Engineering Tests

on:
  schedule:
    - cron: '0 3 * * 1-5'  # 平日3時（JST 12時）に実行
  workflow_dispatch: {}

jobs:
  chaos-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup kubectl
        uses: azure/setup-kubectl@v3

      - name: Configure kubeconfig
        run: |
          echo "${{ secrets.KUBECONFIG }}" | base64 -d > ~/.kube/config

      - name: Run Pod Delete Experiment
        run: |
          kubectl apply -f chaos-experiments/pod-delete.yaml
          # 実験完了を待機（最大5分）
          kubectl wait --for=condition=complete \
            chaosengine/api-pod-delete \
            --timeout=300s -n default

      - name: Verify Steady State
        run: |
          # ヘルスチェック
          STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
            http://${{ secrets.API_ENDPOINT }}/health)
          if [ "$STATUS" != "200" ]; then
            echo "Steady state violated: API returned $STATUS"
            exit 1
          fi

      - name: Collect Results
        if: always()
        run: |
          kubectl get chaosresult -n default -o yaml > chaos-results.yaml

      - name: Upload Results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: chaos-results
          path: chaos-results.yaml

CronWorkflowで定期実行する

CI/CDだけでなく、Kubernetes上で直接定期実行することも可能です。

# chaos-cron-workflow.yaml
apiVersion: chaos-mesh.org/v1alpha1
kind: Schedule
metadata:
  name: weekly-resilience-test
  namespace: default
spec:
  schedule: "0 3 * * 1"  # 毎週月曜3時
  type: Workflow
  historyLimit: 5
  concurrencyPolicy: Forbid
  workflow:
    entry: entry
    templates:
      - name: entry
        templateType: Serial
        deadline: 15m
        children:
          - pod-kill-test
      - name: pod-kill-test
        templateType: PodChaos
        deadline: 5m
        podChaos:
          action: pod-kill
          mode: one
          selector:
            namespaces:
              - default
            labelSelectors:
              app: api-service

よくある間違い:

最初から本番環境でCI/CDパイプラインにカオス実験を組み込もうとするのは危険です。推奨されるステップは以下のとおりです。

  1. ステージング環境で手動実行（1-2週間）
  2. ステージング環境でCI/CD自動実行（2-4週間）
  3. 本番環境で手動実行（GameDay形式）
  4. 本番環境で定期自動実行

よくある問題と解決方法

問題 原因 解決方法
ChaosEngineがcompletedにならない ServiceAccountの権限不足 litmus-admin のClusterRoleに pods/delete 権限を追加
Chaos Meshのchaosd PodがCrashLoopBackOff コンテナランタイム設定の不一致 chaosDaemon.runtime を実際のランタイム（containerd/docker）に合わせる
ネットワーク遅延が反映されない NetworkPolicyとの競合 Chaos MeshのPodにNetworkPolicyの例外ルールを追加
プローブがタイムアウトする probeTimeout が短すぎる カオス注入中はレイテンシが増加するため probeTimeout を2-3倍に設定
ChaosCenter UIにアクセスできない NodePortの割り当て問題 kubectl port-forward svc/litmus-frontend 9091:9091 -n litmus でポートフォワード

まとめと次のステップ

まとめ:

  • カオスエンジニアリングは「定常状態仮説の定義 → 障害注入 → 観測 → 修正」のサイクルで信頼性を向上させる手法です
  • LitmusChaos 3.0はChaosHub・Resilience Probes・ChaosCenter UIが強みで、広範なクラウドサービスにも対応しています
  • Chaos MeshはKubernetes-nativeでWorkflow機能による複合実験のオーケストレーションに優れています
  • 導入時はPod削除のような安全な実験から始め、段階的にブラストレディウスを拡大することが重要です
  • CI/CDへの統合は段階的に行い、本番環境での自動実行は十分な知見を蓄積してから実施してください

次にやるべきこと:

  1. ステージング環境にLitmusChaosまたはChaos Meshをインストールし、最初のPod削除実験を実行する
  2. 主要なAPIサービスのSLI/SLOを定義し、定常状態仮説をYAMLで記述する
  3. GameDay（障害訓練日）を月1回設定し、チーム全体でカオス実験の結果をレビューする

参考

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?