皆様こんにちは、VMware の町田と申します。 今回は、8月末に米国サンフランシスコで開催されたVMworld 2014にて発表された数あるトピックより、日本でも注目が高まってきている DevOps に関連するセッションの内容を取り上げながら、VMware のクラウド管理ソリューションを Dev(開発)とOps(運用)の協調という視点から前編・後編の二回に分けてご紹介します。
はじめに
VMworld 2014 では、多くのエンタープライズ環境がソフトウェアデリバリプロセスにおいて抱える 「安定かつ継続した、ビジネスのスピードにあわせた俊敏なリリース」「コスト削減」「変更への柔軟な対応」などの課題に対して、VMware のクラウド管理ソリューションの導入がもたらす価値について、特に DevOps の視点から複数のセッションが提供されました：
- MGT3210-S (Management Product Overview and Glimpse into the Future)
- OPT2668 (DevOps Demystified! Proven Architectures to Support DevOps Initiatives)
この中で筆者が特に注目する内容としては、MGT3210-S セッション内で [Tech Preview] として紹介された「Continuous Delivery for DevOps」 があります。こちらについては、本記事の[後編]でご紹介します。
※ 補足： 最新情報
～～～
VMworld 2014 EUROPE の開催に合わせて、日本でも2014年10月15日（日本時間）付けでクラウド管理プラットフォームの最新版「VMware vRealize Suite 6」を含む、新たなクラウド管理製品群と機能群を発表しました。この中で、DevOps における継続的デリバリーを実現する「VMware vRealize Code Stream」という製品も発表されています。この製品が、VMworld 2014 US で[Tech Preview]として紹介された Continuous Delivery for DevOps の正式名称となります。
～～～
また、その他で DevOps と関連するものとしては、以下に挙げるセッションがありました。
- HBC2371 (HBC2371 – Stick a Knife in IT! Chef + vCloud Hybrid Service = A Well Done Cloud)
- MGT2650 (Streamline Infrastructure Management with VMware and Puppet)
- MGT3095 (vCloud Automation Center and Pivotal Cloud Foundry – Better PaaS Solution)
- SDDC3281 (A DevOps Story: Unlocking the Power of Docker with the VMware platform and its ecosystem)
- SDDC3350 (VMware and Docker – Better Together)
vCloud Air 環境での”Infrastructure as Code” の実現や、VMware vCloud Automation Center (vCAC)と Puppet の連携、vCAC と PaaS (Pivotal CF) の連携、今ホットな Docker といった、さまざまなテーマで DevOps と絡めた話題が出ていました。
余談
いきなり話が逸れますが、企業が 大変な労力とコストをかけてアプリケーションを開発/テストして、さらなる労力をかけてリリースして運用、保守しているのは、（当然のことですが）ビジネスの価値を高めるためであり、それらは間接的にはアプリケーションを使うことによる業務効率の向上であったり、直接的には売上の増加であったりします。ITシステムに対する要求管理は、今も昔もアプリケーション開発における最も難しいテーマの一つです。
ところで、皆様の組織では、 アプリケーションに対するたった一行のソースコードの変更を本番環境に反映させる（リリースする）までに、どれぐらい時間がかかるでしょうか？また、そのプロセスは安定かつ繰り返し可能なものでしょうか？
サイクルタイム
この問いは、リーンソフトウェア開発有名なポッペンディーク夫妻の書籍で投げかけられているものです。
“How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis? “
(Mary Poppendieck; Tom Poppendieck, “Implementing Lean Software Development, Addison-Wesley Professional, 2006”)
ITシステムがビジネスの要求に対していかに「俊敏」に対応できているか常に振り返るためのきっかけとして、非常に示唆に富んでいます。ITによるビジネスの俊敏性向上とは、サイクルタイムをいかに短く、かつ安定したもにできるかにかかっていると言えるからです。「ビジネス」と言ってしまうと新規アプリケーション開発をイメージして、Ops(運用)の方々にはあまり関係のない話に思われるかもしれませんが、ここでの「変更」とは、リリース後の機能追加や、バグの緊急修正及びリリースなど、システムを利用する多くの利害関係者からの、継続的な要求への対応を含んでいます。
より技術的な観点からは、「継続的デリバリ」のバイブルである書籍の著者であるジェズ・ハンブル氏らが書いている言葉が心に響きます。
“Release your software at the push of a button.”
(Jez Humble; David Farley, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”, Addison-Wesley Professional, 2010”)
ソフトウェアのリリースは、（究極的には）ボタンを一回押すだけで完了できてしかるべきもの、ということでしょうか。
変えないで済む、そして大きな成果を生む
脱線ついでに、もう一つ余談を。
ハイパーバイザーが実現する仮想化には、1つの美学があると思っています。それは
- OSより上で動作するものや、それに関連するものに対して、これまでとまったく変わっていないという幻想を与える
ことです。Docker などのコンテナ技術が注目を集めている今では時に過小評価されるかもしれませんが、新しい技術を組織に導入して浸透させていく際には極めて重要な性質です。変わっていないということは、大部分において、これまでのやり方をそのまま踏襲できるということです。ITの世界ではとにかく目新しく、革新的な（に見える）技術が目を引きがちですが、VMware はそういった中長期的な将来のIT基盤のあり方を変えるようなテクノロジーにも注視する一方で、物理環境から仮想化基盤、そしてその上で従来のアーキテクチャに基づいて作成されたアプリケーションを展開して運用しているような環境から、漸進的にSDDC、そしてハイブリッドクラウド環境へと移行していけるようなソリューションに力を注いでいます。
IT業界で話題になるテクノロジや手法は、 エンジニアを多く抱えたWeb系の最先端IT企業が中心になって推進しているケースが多く、エンタープライズのITでそのまま導入しようとした場合にまったく新しいやり方や、高度な技術的スキルが要求されることも多いです。やり方が新しければ新しいほど、組織構造や業態、技術者のスキルセットと照らし合わせた場合に、採用のための障壁が高くなります。
これから構築していく新しいアプリケーションに対しては、新しいやり方を試すのはそれほど難しくないかもしれません。
では、すでに構築して運用・保守しているアプリケーションのライフサイクルを、これからどうやって管理していけばよいでしょうか？今やモバイル・クラウド時代に突入し、ビッグデータやサービス指向のアーキテクチャも Web サービスの普及とともに広がってきています。
アプリケーション開発チーム
アジャイルソフトウェア開発宣言が公開されたのは2001年のことですが、それから13年、欧米ではすっかり主流の開発手法となっています。
VMworld 2014 のセッションでも、Facebook、LinkedIn などの先端的な Web 系企業では1日に10、100、もしくはそれ以上の回数アプリケーションをデプロイしているような例も語られていました（これは極端な例かもしれませんが）。
アジャイル開発の考え方の最大の特徴の一つは、要求管理の方法にあります。アジャイルは「変化に対応する」ための開発方法とも言えますが、それはひとえに「要件に優先順位をつけて、必要な時に必要なものをジャスト・イン・タイムで計画して作る」「最初に想定していても、必要ないとわかった時点で作らない」点にあります。つまり、ウォーターフォールのようにプロジェクトの最初期で時間をかけて「計画」された要件に縛られるようなことはありません。
アジャイル開発では、従来からの「スコープ」「コスト」「スケジュール」というソフトウェア開発における「鉄の三角形」に代わり、「（リリースされるソフトウェアによって実現される）価値」「品質」を変動できないものとしてとらえ、プロジェクトの制約となる要素のうち「スコープ」を調整することで、変化に対応しながらも安定かつ継続したリリースを実現します。
ここで、頻繁にリリースされるソフトウェアの品質を支えるのが、ソースコードのバージョン管理、テスト駆動開発(TDD)及びテスト自動化、継続的統合(CI)といった、ツールを活用した自動化及び各種のプラクティスとなります。
ただし、仮にアジャイル開発を採用し、うまく現場でまわすことができていたとしても、それだけでは開発チームの悩みは尽きることはないでしょう。
従来からのクライアント-サーバ、あるいはWeb 3階層モデルなどに従ってアプリケーションを設計した場合、デプロイ可能な成果物が完成した後のリリース作業はコストのかかる、骨の折れる作業であることには変わりありません。この要因としては、多くの人員や手作業が必要なケースが多いことや、構成管理が大変なこと、インフラの準備のための時間と工数、また（特にエンタープライズでは通常だと思いますが）「開発チーム」と「運用チーム」をはじめとする複数の組織が関わっていることなどが挙げられます。リリース対象の環境自体も、オンプレの物理環境から仮想化基盤、プライベートクラウド、パブリッククラウドといったように様々な選択肢を検討する必要がでてきており、複雑さとそれに伴うコストは増す一方です。特に、インフラのことについては開発チームだけではなかな手も足もでません。
そのため、AWS などのパブリック IaaS を（シャドーITとしてIT部門を通さずに）利用したり、また最近では PaaS （例えば Pivotal CF など）の検討や、Docker のようなコンテナ技術を活用した新しいアプリケーションの構築、パッケージ化、配布、実行のモデルに注目するケースが増えてきているのでしょう。
これらの根底には、常にアプリケーションリリースのサイクルタイムへの意識があります。
インフラ運用チーム
ここ数年来、仮想化技術が広く普及したこともあり、物理サーバを仮想化基盤に統合してコストを削減するという考え方は、ごく普通のことになりました。VMware では、（VMware の考える） エンタープライズのIT基盤及び組織が進むべき道として、最近では次のようなスライドを使って説明しています。
Ops (運用)の視点から見た場合、例えばエンドユーザのPC利用環境（仮想ワークスペースも含む）の整備などは、アプリケーション開発が絡まない、ITを活用したビジネス生産性向上のための投資といえます。
アプリケーション開発ライフサイクルにおける開発チームの課題と最近の動向については先ほど触れましたが、そこで
特に、インフラのことについては開発チームだけではなかなか手も足もでません。
と書きました。SDDC、ネットワークの仮想化、ストレージの仮想化、ハイブリッドクラウド、クラウド運用管理・・・、インフラ管理者にとって新しい技術や概念が目白押しです。そのような中、競争の激しいビジネスからの要求に応えるため、一秒でも早いサイクルタイムの実現のため、多くの課題を抱えながらアプリケーション開発を続ける開発チームに対して、インフラ及びOps (運用)チームは今何が求められるでしょうか？
Dev と Ops を隔てる壁
特にエンタープライズではその傾向が強いと思いますが、システム開発のライフサイクルにおいては、一般にDev(開発) と Ops (運用) には高い壁があるケースが多いです。
次のスライドは、VMworld 2014 の複数のセッションで使われていたものです。
端的に言うと、両者の利害は一致していません。
開発チームはインフラやアプリケーションのリリースに対するスピードを求め、一方で運用チームはその職務上、安定した運用及びトラブルの予防のためにできるだけ変化がないこと、そして厳しく管理することを求めます。
開発チームはビルドしてデプロイ可能になった成果物を運用チームに渡します。開発チームが掌握できるローカルのテスト環境はまだしも、ユーザ受け入れテスト環境、負荷テスト環境、ステージング環境、そして本番環境・・。開発チームの手を離れてから、実際にアプリケーションが利用可能になるまでに、どれぐらいの時間がかかるでしょうか。アジャイル開発を導入している組織で、デプロイ可能な成果物は1週間に1回リリースできても、インフラ側で環境にデプロイして運用に持っていくまでのスピードが対応できないため、結局実際にアプリケーションが本番環境にリリースされるのは3ヶ月～半年に1回、という例もあるようです。
この壁は、もし存在するのであれば今後もずっと存在していてよいものでしょうか？
DevOps とは？
実は、この壁は先ほどご紹介したような1日に10、100、もしくはそれ以上の回数アプリケーションをデプロイするような環境の企業には存在していません。
Wikipedia によると、DevOps とは
DevOps（デブオプス）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する開発手法をさす。ただし2013年現時点では厳密な定義は存在しておらず、抽象的な概念に留まっている。
とあります。
物事を最適化する方法として、holistic approach (全体論的アプローチ) という言葉が使われることがありますが、アジャイル開発における「チーム」もこのようなアプローチであり、DevOps も開発と運用が連携して協調することで、これまで（誰もがうすうす感づいていながら）システム開発ライフサイクルにおいて非効率であった部分（特にサイクルの後半）に対応していこうとするものです。
ただ、注意点としてこのような取り組みは、ややもすると「組織論」に偏りがちです。体制を変えていく必要があるのは大前提なのですが、複雑さを増す一方のクラウド時代の今、手作業と人間によるコミュニケーションでの改善には限界があります。是非、ツールには適切に投資し、最大限活用することをご検討ください。これはベンダーの立場での都合の良い意見とも取れますが、ITが魔法のような速度で世の中やビジネスを変えているのはソフトウェアの力(とそれを支える強力なインフラ)であり、ツールは特定の目的を最適に実現することを目指して作られたソフトウェアです。
[今できること] SDDC と IaaS++
DevOps のような開発と運用が交わるような領域において、作業の協調、高度な自動化、ハイブリッドクラウド環境への対応、といった技術的にも複雑な取り組みを着実に推進していくためには、そのインフラとなるしっかりとした土台が欠かせません。その中で、VMware がご提供可能なものとしては、SDDC のビジョンを実現する VMware のクラウド運用管理製品を中心としたソリューションになります。
開発チームはこれまでも、開発・テスト環境の準備という観点で非常に苦労してきました。例えば開発者のPC環境のセットアップもその一つです。VMware Workstation などの仮想化製品を使って、PC上にテンプレートから展開した開発・テスト環境を用意するケースも多いと思います（最近では Vagrant がよく話題に上りますね）。
SDDC をベースとする強固な土台を導入していくことで、クラウド環境を使ってこれらの作業を支援し、さらなる効率化を進めることが可能です。
例：
- NSX によるネットワーク仮想化によって、テスト環境の仮想マシン群に対して隔離された論理(L2)ネットワークを個別に提供
- vSAN によるストレージ仮想化によって、ストレージのコスト及び管理工数を削減しつつ、必要に応じてリソースをスケールアウトできる、開発環境に最適なクラスタを構成
- vCAC のポータルを通して仮想マシンの提供を含む各種のサービスを統合していくことで、管理性を保ちながらも、必要なリソースがセルフサービスですぐに手に入る環境を開発者に対して提供
これらは一例ですが、開発、テストにおける作業効率の向上、そしてサイクルタイムの短縮につながります。
ここまでは、システム開発ライフサイクルにおける「ビルド」「テスト」といった主に開発チームの作業をインフラとして支援する範囲となりますが、DevOps という観点から見た、VMware ソリューションとしての 最初のターゲットは、アプリケーションのデプロイ作業の最適化です。
VMware では、仮想化基盤あるいは IaaS 上への仮想マシンのプロビジョニング及び構成に加えて、アプリケーションのデプロイ及び構成管理を含めた部分を簡素化及び自動化するためのソリューションをご提供しています（VMware ではこれを IaaS++ と表現することもあります）。
このソリューションは、以前は VMware vFabric Application Director という名称でしたが、vCAC の一部として統合され、さらに vCAC 6.1 では Application Services と名称が変わっています。
Application Services のクラウド管理製品としての特徴は、ｎ階層の構成を含むアプリケーションをGUIツールを使ってブループリントとしてモデル化し、同一のブループリントから AWS、vCloud、vCAC といった様々なクラウド環境に対してアプリケーションをデプロイできることです。これにより、開発環境、テスト環境、本番環境といった、要件によって異なる環境に同じ構成のアプリケーションを何度もデプロイしなければいけないケースで、一貫性を確保した、安定したデプロイ環境を構築することができます。このような要件は、今後は前提として検討しなければならなくなるでしょう。
アプリケーションのブループリントは、使用するOSの仮想マシンテンプレートを指定する「Logical Templates」、そのOS上で動作するDBなどのミドルウェアを指定する「Services」、そしてさらにミドルウェア上にデプロイされるアプリケーションを指定する「Application Components」などで構成されます。これらの要素は、GUIパレット上でドラッグ&ドロップして、要素を積み重ねることで関係を表現します。また、仮想マシンのプロビジョニングやアプリケーションのデプロイの順番は、依存関係を表すラインで要素間を結ぶことで表現します。
「Services」や「Application Components」などの要素は、ミドルウェアやアプリケーションを仮想マシン上にインストールして構成する動作を指定する、重要な役割を担っています。「Services」を例にとると、これらは「Apache v.2.2.0」「vFabric RabbitMQ v2.4.1」「MySQL v5.0.0」といった個々のミドルウェア毎に管理され、それぞれがApplication Services におけるアプリケーション展開のライフサイクル（INSTALL, CONFIGURE, START, UPDATE, ROLLBACK, TEARDOWN）において行うべき動作を、スクリプトとして記述しています。これらの要素は、スクリプト及び（デプロイ時にカスタマイズ可能な）プロパティからなるテンプレートに過ぎません。なお、このスクリプトですが、Windows では「Windows CMD」「PowerShell」「BeanShell」が、Linux では「Bash」及び「BeanShell」がサポートされています。
Application Services ではブループリントで定義された依存関係から個々の要素の実行順序が導き出され、仮想マシンのプロビジョニング後にそれぞれのスクリプトが順番に呼び出されることによってアプリケーションの展開が実行されていきます。
また、Application Services ではアプリケーション展開後にも、同一のインスタンスに対して一部の構成を変更した上での「Update」や、変更後にエラーが見つかった際の「Rollback」、アプリケーションの取り壊しを行う「TEARDOWN」、そして削除といったライフサイクル管理を行うことができます。
“Infrastructure as Code” を実現する Puppet や Chef などのツールを使ったことのある方なら、例えば次のような DSL 定義を思い浮かべられたかもしれません（これは Puppet のマニフェストの一例です）。
Application Services は、まさに同じようなことを、異なるアプローチで実現するツールといえます。
Application Services はクラウド環境における “Dev” と “Ops” の協調作業プラットフォーム
IaaS++ として Application Services についてご紹介してきましたが、DevOps という視点でまとめると、Application Services とは「クラウド環境における “Dev” と “Ops” の協調作業プラットフォーム」です。仮想化基盤やクラウドの管理者は環境毎の仮想マシンテンプレートやテナントを準備し、カタログ管理者はスクリプトの作成などで開発者、運用者と連携しながら「Services」や「Application Components」のカタログを管理し、アプリケーションアーキテクトはアプリケーションブループリントを作成します。各環境へのリリース段階では、デプロイヤがブループリントを利用し、環境毎のプロパティ値をカスタマイズした上でデプロイし、その後も連携しながらライフサイクルを管理する。このような、クラウドインフラを含めたアプリケーション展開の構成管理を、一つのツールを使って実現することができます。
なお、開発者とは「成果物」の管理を通して連携しています。例えば、開発チームが CI ツール (Jenkins) でビルドして作成するアプリケーションのモジュールを Application Services 側に登録して、ブループリントで指定された「Application Components」が実行時にそのモジュールをダウンロードしてインストールする、といった連携が実現できます。
Puppet Integration
Bash などのスクリプトを使うと聞いて、「うげっ」と思われた方もいるかと思います。時代は DSL ではないのか、宣言的な、あるべき状態の記述ではないのかと。ご安心下さい。Application Services では Puppet とのインテグレーションもサポートしています。これにより、アプリケーションの展開プロセス全体のオーケストレーションや仮想マシンのプロビジョニングは Application Services が行いますが、各仮想マシン上の構成は Puppet Master 及び Agent におまかせする、ということも可能です。vCAC 6.1 ではインテグレーションもさらに強化されています。
個人的には、Bash / PowerShell などの良く使われているツールを使うことができるもの、既存資産の有効活用や、今までと大きくやり方を変えないで済む点で、特にエンタープライズ環境ではメリットの一つだと考えます。
最後に
本記事が、これまで主にインフラの観点から VMware に触れていただいている方々が、DevOps という観点から VMware のクラウド運用管理製品や周辺技術に対して目を向けていただける一つのきっかけになりましたら、大変うれしく思います。
なお[後編]では、先日発表された新製品である VMware vRealize Code Stream を中心に、VMware が今後視野に入れている DevOps 関連のソリューションについて、VMworld 2014 でのセッション内容を交えてご紹介する予定です。
