はじめに
「本番環境でわざと何かを壊す手法」。カオスエンジニアリングにそんな印象を持っている方は多いのではないでしょうか。
私自身、読む前はそのイメージに近いものを持っていました。
本書『カオスエンジニアリング -回復力のあるシステムの実践』を読んで、その認識は大きく変わりました。
本書が描くカオスエンジニアリングは、複雑なシステムを理解するための「実験の規律」 であり、ツールの話よりも設計思想・組織・人の話が中心です。
この記事では、設計やアーキテクチャに関心のあるエンジニア向けに、本書全体を一本にまとめて紹介します。
書籍の細部ではなく、「何が書かれていて、設計者として何を持ち帰れるか」を中心にまとめています。
引用は最小限にとどめ、内容は自分の言葉で要約しています。詳細は書籍をご確認ください。
書籍情報
| 項目 | 内容 |
|---|---|
| 書名 | カオスエンジニアリング -回復力のあるシステムの実践 |
| 著者 | Casey Rosenthal、Nora Jones |
| 訳者 | 堀 明子、松浦 隼人 |
| 出版社 | オライリー・ジャパン（2022年） |
| 構成 | 全5部・21章（16名の著者による共著） |
著者の2人はNetflixでカオスエンジニアリングチームを率いた人物です。
寄稿者にはSlack、Google、Microsoft、LinkedIn、Capital Oneなどの現場の実践者に加え、レジリエンスエンジニアリングの研究者も名を連ねています。
3行でまとめると
- システムは複雑性を取り除けない。だから「理解しきれないこと」を前提に、実験で自信を築く。
- カオスエンジニアリングは「壊す」ことではなく、テストではなく実験として仮説を検証する規律である。
- 回復力を作るのは最終的に人と組織であり、ツールはそのための手段にすぎない。
イントロダクション：カオスの誕生
物語は2008年のNetflixから始まります。データセンターの障害でDVD出荷が止まったことを契機に、クラウド移行が進められました。
ところがクラウド化しても可用性は期待ほど向上しませんでした。当時のクラウドではインスタンスが警告なしに消えることが珍しくなかったためです。
Netflixは「シニアエンジニアに裁量を与え、疎結合に連携する」文化の会社でした。
そのため「この設計パターンに従え」と全社に命じる仕組みがありません。そこで生まれたのが Chaos Monkey です。
- 業務時間中にランダムにインスタンスを1つ停止する
- どう対処するかは各チームの自由（冗長化でも自動スケールでも構わない）
- つまり「動くコードの形をしたマネジメントの原則」だった
その後2012年のクリスマスイブのAWS障害を経て、リージョン障害を想定した Chaos Kong が生まれます。
リージョン退避に最初は50分かかっていたものが、継続的な演習と投資で6分にまで短縮されたというエピソードは、演習の価値を端的に示しています。
第Ⅰ部 舞台準備
1章 複雑なシステムとの出会い
この章の主張は明快です。複雑性は取り除けず、受け入れるしかない。
シンプルなシステムは線形で、出力が予測でき、全体のメンタルモデルを持てます。
複雑なシステムは非線形で、出力が予測できず、完全なメンタルモデルは作れません。
章では、誰も責められない障害の例が3つ紹介されます。
| 例 | 概要 | 教訓 |
|---|---|---|
| ビジネスロジックとアプリケーションロジックの不整合 | キャッシュ停止→永続ストア過負荷→「存在しないはず」の404をデフォルト応答で返す→受け取った側がクラッシュ | 各コンポーネントは合理的でも、組み合わせで破綻する |
| 顧客起点のリトライの嵐 | 更新ボタン連打→キャッシュ応答でI/O低下→スケールダウン→タイムアウト→全員がリトライ | 自動スケールと縮退設計が相互作用して暴走する |
| 休暇シーズンのコードフリーズ | 変更凍結で長時間稼働が続き、約9か月前に混入したメモリリークが顕在化 | 安全のための施策が、バグを露呈させる |
特に3つ目は印象的でした。変更を止めるという「安全策」が、インスタンスの寿命を延ばしてリークを表面化させたのです。
複雑性は 偶発的なもの（優先順位の妥協の蓄積）と 本質的なもの（機能追加そのものがもたらす）に分けられます。
前者を減らす取り組みは持続可能ではなく、後者は機能を足すたびに増えます。だから複雑性を排除するのではなく、受け入れた上で対処する方法を学ぶ、というのが本書の出発点です。
設計者として気になったのは、一人がすべてを把握するアーキテクト像が成り立ちにくくなる、という指摘です。
文脈を最もよく知る実装者自身が設計に深く関わる必要がある、という議論は組織設計にも通じます。
2章 複雑なシステムの舵を取る
複雑性への向き合い方として、2つのモデルが紹介されます。
動的安全モデル
エンジニアが 経済性・ワークロード・安全性 の3つの境界にゴムバンドで繋がれているというモデルです。
- 経済性とワークロードは直感が働く（クラウドに100万インスタンスを立てる人はいない）
- 安全性だけは境界が見えないため、気づかないうちに遠ざかってしまう
- 実験によって安全性の境界を可視化できれば、エンジニアは自然と行動を変える
「ルールで縛る」のではなく「境界を見えるようにして直感を育てる」という発想がこのモデルの核です。
複雑性の経済的支柱
Kent Beckの議論を応用した、4つの支柱のモデルです。
| 支柱 | 意味 | ソフトウェアでの扱い |
|---|---|---|
| 状態 | 取りうる状態の数 | 機能が増えるほど増える。削減は難しい |
| 関係 | 部品や人の関係性 | マイクロサービス化やリモート化で増える |
| 環境 | 外部環境への影響力 | 多くの組織では手が届かない |
| 可逆性 | 判断を元に戻せるか | ソフトウェアが最も強い領域 |
ソフトウェアの強みは可逆性です。バージョン管理、ブルーグリーンデプロイ、カナリア、機能フラグ、CI/CDはすべて可逆性を高める技術です。
カオス実験は「可逆性を損なう脆さ」、特に効率を優先して作り込まれた部分を照らし出す、という位置づけになります。
3章 原則の全体像
ここで「カオスエンジニアリングとは何か」が整理されます。実験のステップは次の4つです。
- 正常な振る舞いを示す測定可能な出力を「定常状態」として定義する
- 制御群と実験群の両方で定常状態が続くと仮説を立てる
- サーバ停止やネットワーク断など、実世界の事象を変数として導入する
- 両群の差を探し、仮説の反証を試みる
実験とテストの違い
テストは「すでに知っている特性」を検証するもので、新しい知識は生みません。
実験は仮説を立てて反証を試みるもので、知らなかった特性を発見できます。
発見された特性をテストに取り込む「回帰実験」という考え方も示されます。
ベリフィケーションとバリデーション
- ベリフィケーション（検証）：システム境界の出力を確認する。中身を知らなくてもよい
- バリデーション（妥当性確認）：内部の部品とメンタルモデルを突き合わせる
カオスエンジニアリングは前者に重きを置きます。蛇口から出る水が清浄かを見るのであって、配管の全構造を理解することが目的ではありません。
「モノを壊す」ではない
「本番でモノを壊す」ではなく、「本番でモノを直す」と言うほうが実態に近い、という整理が気に入りました。
壊すのは簡単で、難しいのは影響範囲を絞り、直す価値を判断し、実験に投資する価値を見極めることです。
また、反脆弱性（Antifragility）とは別物であることも明確にされます。
5つの発展した原則
- 定常状態に関する仮説を立てる
- 実世界の事象を多様化させる
- 本番環境で実験する
- 継続的に実行できるよう実験を自動化する
- 影響範囲を局所化する
2番目の原則で面白いのは、可用性の実験の多くはレイテンシとステータスコードの変更で表現できるという指摘です。
インスタンス停止は「レイテンシが無限大」の特殊ケースにすぎず、CPU張り付きやメモリ枯渇を並べても学びは増えない、と述べられています。
第Ⅱ部 原則の実践
Slack、Google、Microsoft、LinkedIn、Capital Oneの5つの事例が並びます。
「万人向けのプログラムは存在しない」という姿勢で、あえて意見が揃っていません。
4章 Slackの惨劇シアター
もともと耐障害性を前提に作られていない既存システムに、安全にカオスを持ち込むためのプロセスです。
- 開発環境で先に障害を起こし、問題なければ本番へ進む
- 準備では対象・故障モード・仮説・検知手段・顧客影響の見積もりまで具体化する
- 書記を置き、計画から逸脱したらいつでも中断する
- 終了後に振り返り、「人間が介入せざるを得なかった点」「ダッシュボードやドキュメントの誤り」を洗い出す
得られた発見の例として、キャッシュの再割り当て時にデータが古いままになる問題、ネットワーク分断演習で想定外の挙動が出て3回目でようやく成功したこと、緊急用の設定変更モードですら通常経路の通知処理に依存していたことなどが紹介されます。
「演習を繰り返すこと自体が安全性を高める」という姿勢が一貫しています。
5章 Google DiRT
SRE文化の「希望は戦略ではない」を体現したプログラムです。数千回規模で実施されており、近年は自動テストが数百万回の実行に達しています。
特に参考になるのは 実施時の約束事 です。
- SLOを破るような影響を外部やユーザに与えない
- 本物の緊急事態は常にDiRTより優先する
- 透明性を保ち、演習であることを明確に伝える
- コストを最小化し、価値を最大化する
- 実際の機能停止のように取り組む
演習計画のドキュメントはテンプレート化され、チーム外の2名以上のレビューを通します。結果もテンプレートで記録され、社内で検索可能です。
影響の出るユーザを除外する セーフリスト という考え方や、システムだけでなく「キーパーソンが不在でも回るか」という人の障害まで対象にする点も印象的でした。
6章 Microsoftにおける実験の多様化と優先順位づけ
筆者自身の「入念に準備したのに最初の実機テストが散々だった」という体験談から始まります。
実世界で起こりうる事象の領域を考慮しきれていなかった、という反省が、実験の多様化の動機になっています。
- 月次で起きる事象は週次で、週次のものは日次で試し、慣れて恐怖を減らす
- オンコールを抑制せず、電話連絡までをプロセスに含めて演習する
- カオスのための仕組み自体も「システム」であり、障害を起こしうる
7章 LinkedIn：メンバーに対して配慮すること
クラッシュテスト用ダミー人形のたとえで、実験の影響をユーザに及ぼさない設計を説きます。
- 緊急停止ボタンに相当する仕組みを必ず用意する
- ブラウザ拡張で障害を注入し、社員だけを対象に実験する
- サービスアカウントやテストユーザを使った自動実験で、実メンバーへの影響を避ける
- 影響を受けたリクエスト画面のスクリーンショットをレポートに載せる
チェルノブイリを「失敗した安全実験」の教訓として取り上げている点も、読み応えがありました。
8章 Capital Oneにおける導入と進化
金融ならではの制約（規制当局への監査証跡、顧客への影響）の中での進め方が語られます。
- 実験の実行と結果を監査証跡として残せるツールが重要
- 草の根のコミュニティ、ゲームデー、ナレッジベースで普及を進める
- 同じ問題に複数チームがツールを作ってしまう「ツールの複製」を防ぐ
- コンプライアンスや変更管理のプロセスに組み込むと、むしろ導入が後押しされる
第Ⅲ部 人間的な要素
第Ⅲ部は、本書の中でも設計者に刺さる部分でした。システムの回復力は人が作るというメッセージです。
10章は組織そのものへのカオスの適用、11章はツールと人の関係（「線の上」と「線の下」）を扱います。
9章では、実験の「壊す」部分ばかりに注目が集まり、準備と事後処理の価値が見落とされていると指摘されます。
カオスエンジニアリングの狙いは脆弱性探しそのものではなく、システムのメンタルモデルを組織として更新することだ、という整理でした。
12章は技術的で、組み合わせ爆発の問題を扱います。20サービスのノード障害の組み合わせだけで100万通りを超えるため、網羅は不可能です。
ランダム探索にもドメイン知識にも限界があり、実験の選択を計算機に任せる方向を提案しています。
第Ⅳ部 ビジネス要因
13章 カオスエンジニアリングの費用対効果
「起きなかったインシデント」は誰も語らないため、効果の証明は難しいと正面から認めた上で、教育効果の評価モデルであるKirkpatrickモデルを適用します。
評価は「反応（役に立ったと感じたか）→ 学習（理解が増えたか）→ 行動（設計や運用が変わったか）→ 結果（可用性などへの寄与）」の4段階で、後ろへ進むほど証明は難しくなりますが価値は高まります。
演習のために人が集まること自体が、本番インシデントの連携を円滑にする副次的な効果（Collateral ROI）を生む、という指摘も重要です。
14章 オープンな心、オープンな科学、そしてオープンなカオス
Russ Milesによる、協調的に取り組むことの価値の章です。実験の目的・実施時期・発見を誰もが把握でき、ツールや実験を共有できる状態を重視しています。
15章 カオスの成熟モデル（CMM）
導入と洗練の2軸で、自組織の位置を評価するフレームワークです。
導入の軸では、次の4点を考えます。
- 誰が賛同しているか（現場起点か、経営のトップダウンか）
- 組織のどのくらいの割合が参加しているか
- 事前に満たすべき条件
- 導入の障壁
事前条件として挙げられているのは、劣化状態を検知できること、組織内の意識、仮説が支持されるはずという期待、そして発見に対応する連携体制です。
すでに壊れているとわかっているものは、先に直すという注意も、実務的で納得感があります。
洗練の軸は、段階的に進むのが一般的とされています。
ゲームデー → 故障注入のコンサルティング → セルフサービスツール → 実験プラットフォーム → プラットフォームの自動化、という流れです。
第Ⅴ部 進化
| 章 | テーマ | 要点 |
|---|---|---|
| 16章 | 継続的ベリフィケーション | CI→CDの先にあるCV。正確性をインフラ・アプリ・ビジネスの3層で捉える |
| 17章 | サイバーフィジカル | 機能安全や故障モード影響分析との接点。「材料特性」のたとえ |
| 18章 | HOP | 製造業の安全アプローチ。「誤りは正常」「非難しても直らない」など5原則 |
| 19章 | データベース | TiDBの事例。2億規模のユニットテストでも補えない障害をカオスで検証 |
| 20章 | セキュリティ | 本番環境でセキュリティ制御の不具合を実験で見つける |
16章の「正確性の3層」（インフラ・アプリケーション・ビジネス）は、設計の整合性を考える上で使いやすい整理です。
各層で内部的に一貫していても、層をまたぐと食い違うことがあり、それが1章の404の例につながります。
17章の「ソフトウェア集約型システムにも、機械工学の材料特性に相当するものが欲しい」という展望は、カオスエンジニアリングが目指す先を示していて面白い視点でした。
21章 おわりに
ツールは回復力を生みません。回復力を生むのは人です。結論はそこに集約されます。
- ツールを使う人や組織を「線の上」、ツールそのものを「線の下」と呼ぶ
- エンジニアは線の下、つまり1行のコードに原因を帰着させたくなるが、そこで止まってはいけない
- 直感的に正しそうな法則（冗長性を足せば安全になる、複雑性を取り除けば安全になる）は、経験上しばしば誤り
- 安全な操作の境界を関係者に見えるようにし、境界への対処を学ぶ機会を作ることが最も確実
設計・アーキテクチャの視点で持ち帰れること
本書はツールの操作手順書ではありません。その代わり、設計判断に直結する示唆が多くありました。
1. 縮退設計の「継ぎ目」を疑う
1章の例では、各コンポーネントの縮退処理は個別には正しいのに、つなぐと破綻しました。
設計レビューでは、各サービスの異常系だけでなく「相手が想定外の正常応答を返したとき」を問う価値があります。
2. タイムアウトとリトライは設計対象
Slackの事例でも、設定変更APIの全体タイムアウトが緊急モードの足を引っ張っていました。
タイムアウト、リトライ、ジッター、バックオフは「あとで調整する値」ではなく、依存関係の設計そのものです。
3. 可観測性が先、実験は後
15章が示すとおり、劣化状態を検知できないと実験の結果を比較できません。
カオスエンジニアリングの前提として、メトリクスと定常状態の定義が必要です。
4. 影響範囲と停止条件を設計に組み込む
LinkedInやGoogleの事例に共通するのは、緊急停止、セーフリスト、対象の限定です。
実験基盤も「システム」であるため、これらを後付けにしない設計が必要になります。
読んでみて感じたこと
- 「複雑性は消せない」という前提から議論が組み立てられていて、設計論として一貫している
- 企業ごとに考え方が異なる事例が並び、自分の組織に近いものを選べる
- 16名の共著のため、章によって粒度に差がある。ツール導入手順を期待すると肩透かしかもしれない
特に第Ⅰ部と第Ⅲ部は、カオスエンジニアリングを実践しない場合でも、複雑なシステムを設計する人に読んでほしい内容です。
読む順番の目安は、設計に関心がある方は1〜3章→9〜11章→21章、SRE・運用の方は3章→4・5章→15章です。
まとめ
- カオスエンジニアリングは、複雑なシステムに対する 仮説検証型の実験の規律 である
- 「壊す」よりも、影響範囲を絞って学びを得ることに価値がある
- 技術だけでなく、演習を通じて組織のメンタルモデルを更新していく取り組みである
- 導入は小さく始められ、ゲームデーから段階的に洗練させていける
「システムをもっと堅牢にしよう」と考えたとき、冗長化や機能追加の前に、まず自分たちのシステムが実際にどう振る舞うかを知る。
その順番を意識するきっかけとして、本書は有益だと感じました。
参考
- カオスエンジニアリングの原則（日本語版）: https://principlesofchaos.org/ja/
- オライリー・ジャパン 書籍ページ: https://www.oreilly.co.jp/books/9784873119885