アジャイル DevOps: Chaos Monkey を使用する

意図的に障害を発生させてシステムのレジリエンシーを確実にする方法

ソフトウェア・システムの一部 (ソフトウェア・システムが実行されているハードウェアを含む) を無作為かつ意図的に強制終了させることが賢明な考えとなるのは、一体どのような場合なのでしょう?また、それを「早い段階から頻繁に」行うのが効果的なのはどのような場合なのでしょう?連載「アジャイル DevOps」の今回の記事では、DevOps のエキスパートである Paul Duvall が、Chaos Monkey (Netflixが付けた名前) を作成して、不可避のシステム障害から本番環境のインフラストラクチャーがリカバリーできることを確実にする手法について説明します。

Paul Duvall, CTO, Stelligent

Paul DuvallPaul Duvall は、Stelligent の CTO です。数々の主要なソフトウェア・カンファレンスでメインの講演者を務めている彼は、ソフトウェア・プロジェクトの開発者、プロジェクト・マネージャー、アーキテクト、およびテスターと、実質上すべての役割を担当した経験を持ちます。彼が中心的な著者となった共著書『継続的インテグレーション入門 開発プロセスを自動化する 47 の作法』(Addison-Wesley、2007年) は、2008年度の Jolt Award を受賞しました。また、『Startup@Cloud』、『DevOps in the Cloud LiveLessons』(Pearson Education、2012年6月) の著者でもあります。その他の本にも貢献し、developerWorks では 20 の記事からなる連載「万人のためのオートメーション」を書いています。彼は、継続的デリバリーとクラウドを利用して、高品質のソフトウェアをより短時間に、より頻繁に提供することに熱意を持っています。Stelligent.com で彼のブログを読んでください。



2012年 11月 22日

この連載について

開発部門は、運用部門から多くのことを学べます。同じく運用部門も開発部門から多くのことを学べます。この連載では、運用部門の考え方と開発部門の考え方を相互に適用し、ソフトウェア製品をこれまでよりも迅速かつ頻繁に提供可能な総体的要素として捉える場合の実用性を探ることに話題を絞ります。

この連載の最初の記事で述べたように、Amazon.com の CTO である Werner Vogels 氏は、「Everything fails, all the time (年がら年中、あらゆるものが故障する)」という単純な原則に従っています。ソフトウェアに関して私が度々口にするのは、「何事も前提にしてはならない」ということです。ハードウェアでもソフトウェアでも、管理するすべてのリソースでの「失敗」(障害) に常に備えていれば、「成功」の可能性は高くなります。この逆説的な考えは、「本番」のリソースを無作為に使用不可にしたり、強制終了させたりすることで、自動リカバリー・メカニズムがインフラストラクチャーの一部となっていることをテストして確実にするための、さまざまな手段の中核となっています。

そのようなツールのなかで最も注目に値するのが、Netflix の技術チームが開発し、今年になってまもなくオープンソースとして利用できるようになった Chaos Monkey です (このツール、およびその他のツールについては「参考文献」を参照)。この記事では、インフラストラクチャーで起こるべくして起こる不可避の障害に対処できることを確実にするために、Chaos Monkey をインフラストラクチャーに統合する際の原則とステップを紹介します。

Chaos Monkey のようなツールは、仮想化、インフラストラクチャーのコモディティー化、そしてクラウド・コンピューターなどによってもたらされる (前回の記事で説明した) 一時環境へと向けた進化の産物です。以前のインフラストラクチャー (およびその物理マシン、ネットワーク・スイッチ、ファイアウォール、ロード・バランサー、ソフトウェア・サーバー、その他のリソース) は、エンジニアのチームの手によって「一度だけ」セットアップされるものでした。チームはインフラストラクチャーをセットアップした後、その使用状況を監視して、構成の変更やパフォーマンスの改善をはじめとするさまざまな作業を行うために、絶えず手作業で調整を繰り返します。これはもはや望ましいプラクティスとは言えません。大規模なインフラストラクチャーともなれば、こうしたプラクティスを適用するのはまさに不可能です。Chaos Monkey のようなツールは、監視、診断、無作為化、そして混乱状態をインフラストラクチャーに適用することで、大きな問題の発生時にユーザー・エクスペリエンスへの影響を最小限に抑えるための自動化をエンジニアが確実に適用している状態にします。

リソースを見つけて使用できなくする

