BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Chaos Monkeyアップデート

Chaos Monkeyアップデート

原文(投稿日:2016/10/25)へのリンク

NetflixはChaos Monkeyのアップグレードを発表した。Chaos MonkeyはSoftware as a Serviceの弾力性を改善するための汎用ツールであり、サービス提供時間中にランダムにサーバやコンテナを停止する。今回のアップグレードで、Chaos MonkeyはSpinnakerと統合された。SpinnakerはNetflixの継続的デリバリのプラットフォームであり、さまざまなクラウドプラットフォームで利用できる。同社のDockerコンテナのプラットフォームであるTitusも対応している。

Chaos MonkeyはSpinnakerを経由して構成情報を受信し、この情報を使うことでChaos Monkeyはリソースの停止をスケジューリングして実行する。これによって停止のスケジューリングのユーザ体験が向上できる。アプリやスタック、クラスタをグループ化できる。また、さまざまな理由でChaos Monkeyの対象から抜け出すこともできる。リソースの停止は計測やレポートのためにツールによって追跡される。

InfoQは今回のリリースに関わっているNetflixのエンジニアであるLorin Hochstein氏に話を聞いた。

InfoQ: Chaos Monkeyがはじめてリリースされてから5年以上が経ちましたね。これまでの歴史とこの最新リリースの動機について教えてください。

Hochstein: 今回のアップグレード作業を始める前、Simian Armyプロジェクトは変更が難しい状態になっていました。Simian ArmyプロジェクトはChaos Monkeyを含むツール群のプロジェクトです。私たちの内部のSimian ArmyにオープンソースのバージョンのSimian Armyが取り込まれ、Netflix独自の挙動が追加されていました。変更の影響が見積もれないような追加の仕方だったのです。特に辛かったのは、Chaos Monkeyのアプリケーション構成の管理でした。Netflixの内部のバージョンとオープンソースのバージョンでアプリケーション固有の構成データの管理の仕方が違っていたのです。

さらに事態を複雑にしていたのは、Netflix内部のSimian Armyに対する責任がチームで分割されてしまっていたことです。ChaosチームがChaos Monkeyを見て、EngToolsチームがJanitor MonkeyとConformity Monkeyを見ていたのです。そして、内部でのSimian Armyの配置も別々でした。ChaosチームはChaos Monkeyだけが有効になっているSimian Armyを、他のチームはChaos Monkeyが無効になっているSimian Armyをそれぞれ別に使っていたのです。

これらの問題があったため、Chaosチームは、より素早く確実にコードベースを変更できるようにする時期が来たと感じていました。

InfoQ: あなたのブログに書かれているように、今回のアップグレードは大規模なものです。Spinnaker統合はそのひとつですね。この統合と他のアップグレードについて詳しく教えてください。

Hochstein: Spinnakerの統合によって、 Chaos Monkeyはさまざまなクラウドバックエンドに対応できるようになります。例えば、AWS向けのSpinnakerが最初からサポートされていれば、私たちの内部のコンテナクラウドであるTitusのサポートも簡単に追加できます。TitusはSpinnakerをサポートしているからです。Spinnakerは、AWS以外にも、Google Compute EngineやMicrosoft Azure、KubernetesとOpenStackのようなプライベートなクラウドもサポートします。SpinnakerがバックエンドをサポートすればChaos Monkeyはそのままで動くということです。

AWSだけしか使っていなくても、複数のリージョンまたは複数のアカウントを実行している場合、Spinnaker統合によってChaos Monkeyの配置はシンプルになります。前のバージョンのChaos Monkeyでは、それぞれのリージョンまたはそれぞれのアカウントで別々にChaos Monkeyを配置する必要がりました。今回のバージョンでは単一のChaos Monkeyの配置で複数のリージョン、複数のアカウントに対応しています。

Netflixの内部では、配置の異なる側面を管理するため複数のツールを使ってきましたが、これらの機能をSpinnaker UIから使えるように移行しています。この流れを考慮すると、サービスチームが彼らが配置パイプラインや配置状態の視覚的把握に使っているのと同じシステムを使ってChaos Monkeyの構成をできるようにするのが合理的だということがわかりました。

また、Chaos Monkeyが何をインスタンスの論理的なグループとみなすかをユーザが制御できるようになったのも大きな変更です。前のリリースではChaos MonkeyはAWSの自動スケールグループ(ASG)をインスタンスの論理的なグループとして使っていました。つまり、Chaos Monkeyが動作するとASGごとにひとつのインスタンスをランダムに殺していたのです。Netflixの内部では、アプリ、スタック、クラスター、そしてASGという概念があり、ひとつのクラスタはひとつのASGに関連する、といった使い方をしています。しかし、Netflix内部で異なるサービスチーム同士で会話するとき、チームの論理的なクラスタがSpinnakerがクラスタとして把握しているものと一致しないことがありました。そこで、私たちは、Chaos Monkeyに構成上の選択をひとつ追加し、エンジニアが何を論理的クラスタとして定義するか選べるようにしました。Spinnakerのクラスタにマップしても、Spinnakerのスタックやアプリにマップしても構いません。ただし、アプリ/スタック/クラスタという概念はSpinnakerより以前からありました。Netflixの前の配置ツールだったAsgardでも使っていました。

