IBM PureApplication System に対する準備: 第 2 回 アプリケーションを仮想化する準備はできていますか?

連載の第 2 回では、皆さんの特定のアプリケーションに最も適したデプロイメント・オプションをどのように決定すればよいのかを検討します。

Kyle Brown (brownkyl@us.ibm.com), Distinguished Engineer, IBM  

Kyle BrownKyle Brown は、SOA および新興技術を専門とする、IBM Software Services for WebSphere の Distinguished Engineer です。また、フォーチュン 500 社の顧客を対象に、SOA、オブジェクト指向関連、そして J2EE 技術に関するコンサルティングと教育指導も行っています。彼は『Java Programming with IBM WebSphere』、『Persistence in the Enterprise』の共著者であり、カンファレンスでも頻繁に SOA、Enterprise Java、OO デザイン、デザイン・パターンに関する講演を行っています。


developerWorks
        プロフェッショナル著者レベル

2012年 5月 24日

はじめに

前回の「第 1 回 アプリケーションのオンボードに関する概要」では、IBM PureApplication System が仮想アプリケーションと仮想システムの両方をサポートする仕組みを説明しました。簡単に言えば、この 2 つの違いは、制御可能な範囲と自動化レベルとの間のトレードオフをどのレベルに設定するかです。今回の記事では、皆さんの特定のアプリケーションに最も適したデプロイメント・オプションをどのように決定すればよいのかを検討します。


仮想アプリケーションの利点と制約

仮想アプリケーションは、JEE アプリケーションを、そのアプリケーションのスケーリング方法および JVM (Java Virtual Machine) のリソースの使用方法を決定する一連のポリシーと併せてデプロイする手段です。アプリケーションを仮想アプリケーションとしてデプロイすると、例えばロード・バランシングや HttpSession 管理などの詳細な問題を処理する、あらかじめ組み込まれた共有サービス一式も利用することができます。

ただし、これらの自動化による利点には代償が伴います。それは、アプリケーションのトポロジー (例えば、同時に実行されるアプリケーション・サーバーの数や、どのサーバーがどのタイプの要求を処理するかなど) は、PureApplication System によって管理されることです。そのため、例えばアプリケーションを、サーブレットを実行する Web 層とリモート EJB を実行する EJB 層に分離することはできません。このことは、多くのアプリケーションでは問題になりませんが、多層構造のパッケージ化に依存する古いアプリケーションや、特定のアプリケーション・トポロジーの機能に依存する古いアプリケーションにとっては問題です。さらに、限られたプログラミング・モデルしかサポートされないという代償もあります。柔軟性が必要なアプリケーションのために、PureApplication System が仮想アプリケーションの他にサポートしているのが、仮想システムです。


仮想システムの利点と制約

仮想システムとは、仮想イメージで構成されたトポロジー全体のテンプレートあるいはパターンを作成するメカニズムです。仮想システムは、IBM 提供の Hypervisor Edition イメージを用いて作成することも、IBM Tivoli ICON ツールを使って、ベースとなる RHEL イメージから独自の仮想システムを作成することもできます。

仮想システムを作成するには、PureApplication System の「拡張・取り込み」機能を使用することもできます。この機能を使用する場合には、ある特定の仮想イメージにさらにソフトウェアを追加してから、後で使えるように再パッケージ化します。仮想システムを作成する際には、独自に作成したスクリプトを仮想システムに追加できるという点も、考慮すべき重要な事項です。作成済みのトポロジー・パターンにアプリケーションをデプロイするとしたら、そのデプロイメントが、仮想システム・インスタンスを PureApplication System ハードウェアにデプロイするためのインスタンス化プロセスの一環として行われるように、スクリプトを作成する必要があります。


適切な手法の選択

