![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
この連載の最初の記事で述べたように、Amazon.com の CTO である Werner Vogels 氏は、「Everything fails, all the time (年がら年中、あらゆるものが故障する)」という単純な原則に従っています。ソフトウェアに関して私が度々口にするのは、「何事も前提にしてはならない」ということです。ハードウェアでもソフトウェアでも、管理するすべてのリソースでの「失敗」(障害) に常に備えていれば、「成功」の可能性は高くなります。この逆説的な考えは、「本番」のリソースを無作為に使用不可にしたり、強制終了させたりすることで、自動リカバリー・メカニズムがインフラストラクチャーの一部となっていることをテストして確実にするための、さまざまな手段の中核となっています。
そのようなツールのなかで最も注目に値するのが、Netflix の技術チームが開発し、今年になってまもなくオープンソースとして利用できるようになった Chaos Monkey です (このツール、およびその他のツールについては「参考文献」を参照)。この記事では、インフラストラクチャーで起こるべくして起こる不可避の障害に対処できることを確実にするために、Chaos Monkey をインフラストラクチャーに統合する際の原則とステップを紹介します。
Chaos Monkey のようなツールは、仮想化、インフラストラクチャーのコモディティー化、そしてクラウド・コンピューターなどによってもたらされる (前回の記事で説明した) 一時環境へと向けた進化の産物です。以前のインフラストラクチャー (およびその物理マシン、ネットワーク・スイッチ、ファイアウォール、ロード・バランサー、ソフトウェア・サーバー、その他のリソース) は、エンジニアのチームの手によって「一度だけ」セットアップされるものでした。チームはインフラストラクチャーをセットアップした後、その使用状況を監視して、構成の変更やパフォーマンスの改善をはじめとするさまざまな作業を行うために、絶えず手作業で調整を繰り返します。これはもはや望ましいプラクティスとは言えません。大規模なインフラストラクチャーともなれば、こうしたプラクティスを適用するのはまさに不可能です。Chaos Monkey のようなツールは、監視、診断、無作為化、そして混乱状態をインフラストラクチャーに適用することで、大きな問題の発生時にユーザー・エクスペリエンスへの影響を最小限に抑えるための自動化をエンジニアが確実に適用している状態にします。
継続的にインフラストラクチャーをテストする環境を作成するプロセスには、大まかに言うと、以下のステップがあります。
- インスタンスの起動: いくつかの計算インスタンスを起動します。
- 自律型インフラストラクチャーの作成: 正常でないインスタンスを特定すると (同じテンプレートをベースに) 新しいインスタンスを起動するようにインフラストラクチャーを構成します (「参考文献」に記載されている IBM のオートノミック・コンピューティング・ポータルを参照してください)。
- 自動リカバリーを確認する自動テストの適用: エンジニアが問題に対処して修正できる態勢にあるときに、数時間テストを実行します。
- 学習と予防: 障害が発生したら、その障害に対処し、同じ問題が二度と起こらないようにします。
継続的にテストされて自己回復するインフラストラクチャーを使用する上で基本となっている考えは以下のとおりです。
- インフラストラクチャーでの障害発生は避けられないこと。
- 本番環境で障害を発生させるテストは、エンジニアが対応できる時間帯に行うこと。
- 障害が再発したら、ユーザーに気付かれることなく、インフラストラクチャーが自動的に障害からリカバリーできなければならないこと。
継続的改善、つまり「カイゼン」(「参考文献」を参照) に真摯に取り組む組織にとって、このような自律型インフラストラクチャーは多くの点で理想的な「技術」実装です。
要約すると、この新しいタイプの「レジリエンシー」テスト・ツールとこれに伴うインフラストラクチャーには、以下の機能があります。
- 監視: エラーを「診断」するために、デーモン・プロセスが絶えず実行されます。
- 診断: システム監視の一環として診断ツールが実行されます。
- 混乱状態: インスタンスをシャットダウンしたり、その他の破壊的アクティビティーを行ったりして、意図的にインフラストラクチャーで障害を発生させます。
- 無作為化: 結果と振る舞いが予期されないように、「混乱状態」は無作為にインフラストラクチャーに適用されます。
- 自己回復インフラストラクチャー: このレジリエンシー・テスト・ツールの一部にはなっていませんが、ユーザーに気付かれることなくサービス中断からリカバリーできる自律型インフラストラクチャーを、チームが継続的に適用および改善するようになることが期待されます。
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 を実行して、インフラストラクチャーを無作為に混乱させます。
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 のようなツールとクラウド環境の助けがあれば、実際に自己回復可能な自律型インフラストラクチャーの作成に取り掛かれることを学びました。
次回の記事では、テスト駆動型インフラストラクチャーについて説明します。そのなかで、通常は開発者がアプリケーション・コードに使用するテスト駆動型開発手法を、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 コミュニティーでは、組織がアジャイル開発の原則に基づく基礎を固めるために役立つニュース、ディスカッション、トレーニングを提供しています。
Paul 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 で彼のブログを読んでください。