継続的にインフラストラクチャーをテストする環境を作成するプロセスには、大まかに言うと、以下のステップがあります。

  • インスタンスの起動: いくつかの計算インスタンスを起動します。
  • 自律型インフラストラクチャーの作成: 正常でないインスタンスを特定すると (同じテンプレートをベースに) 新しいインスタンスを起動するようにインフラストラクチャーを構成します (「参考文献」に記載されている IBM のオートノミック・コンピューティング・ポータルを参照してください)。
  • 自動リカバリーを確認する自動テストの適用: エンジニアが問題に対処して修正できる態勢にあるときに、数時間テストを実行します。
  • 学習と予防: 障害が発生したら、その障害に対処し、同じ問題が二度と起こらないようにします。

本番環境のインフラストラクチャーをテストする理由

インフラストラクチャーをわざと混乱させるテストは「本番環境以外」の環境で行うべきであり、「決して」本番環境で行うべきではないという意見もあります。Chaos Monkey が意図的に本番環境のリソースを使用できない状態にするのは、エンジニアの大半が発生したエラーを修正できる時間帯です。さらに言うと、実際の環境での問題を発見して修正することが、何にも増して重要です。

継続的にテストされて自己回復するインフラストラクチャーを使用する上で基本となっている考えは以下のとおりです。

  • インフラストラクチャーでの障害発生は避けられないこと。
  • 本番環境で障害を発生させるテストは、エンジニアが対応できる時間帯に行うこと。
  • 障害が再発したら、ユーザーに気付かれることなく、インフラストラクチャーが自動的に障害からリカバリーできなければならないこと。

継続的改善、つまり「カイゼン」(「参考文献」を参照) に真摯に取り組む組織にとって、このような自律型インフラストラクチャーは多くの点で理想的な「技術」実装です。

要約すると、この新しいタイプの「レジリエンシー」テスト・ツールとこれに伴うインフラストラクチャーには、以下の機能があります。

  • 監視: エラーを「診断」するために、デーモン・プロセスが絶えず実行されます。
  • 診断: システム監視の一環として診断ツールが実行されます。
  • 混乱状態: インスタンスをシャットダウンしたり、その他の破壊的アクティビティーを行ったりして、意図的にインフラストラクチャーで障害を発生させます。
  • 無作為化: 結果と振る舞いが予期されないように、「混乱状態」は無作為にインフラストラクチャーに適用されます。
  • 自己回復インフラストラクチャー: このレジリエンシー・テスト・ツールの一部にはなっていませんが、ユーザーに気付かれることなくサービス中断からリカバリーできる自律型インフラストラクチャーを、チームが継続的に適用および改善するようになることが期待されます。

Chaos Monkey

Netflix ではクラウド・インフラストラクチャーを、とりわけユーザーへの動画配信のために大いに活用しています。2012年 7月の報告によると、Netflix ユーザーが 2012年 6月に利用した動画配信は 10 億時間を超えています。つまり、Netflix はありきたりなクラウド・ユーザーではなく、クラウドを相当な規模で使用しているということです。

GitHub で公開されている、Netflix の技術チームによるクイック・スタート・ガイド (「参考文献に記載されている「Quick Start Guide for Chaos Monkey」を参照) では、Chaos Monkey を稼働状態にするためのステップを説明しています。以下に、Chaos Monkey が使用するツールを記載して、それぞれについて説明します。使用していないリソースについては、必ずクイック・スタート・ガイドで説明されているコマンドを実行してすべて削除してください。これを怠ると、いつまでも使用料金が請求されることになります。

  • Auto Scaling: Auto Scaling は、ユーザーが定義するルールに従って、計算キャパシティーを需要に応じてスケールアップ/スケールダウンすることを可能にする AWS (Amazon Web Services) の機能です。これは AWS 固有の機能ですが、このようなスケーラブルな環境は、お使いの (プライベートまたはパブリック) クラウド・インフラストラクチャーにも作成することができます。Auto Scaling には 2 つの主要なコンポーネントがあります。1 つが「起動設定」で、もう 1 つが「Auto Scaling グループ」です。起動設定は、Auto Scaling グループに含まれるインスタンスの起動方法を定義します。Auto Scaling グループは、特定の起動設定を適用する対象インスタンスの集まりです。
  • SimpleDB: SimpleDB は、データを永続化するために使用できる NoSQL データベースです。SimpleDB ドメイン・クラスを定義して、Chaos Monkey が状態を保管するために使用できるようにする必要があります。
  • Gradle: Gradle はビルド・ツールです。このツールは、Chaos Monkey をビルドして、Jetty アプリケーション・コンテナーを起動するために使用されます。
  • プロパティー・ファイル: クレデンシャルやその他の構成可能な情報を使用して、simianarmy.properties ファイルを変更する必要があります。
  • Jetty: インメモリー Jetty サーバーが Chaos Monkey を実行して、インフラストラクチャーを無作為に混乱させます。

