仮想アプリケーション・パターンを使用してアプリケーション・サービスを管理する

仮想アプリケーション・パターンには、何年にもわたるクラウド・アプリケーション・サービス管理の専門知識が集結されています

仮想アプリケーション・パターンは、IBM PureApplication System 環境に不可欠の要素です。仮想アプリケーション・パターンによって、ユーザーはクラウド・アプリケーション・インフラストラクチャーを迅速に構築し、管理することができます。それは、仮想アプリケーション・パターンがアプリケーションを記述し、そのアプリケーションに適切なインフラストラクチャーを構成するためのツールを採用して、そのインフラストラクチャーにアプリケーションをデプロイするからです。何年にもわたるアプリケーション・インフラストラクチャーのデプロイメント経験とベスト・プラクティスを取り込んだ IBM PureApplication System の仮想アプリケーション・パターンには、特定のタイプのアプリケーション・ワークロードをホストする、さまざまなミドルウェア要素に最適なソリューションがカプセル化されています。この記事では、仮想アプリケーション・パターンと、エコシステムでのその位置付けを概説します。そして、仮想アプリケーション・パターンを構成するコンポーネントと機能について説明した後、仮想アプリケーション・パターンの基本的な作成方法と使用方法を紹介します。

Bobby McChesney, Advisory Software Engineer, IBM

Bobby McChesneyBobby McChesneyは、IBM Software Group の顧問ソフトウェア・エンジニアで、IBM に 23 年間勤務しています。現在は、アプリケーションと統合ミドルウェア、そして IBM Workload Deployer を重点に取り組んでいます。



Joseph Bohn, Senior Software Architect, IBM

Photo of Joe BohnJoseph Bohn は、IBM のシニア・ソフトウェア・アーキテクトです。現在は、テクニカル・エバンジェリストの役割を果たしています。テクニカル・エバンジェリストになる前は、Apache Aries や Apache Geronimo を含め、OSGi Alliance の仕様およびオープンソース・プロジェクトで IBM の代表を務めていました。さらにそれ以前は、IBM 内でアーキテクト、設計者、チーム・リーダー、開発者としての複数の製品分野に取り組み、Integrated Solutions Console、Tivoli Presentation Services、そして複数の Tivoli ソリューションをはじめ、さまざまな IBM 製品を扱ってきました。



James Kochuba, Security Test Architect, IBM

James Kochuba photoJames Kochuba は、WebSphere クラウド共有サービスのアーキテクトであり、Workload Deployer および PureScale Application System に従事する保守リーダーです。以前は IBM で WebSphere Application Server のセキュリティー・テスト・アーキテクトとして勤務しており、AIM プレミアム・サポート・チームや、WebSphere Application Server のサポート・チームに属していました。彼は、ロギング、監視、キャッシング・サービスといった共有されるサービスや、IBM Platform as a Service 製品向けサービス (トラブルシューティングなど) のテクニカル・リーダーであり、これまでのお客様対応の経験や技術的なバックグラウンドを活かして、お客様が利用する上での要求を満たす高品質のサービスを提供できるようにしています。



2012年 5月 17日

IBM PureSystems 製品ファミリーの導入は、クラウド・コンピューティングを新しいレベルへと引き上げます。IBM PureApplication System および IBM PureFlex System からなる IBM PureSystems は、エンタープライズ・レベルのクラウド環境を統合、デプロイ、保守するためのエキスパート・インテグレーテッド・クラウド・システムです。このシステムには、アプリケーション、サービス、ハードウェアだけでなく、ベスト・プラクティス・パターンという形で提供される専門知識までもが取り込まれています。

