アジャイル DevOps: 一時環境

環境の希少性を低くするためにキャパシティーが無限にあるような錯覚を扱う

プロビジョニングされた共有環境が、破棄されることなく、エンジニアの手によって継続的に構成が変更されることで、場合によっては何週間も何ヶ月も使われ続けることは珍しくありません。この危険な手法では、デプロイメントの問題や、開発、テスト、本番のサイクルで奇妙な「環境」エラーが頻繁に発生します。そこで、連載「アジャイル DevOps」の今回の記事では、短い期間で破棄される一時環境を作成する方法を説明します。すべての環境がスクリプト化されてバージョン管理されるようになれば、ソフトウェアがデリバリー・パイプラインに沿って本番環境へと移行する間、そのような (スクリプト化されてバージョン管理される) テスト環境が、一連のテストを実行するのに十分な期間だけ使用されるようになります。

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月 08日

この連載について

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

経済学で言う希少性とは、「資源が限られている世界で、人間が限りない欲望と必要性を持つ」ことによる根本的な問題です (「参考文献」を参照)。資源が不足していると、人々はその資源を獲得しようと競い合います。資源の獲得競争は、従来のソフトウェア・プロジェクトで環境を確保しようとする人々の間では顕著です。

素晴らしいことに、ハードウェアがコモディティー化したことや、仮想化、そしてクラウド・コンピューティングのおかげで、適切なパターンとプラクティスがプロジェクトで使用されていれば、リソースをめぐる競争を大幅に少なくすることができます。そのような適切なパターンの 1 つが「一時環境 (transient environment)」です。一時環境とは、その役割を終えるとすぐに破棄される、短い間だけ存続する環境のことです。明確にしておきますが、一時環境によって希少性が消えてなくなることは決してありません。しかし、一時環境は無限のキャパシティーがあるという錯覚をもたらします。一時環境のパターンを適用すると、それが錯覚であることすら忘れてくるでしょう。

このようなタイプの環境は、transient という言葉以外にも ephemeral、temporal、temporary、disposable などの言葉で形容されることもあります。いずれの呼び方をするにしても基本的には同じことを意味しており、「非本番環境は必要最小限の期間だけ存続させる」ということを表しています。最近、私の会社では非本番環境を 72 時間を超えて存続させないように推奨しています。72 時間というのは、上限です。

動機

ソフトウェアの開発でとりわけ難しい問題の 1 つが発生するのは、チームがインスタンスを固定して、誰もそのインスタンスを変更できなくなった場合です。この問題はよく、環境を構成するのに何日も、何週間も、あるいは何ヶ月もかかったことが原因で起こります。これがアンチパターンである理由は、誰一人として環境の作成をスクリプト化するために時間を費やしていないからです。その結果、環境のリソースが不足し、リソースの獲得競争が激しくなります。環境のリース・ポリシーが存在するとしても、多くの場合は無視されるか、あるいはリース期限が繰り返し延長されます。

環境とは何か?

環境とは単なるマシン (物理マシン、あるいは仮想マシン) の別称ではありません。環境とはシステム・リソースの集合であり、これらのリソースには、インスタンス (物理インスタンス、仮想インスタンス、またはマシン抽象化)、ネットワーク構成、(インスタンスごとの) ソフトウェア・サーバーと構成、そして論理ユニットとして扱われるその他のリソースが含まれます (ただし、これらに限定されるものではありません)。環境をテンプレートやその他の構成に基づいてインスタンス化する場合もあります。

私がこれまで目にしたプロジェクトのほとんどには、環境のリース・ポリシーがありませんでした。あるいはリース・ポリシーがあるとしても、非常に大まかに定義されていて、大抵は違反されていました。リース・ポリシーが存在する場合でも、作成された後の環境には、手作業でツールや、データ、構成などをインストールしなければなりません。この手作業でのインストール作業によって、あらゆる環境がそれぞれに特有のものになるため、結果的に環境の管理がさらに困難なものになります。というのも、大規模なエンタープライズ・プロジェクトでは、何百もの環境がプロビジョニングされる場合もあるからです。このような事態になると、単純な方法では環境のベースラインに戻ることはできません。さらに、そのベースラインの状態に戻す方法がわかるチーム・メンバーもいません。そのため、チーム・メンバーはこれらの環境を破棄するのをためらうだけでなく、変更することさえも嫌がるようになります。このアンチパターンにより、環境の作成および破棄のコストが法外に高いものになってしまいます。


特徴

一時環境では、本番環境を除くすべての環境が一時的にしか存続しません (ただし、本番環境を一時環境にする有効な方法もあります)。プロジェクトによって異なりますが、経験則として、一時環境は一連の自動化された予備的なテストをひと通り実行するのに十分な時間だけ存続します。一時環境で重要な前提条件となるのは、これらの環境をスクリプト化してテストし、バージョン管理することです。それには、「アジャイル DevOps: インフラストラクチャーの自動化」で説明しているインフラストラクチャー自動化ツールを使用するのが理想的です。

一時環境の重要な特徴は以下のとおりです。

  • スクリプト化された環境: 一時環境は完全にスクリプト化されてバージョン管理され、テストされます。
  • セルフサービス環境: チームで許可されたすべてのメンバーが、新しい環境を立ち上げることができます。
  • 自動破棄: 一時環境は、チームのポリシーに従って自動的に破棄されます。チーム・メンバーは、ポリシーを無効にすることはできません。

