5分で学ぶ: カオスエンジニアリングの説明書

この記事はNew RelicのチーフエディタFredric Paulによる記事「Breaking to Learn: Chaos Engineering Explained」の翻訳です。

Netfilxは、ただのインターネット越しのお茶の間TVショーというわけではありません。カオスエンジニアリングという分野の産みの親となったのは、まさに必然といえるでしょう。

この概念は矛盾しているように見えます。もしくはB級SF映画の物語か。しかしそれは、複雑な現代的アーキテクチャにおけるレジリエンス（回復力）の改善を実現するために、必要とされてきています。

この記事では、カオスエンジニアは何か、どのように役に立つかについて述べていきます。まずは、カオスエンジニアリングをざっくり理解するために、少し歴史を紐解いていきましょう。

「カオス」を受け入れる

Netflixは何年にも渡ってインフラストラクチャを進化させながら、複雑化や大量リソースの消費に備えてきていました。顧客は1億人、190の地域におんでいます。初期は レンタル事業とストリーミングサービスを運営していて、ラックサーバなオンプレで動いており、単一障害点などの問題を抱えていました。有名な事件では、2008年8月にデータベース障害が発生し、DVDの発送が3日間止まってしまったことがあります。この教訓から、Netflixのエンジニアはアーキテクチャの刷新に乗り出します。2011年、オンプレで動くモノリシックな構成から、AWSに構築したクラウドベースな分散アーキテクチャへの移行を果たしています。

この新しい分散アーキテクチャは数百のマイクロサービスで構成され、単一障害点は存在しません。しかし、信頼性と耐障害性があるシステムには、新しい問題、複雑さがつきまといます。このことから、Netflixのエンジニアリングチームは「障害を絶やさないことで障害を防ぐという」決定的な学びを得ることになります。

カオスの新しい使いみち

この学びを実践するために、NetflixのエンジニアはChaos Monkeyを開発しています。このツールは、システム全体のランダムな箇所、ランダムなタイミングで積極的に障害を起こせるものです。特筆すべきはGitHub上で書かれている通り、「Chaos Monkeyは本番環境で動いている仮想マシンインスタンスやコンテナをランダムに停止させます」。構築したサービスが不意の障害に対して十分に堅牢で十分にレジリエンスがあるか、エンジニアが強制的に学ばされることになります。

そして、Chaos Monkeyの出現により、新しい分野が誕生します。それがカオスエンジニアリングです。もう少しわかりやすく言うと「分散システムにおいてシステムが不安定な状態に耐えることの出来る環境を構築するための検証の規律」ということになります。

2012年、NetflixはChaos MonkeyをOSSで公開しました。現在では、グーグルやアマゾン、IBM、Nikeなど多数の企業でカオスエンジニアリングのプラクティスが実践されており、モダンなアーキテクチャでのレジリエンス性の改善に役立てられています。Netflixはカオスエンジニアリングのツールセットとして、「Simian Army」というシステムに攻撃するツールに発展させています。

カオスエンジニアリング: すべてがカオスということではない

Kolton Andrusは、カオスエンジニアリング分野のスタートアップであるGremlinのCEOです。GoogleとNetflixで働いた経歴を持ち、カオスエンジニアリングを予防接種として捉えるよう提唱しています。将来的に病気を防ぐために体内に有害なものを故意に注入する、このアイデアはクレイジーだと思われるかもしれません。しかし、クラウドベースな分散システムに対するこのアプローチは実に上手くいく、Andrusはそう語ります。カオスエンジニアリングは慎重にシステムに障害を注入し、システムの応答をテストします。これにより企業はサービス停止に備えたり訓練したりするようになり、ダウンタイムの低減に寄与することになります。

ここで有効な言葉は「慎重さ」です。カオスエンジニアリングを実際に混沌としたものと考えるのは間違っています。実際、ランダムなテストはほとんどありません。そのかわりにカオスエンジニアリングでは、実験を綿密に計画して、コントロールし、障害に直面した場合のシステムの動作を実証するようデザインされます。

「昨年、顧客と行ったすべてのカオスエンジニアリング実験のうち、ランダムに割り当てられたのは1つか2つくらいです」Russ Milesはそうインタビューに答えています。ヨーロッパのカオスエンジニアリングプラットフォームであるChaosIQ.ioの創設者兼CEOです。「ほぼすべてが、とても慎重に、とても制御された、適切な実験です。ランダム性をテストしようとしているものでない限り、ランダムに実験しても意味がありません」

爆風エリアを最小化する

カオスエンジニアリングで重要なベストプラクティスについて、Amalgam Insightsの研究員であるTom Petrocelliは「爆風エリアを最小限に抑えることである」と述べています。「ビジネスへの影響を最小限に抑えるということです。技術的な影響ということではありません」

「はい、技術的レジリエンスの抜け穴を発見したいはずです。ただし、事業運営に損害を与えない方法が必要なのです」と、Petrocelliは言っています。

Petrocelliは、実験がビジネスをめちゃくちゃにしないように、エンジニアリングチームにカオスエンジニアリングの実験を「綿密に計画する」よう提案しています。あなたが壊れないと思っていた箇所が、運良く、実際には壊れるかもしれない。これはカオスエンジニアリングの世界では成功と考えられています。

それを念頭に置くと、壊れたときに適切に対応するために適切なチームを配置することが重要だと、Petrocelliは述べています。 「Kubernetesのエンジニア全員がオフサイトミーティングに参加している場合、Kubernetesコンテナはめちゃくちゃにしては駄目です」と彼は警告しています。