IBM PureApplication System アーキテクチャーは、以下の 3 つのミドルウェア・セグメント・モデルをサポートします。クラウド・ソリューションを実現するために使用されるこの異なる 3 つのタイプのワークロードが、IBM PureApplication System の重要な基盤となっています。

  • ワークロード・プラットフォーム・サービスを介して仮想アプリケーション・パターンを使用するモデル。仮想アプリケーションとは、アプリケーションのコンポーネント、動作ポリシー、そしてこれらの間の関係を 1 つに集めたものです。このアプリケーション中心のワークロード定義を使用して、IBM PureApplication System はプロビジョニングに必要なインフラストラクチャーおよびミドルウェア・リソースを構成し、その仮想アプリケーションを継続的に管理します。
  • 仮想化されたミドルウェア・サービスを介して仮想システム・パターンを使用するモデル。仮想システム・パターンとは、特定のデプロイメント要件セットに対して再現されるトポロジーの論理的表現です。例えば、「WebSphere Application Server Cluster」パターンには、IBM Deployment Manager、1 つ以上のカスタム・ノード、IBM HTTP Server、そしてアプリケーションをトポロジーにインストールするための構成スクリプトが含まれます。仮想システム・パターンを使用して詳細なミドルウェア構成が明示的に定義されると、IBM PureApplication System がその定義されたシステムを忠実にプロビジョニングします。
  • 仮想化されたインフラストラクチャー・サービスを介して仮想アプライアンスを使用するモデル。仮想アプライアンスは、単一のサーバー・ワークロード・インスタンスを表します。これは仮想マシン・イメージ・ファイルであり、そこには OVF (Open Virtualization Format) 形式のイメージやアプリケーションにインストール済みの必要なミドルウェア要素とアプリケーション要素をはじめとする、事前に構成されたオペレーティング・システム環境が含まれます。

developerWorks コミュニティーでは、今後、これらの要素について説明するリソースを提供していく予定です。この記事では、上記に挙げた重要なコンポーネントのうち、仮想アプリケーション・パターンを話題に取り上げ、これが IT 専門家に与える影響を説明します。

全体像

基本的に、IBM PureApplication System はハードウェアとソフトウェアを統合することにより、仮想化されたワークロードとスケーラブルなインフラストラクチャーを組み合わせています。この統合には、データとラインタイムのミドルウェア・サポートに加え、これらのアクティビティーを効率化および加速化するデプロイメント機能と管理機能も組み込まれ、さらなる効率性の向上が実現されています。

仮想アプリケーション・パターンは、アプリケーション中心の設計に従って作成されます。仮想アプリケーション・パターンは、ミドルウェア・アプリケーションを、その下層にあるミドルウェア・インフラストラクチャーを抽象化した単純なモデルで表現する手段です。これらのパターンの実装には、仮想アプリケーション・パターン・タイプが使用されます。仮想アプリケーション・パターン・タイプは、完全な、そして時として複雑な環境を 1 つのデプロイ可能な単位として表現できるように、複数のミドルウェアのソフトウェア要素の機能を、目的に合わせた 1 つのソリューションとして統合します。

仮想アプリケーション・パターンは、新しいクラウド・デプロイメント・モデルであり、仮想システム・パターンでサポートされてきた従来のトポロジー・パターンの進化形です。基本的に、仮想アプリケーション・パターンは仮想システム (トポロジー) パターンの抽象化を 1 つ上のレベルに引き上げ、重点をアプリケーションに置きます。つまり、仮想アプリケーション・パターンを使用する場合、その重点はアプリケーション・インフラストラクチャーではなく、アプリケーションに置かれることになります。

仮想アプリケーション・パターンには、ミドルウェアのインストール、構成、統合だけでなく、そのミドルウェアで実行されるアプリケーションのインストールおよび構成もカプセル化されます。これらのインストール、構成、統合のほとんどは、完全にユーザーから隠されます。これは、構成および統合に関してユーザーの制御が及ばなくなってくることを意味しますが、それと同時に、ユーザーは大幅に作業負荷が減り、自由に使える時間が増え、より俊敏な対応ができるようになるということでもあります。ユーザーはアプリケーションとそのコンポーネントの開発に専念し、アプリケーションのためのインフラストラクチャーの作成と管理については、IBM PureApplication System に任せることができます。

ミドルウェア・アプリケーション環境を対象としたクラウド・ベースの手法について調べる場合、これらの手法が、デプロイメント時間の短縮、一貫性の強化、アジリティーの促進といったメリットを持つことを期待するはずです。IBM PureApplication System ソリューションは、クラウド・ミドルウェア環境を再現可能で迅速かつ効率的な方法でデプロイするという問題に対処します。

パターン・ベースの手法は、IBM PureApplication System の基盤です。この点については、仮想アプリケーション・パターンと仮想システム・パターンとで一貫しています。ユーザーはこのクラウド・アプライアンスを使用して、完全に構成されたアプリケーション環境を表すパターンを作成し、そのパターンをデプロイします。特定のアプリケーション環境を実際に使用する段階になったら、あとはパターンを選択してデプロイするだけです。IBM PureApplication System がそのパターンで表される環境を構成するさまざまな仮想マシンを自動的にデプロイ、構成、統合してくれるため、ものの数分でアプリケーション環境が完成します。


仮想アプリケーション・パターンの構成要素と機能

