IT部門がミドルウェアのことを考える時代は終わった

サーバー仮想化だけではクラウドへの道は開けない

――IT部門がインフラとミドルウェアを組み合わせる自由度は「権利からコストに変わった」との考えの下、ミドルウェア以下のレイヤーを専門機能に特化したアプライアンスとして提供することで、ユーザー企業がよりビジネスに近い領域に注力できる環境を整えていくというIBMとしての方針を第1回のインタビューでは伺いました。その端的な例が、先日発表された「Workload Deployer」だと思います。まずは、その概要についてご説明下さい。

　製品名からお気付きになる方もいらっしゃるかもしれませんが、先日発表したIBM Workload Deployerには、末尾に「V3.0」というバージョン番号が付いています。実は同製品は、2009年から「IBM WebSphere CloudBurst Appliance」という名称で提供されてきましたが、今回のバージョン3.0からは「IBM Workload Deployer」に名前を変えて出荷することになりました。

　IBM Workload Deployerは、WebSphere CloudBurst Applianceの機能に加えて、システムインフラを意識することなく、WebアプリケーションやDBアプリケーションといったアプリケーションの種別を意味する「ワークロード」の単位で、仮想化環境上にクラウドを実現するアプライアンス製品です。

　よく誤解があるのですが、IBM Workload Deployerはあくまで仮想化環境上にクラウドを実現する為のエンジンですので、このアプライアンス上でアプリケーションが稼働したり、エンドユーザーからのリクエストがアプライアンス上を行き来したりすることはありません。あくまでアプリケーションが稼働するシステムの実体は、IBM Workload Deployerの配置先となる仮想化環境上のクラウドとなります。

　IBM Workload Deployerは、仮想化環境上の各種システムリソース、例えば、メモリー、CPU、ネットワーク、ディスク、そしてミドルウェアをも共有化し、真のプライベート・クラウドを実現できる製品と言い換えてもいいかもしれません。製品名を変更した理由はいろいろあるのですが、プライベート・クラウドを実現するための製品なのですから、IBMの中の一つのミドルウェアのブランド名である「WebSphere」はもう製品名に冠する必要はないだろうという判断があったこともあります。

　アプライアンスの筺体の色も、WebSphereのブランド・カラーである紫から黒に変更したのも、同様の理由です。IBM Workload Deployerは完全に新しい製品として登場したのではなく、従来製品の豊富な実績と機能を踏まえ、新たにワークロードによる配置という改良を加えたバージョンアップというふうに理解いただければと思います。

――なるほど。では、今回プライベート・クラウドを実現するための新製品を新たにリリースした背景について、もう少し詳しく教えていただければと思います。IBM Workload Deployerは、具体的にはどのようなビジネスニーズに応えるのでしょうか？

　昨今、情報システムにおける効率的なリソース活用の仕組みとして、仮想化やクラウドが注目されています。これらは、システム環境を調達するために必要な期間の短縮、負荷に応じた柔軟なリソースの拡張・収縮、それに伴うコスト削減などの文脈で見れば、これまでのITインフラにおける設計、構築、運用の常識を覆すほどの大きなインパクトがある技術です。

　実際に仮想化やクラウドを導入・運用する形態としては、サービスプロバイダーが提供するパブリック・クラウドのサービスを利用するケースもあれば、自社のインフラを仮想化したり、プライベート・クラウドを構築したりといったケースもあるでしょう。いずれにせよ、既に仮想化・クラウドにかかわる取り組みをされている企業は少なくないと思います。

　しかし、インフラ調達期間の短縮や、柔軟なリソース拡張・収縮といったクラウドの恩恵にあずかるためには、単純に自社のサーバーを仮想化するだけでは不十分です。そのことは、既にサーバーの仮想化を進められている方であれば、よくご存じだと思います。IBMでは、クラウドのインフラが備えるべき要素、言い換えればクラウドとしてのメリットを提供するために必要な要素を3つ定義しています。

　それが「仮想化」「標準化」「自動化」です。1つ目の仮想化に関しては、物理的なハードウェアからシステムリソースを分離して管理できるメリットを、既に多くの方が理解されているかと思います。ただ、仮想化だけで終わってしまうと、クラウドのメリットを十分に享受するのは現実的には難しく、そのために「標準化」と「自動化」が必要になってくるのです。

――確かに近年では、単純にサーバーを仮想化しただけでは、システム構築および運用効率が劇的に向上するわけではないということが広く認識されてきました。

　そうですね。企業システムの場合、たとえ小規模であっても複数のサーバーから構成されることがほとんどでしょう。そして、アプリケーションは、データベース、メッセージング・サービス、ディレクトリー・サービス、非同期メッセージング・サービスなどのミドルウェアが提供する複数種類のAPIを使用して開発されます。

