カオスエンジニアリング比較：Chaos Mesh vs Litmus vs Chaos Monkey で障害耐性をテストする

💥 本番障害を意図的に注入してシステムの回復力を検証する「カオスエンジニアリング」。Chaos Mesh・Chaos Monkey・Litmosを比較します。

カオスエンジニアリングとは

Netflix社が提唱した障害テスト手法。あえて本番環境に障害（ネットワーク遅延・Podクラッシュ・CPU負荷等）を注入し、システムの耐障害性を確認します。

主要ツール比較表

項目	Chaos Mesh	Litmus	Chaos Monkey
ライセンス	Apache 2.0	Apache 2.0	Apache 2.0
開発元	PingCAP	MayaData/CNCF	Netflix
Kubernetes向け	◎	◎	△
クラウド向け	○	○	◎（AWS）
UI	◎	◎	×
スケジューリング	◎	◎	○
CNCF	Sandbox	Incubating	×
設定形式	CRD/UI	CRD/Hub	Go設定

各ツールの特徴

Chaos Mesh

PingCAP（TiDB開発元）がKubernetes向けに開発したカオスエンジニアリングプラットフォーム。WebUIが優れており、複雑なカオスシナリオをグラフィカルに定義できます。

主な特徴:

• Kubernetesカスタムリソース（CRD）でカオスを定義
• Podクラッシュ・ネットワーク障害・CPU/メモリ負荷・IOカオス等を網羅
• Workflow機能で複数のカオスを順番に実行
• ダッシュボードでリアルタイム監視

# Pod障害の注入（30%のPodを無作為にクラッシュ）
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-failure-example
  namespace: chaos-mesh
spec:
  action: pod-failure
  mode: random-max-percent
  value: "30"
  duration: "10m"
  selector:
    namespaces:
      - production
    labelSelectors:
      "app": "api-server"
  scheduler:
    cron: "@every 1h"
---
# ネットワーク遅延の注入
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-delay
spec:
  action: delay
  mode: all
  selector:
    namespaces: [production]
    labelSelectors:
      app: api-server
  delay:
    latency: "100ms"
    correlation: "25"
    jitter: "0ms"
  duration: "5m"

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

# ダッシュボード（ポートフォワード）
kubectl port-forward -n chaos-mesh svc/chaos-dashboard 2333:2333

向いているケース: Kubernetes環境・WebUI重視・複雑なワークフロー

Litmus

CNCF Incubatingプロジェクトで、ChaosHub経由でコミュニティのカオス実験を共有できます。

主な特徴:

• ChaosHub（カオス実験のマーケットプレイス）
• Workflow（Argo Workflows）でカオスシーケンスを定義
• Kubernetes・VMware・AWS等の広範なターゲット
• Resilience Scoreでシステムの耐障害性を定量評価

# Litmus ChaosEngine
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: nginx-chaos
  namespace: default
spec:
  appinfo:
    appns: "default"
    applabel: "app=nginx"
    appkind: "deployment"
  chaosServiceAccount: pod-delete-sa
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "30"
            - name: CHAOS_INTERVAL
              value: "10"
            - name: FORCE
              value: "false"

向いているケース: CNCF標準・ChaosHubのプリセット活用

Chaos Monkey

Netflixが最初に作ったカオスエンジニアリングツール。AWS EC2インスタンスをランダムに停止する「サル」として有名です。

主な特徴:

• AWS Auto Scaling Groupのインスタンスを無作為に停止
• スケジューリング（就業時間内にのみ実行等）
• Spinnaker（Netflix製CD）と統合
• シンプルだが本番環境での実績は最も古い

# Chaos Monkeyの設定
# MySQL DBにスケジュール設定を保存
# CRON設定: 月〜金の9〜17時のみ動作
SIMIAN_ARMY_CHAOS_MONKEY_ENABLED=true
SIMIAN_ARMY_CHAOS_MONKEY_PROBABILITY=0.5
SIMIAN_ARMY_CHAOS_MONKEY_MANDATORY_TERMINATION_ENABLED=false

向いているケース: AWS EC2中心・Spinnaker統合・Netflix的SRE

選択ガイド

状況	推奨
Kubernetes・WebUI重視	Chaos Mesh
CNCF標準・プリセット活用	Litmus
AWS EC2・Netflix流カオス	Chaos Monkey

内部リンク

• OSSのKubernetesポリシー管理比較
• OSSのSLO管理比較

外部リソース

• Chaos Mesh 公式ドキュメント↗
• Litmus Chaos 公式サイト↗
• Chaos Monkey GitHub（Netflix）↗
• カオスエンジニアリング原則（Principlesofchaos.org）↗

FAQ

Q. カオスエンジニアリングは本番環境でやるべきですか？

最初はステージング環境から始め、ゲームデー（カオス実験の日）を設けてチームが準備できた状態でやることが推奨されます。

Q. Chaos Meshはどんな障害を注入できますか？

PodChaos（クラッシュ）・NetworkChaos（遅延/パケットロス）・DNSChaos・HTTPChaos・IOChaos（ディスク障害）・TimeChaos（時刻操作）など多岐にわたります。

Q. カオスエンジニアリングとロードテストの違いは何ですか？

ロードテストはトラフィック量による性能限界を調べます。カオスエンジニアリングは障害（インフラ故障・ネットワーク分断等）への回復力を調べます。

Q. GameDays（カオス実験の演習）はどう進めますか？

仮説（「このPodが落ちてもサービスは継続するはず」）を立て→実験実行→観測→仮説が正しかったか確認→改善、というサイクルを繰り返します。