Simian Army

Chaos Monkey は、Netflix 技術チームの Simian Army に加わった初めてのエントリーです。表 1 に、Netflix が Simian Army を構成するメンバーとして提案しているその他のツールを記載します (「参考文献」を参照)。

表 1. Simian Army
名前説明
Chaos Gorilla可用性ゾーン全体の停止をシミュレートします。
Conformity Monkeyベスト・プラクティスに従っていないインスタンスをシャットダウンします。
Doctor Monkeyヘルス・チェック (CPU など) を実行します。
Janitor Monkey使用されていないリソースを検索して処分します。
Latency Monkeyクライアント・サーバー間の通信に人工的に遅延を生じさせます。
Security Monkey適切に構成されていないセキュリティー・グループなど、セキュリティーの脆弱性を検出します。

上記の表に記載したのは、ほんのわずかな提案のみです。クラウド・ベースの本番環境で、監視、診断、テスト、そして意図的に使用不可にされた状態を組み合わせて適用する方法には、他にも限りない可能性が考えられます。


Chaos Monkey を使いこなしてください

参加してください

developerWorks の Agile Transformation コミュニティーでは、コミュニティーに参加している個人あるいは組織がアジャイル開発の原則に基づく基礎を固めるために役立つニュース、ディスカッション、トレーニングを提供しています。

この記事では、Chaos Monkey のようなツールとクラウド環境の助けがあれば、実際に自己回復可能な自律型インフラストラクチャーの作成に取り掛かれることを学びました。

次回の記事では、テスト駆動型インフラストラクチャーについて説明します。そのなかで、通常は開発者がアプリケーション・コードに使用するテスト駆動型開発手法を、Cucumber などのツールを使用してインフラストラクチャーに適用する方法を学びます。

参考文献

学ぶために

  • Automation for the people: Continuous testing」(Paul Duvall 著、developerWorks、2007年3月): この記事では、コード・ベースを変更するたびに実行する自動テストについて説明しています。
  • Failure as a Service」(Haryadi S. Gunawi 他による共著、カリフォルニア大学バークレー校の技術レポート、2011年7月): このレポートでは、実際のデプロイ済み環境で定期的に行う大規模な障害の演習について述べています。
  • Netflix streaming tops 1 billion hours in month for first time」(Rachel King 著、CNET、2012年7月): 最近、Netflix のデジタル・ストリーミング・サービスの視聴時間が 1 ヶ月に 10 億時間を上回るという画期的な記録を打ち立てました。
  • Chaos Monkey のクイック・スタート・ガイド: 皆さんの環境で Chaos Monkey を実行するためのガイドです。
  • Autonomic Computing: IBM のオートノミック・コンピューティング・ポータルです。
  • カイゼン: ウィキペディアで、日本で生まれた継続的プロセス改善手法について説明しています。
  • Chaos Monkey Released Into The Wild」(Cory Bennett、Ariel Tseitlin 共著、Netflix、2012年7月): GitHub によるオープンソースとしての Chaos Monkey の正式リリース発表です。
  • さまざまな IBM 製品や IT 業界のトピックに焦点を絞った developerWorks の technical events で最新情報を入手してください。
  • 無料の developerWorks Live! briefing に参加して、IBM の製品およびツールについての情報や IT 業界の動向についての情報を迅速に把握してください。
  • Twitter で developerWorks をフォローしてください。
  • developerWorks の on-demand demos で、初心者向けの製品のインストールとセットアップから、熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。

製品や技術を入手するために

  • Simian Army: Chaos Monkey は、Netflix のオープンソース・ツール・スイート Simian Army のエントリーの 1 つです。
  • Bees with machine guns: 多数の蜂 (ミクロ EC2 インスタンス) で武装 (作成) してターゲット (Web アプリケーション) を攻撃 (負荷テスト) するユーティリティーです。
  • IBM Tivoli Provisioning Manager: Tivoli Provisioning Manager は物理サーバー、仮想サーバー、ソフトウェア、ストレージ、およびネットワークを自動化して、動的なインフラストラクチャーを実現します。
  • IBM Tivoli System Automation for Multiplatforms: Tivoli System Automation for Multiplatforms は、エンタープライズ規模のアプリケーションおよび IT サービスの高可用性および自動化を実現します。
  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、ウィキを調べることができます。
  • developerWorks の Agile Transformation コミュニティーでは、組織がアジャイル開発の原則に基づく基礎を固めるために役立つニュース、ディスカッション、トレーニングを提供しています。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps, Java technology, Open source
ArticleID=846082
ArticleTitle=アジャイル DevOps: Chaos Monkey を使用する
publish-date=11222012