ただのテストではない: 知識を創造する実験である

Netflixのカオスチームの元エンジニアリングマネージャーであるCasey Rosenthalは、DZoneのQ＆Aで、カオスエンジニアリングは単なるシステムテストではないことを明言しています。テストは2値の結果を見つけ出します。課題に合格しましたか（はい/いいえ）？一方、カオスエンジニアリングは新しい知識を創造する方法論です。現代のソフトウェアシステムは複雑すぎて完全に理解することは誰にとっても難しくなっています。エンジニアがシステムをより理解するためには、実験が必要なのです。Rosenthalによると、テストは依然として重要ですが、カオスエンジニアリングは従来のテストを補完するものになります。

カオスエンジニアリングは、システムの弱点を明らかにするための実験を円滑に進める方法だと考えることができます。実験は多くの場合、次の4つのステップで行います。

1.「定常状態」を定義して測定する

システムが正常に機能していることをリアルタイムで示すメトリックを特定することから始めます。 Netflixは、顧客がビデオストリーミングデバイスの再生ボタンを押す速度を定常状態として使用し、これを「1秒あたりのストリーム数」と呼んでいます。これは技術的な指標ではなく、ビジネス上の指標であることに注意しましょう。事実として、カオスエンジニアリングでは、ビジネスのメトリックは技術的なメトリックよりも有用です。これは、顧客の体験や操作の測定に適しているためです。

2.仮説を立てる。他の実験と同様に、テストのための仮説が必要

システムの通常の実行状態（定常状態）を破壊するとします。そのときの仮説を「Xを実行したとしても、このシステムの定常状態に変化はないはずである」のように立てます。特定のアクションがシステムの定常状態を変えてしまう懸念があるなら、まずはシステムを修正して、そのアクションが影響を与えないようにすべきです。カオスエンジニアリングは、実際に実験をして、未知な現実をあぶり出す方法論です。

「カオスエンジニアリングは、予測可能な挙動や、手順書でカバーされている障害、自動化する必要があることはわかってるにもかかわらずまだやっていないもの、そのようなインシデントのためではありません」とBeth Longは言います。彼女はNew RelicのDevOpsソリューションストラテジストであり、それ以前はサイト信頼性エンジニアでした。「複雑さ自体の性質から生じる類の問題のために必要なのです。みんながSlackに山積みしたり、どうすべきかわからずに頭をかきむしるような問題です」

3.現実で起こり得ることをシミュレートする

O’Reillyの本「Chaos Engineering：System Behavior in System Behaviors by Experiments」では、Netflixのカオスエンジニアリングのアーキテクト、Casey Rosenthal、Lorin Hochstein、Aaron Blohowiak、Nora Jones、Ali Basiriがいくつかのカオスエンジニアリング実験を提案しています:

• データセンターの障害をシミュレートする
• システムクロックの同期を強制的にずらす
• ドライバーのコードでI/Oエラーを発生させるルーチンを実行する
• サービス間のレイテンシを遅延させる
• ランダムに例外を発生させる

一般に、システムが使用できなくなったり、パフォーマンスが低下したりする可能性があるシナリオをシミュレートする必要があります。 「何がうまくいかないのか」と自問してください。そして、それをシミュレートします。潜在的なエラーにも優先順位を付けてください。 「非常に複雑なシステムの場合、予期できないダウンストリーム効果をとても簡単に見つけられます。これは、カオスエンジニアリングが探しているものの1つです」とPetrocelliは言います。「なので、システムが複雑になり、より重要になるほど、カオスエンジニアリングの候補になる可能性が高くなります」

4.仮説を証明/反証する

定常状態のメトリックと、システムに障害を注入したときに収集したメトリックと比較します。測定値に違いがある場合、カオスエンジニアリングの実験は成功しています。実際に同様のインシデントが起こって問題が顕在化しないように、システムを強化していきましょう。もしくは、定常状態が安定していることがわかった場合には、システムのその部分は高い信頼度があるということで、他の部分に取り掛かることができます。

システムを壊すのではない、学んで改善しよう

「カオスエンジニアリングとは、システムやビジネスなどを破壊することでもありません。学習することです」とMilesは言います。 「あなたはチームに学習ループを導入しようとしています。グループの人間が知識を最もよく吸収する方法は、経験を積ませることです」

「もちろん、実際の機能停止から学習することはできますが、とても痛みを伴います」とRussは述べています。 「カオスエンジニアリングは、あなたの管理下にある事象の『事前分析』を行う機会を与えてくれます」

カオスエンジニアリングでは、複雑なシステムを最もよく知っている人々の頭脳も活用していきます。 Longによると「意義のあるカオスエンジニアリングの実験は、自明な仮説に基づいているものではありません。例えば『このラックに障害が発生した場合、そのサービスは遅延を増加させるが、それでも利用可能である』のようなものは、あまり意味はありません。直感では考えつかないような現象について理解を深められるような実験に価値がでてきます。カオスエンジニアリングのプロセスは、専門家の直感に頼ることなく、明確で、テスト可能で、外部からシステムを眺めるだけでは簡単に得られないような貴重な情報を明らかにします」

多くのツールキットが利用可能です。このように、オーストラリアのメルボルンに本拠を置くコンサルティング会社DIUSのプリンシパルコンサルタントであるMatthew Fellowsは言います。 （GitHubにある カオスエンジニアリングに関するリスト をチェックしましょう）「やったことがない実験をやるのはとても怖いかも知れませんが、間違いなくやる価値があります」Fellowsはこのように提案しています。