任意のサーバのシャットダウンやプロダクション環境のデータセンター全体のシャットダウンをシミュレーションしてきた経験に基づいて、NetflixがChaos Engineeringの原則を提案している。
NetflixはChaos Engineeringを「プロダクション環境の過酷な状況に耐えられるというシステムの能力に自信を持つため、分散システムで実験するという規律」だと定義している。コントロールされた実験でシステムの振る舞いを観察することにより、プロダクションシステムの弱点が望ましくないやり方で現れる前に見つける必要があると、Netflixは述べている。彼らはシステムの弱点になり得るものとして、「サービス利用停止時の不適切なフォールバック設定、不適切に調整されたタイムアウトによるリトライの嵐、下流にあるものが過度のトラフィックを受信している時の機能停止、単一障害点がクラッシュした時の連鎖的エラーなど」を述べた。
Netflixによると、Chaos Engineeringの4つの原則は以下の通り。
定常状態の振る舞いについて仮説を立てる
システムの内部属性ではなく、システムの測定可能なアウトプットに注目しよう。短い期間を超えたアウトプットの測定は、システムの定常状態の代わりになる。システム全体のスループット、エラー率、レイテンシパーセンタイルといったものは全て、定常状態の振る舞いを表す興味深いメトリクスになるだろう。実験中のシステムの振る舞いのパターンに注目することで、システムがどのように動作するかを検証しようとするのではなく、Chaosはシステムが動作することを検証する。
実世界の事象は多様である
Chaosの変数は実世界の事象を反映している。事象を潜在的影響もしくは想定頻度のいずれかで優先順位付けしよう。サーバの死亡といったハードウェアエラー、不正な形式のレスポンスといったソフトウェアエラー、そしてトラフィックの急増やスケーリングといった非エラー事象に対応した事象について検討しよう。定常状態を壊すおそれのあるどんな事象も、Chaos実験の変数になり得る。
プロダクション環境で実験を実行する
システムは、環境やトラフィックパターンによって異なる振る舞いをする。利用の振る舞いは常に変化するため、実際のトラフィックをサンプリングすることが、リクエストパスを確実に記録する唯一の方法だ。システムの実行方法の信頼性と現在デプロイされているシステムとの関連性の両方を保証するため、Chaosはプロダクション環境のトラフィックで直接実験することを強く推奨する。
実験を自動化して、継続的に実行する
手作業による実験の実行には多くの人手が必要で、結局は長続きしない。実験を自動化して、継続的に実行しよう。Chaos Engineeringはシステムを自動化して、オーケストレーションとアナリシスの両方を動かす。
簡潔に言うと、Netflixは次のような実践的ステップを提案している。
- システムの通常の振る舞い、その「定常状態」が何なのかを定義する。
- コントロールシステムと実験システムを構築する。
- サーバクラッシュ、HDD異常、ネットワークエラーなどの実際の事象をシミュレートして、実験システムにおいて強制的に壊していく。
- コントロールシステムの定常状態と実験システムの定常状態を比較する。通常からの逸脱が小さければ小さいほど、システムの弾力性に自信が持てる。もし実験中に問題があれば、起こったことから学んで、適切な措置をとることができる。
Chaos Engineeringの原則は常に更新されるドキュメントであり、Netflixは他の組織にもコントリビュートを求めている。
Netflixには、Chaos Monkey、Gorilla、Kongといったツールを構築し、利用してきた経験があり、様々なシステム、ゾーン、さらにはリージョン全体がダウンした時に、サービスがどのように振る舞うのかテストしてきた。NetflixのエンジニアであるNir Alfasi氏によると、ゾーン停止が起こることはまずないため、Gorillaは実際には使われていないが、ほぼ毎月、Kongを使ったリージョン停止を実施しているという。Chaos Monkeyは前にSimian Armyプロジェクトおいてオープンソースで公開された。Simian Armyのツールには、他にもJanitor MonkeyとConformity Monkeyがある。