IBM PureApplication System には、仮想イメージ、仮想システム・パターン、および仮想アプリケーション・パターン・タイプのセットがすぐにデプロイできるように事前にビルドされた形で同梱されています。その一方、これらのイメージやパターン・タイプから独自のカスタム・パターンを作成すれば、パターン・ベースの手法がもたらす価値はさらに高まります。そのため、IBM PureApplication System には、サポートしている仮想システム・パターンと仮想アプリケーション・パターンの両方のモデルを対象に、包括的なカスタマイズ手法が用意されています。

IBM PureApplication System の仮想アプリケーション機能は、標準化されたアプリケーション中心のパターン・ソリューションの概念に基づきます。標準パターンを使用することにより、クラウド環境のアプリケーションの開発者は、ミドルウェア・インフラストラクチャーや、アプリケーションをデプロイするために必要なミドルウェア製品の複雑になりがちな構成ではなく、アプリケーションとその要件に専念することができます。

仮想アプリケーションをサポートするために必要なリソース (Web アプリケーション、データベース、ユーザー・レジストリーなど) は、仮想アプリケーション・パターンが定義します。これらの仮想アプリケーション・パターンが、仮想アプリケーションのデプロイメント単位となります。

例えば、「Web アプリケーション」パターン・タイプには、Web アプリケーション、エンタープライズ・アプリケーション、データベース、ユーザー・レジストリーなどの共通アプリケーション・コンポーネントが用意されています。これらの共通コンポーネントに加え、ユーザーがコンポーネントとポリシーとの間の関係を定義して、アプリケーションの機能要件と非機能要件を指定することができます。IBM PureApplication System は、これらのアプリケーション・コンポーネント、ポリシー、そしてリンクを「Web アプリケーション」パターン・タイプによって提供される機能と併せて解釈し、このアプリケーションに応じたソリューションを構成して管理します。

図 1. 全体像: 仮想アプリケーション・パターンから仮想アプリケーション・インスタンスへの変換
全体像: 仮想アプリケーション・パターンから仮想アプリケーション・インスタンスへの変換

パターン・タイプとプラグイン

仮想アプリケーション・パターンの基礎構造は、パターン・タイプです。パターン・タイプとは、仮想アプリケーションのタイプに応じて必要となるソリューションとトポロジーにそれぞれ固有のリソースのコンテナーです。パターン・タイプは、キャッシング・サービスや弾性のあるロード・バランシングなどのランタイム・サービスを組み込んだ、共有されるサービスも提供します。まさに、パターン・タイプには特定のタイプのアプリケーションに対処する各種の機能が集約されています。一方、実際のソリューションに固有のインテリジェンスは、プラグインによって提供されます。プラグインは複数のパターン・タイプに関与することができますが、プラグインには必ず主要なパターン・タイプが 1 つ関連付けられます。

プラグインは、コンポーネント、リンク、ポリシー、サービス、そしてその他の主要な要素に対して、実際のエンティティーを作成して管理するために必要なすべての機能を提供します。第一に、ユーザーが仮想アプリケーション・パターンを作成するときに仮想アプリケーション・ビルダーに表示される可視の要素を提供します。さらに、最終的にクラウドにデプロイされることになるシステムのモデルを作成するために必要な機能を提供するという役割もあります。また、特定のアプリケーション要素をプロビジョニングして構成するために必要なスクリプトも提供します。必要な要素のフェデレーションを行ったり、構成の変更を明らかにしてそれに対応したり、ポリシーのサポートにおいて動的な処理を行ったりするためのロジックも、プラグインには組み込まれます。

以上の処理を容易にするためのユーティリティーを数多く取り揃えている IBM PureApplication System は、プラグインとのやりとりを調整し、アプリケーションのサポートに必要な機能を提供します。そのすべてはパターン内部で最適化され、自動化されているため、パターンを使用する通常のユーザーがミドルウェアのあらゆる詳細を理解する必要はありません。代わりに、アプリケーションが望ましい動作をするための作業に重点的に取り組むことができます。

デフォルトの仮想イメージ

すべての仮想アプリケーション・パターンのコンポーネントには、デフォルトの仮想イメージが使用されます。デフォルトの仮想イメージは、IBM PureApplication System 仮想イメージ・カタログに、仮想システム・パターンで使用される他の仮想イメージと一緒に含まれています。ただし、デフォルトの仮想イメージは、事前にインストール済みのミドルウェアが 1 つも組み込まれていないという点で特殊です。したがって、すべての仮想アプリケーションのデプロイメントに共通の仮想イメージとして使用されます。

