[書評] Chaos EngineeringのO’Reilly Media本を読んでChaos Engineeringを理解していこう

カオスエンジニアリングってなんじゃろ？

Gartnerが2019年12月5日にPredicts 2020: Agile and DevOps Are Key to Digital Transformation　というレポートを公開しました。

※ 完全なレポートを読むには、https://www.gremlin.com/gartner-predicts-2020-devops/ からリクエストできます

Digital Transformationの推進に必要なことがなんなのかを、現状の調査や分析とともに記載されています。

その中に

2023年までに、組織の40％がDevOpsイニシアチブの一環としてカオスエンジニアリングプラクティスを実装し、予定外のダウンタイムを20％削減します。

ということが予測されていました。 詳しくはレポートを読んでいただきたいのですが、カオスエンジニアリングを行うことの重要性がビジネス上重要な使命であると言及されています。

ふむふむ、 カオスエンジニアリングも随分と認知されてきているんだなと感じましたが、自身の知識が断片的であったので再度学習せねばと思いたち、 記事のタイトルにも書いているO'Reilly MediaのChaos Engineeringを読みましたので、軽く内容をご紹介していこうと思います。

読んだO'Reilly Media：

目次

1. Why Do Chaos Engineering?
2. Managing Complexity
3. Hypothesize about Steady State
4. Vary Real-World Events
5. Run Experiments in Production
6. Automate Experiments to Run Continuously
7. Minimize Blast Radius
8. Designing Experiments
9. Chaos Maturity Model
10. Conclusion

1-2章: Introduction

3-7章: The Principles of Chaos

8-10章: Chaos In Practice

1. Why Do Chaos Engineering?

カオスエンジニアリングを行なって何をするのか、障害テストとどう違うのかということを実験,学習 というワードを用いて述べられています。

カオスエンジニアリングの前提条件も重要で、実験がシステムに重大な問題を引き起こすか、システムの現在の状態を判断できているか を我々は答えなくてはいけません。

カオスエンジニアリングではNetflixが有名ですが、それ以外の企業、業界でも複雑なシステムを改善するため広く適用されてきている手法でると強調されており、 特定の企業のものだけでなく、この本を読むことによってどういったアプローチをとっていけるかが意識づけされているように感じました。

2. Managing Complexity

マイクロサービスアーキテクチャにより実装されたシステムの複雑性を例とともに説明されています。 より大きなシステムになる程、人間が各サービスの相互作用を理解することが難しく、特定の条件下で起こるような現象を知るには 単体テスト、機能テスト、および統合テストで構成される古典的なテストでは不十分と述べられていました。

カオスエンジニアリングの実験でこれらの影響を明らかにする機会を提供し、複雑な分散システムに自信を与えます

様々な実験を行い、学習することの重要性が伺えました。

3. Hypothesize about Steady State

システムが正常に機能しているかを定常状態として定義し、どういったデータで作ればいいのかの説明があります。 CPU負荷、メモリ使用率、ネットワークI/Oなどはシステムメトリックと呼ばれ、定常状態の定義にはあまり向かず、 ビジネスメトリックの期待値に基づいてシステムの定常状態を特徴付ける　ことが重要というのが刺さりました。

Netflixを例としてビジネスメトリックの内容が説明されているので参考になります。 ビジネスメトリックにアクセスできない場合はシステムスループット、エラー率、99パーセンタイル遅延などのシステムメトリックを用いることも可能と説明されていますね。

そして、この定常状態の動作を理解すれば実験の仮説を定義できて、いろいろなイベントを注入して定常状態の変化を計測していくことになります。

4. Vary Real-World Events

システム運用を行なっていれば、様々なイベントが発生し可用性に影響を受けます。 可用性に対する脅威を防ぐことはできませんが、それらを軽減することは可能で、 どういった障害イベントを注入すべきかが述べられています。

システムだけに目がいきがちですが、人間も回復力と可用性において重要な役割を果たすと書かれており、共感できました。 この部分の実験も必要そうですね（インシデント対応など)

5. Run Experiments in Production

従来のテストの考えは、本番環境から離れたところで行いバグを特定する でしたが、カオスエンジニアリングは逆で、なるべく本番環境に近いところで行う（理想は全て本番環境で）。 カオスエンジニアリングはシステム全体の動作に焦点を当てていて、コードのテストだけでは不十分としている考えです(予測が困難なイベントがシステムに影響を与える）

この章では本番環境でのカオスエンジニアリングの実験が重要である理由も述べられています。 7つの項目に分けられて書かれていますが、本番環境、もしくはそれになるべく近い環境で行うには章の最後の一言がとても重要と思います。

将来の重大な機能停止からシステムを保護するために、少量の危害をかける方が良いです

6. Automate Experiments to Run Continuously

はじめは手動でカオスエンジニアリングの実験を行い、正しく実行され、実験の爆風半径が最小であることを確立できたら自動化しましょう、 ということがNetflixの例を用いて説明されている章です。 変更のたびにわざわざ手動で行うリソースを使うより、自動化を行うためにリソースを使うという考えはとても参考になるのではないでしょうか。

また、実験の設計の自動化にも取り組んでいると書かれていました。これはとてつもなく難しことで、時間やリソースがなかなか無いとのことです。

7. Minimize Blast Radius

カオスエンジニアリングの実験では予期せぬ失敗の影響を探していますが、システム停止などの大規模な障害を起こしてはいけません。 爆風半径の最小化という言葉を用いてどういうステップで実験を進めていけばいいのかが説明されている章です。

また、いつでも実験を停止できるようにすることも重要です。システムの回復性を確認する実験でシステムが不使用になることは避けたいですよね。

営業時間中にのみ実験を実行するといった取り決めも必要になってきます(実験が異常に実行されたときに応答する能力を高めるため)。 17時以降はコードの本番デプロイはしないといったことを取り決めている組織も多いですし共感できるかなと思います。

8. Designing Experiments

3-7章までは原理についての説明でした。ここからはカオスエンジニアリングの実験を設計する際の核心の章になってきます。

以下のプロセスの説明がされています。

• 仮説を選ぶ
• 実験の範囲を選択してください
• 視聴する指標を特定する
• 組織に通知する
• 実験を実行する
• 結果を分析する
• 範囲を広げる
• 自動化

原理に沿った内容で、　準備 -> 実行 -> 分析 -> 自動化　のサイクルを回すことが重要だと感じています。

9. Chaos Maturity Model

組織内でカオスの実験を行うにあたり、有効性と安全性をわかるための洗練、 カオスの実験のカバレッジの深さと幅を測定するための採用 というメトリックを使い、組織内のカオスプログラムの状態をマップする方法を提供しましょう　ということが説明されています。

Chaos Maturity Model（CMM）　というのを使い、 いつ行うか、うまくいくかどうか、どのように改善するかを知ることができると述べられています。

可視化することにより何に焦点を当てていくべきなのかをわかるようにするには有効だと思いました。

最後に

１０章のConclusionにも書かれていますが、カオスエンジニアリングはまだ非常に若い分野で、ツールもどんどん進化しています。 我々も実践し、カオスエンジニアリングを前進させましょう　という言葉で締めくくられています、

このメディア自体、カオスエンジニアリングについてしっかり学び、実践していく気にさせてくれる内容でした。 すでに実践している人、これから始めようと思っている人、どうすればいいかわからない人全員が読むべきかなと考えています。

カオスエンジニアリングは常に進化していくので、本の内容も更新されていくと予想されますので、その度に読み返そうかなと。

レッツカオス