もうひとつの新しい機能はユーザがChaos Monkeyと他のサービスを連携できるようにするフックです。例えば、ユーザは独自の"トラッカー"を定義できます。トラッカーはChaos Monkeyがインスタンスを停止しようと決めたときに実行されます。私たちは内部では、Atlasにメトリクスを送信し、イベントをログインするサービスに停止を記録する。以前のバージョンのChaos Monkeyは通知のためメール送信ができなければなりませんでした。これは、AmazonのSimple Email Service(SES)に結びついていたのです。新しいバージョンでは、Netflixのエンジニアは単にメールのアラートをAtlasで構成すればよいだけです。また、現在停止しているインスタンスがあるかどうかの問い合わせ用のインタフェースとしてフックを使うこともできます。現在進行の停止があった場合は、Chaos monkeyはインスタンスを停止しません。

InfoQ: インスタンスの停止だけで遅延などほかの障害を注入できないようになっているのは制限のように思います。この制限についてコメントいただけますか。

Hochstein: Netflixではの内部ではほかのタイプの障害を発生させていません。これを実現するにはインスタンスに対するsshでのアクセスや、インスタンス上でのエージェントの実行をしなければなりません。私たちはこれ以上の複雑さを追加したくないのです。

Netflix Tech Blogで今回のアップグレードを発表したとき、ブログへのコメントで、ほかのタイプの障害のほうが単なるインスタンスの停止よりも問題を含んでいる、と指摘されました。この指摘は正しいです。私たちにはまだオープンソースにしていないLatency Monkeyがあります。これは遅延をランダムに発生させます。しかし、内部でも大規模には使っていません。危険が大きすぎると判断しているためです。

ほかのタイプの障害をランダムに発生させるのではなく、そういった障害に対して回復力のあるサービスにするためにより焦点を絞り込んだテストをしています。例えば、前のバージョンのChaos MonkeyではCPU利用率上昇、I/O上昇、ローカルのディスクスペースの消費のような障害をサポートしていました。障害に苦しんでいるインスタンスへRPC呼び出しをするクライアントから見ると、これらの障害の多くは呼び出しの遅延か呼び出しの失敗かその両方のいずれかとして確認されます。つまり、私たちは障害の大部分を遅延かRPCレベルの失敗としてモデル化できるということです。NetflixにはこのようなRPCの失敗を一定期間注入するFITというシステムがあります。

また最近では、Chaosチームがツールを開発しFITを使ってより焦点を絞った失敗を注入することができるようになりました。同僚のAli Basiriがこの方法について近々開催されるQCon SFで発表します。私もIEEE International Symposium on Software Reliability Engineeringで話すつもりです。

InfoQ: 開発者または設計者として、私がChaos Monkeyを使いたい場合、Spinnakerと同時に使う必要がりますか。Chaos Monkeyを自分たちのクラウドやコンテナプラットフォームに統合したい開発者や設計者にアドバイスをお願いします。

Hochstein: Chaos Monkeyを使いたいのに配置プラットフォームにSpinnakerを使っていないという状況は現時点では、不幸と言わざるを得ないですね。

Chaos Monkeyの複雑さの主要な部分はインスタンスの停止の部分ではありません。直近のChaos Community Dayで、GitHubのJesse NewlandがKubernetes Pod Chaos Monkeyを実装しました。たった20行のシェルスクリプトです。配置のドメインモデルの作成が複雑なのです。Netflixでは, Chaos Monkeyが、すべてのチームの共通理解になっているアプリ/スタック/クラスタという概念を理解し、Spinnakerからアクセスできます。Spinnakerを使っていないなら、配置はこのモデルに従わないので、私たちのChaos Monkeyの活用の仕方はそのままフィットしません。

私のおすすめは、開発者が自分たちの配置パターンに適合するchaosツールを探すことです。いくつかのツールがあります。pumba、Chaos Lemur、Chaos Lambda、Blockade、Simoorg、そしてMicrosoft AzureのFault Analysis Serviceというのもあります。きちんとマッチするものがなかったら、一番合うのをフォークして必要に応じてカスタマイズするのがいいかもしれません。

また、Principles of Chaos Engineeringを読んでください。これは、カオスエンジニアリングを導入してシステムの回復力を確保する方法についての私たちの考えを書いています。

InfoQ: Chaos MonkeyのコントリビュータはNetflixだけですか。新しいリリースで変わりますか。

Hochstein: 歴史的にはNetflixはChaos Monkeyの第一のコントリビュータです。しかし、コミュニティも貢献しています。例えば、Chaos Monkeyの最初のリリースに入った追加障害モードはコミュニティのメンバによって貢献されたものです。

新しいリリースでもNetflixが第一のコントリビュータであり続けます。Spinnakerが普及すればChaos Monkeyに対するコミュニティの貢献も増えるのではないでしょうか。

Chaos Monkeyのgithubリポジトリではより詳細な情報が得られる。

 
 

Rate this Article

Relevance
Style
 
 

この記事に星をつける

おすすめ度
スタイル

BT