カオスエンジニアリングが変わりつつある？

きっかけはMSのクラウドソリューションアーキテクトの真壁さんの発言と記事。

本番環境で試験することを前提に進められてきたカオスエンジニアリングは、クラウドネイティブ前提の環境とKubernetesの躍進によって、本番環境に出す前に試験するように姿が変わってきている。もしくは見直されようとしているのではないか？

そういう趣旨だ。

この変化がなぜ今起きようとしているのだろうか。

その理由を2015年に成立したカオスエンジニアリングの原則、さらにその昔の提案元であるNetflixの技術背景を見ながら考察したい。

そもそもカオスエンジニアリングってなんだ？

カオスエンジニアリングとはなんだろうか？

まずは、カオスエンジニアリングの規範である、カオスエンジニアリングの原則を参照したい。

カオスエンジニアリングは、分散システムにおいてシステムが不安定な状態に耐えることのできる環境を構築するための検証の規範です。

出典：カオスエンジニアリングの原則

微妙に言葉が硬い。国内で最初期にカオスエンジニアリングを実サービスに導入したクックパッドさんのテックブログはどうだろうか。

本番環境の分散システムが過酷な状況でも耐えれるとの確信を得るために、実験するという取り組み

出典：クックパッド「Chaos Engineering やっていく宣言」

最後の実験するという意味についてもう少し詳しく説明しよう。

実験内容はこうだ。

実サービスが動いている本番環境を用意する
今動いている本番環境のことをあらゆる測定可能な手段で知る
- スループット、エラー発生率、ユーザーの待ち時間などの測定可能な出力に基づいて、システムの通常の動作（その「定常状態」）を定義する
- 安定な対照群と比較して、実験群の定常状態の挙動について仮説を立てる
- 当然、実験群では障害するかもしれない。それをも含めた定常状態との違いを予測する
- 障害が未然に防げれば当然何も起きない
実験という名の障害を引き起こす
- 実験グループを、サーバーのクラッシュ、ハードドライブの誤動作、ネットワーク接続の切断などの現実的なイベントをシミュレートさせる。
実験結果を見る
- 対照群と実験群の定常状態を比較して仮説を検定する

こうやってみると、カオスエンジニアリングの名前から想像がつかないような厳密な手順でやっていることがわかるだろう。まるで実験室から学振会に科研費を出すように慎重な手段だ。

決して"モンキーテストのようにランダムな指向を施行を行い、表面化した影響事象をバグとしてアドホック的に対応する"といったものではないことがわかる。

最近発表されたChaos EngineeringのManaged Serviceである"AWS Fault Injection Simulator"の挿絵を注意深くみてほしい。

Experiment(実験)という言葉が並んでいることに気づくだろう。

カオスエンジニアリングとは実験である。そして実験には実験計画とその実験結果を知るための手段、そして実験した後始末が必要だ。つまり運用環境を監視し、元の状態に復旧するための仕組みである。^[1]^[2]

これが揃ってカオスエンジニアリングは初めて可能になる。

本番環境で検証を実行しよう

Run expreriments in production.

カオスエンジニアリングの原則に書いてある言葉だ。

ここで注目すべきは productionという意味だ。本番環境、商用環境を指す。
ネットワーク環境やトラフィックなど、本番環境でないと再現できない環境だからこそ本番環境でやるべきだ。

この頑なともいえる信念には、本番環境でのテスト: 難しい側面(上) というCindy Sridhara氏による所見でも詳しく説明されているように様々な忌避感があるがひとまずおいて、Netflixの意思を改めて確認してみよう。

どうして本番環境でやることを取り入れようとしたのか？
そのためになにかイベントがあったのではないか？

そう思い、Netflixの技術史からカオスエンジニアリングに関係しそうなものをピックアップしてみた。

Netflixの技術史^[3]

2008年

とあるDB障害がNetflixのアーキテクチャデザインを変えた