各ハイパーバイザー・タイプのデフォルトの仮想イメージは、「Default Deploy Settings (デフォルトのデプロイ設定)」で指定します。デフォルトの仮想イメージは、企業の特定の要件に応じてカスタマイズすることができます。デフォルトの仮想イメージが提供するのは、仮想アプリケーション・パターンをデプロイして実行し、アプライアンスによって管理できるようにするための機能的環境です。この環境に含まれるアクティベーション・コードが、デプロイメントのブート・プロセスおよび仮想アプリケーションの管理におけるさまざまな段階で、アプライアンスとの通信をセットアップします。さらに、デフォルトの仮想イメージには、ロード・バランシングやキャッシングといった共有されるサービスのすべてのパターンをサポートするためにアプライアンスに必要となるコードも含まれています。

例: 「Web アプリケーション」パターン・タイプ

IBM PureApplication System にあらかじめ用意されている仮想アプリケーション・パターン・タイプの 1 つは、「Web アプリケーション」パターン・タイプです。これは、標準的なオンライン・トランザクションを処理する Web アプリケーション用に作成されています。デモンストレーションのために、この記事の残りでは「Web アプリケーション」パターン・タイプを例に、仮想アプリケーションに伴う概念と、これらの仮想アプリケーションをサポートするパターン・タイプについて説明します。

「Web アプリケーション」パターン・タイプは、オンライン Web アプリケーション・スタイルの仮想アプリケーションを作成するために使用できる、IBM PureApplication System の拡張機能です。このパターン・タイプには、Web アプリケーションの標準的なコンポーネント・セットとして、Java EE (Java Enterprise Edition)、DB2 プロビジョニング、データベース JDBC 接続、LDAP (Lightweight Directory Access Protocol) ユーザー・レジストリー、Java メッセージングなどが用意されています。

「Web アプリケーション」パターン・タイプには WebSphere Application Server 用のプラグインが組み込まれています。これらのプラグインが、WAR (Web ARchives) ファイル、EAR (Enterprise ARchives) ファイル、OSGi EBA (Eenterprise Bundle Archive) アプリケーションおよびプラグインを実行して、WebSphere Application Server でホストされるアプリケーションから既存のリソース (データベース、Web サービス、MQ、CICS、IMS、LDAP サーバーなど) への接続を構成します。パターンには、動的にスケーリングされるサーバー・プロビジョニング、ロード・バラシング、キャッシングを構成するためのポリシーも組み込まれています。

ユーザーが仮想アプリケーション・パターンとその動作に慣れることができるように、「Web アプリケーション」パターン・タイプには、すぐにデプロイできるサンプル・アプリケーション・パターンがいくつか組み込まれています。これらのサンプルは、「Virtual Application Patterns (仮想アプリケーション・パターン)」ビューに示されます。独自のカスタム仮想アプリケーション・パターンを一から作成する場合にも、提供されているサンプルの複製を基に作成する場合にも、このビューが出発点となります。図 2 に、「Virtual Application Patterns (仮想アプリケーション・パターン)」ビューを示します。

図 2. 「Virtual Application Patterns (仮想アプリケーション・パターン)」ビュー
「Virtual Application Patterns (仮想アプリケーション・パターン)」ビュー

上記のビューには、「Web アプリケーション」パターン・タイプに付属の 3 つのサンプル仮想アプリケーションが表示されています。ここで選択されているサンプルは「Secured Java EE web application (セキュア Java EE Web アプリケーション)」で、右側ペインには、このサンプルの詳細が表示されています。左側ペインのリストの先頭にある「Daytrader」は、サンプルではありません。これは、「Sample Java EE web application (サンプル Java EE Web アプリケーション)」を複製して、仮想アプリケーション・エディターでマイナーな変更を加えて作成したカスタム・パターンです。

仮想アプリケーション・パターンを選択すると、そのパターンに関する情報を詳細パネルで確認することができます。選択したパターンを編集するには、「Open (開く)」アイコンを選択して仮想アプリケーション・ビルダーを開き、パターンのコンポーネント、リンク、ポリシー、プロパティーを編集します。

仮想アプリケーション・ビルダー

仮想アプリケーション・パターン・タイプの機能に寄与する主要な要素は、コンポーネント、リンク、ポリシーの 3 つです。図 3 に、サンプル・アプリケーションに含まれるコンポーネント、リンク、ポリシーのスクリーン・ショットを示します。

図 3. サンプル・パターンに含まれるコンポーネント、リンク、およびポリシー
サンプル・パターンに含まれるコンポーネント、リンク、およびポリシー