　つまり複数のサーバーとミドルウェアが連携して、はじめて企業システムにおけるアプリケーションを実現できるのです。こうした環境をプライベート・クラウドで実現するとなると、単純なサーバーの仮想化だけでは無理で、複数の仮想マシン群におけるミドルウェア特有の設計を考慮し、クラウド環境をデザインする必要が出てきます。

　多くの企業システムの開発および構築プロジェクトでは、通常、共通IT基盤設計・構築と称されるタスクがあり、この中で複数サーバーのトポロジーや、各種ミドルウェアの設定に関する標準化を行っています。単純にサーバーを仮想化しているだけでは、結局、このタスクが必要になるのです。クラウド化はコスト削減をメリットの一つとして考えている中で、結局ミドルウェアの設計、構築の人件費が必要になるのでは、あまりコスト削減のメリットは現れてこないのです。

 

　それ以外にも、数十ギガバイトにもなる巨大な仮想イメージに対するパッチの適用やモジュールの追加・削除といった仮想イメージのフルライフサイクルの視点での管理方法や、仮想イメージを自動的に活性化させる為のスクリプトとの連携の仕組みなど単なるサーバーの仮想化では対応できない問題を解決する必要があります。

　こうした課題を解決し、仮想化、標準化、自動化の要素を取り入れたプライベート・クラウドを実現するための手段として、弊社ではIBM Workload Deployerの提供を開始しました。仮想化に加え、先ほど述べた標準化と自動化の機能をアプライアンスとして提供することで、迅速かつ容易にプライベート・クラウドを実現できるのです。

システムのパターン化とデプロイメントの自動化による環境構築

――ところで「標準化」と「自動化」とは、一体何を意味するものなのでしょうか？

　標準化とは、企業や組織の中で利用するシステム環境をパターン化し、システム・トポロジー、使用するミドルウェアのバージョン、パッチレベル、構成パラメーターなどを事前に取り決めておいた上で、そのパターンを再利用していくという考え方です。システム環境を構築する際に、いちいち初めから作り直すのではなく、あらかじめ用意されている標準パターンを再利用できれば、情報システム部門の日々の業務負荷を大きく減らせるはずです。

　また、標準化されたパターンができていれば、自動化の仕組みの上にも載せやすくなるので運用管理を効率化でき、かつ手動による作業のミスも防止できます。IBM Workload Deployerはこのように、標準化されたパターンを活用し、それに対して自動化の枠組みをはめていくことで、人的エラーのない、繰り返し作業に強いシステム構築を実現する製品なのです。

 

――標準化されたパターンとは、具体的にはIaaSにおける仮想マシンの導入イメージのことを指すのでしょうか？

　仮想イメージは、パターン化される要素のひとつにすぎません。IaaSでは、仮想マシンに割り当てるCPU、メモリー、ディスク、ネットワークといったシステムリソースやOSとして使用される仮想イメージを標準化しますが、その上に載るミドルウェアまでは考慮しません。

　よって、仮想マシンの配置後に、ミドルウェアのインストールとセットアップ、パッチ適用などをすべて手動で行う必要があります。IBMでは、あらかじめOSと自社のミドルウェア製品を組み合わせたOVF形式の製品を「ハイパーバイザー・エディション」として提供しており、これを使用すればミドルウェア環境がセットアップされた仮想マシンを簡単に作成することができます。

 

 

――IBM Workload Deployerは、どのような形でPaaSを実現するのでしょうか？

　IBM Workload Deployerが実現するPaaSは、OSだけでなくミドルウェアまで標準化できるので、IaaSに比べればより標準化の度合いが上がります。一方、アプリケーションの視点ではJava EEという広い自由度が確保されますから、SaaSと比較した場合、より多様なニーズにフィットするアプリケーションを柔軟に開発できます。ですから、企業システムにおいては、こうしたPaaSのニーズは高いと考えています。

　IBM Workload Deployerも持つ機能としては、「トポロジー・パターン」で実現されます。クラウドとして必要とする仮想マシンの数、そこで使用する仮想イメージのバージョンやパッチレベル、システムコンポーネントとしての役割(Webサーバー、アプリケーション・サーバー、DBサーバーなど)やそれらの依存関係、高可用性の為のクラスター構成の有無といったシステム構成に必要な要素をトポロジー・パターンとして定義します。そして、環境が必要になったら、そのパターンを呼び出して実行すれば良いわけです。

　定義したトポロジー・パターンの大きさに依存しますが、仮想マシンの作成、OSやミドルウェアの導入と構成を含め、アプリケーションが稼働できる状態にするのに、数十分というレベルの時間感覚で実現できるようになります。また、こうしたトポロジー・パターンを定義する作業は、ブラウザーでIBM Workload Deployerにアクセスし、GUI上でドラッグ＆ドロップの操作を行うだけで簡単に行うことができます。

 

 