ほとんどの場合、PureApplication System にアプリケーションをオンボード (配置) するのは実際には複雑なプロセスではありませんが、PureApplication System でのマイグレーション・プロセスを最大限に利用する鍵は、アプリケーションをオンボードするための適切な手法を選択する必要性を理解することです。PureApplication System では、さまざまな方法でアプリケーションをデプロイできるようになっています。最も少ない作業量で最大のメリットを実現する結果となる手法を選ぶことが、このマイグレーション・プロセスで行う最も重要な決定事項です。既存の多くの ISV アプリケーションをオンボードしてきた経験のなかで私たちが発見したのは、以下の一連の質問に答えることが、適切な手法を決定する最も簡単な方法だということです。

  1. 新しいアプリケーションを構築しているのですか?

    この質問に最初に答えなければならない理由は単純に、最もシンプルで最も容易なデプロイメント・メカニズムを利用するためです。前に説明したように、PureApplication System で提供している最もシンプルなデプロイメント・モデルは仮想アプリケーションです。新しいアプリケーションを構築していて、アプリケーションの技術や設計に関する決定を左右できるとしたら、仮想アプリケーションに対応するアプリケーションになるような技術、設計を選択してください。

    けれども、ほとんどの場合、皆さんが日常的に扱っているアプリケーションは開発の余地が残されているアプリケーションではなく、確立された既存のアプリケーションであり、既存の環境ですでに実行されています。その場合には、次の質問を検討しなければなりません。

  2. それは Web アプリケーションですか?

    これは一見単純な質問のように思えますが、この質問の真意は、「インバウンド HTTP でのみリクエストを受け取るアプリケーションであるかどうか」です。Web アプリケーションの定義には多種多様なアプリケーション開発のパターンが含まれ、以下のアプリケーションのどれにでも当てはまります。

    • Javascript および Ajax 技術を使用して作成されたユーザー・インターフェースに RESTful なサービスを提供するアプリケーション
    • インターネット上の外部クライアントを対象に SOAP サービスを実装する Web サービス・プロバイダー
    • サーブレットと JSP で作成された従来の Web アプリケーション

    ただし、この Web アプリケーションの定義は、特定のアプリケーション・タイプを除外します。例えば、Java シック・クライアントが RMI または RMI/IIOP によってバックエンドの EJB に接続する Java クライアント/サーバー・アプリケーションは、この定義による Web アプリケーションには当てはまりません。それを考えると、次の質問につながっていきます。

  3. リモート EJB を使用しますか?

    EJB は誕生して以来、JEE プログラミング・モデルの有用な部分として使用され続けています。けれどもリモート EJB には、その利点の一方でアプリケーション・トポロジーの複雑さという点でのトレードオフが伴います。アプリケーション・サーバーがサーブレット、JSP、Web サービスへの着信 HTTP トラフィックだけでなく、EJB クライアントからの着信 RMI/IIOP トラフィックも処理しなければならないためです。これに対処するには一般に、2 層のアプリケーション・サーバーを構成し、一方のアプリケーション・サーバーが HTTP トラフィックだけを処理し、もう一方のアプリケーション・サーバーが RMI トラフィックだけを処理するという方法が採られます。しかし、仮想アプリケーションを使用した単純化のプロセスでは、このような多層構成のトポロジー・オプションを諦めざるを得ません。したがって、前述したようなリモート EJB が必要な場合には、多層構成のトポロジー・オプションを使用できる仮想システムを必ず使用するようにしてください。

  4. アプリケーションは標準的な方法でパッケージ化されていますか?

    これも、一見単純に思える質問です。「標準的な方法」とは、アプリケーションを EAR ファイル、WAR ファイル、ZIP アーカイブ、あるいは EBA (OSGi Enterprise Bundle Archive) としてパッケージ化することを意味します。ご存知のとおり、JEE 標準ではアプリケーションを EAR または WAR ファイルとしてパッケージ化することになっており、OSGi 標準では EBA アーカイブが導入されていますが、多くのアプリケーションはこれらの標準的な方法でパッケージ化をせずに、今でも「膨れ上がった」ディレクトリー構造として出荷されています。Tomcat のような単純なサーバーでは従来のパッケージ化でも上手く行くかもしれませんが、標準以外の方法に従っていると、仮想アプリケーションをサポートするような新しい JEE サーバーに移行するときに事態が複雑になってきます。したがって、この質問に対する答えが「いいえ」の場合は、アプリケーションを標準フォーマットのいずれかで再パッケージ化してください。同様に、WebSphere Application Server には、他にも利用できる多くのパッケージ化戦略があります。その一例はサーバーに関連付けられた共有ライブラリーですが、例によって、モデルの単純化を目的とする仮想アプリケーションでは、これらのパッケージ化戦略は使用されません。これらの方法でパッケージ化せざるを得ない場合には、仮想アプリケーションではなく仮想システムの使用を検討してください。

  5. アプリケーションには標準 JEE プログラミング・モデルが使用されていますか?

    かねてから、「標準に関して素晴らしい点の 1 つは、選択肢が豊富にあること」と言われています。プログラミング・モデルに関して言えば、この言葉が当てはまりますが、新しい API が急ピッチで導入されているなか、残念ながら Java コミュニティー・プロセスには、承認されることも、JEE 標準に公式に組み込まれるまでの支持を受けることもなかった JSR が溢れています。ここでも仮想アプリケーションを使用する場合に問題となるのは、物事をシンプルにしておかなければならないことです。したがって、アプリケーションでサポートする API を管理可能な一式に制限しなければなりません。アプリケーションで使用する API が、JEE5、J2EE1.4、1.3 または 1.2、OSGI、JPA、JAX-RPC、JAX-WS および JAX-RS による標準 API だけであれば、問題なく仮想アプリケーションを使用することができます。

    その一方、上記よりも新しい JEE レベル (JEE 6 など) に対応するアプリケーションを作成している場合、あるいは JCP の中に埋もれた不明瞭な API を使用している場合には、そのアプリケーションを仮想アプリケーションとして機能させるのはおそらく無理です。ただし、IBM では新しい API のサポートをフィーチャーパックによって提供するという手法をとっています。新しいAPI レベルをターゲットにしようと計画している場合には、WebSphere Application Server V8 を使用して仮想システムを作成し、該当するフィーチャーパック (および新しい API のサポート) を入手可能になった時点で組み込むという方法を検討してください。

  6. アプリケーションを現在 WebSphere Application Server のバージョン 7 またはバージョン 8 で実行していますか?

    これは容易に答えられるものの、重要な質問です。この質問には、検討の必要がある何通りかの答えがあります。この質問に対する答えが「はい」であっても、ここまでの質問のうち、プログラミング・モデル、パッケージ化、リモート EJB の使用に関する 3 つの質問のいずれかに対する答えが「はい」の場合には、もう結論は決まっており、アプリケーションを仮想アプリケーションにすることはできません。一方、今回の質問に対する答えが「いいえ」の場合には、仮想アプリケーションとしてアプリケーションを実行できる可能性はまだ残されており、プログラミング・モデルに関する質問とパッケージ化に関する質問に対する答えがいずれも「はい」であれば、仮想アプリケーションとして実行できる可能性があります。それでもアプリケーションがかなり前のバージョンのWebSphere Application Server や別のアプリケーション・サーバー上で実行されているとしたら、マイグレーション作業を初めに完了してからでないと、仮想アプリケーションまたは仮想システムのいずれかに移行できない可能性があります。

  7. アプリケーションに、WebSphere Portal Server や WebSphere Process Server などの WebSphere ファミリーの製品が必要ですか?

    前述したように、仮想アプリケーションの手法は、Web アプリケーションの構築をターゲットとした手法です。アプリケーションのタイプ (あるいは、「ワークロード」という用語を使用するのでも構いません) が Web アプリケーションでなければ、現行の仮想アプリケーションの手法では、そのアプリケーションにとって適切な手法にはなりません。これは純粋に、今の時点での話です。いずれは新しいワークロードのタイプが IBM Workload Deployer および PureApplication System に追加されていくはずです。その時点で、ビジネス・プロセス管理アプリケーションであっても、仮想アプリケーションが現在 Web アプリケーションに提供している以上の自動化を利用できるようになります。けれども今のところは、WebSphere ファミリーの製品が必要な場合には、PureApplication System または IBM Workload Deployer のオンライン・カタログの一部として出荷される IBM Hypervisor Edition 製品を組み込んだ仮想システムを作成するしか方法はありません。

  8. アプリケーションは、WebSphere eXtreme Scale によるセッション管理を利用できる状態にありますか?

    これまでの質問の多くと同じく、この質問にも多くの意味が含まれています。基本的には、最初に検討しなければならないのは、HttpSession API の使用についてです。多くのアプリケーションは完全にステートレスに作成されていて、HttpSession API をまったく使用しません。そのようなアプリケーションであれば、仮想アプリケーションに完璧に適しています。その一方、アプリケーションで現在 HttpSession を使用しているとしたら、その使用方法について多少考慮する必要があります。

    まずは、HttpSession のすべてのコンテンツが java.io.Serializable として宣言されていますか?宣言されていない場合は、問題があります。仮想アプリケーションの場合、スケーリング・ポリシーが従うモデルでは、アプリケーションで処理する負荷の量に応じて随時、アプリケーション・サーバー・インスタンスが動的に作成または破棄されます。サーバーは長時間稼働しているものであるため、サーバーのメモリーを、セッション情報を格納するための「安全な」リポジトリーであると見なしていると、仮想アプリケーションを実装しようとするときに、手痛い見当違いであることに気付くはずです。

    同様に、セッションがかなりの大きさ (数百メガバイト) である場合、WebSphere eXtreme Scale グリッドからネットワーク経由でセッションをロードするのにかかる時間に驚くかもしれません。逆に、HttpSession のベスト・プラクティスに従った、完全にシリアライズ可能な小さいセッションであれば、仮想アプリケーションを使用することができます。

  9. アプリケーションで外部セキュリティー製品を使用したり、TAI (Trust Authentication Interceptors) または JAAS プラグインのような特殊なセキュリティー API を使用したりしていますか?

    最後に検討しなければならないのは、アプリケーションに設けられるセキュリティー要件です。アプリケーションにセキュリティー要件がないか、あるいは単純に WebSphere セキュリティーを使用していて、なおかつサポートされているユーザー・レジストリー (TDS、Microsoft Active Directory) のいずれかを使用している場合は、システムを仮想アプリケーションとして実装することができます。一方、Tivoli Authentication Manager やその競合製品のいずれか、あるいは JAAS や TAI に類似の WebSphere 特有のセキュリティー機能を使用している場合には、仮想システムの作成を計画する必要があります。