コンポーネント
コンポーネントは、仮想アプリケーション・インスタンスに必要なミドルウェアの機能を表します。一般に、ミドルウェア・アプリケーションには、Web ベースのコンポーネント、データベース・スキーマの定義、ユーザー・レジストリーの仕様などの成果物が含まれます。これらのコンポーネントを仮想アプリケーション・パターンに組み込むと、仮想アプリケーション・パターンがシステムに対し、仮想アプリケーション・パターンのデプロイ時にこれらの機能のインスタンスを作成する必要があることを通知します。

「Web アプリケーション」パターン・タイプに含まれる一般的なコンポーネントには、例えば以下のものがあります。

  • Enterprise Application (エンタープライズ・アプリケーション) (WebSphere Application Server など)
  • Web Application (Web アプリケーション) (WebSphere Application Server など)
  • Additional archive file (追加のアーカイブ・ファイル)
  • Existing Web Service Provider Endpoint (既存の Web サービス・プロバイダー・エンドポイント)
  • Policy set (ポリシー・セット)
  • OSGi application (OSGi アプリケーション) (WebSphere Application Server など)
  • External OSGi bundle repository (外部 OSGi バンドル・リポジトリー)
  • Database (データベース) (DB2 など)
  • Existing database component (既存のデータベース・コンポーネント)
  • Remote database component (リモート・データベース・コンポーネント)
  • Existing IMS database (既存の IMS データベース)
  • User registry (ユーザー・レジストリー) (ディレクトリー・サーバーなど)
  • Messaging services (メッセージング・サービス)
  • CICS transaction gateway (CICS トランザクション・ゲートウェイ)
  • Existing IMS TMRA (既存の IMS TMRA)
  • generic target (汎用ターゲット)

リンク
リンクはコンポーネント同士を接続します。つまり、コンポーネント間の何らかの依存関係、または相互作用を表します。例えば、「Web アプリケーション」パターン・タイプに含まれる特定のコンポーネントは、他のパターン・タイプに含まれるコンポーネント (「IBM データベース」パターン・タイプの「Database (データベース)」コンポーネントなど) へのリンクをサポートします。

リンクには以下の役割があります。

  • リンクの両端にある接続元コンポーネントと接続先コンポーネントが、接続をサポートするように適切に構成されることを確実にします。
  • 通信ができるようにネットワークとファイアウォールが適切に構成されることも確実にします。
  • さらに、確実に依存関係が確認されてサポートされるようにして、コンポーネントが適切に依存関係の変更や障害に対応できるようにします。

ポリシー
ポリシーとは、デプロイ時のミドルウェア・サービスの構成方法を表します。例えば、仮想アプリケーションにはオプションの QoS (Quality of Service) ポリシーを追加することができます。2 つの仮想アプリケーションが同じコンポーネントを組み込んでいるとしても、実現しなければならないサービス・レベル・アグリーメントが異なる場合には、異なるポリシーが必要です。

アプリケーションにポリシーが追加された場合には、アプリケーションの機能を拡張することができます。例えば、Web アプリケーションに極めて高い可用性を持たせたい場合には、仮想アプリケーション・ビルダーでスケーリング・ポリシーを追加すれば、IBM PureApplication System によってその要件を満たすアプリケーションとトポロジーが作成されます。

「Web アプリケーション」パターン・タイプに通常使用されるポリシーを以下に挙げます。

  • スケーリング・ポリシー
  • ルーティング・ポリシー
  • Java 仮想マシン (JVM) ポリシー
  • ログ・ポリシー

ポリシーによって、起動される仮想マシンの数は左右されます。例えば、スケーリング・ポリシーを追加すると、複数のアプリケーション・サーバー・インスタンスが互いに接続されるとともに、ロード・バランサーや、オプションでセッションを共有するためのIBM WebSphere eXtreme Scale サーバーが接続されます。このトポロジーに応じてコンポーネントを起動し、構成することによって、アプリケーション成果物がデプロイされます。


仮想アプリケーション・パターンを作成する

例えば、組織に稼働中のアプリケーションが多数あり、その数はさらに増える予定だとします。IT 部門の通常のプロセスでは、各アプリケーションのハードウェア要件とソフトウェア要件を判断し、必要なハードウェア、ソフトウェアを入手するための申請書を提出します。その後は、ハードウェアとソフトウェアを準備し、インストール、構成という時間のかかる面倒なプロセスが待っています。