Netflixは当時はレンタルDVDの配送サービスを行っていた
システムはオンプレミスで構築していた
2007年に1000タイトルから始まった事業は、2009年には12000タイトルと順調にサービスを拡大…するはずだった
2008年8月データベースのハードウェア障害により3日間のサービス停止とその後の遅配が生じる　(当時の新聞に記載在り。以前、ローカル紙の記載をどこかで見たのだがなかったのでこれで許して)
この障害を契機に、単一障害点(SPOF)を持つ垂直方向にスケールするRDBから、クラウド上の信頼性が高く、水平方向にスケーラブルな分散システムへと移行することをCIOは決意する
- 参照: https://media.netflix.com/en/company-blog/completing-the-netflix-cloud-migration
その後、DVDの販売は停止し、同年始めていたストリーミング通信にシフトすることをも宣言する

2009年

NetflixはAWS Cloudへの移行を開始する

NetflixはAWS Cloudへの移行を開始した
決断した理由について、自社のテックブログで次のように述べている
- 従来の三層構造型のデータベース指向アーキテクチャについて、前年の障害を踏まえて再設計する必要があったこと
- ユーザー数の増加など、ビジネスの成長速度に予測がつかなかったこと。そしてそれを水平方向でのスケーリングで可能にするアーキテクチャデザインが、AWSというクラウド環境とマッチしていたこと
- クラウドコンピューティングが未来だと確信していたこと
- オンプレミス環境で自サバ管理なんてもう嫌

2010

2010年はNetflixにとって技術的開花の年

この年にNetflixの商用環境に導入された技術要素を見てみよう。
それらは10年後の今、どれも標準的といえるものだ。

そしてカオスエンジニアリングのための専用ツールであるChaos Monkeyの開発もこの年に行われた。

初期のChaos MonkeyはEC2のインスタンスをランダムに落とすものだった。Netflixがテックブログ5 Lessons We’ve Learned Using AWSで2010/12月にさらっと紹介されたこのツールの名前は一部の技術的に敏感なエンジニアにはすでに注目されていたが、一躍脚光を浴びるには翌年のAWS障害を待たなくてはいけなかった。

2011

2012

Chaos MonkeyがOSSとして公開される

2013

Chaos Kongなど、Chaos Monkeyに仲間が増え始める
- 最終的にSimianArmy(猿山軍団)を形成するが、後述する事情によりChaos Monkey以外全員リタイアし、開発は停止される

2014

Chaos Engineeringという役職がNetflix内にできる
カオスエンジニアリングにおいて、本番環境でのテストのやりすぎがサービスレベルに影響を及ぼしてしまう
→ 反省を踏まえて、L7のロードバランサーに障害を注入するタイプのテスト、FIT( Failure Injection Testing )を開発。カオスエンジニアリングを制御する必要性が強調されるようになる。^[4]

What we need is a way to limit the impact of failure testing while still breaking things in realistic ways.
私たちが必要としているのは、現実的な方法で物事を壊しながらも、失敗テストの影響を制限する方法です
https://netflixtechblog.com/fit-failure-injection-testing-35d8e2a9bb2

2015

カオスエンジニアリングの原則として、明文化される

2015年までの振り返り

軽く2015年まで、カオスエンジニアリングの原則として明文化されるまでを振り返ってみた。

俯瞰してみると。2011年のAWSの障害が、大きな、そして決定的なイベントであることがわかるだろう。EC2インスタンスをランダムに落として影響を調べるChaos Monkeyはこの障害のためにあったツールであるともいっていい。

ただし、2012年のクリスマスの日にNetflixはユーザーが殺到して落ちるということも経験しているので、サービスを安定的に稼働させるには決して十分ではなかったともいえる。EC2インスタンスを単純にランダムに落とすだけだったChaos Monkeyに後続する仲間が増えたのもそのためだ。

Netflixはその後も本番環境で実験を行うべく、手法を洗練させていく。
その後を知りたい場合、2018年の記事であるレジリエントなサービスを設計する - Nora Jones氏がQCon SFでNetflixのカオスエンジニアリングを論議等が参考になるだろう。

