書評『カオスエンジニアリング――回復力のあるシステムの実践』
meiko hori (@m3iq) | Twitter から献本いただきました！ありがとうございます！
カオスエンジニアリングについての説明から実践例、導入方法や応用などまとまった情報が集まっていました。
各章のざっくりまとめメモ
イントロダクション：カオスの誕生
- 「カオスエンジニアはテストではなく、実験の1つ」単にカオスをもたらすのではなく、本番環境の不安定さに耐える能力に自身を持つために行う。
自信があるならそもそもやらなくていいし、自信をつける他の良い方法があるならそれを使ってもいい。 - 予測不可能な複雑性に対しては、ユニットテストのように既知のロジックを検証するのではなく、 ブラックボックス的に、システムの一部を壊したとしてもシステムがの定常状態を維持できるかを試すことで自信をつける。
1章 複雑なシステムとの出会い
- 複雑な分散システムににおいては各コンポーネントそれぞれは最大限努力した上でも、どうしても予期できないエラーが起きてしまう。
例）ブッラクフライデーに備え、コードをフリーズしたことに起因する障害が起きた。何もしてないのに（から）壊れた事例。 - 複雑性を認める。シンプルに留めたくても機能を追加するたび、偶発的な複雑性（技術的負債）と機能自体の本質的な複雑性が増していく。
これを受け入れ、対処することが重要になる。
2章 複雑なシステムの舵をとる
- 動的安全モデル：開発者はコストや人的リソースについては直感的に考慮できるが、安全性（可用性・セキュリティ）についてはそうではない。そのままだと安全性が軽視されてしまうので、何らかの形で自然と考慮できるようになると良い。
- 経済的支柱：複雑性には、状態・関係・環境・可逆性の4つの要素があるが、ソフトウェアエンジニリングにおいては可逆性に最適化するのがよい。
3章 原則の全体像
- カオスエンジニアリングは「実験」：システムの定常状態に対し、現実に起こりうる変数を導入しても、定常状態が保たれるかを試す。
なぜ結合テストだけではだめかというと、テストはあくまで既知の要素に対する検証で新しい知識を生まないから。 - どんな変数を選ぶか：学びを最大化できる変数、ユーザー体験に直結する部分を検証する。
- 金融機関や医療機関は当初懸念を示したが、むしろカオスエンジニアリングを使うようになった。
主な懸念は「そうですね、たぶん娯楽サービスやオンライン広告にはいいかもしれませんが、私たちはオンラインで本物のお金を扱っているんですよ」といったところです。それに対してカオスチームは「機能障害が起きることはありませんか？」と問いかけたものです。
4章 Slackの惨劇シアター
- カオスエンジニアリングのSlackでの適用法が詳細な手順とともに紹介されている。きちんと計画し、開発環境をへて本番環境で実験を行う。目的は学習というところにフォーカスしていて、書記の重要さがたびたび言及されている。
5章 Google DiRT：災害からの復旧テスト
- Googleも似たことに2006年から取り掛かってきており、彼ら独自の原則と適応例をかなりきちんと整備している。
6章 Microsoftにおける実験の多様化と優先順位づけ
- Microsoftにおけるカオスエンジニアリングの方法論、また別の切り口の解説でどのようなテストをおこなうと良いかの参考になりそう。
7章 LinkedIn メンバーに対して配慮すること
- LinkedInの事例。いかに実験がユーザー体験に影響を及ぼさないようにしているか。リクエストのモックや「緊急停止ボタン」、ブラウザエクステンションでの実行など。
8章 Capital Oneにおけるカオスエンジニアリングの導入と進化
- オンラインバンクである Capital One での例。CI/CD回すのにさえ監査の対応が必要な中でもカオスエンジニアリングを実践する。
コンプライアンスと規制はカオスエンジニアリングの実践を後押しするのに役立ちます
9章 先見性を生み出す
- レジリエンスエンジニアリング：カオスエンジニアリングのゴールは何かを壊すことではなく、レジリエンスを高めること。
- どのようにカオスエンジニアリングを社内に導入していくか：自動化・ナレッジシェア、ゲームデーなど
10章 人間的なカオス
- 会社組織への応用：組織もまた複雑な分散システム。ならばカオスエンジニアリングを組織や人のコミュニケーションにも応用ができるのでは。
- 「事例1：ゲームデーをゲームする」：インシデントレスポンスのシミュレーションゲームを行う。誰か（例えば知識の単一障害点になりそうな人を）をわざと「休場」させてみる。
- 「事例に2：点と点をつなく」：チームメンバーを一時的に移動させ、異なるチームと数週間から数ヶ月過ごす。生産上のプレッシャーによる欠員への抵抗はあったものの、一部の開発エンジニアが運用チームの仕事をそのまま1年間続けることにするなど面白い結果になった。人気が出てむしろシステムの施工が難しくなった。
- 「事例3：基本的な想定を変える」：向上心に燃えるエンジニアへのメンターシップ。チームのヘルスチェック。
11章 ループの中の人々
- カオスエンジニアリング自体をどう自動化するか。どの部分をどのように自動化できるか。Fittts のリスト。
12章 実験の選択に関する課題（と、その解決策）
- どの部分を実験するかという選択を自動化できそう。初期の Chaos Monkey はランダムに探索していたが、組み合わせが広大すぎてあまりうまく行かなかった。
- そこから専門家が必要になったがトレーニングに時間がかかってしまう。
13章 カオスエンジニアリングの費用対効果
- カオスエンジニアリングによって得られる効能をどう計測するか。Kirkpatrickモデル（反応、学習、行動、結果）
- カオスエンジニアリングによって「反証」されたことによるKPIへの影響を測定する。
- ナレッジシェアやコミュニケーションの促進など目に見えない効果もある。
14章 オープンな心、オープンな科学、そしてオープンなカオス
- 協調的なマインドセット：「なぜシステムに改善が必要なのか思い知らせてやろう」という気持ちだと、他のチームの拒絶反応を招く。
「システムの改善を手助けしよう」というマインドセットなら一丸となってシステムの弱点を探求できる。
15章 カオスの成熟モデル（CMM)
- どうやってマネージャーを説得するか：インシデント発生直後がむしろチャンスになる。
- 成熟モデル：どういった段階を経てカオスエンジニアリングの導入が進んでいくか
16章 継続的ベリフィケーション
- CI/CD の上にさらにカオスエンジニアリングを継続的ベリフィケーション（CV）として乗っける。
17章 サイバーフィジカルで行こう
- サイバーフィジカルシステムとは、ハードウェアとソフトウェアが相互接続されたシステム（航空電子、自動走行車、工業制御など）
- 伝統的な「故障モードと影響解析」の手法では見落としてしまう部分をカオスエンジニアリングで補う。
- プローブ効果：観測システム自体が測定に影響してしまうこと。カオスエンジニアリングでもこれに気をつけなければいけない。
18章 HOPとカオスエンジニアリングの出会い
- HOP: Human and Organizational Performance（人間と組織のパフォーマンス）組織とプロセスを改善するアプローチ。5つの原則。
- カオスエンジニアリングをHOPにも応用できる。シミュレーションゲームの例。
19章 データベースにおけるカオスエンジニアリング
- TiDBという分散データシステム自体に対するカオスエンジニアリング。
CPU、メモリ、ネットワーク、ファイルシステムなどに故障を注入する。 - Schrodinger というカオスエンジニアリング自動化ツールを作り、継続的に実行する。
20章 セキュリティカオスエンジニアリングの事例
- セキュリティについてもインシデントに対して受動的に対応するのではなく、能動的に学べるとよい。
- セキュリティゲームデー、ChaosSlingr によるセキュリティカオスエンジニアリング。
21章 おわりに
- 直感的な考えは経験的に間違っていることもある。
- ツールそれ単体が回復力を生み出すことはないが、カオスエンジニアリングというツールをつかってシステムを改善しよう。
感想
カオスエンジニアリングを初めて聞いた時には、本番でわざと障害を起こすというセンセーショナルな説明を聞いて奇想天外なアイデアだな思ったものだが、この本を読んでむしろだいぶ成熟し、定着してきている考えだと感じた。
カオスエンジニアリングは、大規模で複雑な分散システムを運用する中、
起こる障害に対してただリアクティブにインシデント対応をするより、プロアクティブに対応してシステムをより強固にしたいという実際的なニーズから生まれた。
「カオスエンジニアリング」という名前自体は導入の妨げになっていないという話はあったが、「レジリエンスエンジニアリング」と言ったほうが意味がわかりやすくて抵抗感がないのかな、と思った。
個人的には10章が面白かった。本番環境で実験を行える様になる（または実験を行う必要性がでてくる）には早いという会社も多いと思うけど、インシデントレスポンスのゲームデーなどはより手軽にでき、学びが多そうだと思った。
14章のマインドセットの話もすごく良かった。カオスエンジニアリングに限らず、例えばコードレビューをするにしても、間違いを探して指摘してやろうというより、より良いコードにできないかと考えのもと、コミュニケーションするほうが絶対に良い。