このプロセスが終わると、次のフェーズでは、監視およびフェイルオーバーのセットアップをし、ログの収集および監視の方法を設定します。そして最後に、次回の作業が楽になるようにアプリケーションごとにカスタム・スクリプトを作成したとすると、最終的にはまったく異なるハードウェア、ソフトウェア、アプリケーション、スクリプトなどが、かなりの数に膨れ上がってしまうことでしょう。

アプリケーションの要求を標準化して、稼働中のアプリケーションの数だけでなく、開発中、テスト中のアプリケーションの急増にも十分対応できるだけの余裕を持てるとしたらどうでしょうか?そこで活躍するのが、IBM PureApplication System です。

例えば、標準的なアプリケーションで、一部のコードが J2EE アプリケーション・サーバーにデプロイされていて、一部のデータがリレーショナル・データベースに保管されているとします。このアプリケーションをデプロイして管理し、ロギング、監視、フェイルオーバーなどを素早く簡単にセットアップする方法があるとしたら、それは、IBM PureApplication System に他なりません。典型的な「Web アプリケーション」パターンの例で説明すると、このパターンをベースとした仮想アプリケーションには、通常は以下の成果物が含まれます。

  • アプリケーション・サーバーにデプロイする J2EE EAR (Enterprise Archive) または J2EE WAR (Web Application Archive)
  • データベースを初期化するためのデータベース・スキーマ/テーブル/行の作成スクリプト
  • LDIF (LDAP Data Interchange Format) ファイルの形をとったユーザーおよびグループのリスト

すでに説明したように、「Web アプリケーション」パターン・タイプには上記のすべてのコンポーネントが簡単に使用できるように最適化されて完全に統合された形で組み込まれています。さらに、仮想アプリケーション・ビルダーを使用して、単純なドラッグ・アンド・ドロップ式のユーザー・インターフェースで極めて簡単にパターンを作成できるようになっています。このようなシステム仮想アプリケーション・パターンでは、仮想アプリケーションを設計し、成果物をアップロードし、ロギング、監視、スケーリングに関するポリシーを指定し、仮想アプリケーションをプライベート・クラウドにデプロイするまでのプロセスを短時間で完了することができます。

IBM PureApplication System には、仮想アプリケーション・パターンを簡単に作成して編集する手段として Virtual Application Builder (仮想アプリケーション・ビルダー) が組み込まれており、図 3 で説明した仮想アプリケーションの要素の 1 つになっています。

このエディターを使用するのは極めて簡単で、次のような動作をします。例えば、新しい仮想アプリケーションを作成し、「Virtual Application Builder (仮想アプリケーション・ビルダー)」のキャンバスに「Enterprise Application (エンタープライズ・アプリケーション)」コンポーネントと「Database (データベース)」コンポーネントをドラッグ・アンド・ドロップして、この 2 つのコンポーネントをリンクさせます。そして、コード成果物と、そのコードが要求するテーブル構造を記述するデータベース・スキーマとが含まれる JEE ベースの EAR または WAR をアップロードします。このパターンは「Web アプリケーション」パターンと「IBM データベース」パターンのコンポーネントの一部を使用するため、IBM PureApplication System は、この 2 つのパターンを最適な形で使って、これらのコンポーネントに組み込まれた情報を利用します。

仮想アプリケーションを仮想システムと比較したときの大きな違いの 1 つは、仮想アプリケーションでは、実行システムを作成するためにハイパーバイザー上で最終的に起動されることになる仮想マシンの正確な数を、ユーザーが決定することもなければ、知る必要もないことです。これを決定する役目は、IBM PureApplication System に任せることができます。IBM PureApplication System が、コンポーネントやコンポーネント間のリンク、そして関連するポリシーを調べ、仮想マシンの数、そして何をどの仮想マシンで実行するかに関して最適な判断を下します。

仮想アプリケーションを使用する場合、ユーザーがアプリケーションを設計する際に必要となる作業は、例えばアプリケーションのスケーラビリティーなどの側面を管理するポリシーを指定することだけです。必要なミドルウェア・コンポーネントとその数を決める必要はありません。

デプロイされた後のアプリケーションは、その高可用性が自動的に管理され、実行状態に応じて、ユーザーが指定したポリシーに従います。アプリケーションの状態は、完全に統合されて最適化されたユーザー・インターフェースで確認することができます。つまり、異なる管理コンソールを交互に切り替えることなく、システムを管理および構成することができるのです。


仮想アプリケーション・パターンを使用する