また、具体的にChaos Monkeyなどのカオスエンジニアリングツールを使って、どのように本番環境で実験するのかは、過去にサイゲームズとAWSの人が講演している下記の資料が大いに参考になるだろう。

Chaos Engineering 〜入門と実例〜

自分は観点を変えて、昨今のカオスエンジニアリングの状況を振り返りたい。

そう、この記事で取り上げたいのはカオスエンジニアリングの原則にもあるように
本番環境で実験をやることが鉄則だった状況が変わりつつあることの理由を探ることだ。

そのためにはカオスエンジニアリングのために開発されたツールの"その後"を探る必要がある。

カオスエンジニアリングは既にカンブリア紀を過ぎた

カオスエンジニアリングが、原則という名前によって洗練された前後、様々なツールが誕生した。それらを第一世代とすると、実はその中で現在も変わらず開発、保守が続けられているものはそう、多くはない。

本家であるNetflixのカオスエンジニアリングツールに関しても実はChaosMonkey以外にも様々なカオスエンジニアリングツールが開発されたが、現在はプロジェクトが整理されてほとんどがArchivedな状態にある。

なぜか？その端緒を掴むためにHystrixと呼ばれるOSSを見てみよう。このOSSもまたArchivedにこそなっていないものの、最後のリリースは2018年、開発は完全に止まってしまった。
https://github.com/Netflix/Hystrix

Hystrixはサーキットブレーカーツールと呼ばれる、分散システムのどこかのサービスで障害が発生したときにそのサービスにリクエストを送らないようにするためのツールだ。

マイクロサービスアーキテクチャを採用しているサービスでカオスエンジニアリングを実践したいなら、サービスのResilience(回復力)を持たすことも欠かせない。

サービス間の関係性を表した、マイクロサービスを象徴する有名な図だ。この複雑な関係の中で手動でサービスを復旧させようとすると非常に難しいだろう。そこで、サービスが自分自身で回復力、Resilienceをもたすようにしようという考えが出てきた。

それ自体はとても重要な考え方だったが、じきにサービス自身が回復力を持つ需要性はなくなってしまう。

サービスではなく、その土台であるプラットフォームやサービスを管理するオーケストレーションツールがサービスにResilienceを与える考え方が主流になったためである。

「カオスエンジニアリングの原則」が明文化されるより少し遡った2014年、Kubernetesというゲームチェンジャーの誕生により、決定的に考え方は変わってしまった。

後半

脚注

カオスエンジニアリングを始めるには本番環境をあらゆる測定可能な手段で知る必要がある。例えば2020/4にクラスメソッドさんが発表したNew Relic, AWS 国内トップパートナーのクラスメソッド社とカオスエンジニアリングによる新ソリューション開発を中核としたパートナー契約を締結というカオスエンジニアリングをやっていきますというプレスリリース、APMとして老舗のNew Relicが入っていることにも納得がいくだろう。Brendan Gregg氏は運用監視のために必要なメトリクス、USE METHODの提唱者で知られる、プログラムのトレーシングツールの第一人者だが、彼の所属先はNetflixである。 ↩︎
実験に関しては学術的知見が不可欠だ。最近読んだ「A/Bテスト実践ガイド　真のデータドリブンへ至る信用できる実験とは」は、実装にあたって知見に富んでいたのでお勧めする。 ↩︎
元Netflixの人がスピンアウトし、Chaos EngineeringのManaged Serviceを展開しているGremlin社の記事: Chaos Engineering: the history, principles, and practiceや Netflix社のテックブログ、リンクが思い出せなくて恐縮ですがhackernewsのコメントなどを参考にした。 ↩︎
Minimize Blast Radius という洗練された言葉になるのは、チェルノブイリ原発事故を元に2017年4月にAaronが同僚のCasey氏にこの言葉を追加するように提案してからになる。https://twitter.com/aaronblohowiak/status/1251510556831313920 ↩︎

Discussion