運用・監視

カオスエンジニアリングかおすえんじにありんぐ

耐障害性NetflixChaos Monkey復旧訓練SRE信頼性

カオスエンジニアリングって何？わざと壊すってこと？

簡単に言うとこんな感じ！

そう、わざと壊すんだよ笑！「本番環境で本物の障害が起きた時に自分たちのシステムが本当に大丈夫か」を確かめるために、コントロールされた条件でわざと障害を起こして検証する手法なんだ。消防訓練みたいなイメージ。Netflixが「Chaos Monkey」というツールで有名にしたよ！

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

カオスエンジニアリングとは、本番システムに意図的に障害を注入し、システムの耐障害性・自動復旧能力を実験的に検証するエンジニアリング手法です。2010年代にNetflixが開発した「Chaos Monkey」を起点として広まりました。「どうせいつか本番で障害は起きる。なら自分たちでコントロールした状態で先に経験して、弱点を発見・修正しよう」という発想です。

カオスエンジニアリングは以下の手順で実施します。①定常状態の定義：正常時のシステムの振る舞い（エラー率・レイテンシ・スループット）をメトリクスで定義します。②仮説を立てる：「サーバーを1台落としても定常状態が維持されるはず」などの仮説を立てます。③実験の実施：実際に障害を注入します（サーバー停止・ネットワーク遅延・CPUスパイクなど）。④観察と学習：定常状態が崩れたか・どう回復したかを観察し、脆弱性を修正します。

カオスエンジニアリングの原則に**「本番環境で実施する」があります。ステージング環境ではなく本番でこそ発見できる問題（負荷・依存関係・サードパーティの挙動）があるからです。ただし最初は影響範囲を限定（ゲームデー）**して実施し、自動化によるコンティニュアスカオスへ段階的に移行するのが一般的です。

カオスエンジニアリングで注入する障害の種類

障害の種類	具体例	確認したいこと
インフラ障害	サーバー・コンテナの強制停止	オートスケール・ヘルスチェック動作
ネットワーク障害	特定サービスへの通信を遅延・切断	サーキットブレーカー・タイムアウト設定
リソース枯渇	CPU/メモリを人工的に使い切る	縮退動作・アラート発火
依存サービス障害	外部API・DBの応答を止める	フォールバック処理の動作確認
クラウドAZ障害	特定リージョン・ゾーンを遮断	マルチAZ構成の冗長性確認

歴史と背景

2010年：Netflixがクラウドへの移行後、意図的にAWSのインスタンスを停止する「Chaos Monkey」を社内開発
2012年：NetflixがChaos Monkeyをオープンソース公開。業界への影響が広がる
2014年：Netflixが「Simian Army」（Chaos Monkey拡張版）を公開。AZレベルの障害やセキュリティグループ誤設定の検出も
2017年：Principia Chaos（カオスエンジニアリングの原則文書）が公開。科学的手法としての体系化が進む
2019年：CNCFのLitmusChaos・Chaos Meshなどのオープンソースフレームワークが登場。Kubernetes対応
2020年〜：Gremlin・AWS Fault Injection Simulator（FIS）などのマネージドカオスサービスが普及
2023年〜：AIを使ったカオス仮説の自動生成が研究・実用化段階に

規格・RFC番号	内容
Principles of Chaos Engineering	Netflixが主導するカオスエンジニアリング原則の公式ドキュメント（principlesofchaos.org）
LitmusChaos	KubernetesのCNCF Graduated。カオス実験のフレームワークとリポジトリ

カオスエンジニアリングかおすえんじにありんぐ

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

カオスエンジニアリングで注入する障害の種類

歴史と背景

カオス実験のフロー

関連する規格・RFC

関連用語