適切な手法を適切なタイミングで選択する

考慮すべき重要な事項の 1 つは、アプリケーションにはライフサイクルがあり、単一のデプロイメント・モデルではアプリケーションの存続期間にわたって対応しきれない可能性があることです。例えば、あるアプリケーションを仮想アプリケーションとして開発環境およびテスト環境にデプロイし、最もシンプルなモデルで、その環境の構成パラメーター (JVM ポリシーなど) を正しく確実に取り込みたいような場合があるかもしれません。しかしその一方で、アプリケーションに最適化した本番環境を構築するためには、アプリケーションを仮想システムとしてデプロイしなければならない可能性があります。それと同じく、既存のアプリケーションを現時点では仮想システムとしてデプロイしなければならないとしても、アプリケーションのその後のバージョンでアプリケーションのコードを徐々に変更し、仮想アプリケーションとしてデプロイできるようにすることも可能です。


将来に向けた計画

アプリケーションが仮想アプリケーションに対応するかどうかを計画する際にできる最善のことは、単純に、時間をかけてそのプロセスの計画を練ることです。幸い、IBM ではこのプロセスを支援する準備を整えています。この質問に対して答えていくプロセスを通して、IBM Client Technical Professional では、皆さんの特定のアプリケーションにとって、どのデプロイメント・モデルが最適であるかがわかるように支援します。同様に、IBM Software Services for WebSphere でもアプリケーションのマイグレーション・サービスやその他のオファリングによって PureApplication System の導入を支援します。さらに支援が必要な場合、そして導入の際には、IBM 営業担当者にお問い合わせください。


まとめ

この連載の第 2 回では、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=WebSphere, Cloud computing
ArticleID=816725
ArticleTitle=IBM PureApplication System に対する準備: 第 2 回 アプリケーションを仮想化する準備はできていますか?
publish-date=05242012