皆さんは今、「どのような場合に、IBM PureApplication System の仮想システム・パターンではなく、仮想アプリケーション・パターンを使用したほうが適切なのか」を考えていることでしょう。その答えを明らかにするために、ここではこの問題についてもっと詳しく検討してみましょう。

本質的に、仮想アプリケーション・パターンと仮想システム・パターンは、どちらもクラウドにデプロイするための仮想アプリケーションのモデルを表すという点で似ています。クラウドのコンテキストで言うパターンとは、クラウドに環境をデプロイして管理する作業を大幅に簡易化する、インストール、構成、統合作業のカプセル化を意味します。最終的にどのタイプのパターンを使用するかに関わらず、潜在的に複雑なミドルウェア・インフラストラクチャー環境あるいはミドルウェア・アプリケーションを、その作成、デプロイ、管理のライフサイクル全体を通して 1 つのアトミック単位として扱うことにはメリットがあります。

まずは、仮想アプリケーション・パターンと仮想システム・パターンのデプロイメントの違いを理解するために、クラウドの一連のトレードオフについて検討しましょう (ここでは、IBM Workload Deployer を使用しています。その理由は、これは IBM PureApplication System の前身となった技術であり、豊富なデータがあること、そして私たちは IBM Workload Deployer の使用経験を積んでいるためです)。

図 4. クラウドのトレードオフを示すグラフ
クラウドのトレードオフを示すグラフ
  • X 軸は、最終的な環境のカスタマイズに対して、ユーザーがどれだけの制御レベルを持てるのかを表します。制御レベルは、X 軸を左から右へ行くにつれて低くなります。
  • 左側の Y 軸は総保有コスト (TCO) を表し、Y 軸を下から上に行くにつれてコストが下がります。
  • 右側の Y 軸は価値を生み出すまでの時間を表し、同じく Y 軸を下から上に行くにつれて時間が短くなります。

当然、企業は Y 軸を上に進むことを目指しますが、それと引き換えに制御を手放すこと (X 軸を右に行くこと) に消極的なこともあります。

この図で示しているのは、2 つのパターン・ベースの手法についてさらに検討を始める際の基準点です。

仮想システム・パターンを使用するシナリオ

クラウドにデプロイしようとしている Web サービス・アプリケーションが、かなり単純なものであるとします。仮想システム・パターンを使用して、このアプリケーションをクラウドにデプロイするとしたら、その作業はおそらく、WebSphere Application Server Hypervisor Edition イメージのパーツを使ってトポロジーをレイアウトするところから始まります。これらのパーツには、デプロイメント・マネージャー、2 つのカスタム・ノード、そして Web サーバーが考えられます。

トポロジーを確立した後、カスタム・スクリプト・パッケージを追加して Web サービス・アプリケーションをインストールし、それからアプリケーションが依存するリソースを構成します。仮想システム・パターンをデプロイすることにしたユーザーは、仮想システム・パターンにアクセスし、構成の詳細 (WebSphere Application Server のセル名、ノード名、仮想リソースの割り当て、カスタム・スクリプトのパラメーターなど) を指定した上で、パターンをデプロイすることになります。

デプロイメントが完了すると、ユーザーは普段と同じように、この環境とミドルウェア・インフラストラクチャーにアクセスできるようになります。つまり、管理スクリプトを実行したり、デプロイされたミドルウェア・ソフトウェアが提供する管理コンソールにアクセスしたり、通常実行する必要がある構成操作を行ったりすることができます。

上記と同じナリオで、 仮想アプリケーション・パターンを使用する

上記と同じ Web サービス・アプリケーションをサポートするために仮想アプリケーション・パターンを使用する場合、デプロイメントの点でも、管理の点でも、まったく異なるものになってきます。

仮想アプリケーション・パターンの手法を使用する場合には、ユーザーはまず、アプリケーションのタイプに応じた適切な仮想アプリケーション・パターン・タイプを選択するところから始めます。この場合、Web アプリケーション用の「IBM Workload Deployer」パターンなど、IBM が提供するパターン・タイプを選択することも、アプライアンスに組み込まれた拡張メカニズムを使ってユーザーがパターンを作成することもできます。

適切なパターンを選択した後、ユーザーは Web アプリケーションを提供し、そのアプリケーションの機能要件と非機能要件をポリシーによって定義してからデプロイします。

ミドルウェア・インフラストラクチャー、そしてアプリケーション自体をインストール、構成、統合するために必要な情報は、仮想アプリケーション・パターンと IBM PureApplication System が提供します。デプロイメントが完了すると、ユーザーは PureApplication System が提供する極めて単純化されたレンズを通して最終的なアプリケーション環境を管理します。このレンズの内側では、PureApplication System がアプリケーションに適切なコンテキストで環境を監視し、継続的に管理します。