――そのように、複数の仮想マシンを組み合わせたシステム環境を自動的に配置できるようになることで、ユーザーには具体的にどのようなメリットがあるのでしょうか？

　一番分かりやすい例は、開発業務でしょう。通常のアプリケーション開発プロジェクトでは開発環境、テスト環境、本番環境、検証環境と、多くの環境を使い分けますが、必要になる度に初めからこれらを構築していては、手間が掛かりすぎますし、人的ミスが発生する可能性もあります。かといってこれらの環境を、使わない間もずっと保持しておくのも、システムリソースの無駄使いになります。一般的にデータセンターにおけるサーバーの平均85%がアイドル状態であると言われているのは、このようなサーバーのCPU使用率が関係しているのでしょう。

　このようなケースにおいて、IBM Workload Deployerのような仕組みで、今まさに使いたいシステム環境のトポロジー・パターンを即座に呼び出して自動的に配置できるメリットは、非常に大きいといえます。また、トポロジー・パターン情報のみをIBM Workload Deployer内に残し、システムリソースを解放して停止するモードを提供しているので、古いテスト環境を一年後に復活させるといったことも簡単に実現できるのです。クラウドでは、システムはリムーバルなリソースであり、取り付けが自由自在なのです。

アプリケーションのタイプでパターン化

――では、ワークロード・パターンとはどのような機能なのでしょうか？

　実は今まで述べた「仮想イメージ」と「トポロジー・パターン」の機能は、旧バージョンから実現されていたものです。今回、IBM Workload Deployerはこれらに「ワークロード・パターン」という機能が新たに加わりました。先ほど、トポロジー・パターンと比べると、ワークロード・パターンではさらに抽象度を上げたパターン化が可能になります。

 

 

　想定したサービスレベルにおいて、アプリケーションを動かすことができればいいという視点に立てば、トポロジーのパターン定義さえ煩わしい作業と見ることができます。「アプリケーション・サーバーに仮想マシンを何台割り当てるかなんてことはどうでもいい。自分たちはエンドユーザーにストレスを感じさせないレスポンスでWebアプリケーションを動かしたいだけなんだ。インフラのことまで考えたくない」。ワークロード・パターンは、こういったニーズにも応えることができるのです。

――もう少し具体的な内容を教えていただけますか？

　ここで言うワークロードとは、すなわちアプリケーションのタイプを意味します。例えばWebアプリケーションをクラウド上で稼働させたい場合、先ほどのトポロジー・パターンであれば、Webサーバー、アプリケーション・サーバー、DBサーバーといったシステムインフラのスキルのある人が、それらを意識しながらと定義しなくてはなりませんでしたが、ワークロード・パターンでは、これらもすべてIBM Workload Deployerが推奨構成を自動的に決定してくれます。

　従って、ワークロード・パターンを定義する際には、システムインフラの要素はなく、エディタ画面上で、アプリケーションが格納されるファイル、データベースのスキーマ定義、インフラに期待するスケーリングのポリシーといったアプリケーションの特性さえ設定すればよいのです。現時点でIBM Workload Deployerには、Webアプリケーションとデータベース用の二種類のワークロード・パターンをサポートしています。将来的にはほかのタイプのワークロードにも対応していく予定です。

――ワークロード・パターンの提供がユーザーにもたらすメリットはどのようなものでしょうか？

　トポロジー・パターンと比較すると、ワークロードという概念を導入することによって、ミドルウェアをも仮想化の対象とし、クラウド上で稼働できるアプリケーション群の集約率を格段に高めることができます。同時に、クラウドにおける標準化と自動化という特性が有効に機能し、トポロジー・パターン適用時以上のシステム構築時間の短縮と、構成パラメーターのよりいっそうの減少により、繰り返し作業における人的ミスの排除が実現できます。

　これらは結果として、システムリソースの使用率を高め、人的リソースの効率化を実現できることを意味し、最終的には短期間かつ低コストで、エンドユーザーへのアプリケーションの提供を実現することができるのです。一方で、通常の人手による手作りシステム構築と比べ、システムのカストマイズに対する自由度は下がります。クラウドのメリットを最大限に享受する為には、ある程度の制約は受け入れ、クラウドの作法に従う許容が必要です。

　今後のIT部門では、アプリケーションの特性を見極め、自由度とコストおよび時間のバランスを評価し、クラウドの適用を判断できるスキルが重要になってくるでしょう。今後は、システムインフラにおける設計、導入、構成といったパターン化できる人手の作業をアプライアンスのIBM Workload Deployerに任せ、その分余ったリソースをよりビジネス価値の高い仕事に振り分けることができるようになるのです。第1回のインタビューで山本がお話ししたような世界が、まさに実現するわけです。

――ありがとうございました。