カオスエンジニアリングとは？原則やツール、事例について解説

マイクロサービスやクラウドネイティブの浸透によって、システムは利用者やトラフィックの増加にも柔軟に対応できるようになりました。しかし構成が複雑になるほど「障害は必ず発生する」という前提で運用を設計しなければ、ある日突然サービス全体が停止する危険性があります。

そこで脚光を浴びているのがカオスエンジニアリングです。今回はカオスエンジニアリングとは何か、その概要と原則、手順や代表的なツール、NetflixやAWSにおける事例などを詳しく解説します。

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

まずは、カオスエンジニアリングとはどのようなものか、その始まりや背景も合わせてみていきましょう。

意図的に障害を起こす実験手法

カオスエンジニアリングとは、本番環境またはそれに極めて近い環境で意図的に障害を起こし、その影響を観測して弱点を発見・改善する実験手法です。

カオスエンジニアリングの狙いは、停電やサービスの一部停止、トラフィックの急増など不測のイベントに耐えられるレジリエンス（回復性）を確認し、安心して開発・運用できる状態をつくることにあります。

カオスエンジニアリングの始まりと普及の背景

カオスエンジニアリングの始まりは「Netflix」の取り組みです。クラウドを移行するにあたってカオスエンジニアリングのためのツール「Chaos Monkey」を開発し、2011年頃から運用を開始。2012年7月にOSS（オープンソースソフトウェア）として公開しました。（現在はプロジェクトを終了）

それから10年以上が経ち、ITシステムは、オンプレミスとクラウドの混在、マイクロサービスの利用など、一段と複雑さを増しました。一つのサービスが停止した影響が思わぬ形で全体に波及することもあり、カオスエンジニアリングがより存在感を増したのです。

出典：Lessons Netflix Learned from the AWS Outage｜Netflix TechBlog

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

カオスエンジニアリングを安全かつ効果的に進めるには、標準的なガイドラインとして利用されている「Principles of Chaos Engineering」に沿った5つの原則を押さえるとスムーズです。

1. 定常状態の仮説を立てる

まず、システムの「定常状態（正常な状態）」を定義します。スループット、エラーレート、レイテンシといった、ビジネスやシステムのパフォーマンスに直接的に関わる指標を用いることが理想です。

次に、その定常状態を基に「特定のコンポーネントに障害が起きても、システム全体のパフォーマンスは定常状態を維持できるはずだ」という仮説を立て、それが実験の軸となります。

2. 実世界の事象を反映させる

実験で引き起こすイベントは、サーバークラッシュやネットワーク切断など、現実に起こりうる障害を忠実に模倣したものにします。

ハードウェア障害だけでなく、不正なAPIレスポンスなどのソフトウェアレベルの問題、証明書の失効、DNS障害など多様なシナリオを想定することで、より現実的な問題を発見できます。

3. 本番環境で実験する

構成が同じでも、ステージング環境と本番環境ではデータ量やユーザー行動、依存サービスなどが異なります。本番環境でなければ得られない影響を把握するため、トラフィックを1～5％に限定した「カナリア試験」や、深夜帯に実験する方法が一般的です。

4. 実験を自動化し継続的に実行する

カオスエンジニアリングは、一度きりの実験で終わるものではありません。なぜなら、システムは日々変化し、そのたびに新たな脆弱性が生まれる可能性があるからです。

実験を継続して行なうため、プロセスを自動化し、CI/CDパイプラインに組み込む工夫も必要です。これにより、システムの信頼性低下を早期に発見して、常に高いレジリエンス（回復性）が維持できます。

5. 影響範囲を最小限に抑える

本番環境での実験では、その影響が予期せず拡大することを避けなければなりません。

ユーザーへの影響を最小限に食い止める具体的な手法として、実験対象を一部のトラフィックのみとすることや、異常を検知したら即座に実験を自動停止する「キルスイッチ」を設けるなどの配慮が必要です。

出典：カオスエンジニアリングの原則｜Principles of chaos engineering.org

カオスエンジニアリングの手順

カオスエンジニアリングは、一般的に「準備・計画」「実行」「検証・改善」というサイクルで進めます。

1. 準備・計画

準備と計画は、実験の成否を分ける重要なフェーズです。まずは、システムの「定常状態」を定義し、検証したい「仮説」を立てます。次に仮説を検証するための「シナリオ」を設計します。

1.対象の選定

どのコンポーネントに障害を注入するか（例：商品データベース、認証マイクロサービス）

2.障害の種類

どのような種類の障害を発生させるか（例：500msのネットワーク遅延、CPU使用率90%の状態を5分間継続）

3.測定項目

何を測定し監視するか（例：APIのレスポンスタイム、エラーレート、キューの滞留数）

4.中止条件

どのような状態になったら実験を中止するか（例：エラーレートが5%を超えた場合）

5.ロールバック計画

万一の事態に備えシステムを速やかに正常な状態に戻す手順を準備する。