つまり、一般に管理コンソールはなく、ユーザーが変更できるのは明確に定義された環境の側面だけです。これは、ミドルウェア・アプリケーションのデプロイメントと管理の考え方における大々的な転換です。

どちらを使用するべきか

以上のシナリオの要点をまとめると、仮想システム・パターンを使用してソフトウェアをデプロイする場合、その環境を管理する方法は、今までその特定のソフトウェアを管理してきた方法とほとんど変わりません (通常は、管理コンソールを使用します)。仮想システム・パターンを使用するユーザーは、ソフトウェアの操作や管理方法の変更に気を取られることなく、主にそのソフトウェアを実現する方法の改善に取り組むことになります。

仮想アプリケーション・パターンの場合には、環境に関するすべての側面が抜本的に変わります。ユーザーが扱っているのは、高度に最適化および自動化されたソリューションです。高可用性や、変化する条件への動的対応などを管理する作業は、そのパターン・タイプのソリューションに組み込まれます。したがって、ユーザーに必要な作業は、ビジネス・レベルの要件を指定することだけとなります。環境の管理および運用は、完全に IBM PureApplication System ユーザー・インターフェースに統合されています。このように、あらゆるものが統合され、特定のアプリケーション・タイプに応じて高度に特化されます。

注目すべき重要な点は、IBM PureSystems はこの 2 つのモデルを同時にサポートし、両方のパターン・タイプをアクティブに管理できることです。決定の根拠にしなければならないのは、検討対象としている特定のアプリケーションの要件、そしてアプリケーションを管理する必要性です。

仮想システム・パターンのミドルウェア・インフラストラクチャーを中心とした手法を採るか、それとも仮想アプリケーション・パターンのアプリケーションを中心として手法を採るかは、アプリケーションごとに決定する必要があります。その決定は、サポートする必要がある構成によって左右されることもあります。例えば、構成が極めて特有で、現在用意されている仮想アプリケーション・パターン・タイプに当てはめるのが難しい場合には、独自の仮想アプリケーション・パターン・タイプを作成するか、あるいは仮想システム・パターンを使ってアプリケーションの要件と完全に一致するトポロジーを作成し、場合によっては以前に実装した物理環境を複製するという方法を選べます。このような場合を抜かせば、用意されている既存の仮想アプリケーション・パターン・タイプのなかから、アプリケーションによく適したパターンが見つかるはずです。

できる限り、仮想アプリケーション・パターンの最適化と利便性を利用するように努めてください。そうすることで必ず、総所有コストが最小限になり、価値をもたらすまでの時間が最短になります。一方、極めて詳細な構成が必要であることから、細かいところまで制御できる仮想システム・パターンを選ぶというシナリオも当然考えられます。

最も重要なことは、すべての選択肢を理解し、十分な情報に基づいて決定を下すことです。それぞれの使用ケースを調べ、その使用ケースを実現するために利用できる選択肢を理解した上で、最終的に、目標とするユーザー・エクスペリエンスを決定してください。

最後に、もう 1 つの重要な点として、IBM PureApplication System は、この 2 つのモデルを同時にサポートします。したがって、仮想アプリケーションと仮想システム、さらには仮想アプライアンスをすべて同じクラウド・リソースのプールにデプロイすることができます。この多種多様なデプロイメントを可能にするのは、IBM PureApplication System に組み込まれている堅牢な機能の数々です。これらの機能のおかげで、アプリケーションごとにデプロイメント・モデルを選択することができるため、その最善の組み合わせを最大限の投資収益率で実現することができます。


まとめ

この記事では、仮想アプリケーション・パターンと、IBM PureApplication System エコシステムでのその位置付け (そして、仮想システム・パターンや仮想アプライアンスと仮想アプリケーション・パターンとの違い) を紹介しました。さらに、仮想アプリケーション・パターンのコンポーネントと機能を説明し、基本的な仮想アプリケーション・パターンの作成方法と使い方を検討しました。

パターン中心のクラウド・デプロイメントについてさらに詳しく学ぶには、「参考文献」セクションの関連するコミュニティー、フォーラム、記事を調べてください。

参考文献

学ぶために

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

議論するために

コメント

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=Cloud computing, WebSphere, Information Management, Java technology
ArticleID=814605
ArticleTitle=仮想アプリケーション・パターンを使用してアプリケーション・サービスを管理する
publish-date=05172012