環境を完全にスクリプト化すれば、許可されたチーム・メンバーがその環境をセルフサービス方式で取得できるようにすることが可能です。単純にオンデマンドで環境の立ち上げと破棄ができる自由には、責任が伴います。この責任を果たせるように、環境の破棄ポリシーが定義され、これらのポリシーが環境を定期的に破棄する自動プロセスを介して施行されます (テスト駆動型インフラストラクチャーとバージョン管理については、連載の今後の記事で取り上げる予定です)。


利点

参加してください

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

プロジェクトで一時環境のポリシーを定義し、これらのポリシーの実装を自動化することによって実現できることはいくつもあります。具体的には、それぞれが異なる特有の環境の増殖を抑えること、セルフサービス・デプロイメントをサポートすること、環境インスタンス化の自動化を促進すること、コモディティーとしての環境様式に移行すること、テストの分離を可能にすること、そして環境固有の問題のトラブルシューティングを大幅に減らすことなどです。以下に、一時環境を利用する主な利点を記載します。

  • 環境依存性の軽減: チームが自由に環境の立ち上げと破棄をできるようにして、ある特定の環境に対するチームの依存性を軽減します。
  • リソースの有効利用: 使用されなくなった環境を破棄することで、キャパシティーを他の用途に使用できるように解放します。
  • 知識の継承: チーム・メンバーが、使用している環境が特定の時点で破棄されるとわかっている場合、その環境を構成する方法を体系的に伝えるには、自動化が唯一のソリューションになります。

一時環境の仕組み

一時環境が優れている点は、環境を完全にスクリプト化してバージョン管理し、テストするようにしてしまえば、比較的簡単に実装できるパターンであることです。実装する時点で行う主要なタスクには、以下の 3 つがあります。

  • チーム・ポリシーの作成: チーム・メンバーと協力して、プロジェクトの要件を基にチーム・ポリシーを決定します。一時環境の存続期間は、まずは積極的に短くして、通常は約 72 時間に設定することをお勧めします。
  • 環境破棄の自動化: チームのリース・ポリシーの規定を超えるすべての環境を破棄するスクリプトを作成します。
  • 環境破棄のスケジューリング: 定期的に環境破棄スクリプトを実行するプロセスをスケジューリングします。

チーム・ポリシーは、必要なすべてのテストを実行するのに必要な時間に基づいて決定してください。

環境の破棄をスケジューリングするには、まず、cron や (Java を使用している場合は) Quartz (「参考文献」を参照) などのスケジューラーを使用してみることができます。また、継続的インテグレーション・サーバーが提供するスケジューラーを使用して、毎日決められた時刻にジョブを実行することもできます。以下に、毎日午前 2 時 15 分にスクリプトを実行する単純な cron 式の例を記載します。

0 15 02 * * /usr/bin/delete_envs.sh

次の例では、AWS (Amazon Web Services) CloudFormation に用意されているコマンドライン・インターフェースを使用して、CloudFormation スタックで定義された環境を破棄します。

/opt/aws/apitools/cfn/bin/cfn-delete-stack --access-key-id $AWS_ACCESS_KEY \
--secret-key $AWS_SECRET_ACCESS_KEY --stack-name $current_stack_name --force

このようなスクリプトは、環境カタログをループ処理して、関連するすべてのリソースを破棄するように拡張することができます。

積極的なチーム・ポリシーを定義し、プロセスをスケジューリングし、環境の破棄を自動化することで、チームは先を見越してリソースを管理し、プロジェクトで利用している環境が何週間も、何ヶ月も存続する可能性を減らすことができます。

トラブルシューティング

ほとんどのプロジェクトで、トラブルシューティングが通常どのように行われているのかを考えてみてください。私の経験から言うと、何が誰によってどういう理由で変更されたのかを突き止めるのは、長くて辛い作業です。大抵は、複数の関係者が問題を調査して、適切な改善措置を決定します。問題が再発することは珍しくありません。それは、それぞれの環境が特有であり、そのような環境が数週間や数ヶ月にわたって実行されるなかで、その環境に特有の修正が加えられるためです。

一方、スクリプト化されてバージョン管理され、テストされた環境に基づく一時環境ポリシーでは、環境を既知の状態にすることになります。それには、新しい環境を立ち上げて変更を適用し、その効果を判断します。その上で、自動化されたテストとスクリプトを作成して、変更をバージョン管理します。効果的な変更管理が行われていれば、無数のユーザーによって変更された動的環境で何が変更されたのかを判断するために何時間も何日も無駄にすることなく、いつでも既知の状態に戻して変更を行うことができます。これこそが、標準的な環境を使用する本質です。


一時的な利用

この記事では、アジャイル DevOps 環境の存続期間は必要最低限にされ、その長さは数時間、あるいは長くても数日であることを説明しました。ポリシーを定義して環境の自動破棄をスケジューリングすることで、限られた数の特有の環境に対する依存性が軽減され、リソースが有効利用され、自動化が促進されます。それにより、オンデマンドで環境の立ち上げと破棄ができるようになります。

連載「アジャイル DevOps」の次回の記事では、定期的に失敗する環境の作成について説明します。逆説的ですが、その目的は障害を防ぐためです。記事の説明では、Chaos Monkey を取り上げます。Netflix の技術チームが開発したこのツールは、障害が発生しても確実にシステムが稼働し続けるようにするために、Netflix の本番環境のインフラストラクチャーで意図的かつ無作為に、ただし一定の間隔でインスタンスを破棄します。

参考文献

学ぶために

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

  • Quartz: Quartz はオープンソースのジョブ・スケジューリング・サービスです。
  • 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, Cloud computing, Java technology
ArticleID=844126
ArticleTitle=アジャイル DevOps: 一時環境
publish-date=11082012