Dev(開発)とOps(運用)の協調という視点から前編・後編の二回に分けてご紹介します。こちらについては、本記事の[後編]でご紹介します。6」を含む、新たなクラウド管理製品群と機能群を発表しました。Stream」という製品も発表されています。関連するものとしては、以下に挙げるセッションがありました。絡めた話題が出ていました。大変な労力とコストをかけてアプリケーションを開発/テストして、さらなる労力をかけてリリースして運用、保守しているのは、(当然のことですが)ビジネスの価値を高めるためであり、それらは間接的にはアプリケーションを使うことによる業務効率の向上であったり、直接的には売上の増加であったりします。ITシステムに対する要求管理は、今も昔もアプリケーション開発における最も難しいテーマの一つです。アプリケーションに対するたった一行のソースコードの変更を本番環境に反映させる(リリースする)までに、どれぐらい時間がかかるでしょうか?また、そのプロセスは安定かつ繰り返し可能なものでしょうか?サイクルタイムこの問いは、リーンソフトウェア開発有名なポッペンディーク夫妻の書籍で投げかけられているものです。2006”)ITシステムがビジネスの要求に対していかに「俊敏」に対応できているか常に振り返るためのきっかけとして、非常に示唆に富んでいます。ITによるビジネスの俊敏性向上とは、サイクルタイムをいかに短く、かつ安定したもにできるかにかかっていると言えるからです。「ビジネス」と言ってしまうと新規アプリケーション開発をイメージして、Ops(運用)の方々にはあまり関係のない話に思われるかもしれませんが、ここでの「変更」とは、リリース後の機能追加や、バグの緊急修正及びリリースなど、システムを利用する多くの利害関係者からの、継続的な要求への対応を含んでいます。技術的な観点からは、「継続的デリバリ」のバイブルである書籍の著者であるジェズ・ハンブル氏らが書いている言葉が心に響きます。2010”)ソフトウェアのリリースは、(究極的には)ボタンを一回押すだけで完了できてしかるべきもの、ということでしょうか。変えないで済む、そして大きな成果を生む脱線ついでに、もう一つ余談を。ハイパーバイザーが実現する仮想化には、1つの美学があると思っています。それはOSより上で動作するものや、それに関連するものに対して、これまでとまったく変わっていないという幻想を与えることです。コンテナ技術が注目を集めている今では時に過小評価されるかもしれませんが、新しい技術を組織に導入して浸透させていく際には極めて重要な性質です。変わっていないということは、大部分において、これまでのやり方をそのまま踏襲できるということです。いった中長期的な将来のIT基盤のあり方を変えるようなテクノロジーにも注視する一方で、物理環境から仮想化基盤、そしてその上で従来のアーキテクチャに基づいて作成されたアプリケーションを展開して運用しているような環境から、漸進的にSDDC、そしてハイブリッドクラウド環境へと移行していけるようなソリューションに力を注いでいます。エンジニアを多く抱えたWeb系の最先端IT企業が中心になって推進しているケースが多く、エンタープライズのITでそのまま導入しようとした場合にまったく新しいやり方や、高度な技術的スキルが要求されることも多いです。やり方が新しければ新しいほど、組織構造や業態、技術者のスキルセットと照らし合わせた場合に、採用のための障壁が高くなります。これから構築していく新しいアプリケーションに対しては、新しいやり方を試すのはそれほど難しくないかもしれません。サービスの普及とともに広がってきています。アプリケーション開発チームアジャイルソフトウェア開発宣言が公開されたのは2001年のことですが、それから13年、欧米ではすっかり主流の開発手法となっています。系企業では1日に10、100、もしくはそれ以上の回数アプリケーションをデプロイしているような例も語られていました(これは極端な例かもしれませんが)。アジャイル開発の考え方の最大の特徴の一つは、要求管理の方法にあります。アジャイルは「変化に対応する」ための開発方法とも言えますが、それはひとえに「要件に優先順位をつけて、必要な時に必要なものをジャスト・イン・タイムで計画して作る」「最初に想定していても、必要ないとわかった時点で作らない」点にあります。ウォーターフォールのようにプロジェクトの最初期で時間をかけて「計画」された要件に縛られるようなことはありません。アジャイル開発では、従来からの「スコープ」「コスト」「スケジュール」というソフトウェア開発における「鉄の三角形」に代わり、「(リリースされるソフトウェアによって実現される)価値」「品質」を変動できないものとしてとらえ、プロジェクトの制約となる要素のうち「スコープ」を調整することで、変化に対応しながらも安定かつ継続したリリースを実現します。(CI)といった、ツールを活用した自動化及び各種のプラクティスとなります。仮にアジャイル開発を採用し、うまく現場でまわすことができていたとしても、それだけでは開発チームの悩みは尽きることはないでしょう。3階層モデルなどに従ってアプリケーションを設計した場合、デプロイ可能な成果物が完成した後のリリース作業はコストのかかる、骨の折れる作業であることには変わりありません。この要因としては、多くの人員や手作業が必要なケースが多いことや、構成管理が大変なこと、インフラの準備のための時間と工数、また(特にエンタープライズでは通常だと思いますが)「開発チーム」と「運用チーム」をはじめとする複数の組織が関わっていることなどが挙げられます。リリース対象の環境自体も、オンプレの物理環境から仮想化基盤、プライベートクラウド、パブリッククラウドといったように様々な選択肢を検討する必要がでてきており、複雑さとそれに伴うコストは増す一方です。インフラのことについては開発チームだけではなかな手も足もでません。ようなコンテナ技術を活用した新しいアプリケーションの構築、パッケージ化、配布、実行のモデルに注目するケースが増えてきているのでしょう。これらの根底には、常にアプリケーションリリースのサイクルタイムへの意識があります。広く普及したこともあり、物理サーバを仮想化基盤に統合してコストを削減するという考え方は、ごく普通のことになりました。エンタープライズのIT基盤及び組織が進むべき道として、最近では次のようなスライドを使って説明しています。(運用)の視点から見た場合、例えばエンドユーザのPC利用環境(仮想ワークスペースも含む)の整備などは、アプリケーション開発が絡まない、ITを活用したビジネス生産性向上のための投資といえます。アプリケーション開発ライフサイクルにおける開発チームの課題と最近の動向については先ほど触れましたが、そこで特に、インフラのことについては開発チームだけではなかなか手も足もでません。SDDC、ネットワークの仮想化、ストレージの仮想化、ハイブリッドクラウド、クラウド運用管理・・・、インフラ管理者にとって新しい技術や概念が目白押しです。高い壁があるケースが多いです。複数のセッションで使われていたものです。端的に言うと、両者の利害は一致していません。開発チームはインフラやアプリケーションのリリースに対するスピードを求め、一方で運用チームはその職務上、安定した運用及びトラブルの予防のためにできるだけ変化がないこと、そして厳しく管理することを求めます。開発チームはビルドしてデプロイ可能になった成果物を運用チームに渡します。チームの手を離れてから、実際にアプリケーションが利用可能になるまでに、どれぐらいの時間がかかるでしょうか。アジャイル開発を導入している組織で、デプロイ可能な成果物は1週間に1回リリースできても、インフラ側で環境にデプロイして運用に持っていくまでのスピードが対応できないため、結局実際にアプリケーションが本番環境にリリースされるのは3ヶ月~半年に1回、という例もあるようです。?実は、この壁は先ほどご紹介したような1日に10、100、もしくはそれ以上の回数アプリケーションをデプロイするような環境の企業には存在していません。DevOps(デブオプス)は、ソフトウェア開発手法の一つ。組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する開発手法をさす。2013年現時点では厳密な定義は存在しておらず、抽象的な概念に留まっている。開発と運用が連携して協調することで、これまで(誰もがうすうす感づいていながら)システム開発ライフサイクルにおいて非効率であった部分(特にサイクルの後半)に対応していこうとするものです。注意点としてこのような取り組みは、ややもすると「組織論」に偏りがちです。体制を変えていく必要があるのは大前提なのですが、複雑さを増す一方のクラウド時代の今、手作業と人間によるコミュニケーションでの改善には限界があります。ツールには適切に投資し、最大限活用することをご検討ください。これはベンダーの立場での都合の良い意見とも取れますが、ITが魔法のような速度で世の中やビジネスを変えているのはソフトウェアの力(とそれを支える強力なインフラ)であり、ツールは特定の目的を最適に実現することを目指して作られたソフトウェアです。ような開発と運用が交わるような領域において、作業の協調、高度な自動化、ハイブリッドクラウド環境への対応、といった技術的にも複雑な取り組みを着実に推進していくためには、そのインフラとなるしっかりとした土台が欠かせません。クラウド運用管理製品を中心としたソリューションになります。開発チームはこれまでも、開発・テスト環境の準備という観点で非常に苦労してきました。開発者のPC環境のセットアップもその一つです。ベースとする強固な土台を導入していくことで、クラウド環境を使ってこれらの作業を支援し、さらなる効率化を進めることが可能です。ポータルを通して仮想マシンの提供を含む各種のサービスを統合していくことで、管理性を保ちながらも、必要なリソースがセルフサービスですぐに手に入る環境を開発者に対して提供これらは一例ですが、開発、テストにおける作業効率の向上、そしてサイクルタイムの短縮につながります。最初のターゲットは、アプリケーションのデプロイ作業の最適化です。表現することもあります)。名称が変わっています。いった様々なクラウド環境に対してアプリケーションをデプロイできることです。これにより、開発環境、テスト環境、本番環境といった、要件によって異なる環境に同じ構成のアプリケーションを何度もデプロイしなければいけないケースで、一貫性を確保した、安定したデプロイ環境を構築することができます。このような要件は、今後は前提として検討しなければならなくなるでしょう。Components」などで構成されます。これらの要素は、GUIパレット上でドラッグ&ドロップして、要素を積み重ねることで関係を表現します。仮想マシンのプロビジョニングやアプリケーションのデプロイの順番は、依存関係を表すラインで要素間を結ぶことで表現します。Components」などの要素は、ミドルウェアやアプリケーションを仮想マシン上にインストールして構成する動作を指定する、重要な役割を担っています。TEARDOWN)において行うべき動作を、スクリプトとして記述しています。これらの要素は、スクリプト及び(デプロイ時にカスタマイズ可能な)プロパティからなるテンプレートに過ぎません。「Bash」及び「BeanShell」がサポートされています。ブループリントで定義された依存関係から個々の要素の実行順序が導き出され、仮想マシンのプロビジョニング後にそれぞれのスクリプトが順番に呼び出されることによってアプリケーションの展開が実行されていきます。アプリケーション展開後にも、同一のインスタンスに対して一部の構成を変更した上での「Update」や、変更後にエラーが見つかった際の「Rollback」、アプリケーションの取り壊しを行う「TEARDOWN」、そして削除といったライフサイクル管理を行うことができます。マニフェストの一例です)。同じようなことを、異なるアプローチで実現するツールといえます。協調作業プラットフォーム」です。Components」のカタログを管理し、アプリケーションアーキテクトはアプリケーションブループリントを作成します。各環境へのリリース段階では、デプロイヤがブループリントを利用し、環境毎のプロパティ値をカスタマイズした上でデプロイし、その後も連携しながらライフサイクルを管理する。このような、クラウドインフラを含めたアプリケーション展開の構成管理を、一つのツールを使って実現することができます。開発者とは「成果物」の管理を通して連携しています。Components」が実行時にそのモジュールをダウンロードしてインストールする、といった連携が実現できます。スクリプトを使うと聞いて、「うげっ」と思われた方もいるかと思います。ないのか、宣言的な、あるべき状態の記述ではないのかと。インテグレーションもサポートしています。おまかせする、ということも可能です。インテグレーションもさらに強化されています。良く使われているツールを使うことができるもの、既存資産の有効活用や、今までと大きくやり方を変えないで済む点で、特にエンタープライズ環境ではメリットの一つだと考えます。クラウド運用管理製品や周辺技術に対して目を向けていただける一つのきっかけになりましたら、大変うれしく思います。セッション内容を交えてご紹介する予定です。Blogsコメントは停止中です。