Chaos Engineering 書評
NetflixのChaos Enginnering事情がまとめられた本を読了したので内容の概要と感想を記載しておきます。
Chaos Enginneringは下記の3Partで構成されています。
- Part I. Introduction
- Part II. The Principles of Chaos
- Part III. Chaos In Practice
カオスエンジニアリングとは
まずカオスエンジニアリングとはなんぞやというところからですが、Part I. を読む限りでは、
- 「個々の要素は合理的な動作をしていても全体としては望ましくない動作をすることがある」（ブルウィップ効果）という問題点を持つ分散システム（Microservice）の回復性を検証するために、意図的に障害を作り出して注入する試験を実施する作業のこと
ということかなと理解しました。 具体的にやることを1行で書くと
- （障害を引き起こす可能性のある）イベントXを注入してもSteady Stateは変化しない、という仮説を検証する
ということになるのかなと。
そしてこのSteady Stateというのが重要な概念のようでした。これは許容できる通常動作を定義したもので、例えば人間で言うところの体温のような指標ということです。またマシンリソース等の指標ではなくビジネス指標であることが望ましい模様。
指標として用いるかの基準としては「顧客を失うかどうか」という点で判断する必要があります。例えばNetflixではビデオストリーミングデバイスの再生ボタンを押す割合（STS, video-stream starts per second）という指標を用いているようです。
またリアルタイム性が重要で、理由としてはスパンが広すぎると今日の状態が健全なのかどうかの判断が出来ないから、ということ。
「ビジネスメトリクスを収集できない場合はより相関が強いと思われるシステムメトリクスを見る」という記載もあるので、ひとまずはSLOとして設定しているシステムメトリクスから始めてもいいのかも知れないと思いました。
Steady Stateで使用する指標が一定値で安定している場合は閾値を超えたらアラートということができそうですが、周期的な変化をする指標の場合はElasticsearch/DatadogのMachine Learning機能のようなものが必要かも知れないです。あるいは前の周期との差分の合計で判断するとかすればいいかも？
具体的な手順
最終Partでは下記のような具体的な実施の流れが記載されていました。
- テストする仮説を選択
- 実験の範囲を選択
- 影響範囲が小さいテストから実施する
- 事前にテスト環境での試験も実施する
- 監視する指標（Steady State）を特定
- 指標となる値が悪化したときに即座に中断できる準備もしておく
- 組織に通知する
- カオス実験の実施や実施の目的を連絡しておく
- 回数を重ねるごとに通知する必要がなくなっていく
- 実験を実行する
- 結果を分析する
- 期待通りの動作をしたか確認する
- 実験の結果をすべての関連チームにフィードバックして、チームがあらゆる弱点を軽減できるようにする
- 範囲を広げる
- 自動化する
- ツール等で自動で定期的に実行するように設定する
「事前にテスト環境での試験も実施する」というところは重要な気がしました。 当たり前ではあるけど、テスト環境の試験では不十分だから実施するのであって、テスト環境の試験でわかるものは事前に潰しておくべきだなと。
あと、被害を最小限に食い止めるためにも自動化は必須だなと感じました。Canary ReleaseでSteady Stateを監視して、値が正常範囲を外れたらすぐ切り戻す、というのを自動化しておけば、そんなに怖くないのかも。Spinnakerとかちゃんと使えるようになりたいな......。
まとめ
ただ上辺だけ真似しても怪我して終わりそうだなという印象を受けました。
（チェルノブイリ原発事故も冷却剤ポンプのための冗長電源を検証しているときに起きたというから恐ろしい...）
ただ古典的なシステムテストでは対応しきれないほど複雑な分散システムを扱うようなケースは今後どんどん増えていくと思うので、必須になってくるのかなとも思いました。
