Chaos Monkey
本番環境でランダムにインスタンスを停止し、システムの耐障害性を検証するツール
Chaos Monkey とは
Chaos Monkey は、Netflix が 2011 年にオープンソース化したカオスエンジニアリングツールで、本番環境でランダムにインスタンスを停止し、システムが単一障害点なく設計されているかを検証する。Netflix が 2008 年にデータセンターから AWS に移行した際、クラウド環境の不確実性に対応するために開発された。
「障害は避けられない。だから常に備える」という思想のもと、営業時間中に本番環境で実行される。障害が日常的に発生する環境を作ることで、エンジニアが耐障害性を前提とした設計を行うようになる。
Netflix の Simian Army
Chaos Monkey の成功を受けて、Netflix はさまざまな障害シナリオに対応するツール群「Simian Army」を開発した。
| ツール | 障害の種類 | 目的 |
|---|---|---|
| Chaos Monkey | インスタンスの停止 | 単一インスタンス障害への耐性 |
| Chaos Gorilla | AZ 全体の障害 | AZ 障害への耐性 |
| Chaos Kong | リージョン全体の障害 | リージョン障害への耐性 |
| Latency Monkey | ネットワーク遅延の注入 | 遅延への耐性 |
| Conformity Monkey | ベストプラクティス違反の検出 | 設定の標準化 |
| Janitor Monkey | 未使用リソースの検出・削除 | コスト最適化 |
Chaos Kong は Netflix が実際にリージョン間フェイルオーバーを検証するために使用しており、US-East-1 の障害時に US-West-2 に自動切り替えできることを定期的に確認している。
AWS Fault Injection Service (FIS)
AWS のマネージドカオスエンジニアリングサービスで、Simian Army の機能を AWS ネイティブに提供する。EC2 インスタンスの停止、AZ 障害のシミュレーション、ネットワーク遅延の注入などを、IAM で制御された安全な環境で実行できる。
サーバーレス環境での適用
Lambda はインスタンスの概念がないため、Chaos Monkey のアプローチは直接適用できない。サーバーレスでは以下のような代替手法を用いる。
| 実験 | 方法 |
|---|---|
| Lambda スロットリング | Reserved Concurrency を制限 |
| DynamoDB スロットリング | プロビジョンドモードで WCU を制限 |
| 外部 API 障害 | Lambda Layer でレイテンシ/エラーを注入 |
| AZ 障害 | VPC Lambda のサブネットを制限 |
カオスエンジニアリングの原則や実験の進め方については「カオスエンジニアリング」を参照。
Chaos Monkey が変えた文化
Chaos Monkey の最大の貢献は技術的なものではなく、文化的なものだ。「障害は起きるもの」という前提をチーム全体に浸透させ、耐障害性を設計の初期段階から考慮する文化を作った。この思想は Netflix を超えて、Amazon、Google、Microsoft など多くの企業に広がっている。
Chaos Monkey の背景や設計思想は関連書籍に詳しい。
この記事は役に立ちましたか?
関連用語
ゲームデイ
本番環境で意図的に障害を発生させ、チームの対応力とシステムの耐障害性を検証する訓練
フェイルオーバー
障害発生時にスタンバイシステムへ自動的に切り替え、サービスの継続性を確保する仕組み
ヘルスチェックパターン
サービスの稼働状態を定期的に確認し、異常を検知したらトラフィックを切り離す仕組み
カオスエンジニアリング
本番環境で意図的に障害を注入し、システムの耐障害性を検証する実践手法
グレースフルデグラデーション
システムの一部が障害を起こしても、機能を縮退させて全体のサービスを継続する設計手法
DevOps
開発チームと運用チームの協働を促進し、ソフトウェアのデリバリーと品質を継続的に改善する文化・プラクティスの総称
関連する記事
障害対応の夜に思い出す、あの本の 1 ページ
本番障害の緊迫した場面で、過去に読んだ技術書の知識が助けてくれた経験はありませんか。「いつか役立つ」知識が「今この瞬間」に変わる読書の価値を考えます。
深夜 3 時のデプロイ前に読み返したい 1 ページ
本番デプロイの直前、最終確認のチェックリストとして技術書の特定のページが役立つことがあります。緊張の場面で頼りになる「お守りの 1 ページ」の見つけ方と活用法。
バグを生むのは知識不足ではなく想像力不足である
バグの多くは、コードを書いた時点で「こういうケースもありうる」と想像できなかったことが原因です。想像力を鍛える読書法と、エッジケースへの感度を高める方法を解説します。