このタイミングで、関係者へ実験の目的とリスクを共有しておくことも大切です。

2. 実行

計画に沿って実際に障害を注入します。カオスエンジニアリングツールを活用することで、プロセスを安全かつ効率的に進められます。

実験中は、計画で定めた測定項目をダッシュボードなどで注意深く監視し、システムの挙動をリアルタイムで把握します。なお、中止条件に至った場合、ツールが自動的に実験を停止します。

3. 検証・改善

実験終了後、収集したデータを分析して結果を評価します。

仮説が覆されて予期せぬ問題が見つかれば、それが最大の学びとなります。根本原因をチームで特定し、弱点を補強する改善策（アーキテクチャの変更、設定値の見直しなど）を立案し、適用しましょう。

そして、改善策の有効性を確認するため、再度同じ実験を行います。

カオスエンジニアリングに用いられるツール

カオスエンジニアリングはツールなしでも実装できますが、ツールを活用すると安全性と再現性が高まります。ここでは代表的なツールについて解説します。

Chaos Monkey（Netflix）

公式サイト：https://github.com/netflix/chaosmonkey

カオスエンジニアリングの原点であるNetflix社のツールです（OSS）。AWSのEC2インスタンスをランダムに停止させるシンプルな構成で、クラウド移行期の障害耐性向上に寄与しました。

Chaos Monkeyを含むSimian Armyプロジェクトは終了し、現在はアーカイブ状態となっています。しかし、Chaos Monkey単体は別リポジトリで利用可能です。

Gremlin

公式サイト：https://www.gremlin.com/chaos-engineering

エンタープライズ向けの商用SaaSとして広く利用されているプラットフォームです。AWS、Azure、GCP、Kubernetesなど幅広い環境をサポートし、CPU、メモリ、ネットワークといった多岐にわたる障害シナリオをGUIを使って簡単に実行できます。

AWS Fault Injection Simulator（FIS）

公式サイト：https://aws.amazon.com/jp/fis/

AWSが提供している公式サービスです。EC2、ECS、Lambdaなど様々なAWSサービスと連携し、権限管理やCloudWatchと連携した監視・自動停止が容易に行えます。AWSエコシステムとの親和性の高さが強みです。

Chaos Mesh

公式サイト：https://chaos-mesh.org/

Kubernetesネイティブな環境におけるスタンダードになりつつあるCNCFのプロジェクトです。Podの削除やネットワークの遅延・分断など、コンテナ環境に特化したきめ細やかな障害を再現できます。クラスタ外からのUI操作やGitOps連携も可能です。

カオスエンジニアリングの実践例

ここでは、国内外におけるカオスエンジニアリングの実践例を3つご紹介します。

Netflix

カオスエンジニアリングの先駆者である「Netflix」は、2011年に本番環境のサーバーインスタンスを意図的、かつランダムに停止させる「Chaos Monkey」を導入。障害耐性を意識した自動復旧システムを構築することで、サービス全体の回復力が高まりました。

Netflixでは様々な障害シナリオがテストされています。例えば、通信遅延を発生させる「Latency Monkey」や、ベストプラクティスに違反したインスタンスを停止する「Conformity Monkey」、さらにAWSのAvailability Zone（AZ）全体を停止させる「Chaos Gorilla」などが開発・運用されています。

出典：The Netflix Simian Army｜Netflix TechBlog

Amazon/AWS

Amazon（AWS）は、耐障害性テストツールである「AWS Fault Injection Simulator（FIS）」と、ビヘイビア駆動開発（BDD）を組み合わせ、カオスエンジニアリングを高度化しています。

この手法は、自然言語で書かれたシナリオに基づき、CI/CDパイプラインでシステムのレジリエンス（回復性）を自動的かつ継続的に検証するのが特徴です。

これによって、「EC2インスタンスの停止」や「EKS（Kubernetes）上のPod削除」といった障害注入を自動テストとして実行し、アプリケーションが正常に応答し続けることを実証しています。

出典：Behavior Driven Chaos with AWS Fault Injection Simulator｜AWS Architecture Blog

出典：Chaos engineering on Amazon EKS using AWS Fault Injection Simulator｜AWS DevOps & Developer Productivity Blog

メルカリ

メルペイ（メルカリの決済サービス）チームは、2021年頃からKubernetes上で「Chaos Mesh」を活用しています。導入の背景には、外部APIの遅延がサービス全体の障害に繋がったという課題がありました。その対策として講じたタイムアウト設定の最適化が、本当に有効かを実証するために活用されています。

これにより、外部APIで遅延スパイクが発生した際の影響が、実装した緩和策によって実際に軽減されることを確認しました。また、エンジニアリングブログでは、実験の自動化にSpinnakerパイプラインを活用した手法を紹介しており、他のエンジニアやQA担当者が障害注入を手軽に行えるようにしたことを公開しています。

出典：Chaos engineering with chaos mesh in payment-service｜mercari engineering portal