jb weblogic guide - jp.redhat.com · 戦略的マイグレーションガイド weblogicからjboss...

戦略的マイグレーションガイドWebLogicからJBoss Enterprise Application Platformへ

戦略的マイグレーションガイドWebLogicからJBoss Enterprise Application Platformへ

www.jp.redhat.com/JBoss

2 www.jp.redhat.com/JBoss

戦略的戦略的マイグレーションガイド

目次

1. はじめに 3

プリプランニング 3

マイグレーション・プランニング・プロセス 4

2. マイグレーションにおける考慮点 4

マイグレーションの動機 4

マイグレーションにおいて考えられるシナリオ 5

コンフィギュレーションされたサービス群 7

マイグレーションにおける実装シナリオ 9

ハードウェア・マイグレーション 14

その他のコンソリデーション 19

3. 戦略的マイグレーションの概要 20

マイグレーション・プロセス・オーバービュー 20

フェーズ I：サーバ・アーキテクチャと実装モデル 21

フェーズ II：アプリケーション・マイグレーション・アセスメント 21

フェーズ III：必要な作業とリスクのアセスメント 23

フェーズ IV：サーバとアプリケーションのマイグレーション・プラン 25

フェーズ V：マイグレーションの実施 26

4. エンタープライズ・サービス 26

ミドルウェア・コンサルティング・サービス 26

プラットフォーム・コンサルティング・サービス 27

トレーニング 30

5. 最後に 32

3www.jp.redhat.com/JBoss


1. はじめに

企業のIT部門は、より高品質なソリューションを、より低いTCO（総所有コスト）で提供するという難しい課題に常に直面しています。オープンソース・ソフトウェアが求められている品質と安定したソリューションを提供するようになってきており、既存のエンタープライズ・アプリケーションを、多くの支持を集めているJBoss® Enterprise Application Platformなどへ移行可能であることも、広く一般に知られるようになってきました。

JBoss Enterprise Application Platformは、ビジネス・プロセス管理、SOA（サービス指向アーキテクチャ）、エンタープライズ・ポータル、データサービス・ソリューションなど、様々なビジネス課題に応えられるソリューションを包括的に提供しています。

プロプライエタリなテクノロジーからJBoss Enterprise Application Platformへ移行することで、プロプライエタリなJava EEソリューションに比べてのコスト削減、卓越したスケーラビリティ、サーバ環境のカスタマイズなど、企業のIT部門はこの他にも様々な恩恵を享受できます。またこの他にも：

• 業界の仕様に準拠：JBossは単にオープン・スタンダードのサポートを受けてきただけではなく、JPA、JSF、EJB、CDIなど、エンタープライズにおけるオープン・スタンダードのJava環境の発展に貢献してきました。オープン・スタンダードを利用したオープンな実装を基盤環境に用いることで、選択したプラットフォームの将来におけるリスクを大幅に低減することができます。

• コスト：JBossはOracle WebLogicと比べて導入初期費用が不要なのはもとより、サブスクリプションによるミッションクリティカル・サポートの提供を受けながら、TCOを包括的に削減することが可能です。初期費用が発生せず、またオープン・スタンダードにも準拠しているためJBossを利用すればベンダーロックインを避けることができます。JBossは1つのベンダーにロックインされてしまう心配を排除して柔軟性を与え、IT環境に対するコントロールを取り戻します。

• 柔軟性：JBossはモジューラ形式のエンタープライズJava環境のパイオニアであり、その第2世代マイクロコンテナ・モデルが運用におけるオーバーヘッドを削減し、実装における柔軟性を提供します。

JBossでは、イノベーションを生み出し、ユーザの要件に最も応えやすい"Release Early, Release Often"モデルに則ったコミュニティ・バージョンをプロジェクトで採用しています。適切なバージョンのオープンソース・プロジェクトが統合され、JBoss Enterprise Application Platformのようなエンタープライズ・クラスのソリューションとして応えられるよう厳格な検証プロセスを踏みます。

スムーズかつ成功裏にJBossへ移行するためには戦略的なレベルでの事前のプランニングが必要となり、マイグレーションにおけるリスクとコストを最小化するためには、そこに含まれている課題や問題点を把握できていなければなりません。本ドキュメントでは、もっとも重要だと思われる点をカバーし、また、幾つかのリソースと、マイグレーションを成功裏に完了するために必要なリファレンスを読者に提供します。

プリプランニング

JBossへの移行によるメリットを明確にするためには、マイグレーションを行う環境を完全に把握しつくすことが最初の重要なステップとなります。それらが選択肢、メリット、トレードオフに大きく影響を及ぼすため、実際に業務で利用されているソフトウェア・プラットフォームをなぜマイグレーションするのかを充分に検討する必要があります。また、実装時のシナリオを明確にすれば、様々な障害や問題、そして将来のニーズを把握することも可能になります。



マイグレーション・プランニング・プロセス

レッドハットでは、マイグレーションによって得られるメリットの明確化、様々なマイグレーションのシナリオに関連したリスクの特定、エンタープライズ環境の標準化、そして包括的かつ戦略的なエンタープライズ向けマイグレーション・プランの構築を実現するために5つのプロセスを確立しました。

このプロセスを使えば、企業のIT部門は以下が可能になります：

1. 既存のアプリケーション・サーバとプラットフォームの検証と、同等の環境を実現可能なJBoss EAPエコシステムの明確化

2. プロプライエタリな機能やネイティブ機能の検証と、JBoss EAPで提供できる同等の機能の明確化

3. 企業としての受け入れ状態と、マイグレーション・リスクの包括的な把握

4. 詳細なロードマップとコストの見積りを含む、戦略的マイグレーション・プランの作成

5. 戦略的マイグレーション・プランの導入と、サポート戦略の適用

この後、JBoss Enterprise Application Platformへの移行において必要となる検討事項とプロセスについて、詳細をご説明差し上げます。ぜひともこれらをチームの皆様でご共有いただき、マイグレーション・プランニングにお役立てください。レッドハットでは、これらの情報提供を通じ、皆様のマイグレーション・プランニングを成功に導くためのお手伝いをできればと考えております。

2. マイグレーションにおける考慮点

1つのアプリケーション・サーバから他のアプリケーション・サーバへの移行を企業が決定する際、その裏側には幾つかの動機があると考えれられます。コスト面での考慮やより多くのイノベーションの創出、また、異なるテクノロジーを備えたデータセンターの統合などが一般的なものでしょう。

マイグレーションの動機

• コスト • 柔軟性の提供

　　• アプリケーションを備えた分散型サーバの顧客への提供 • アウトソーシングの失敗

　　• CPU毎のライセンス費用の排除 • 企業統合や企業買収

　　• より安価なハードウェアと堅牢なクラスタ環境の採用 • データセンター統合

　　• サポートコストの低減 • RADテクニックの採用

• ハードウェアの拡張 • 最新技術や機能の利用

• 標準仕様への準拠 • パフォーマンス向上

• 統合やカスタマイズ • スケーラビリティの改善



その動機がどのようなものであれ、マイグレーション・プランニングの際はそれを念頭に置き、忘れないことが大切です。動機は実際の移行の際の優先順位付けや方法論の決定に役立ちます。動機は、マイグレーションにおいてどのようなシナリオを描き、いかにして実装するかを決定づける際の重要な要素です。もしも最新技術や機能の利用によるメリットの享受が主な動機なのであれば、マイグレーション・プロジェクトにおいて求めている機能を描き出し、構成を変更することでどれを実現できるか、また、どれがソースコードのアップデートを必要としているかを見極める必要があります。

マイグレーションにおいて考えられるシナリオ

一般的なWebアプリケーションのマイグレーション

サーブレットやJava EEの仕様に則って構築された一般的なWebアプリケーションのマイグレーションは、もっと容易で、費用対効果にも優れたスタート地点となります。また、必要となる事柄を見極める上での良い例にもなります。もしそのアプリケーションが、Eclipseなどのオープンな仕様に基づいたIDEで開発されていたなら、マイグレーションは極めてスムーズに行えるはずです。プロプライエタリなIDEはプロプライエタリなライブラリへのリンクを設けるため、マイグレーションの際にも更なる課題が浮上する可能性があります。

標準仕様に則ったWebアプリケーションにはweb.xmlと呼ばれる実装ディスクリプタが含まれています。アプリケーション・サーバは通常シンタクスとノーテーションを用いて制御を行っており、これはポーティングできません。レッドハットではこれらのドキュメント化に努め、特手のアプリケーション・サーバからJBossソリューションへのマイグレーションの際に変更が必要な箇所をリストアップ済みです。

また、付加価値的な機能を提供するために、ほとんどのアプリケーション・サーバに標準仕様に基づかない二次的な独自の実装ディスクリプタが含まれています。この二次的なディスクリプタは、WebLogic Server (WLS)ではweblogic.xml、JBossではjboss-web.xmlと呼ばれます。レッドハットでは、他のベンダーのディスクリプタにおいて特徴や機能がオーバーラップしている箇所をJBossがサポートしているjboss-web.xmlへ変換するためのXMLスタイルシートの保守を行っています。

既存環境

必要なJARをディレクトリもしくはEARへ追加

オープンな仕様

JMS、EJB、JPA等

フレームワーク

Hibernate、Spring、Seam、Flex、Struts、JBPM、ルール・エンジン、

ワークフロー・エンジン

JBOSS

オープンな仕様


アプリケーションからプロプライエタリなインポートを取り除いてマイグレーション



WebLogicで開発と実装が行われたWebアプリケーションのマイグレーションは、アプリケーションのアーキテクチャがどの程度プロプライエタリなものか、依存関係がどのような状態かによって多少は複雑になりますが、基本的にはとてもシンプルに行えます。多くのアプリケーションは、まったく手を加えることなく単純にコピーしてJBossへ実装することが可能です。Webアプリケーションのマイグレーションにおける一般的な障壁には以下のようなものがあります：

1. 展開済みのディレクトリとしてJBossへ実装する際には、そのディレクトリには拡張子として.warを付加する必要があります。WebLogicと同様の命名規則が用いられることはまれです。

2. ほぼ全ての場合において、WebLogicのWebアプリケーションにはweblogic.xml実装ディスクリプタがバンドルされています。このディスクリプタには付随的な構成情報等が含まれていることがほとんどであるため、参照しなくてもJBoss環境下で問題が発生することはありません。これが付随的な構成情報を提供していた場合、Webアプリケーションのコンテクスト・ルートやセキュリティ設定などシンプルなものがほとんどで、これらはJBoss環境下においてjboss-web.xmlファイルで提供することが可能です。

3. JSPタグライブラリやWebLogicヘルパー・クラス等、WebアプリケーションはWebLogicが提供するライブラリを利用していることがあります。ここで、利用されているライブラリの内容と振る舞いを正確に把握し、どのようなオープンソースの代替ソリューションへ置き換えるか等を明確にしなければならないため、マイグレーションに必要な労力は非常に大きなものとなります。

Java EEアプリケーションのマイグレーション

理論上、Java EEアプリケーションのマイグレーションは、ピュアなWebアプリケーションのマイグレーションと同様にさほど難しくはありません。しかしながら、Java EE仕様の性格上、様々な機能を提供するために複数のフレームワークと統合利用されている場合が少なくありません。そのため、実際の移行においては多くのミニ・マイグレーションが発生することになります。これに関してはJSRマイグレーションの章で、もう少し詳しく取り上げます。

マイグレーションするアプリケーション

App 1

App 1

App 2

App 3

App 4

App 5

Jakarta Commons 3.2

Apache

等

Hibernate 3.1

Hibernate 3.4

Spring 2.1

Oracle 10g データベース

等

App 2 App 3 App 4 App 5

アプリケーション

ライブラリ




Java EEアプリケーションの開発に際してプロプライエタリなIDEが利用されていた場合、プロプライエタリなクラスやインタフェースを拡張したクラスを生成している場合があります。JBoss MASSプロジェクトでは、アプリケーションのソースコードをスキャンしてプロジェクトなライブラリやインポートを特定する、MATと呼ばれるマイグレーション分析ツールを提供します。MATを利用することで、Java EEマイグレーションに必要となる工数をより正確に見積もるための貴重な情報を得ることが可能になります。

このツールは http://www. jboss.org/mass/MAT.html からダウンロードいただけます。

またJBoss MATは、サーバの構成、実装アプリケーション、クラスの依存関係をカバーする詳細なHTMLレポートを提供します。

高度なJSRマイグレーション

JSR（Java Specification Requests）は以下のエリアにおける標準化を目指した、Javaコミュニティによる取り組みです：

• Portal

• ESB

• Rules engine

• ワークフロー・エンジン

• Injection

各々のJSRにおいて異なるマイグレーション・パスが存在し、仕様の完成度によって、マイグレーションに必要な工数が大きく異なってきます。また、XMLを利用するのではなく注釈を用いていることが一般的です。

コンフィギュレーションの移行

WebLogicドメインは、管理サーバと1台以上のクラスタで構成されています。WebLogicドメインのコンフィギュレーション情報を取得するためには、管理サーバの中にあるdomainディレクトリを検証します。ドメイン中の各クラスタはJBossクラスタにマッピングされ、また、クラスタの外部で利用されているサーバはJBossのサーバ・インスタンスとしてマッピングされます。ドメインのコンフィギュレーションはdomainディレクトリ配下のconfigディレクトリに置かれており、詳細なコンフィギュレーションはconfig.xmlに記載されています（バージョン10.xのWLS）。

コンフィギュレーションされたサービス群

JWebLogic Serverは、実装されたアプリケーション群とコンフィギュレーションされたサービス群というコンセプトを持ちます。WLS

用語におけるサービスには、JBossによって実装可能なJDBCサービスやJMSデスティネーションが含まれます。これらは、全く異なる2

つのモデルを生み出すことになります：

WLSにおいて、JDBCやJMSなどのサービスはWebLogicの管理者がアドミン・コンソールを用いてコンフィギュレーションします。これは実稼働ラインと開発ラインの両方において言え、開発環境において開発者は、WLSの管理者として振る舞うことができます。これらサービス・コンフィギュレーションは最終的にはアプリケーション要件によって異なり、物理的にも論理的にもアプリケーションそのものとは分離されています。通常、アプリケーションの開発者はサービスの依存関係をドキュメント化しており、管理者はそのドキュメントに則って必要なサービスを設定し、アプリケーションが適切に稼働するようにします。



JBossにおいて、各サービス（例えばJDBCコネクション・プールやJMSキューなど）は各々のXMLファイルを用いてコンフィギュレーションされます。同じ種類の2つ以上のサービスは、可能であれば同じXMLを用いてコンフィギュレーションすることもできます。これによってコンフィギュレーションにおける柔軟性が生まれます。管理者は、提供されているドキュメントに則り構成するという、WebLogicと同じコンフィギュレーション方法を用いることができます。また、開発チームはアプリケーションに実装可能なXMLに詳細を記述したり、それらを同じフォルダにバンドル／アーカイブすることが可能です。後者の場合、自らのコンフィギュレーションの依存関係を含んだアプリケーションを構築できます。

JBossが提供するMAT（Migration Analysis Tool ）は、WebLogic環境を自動的に検証し、コンフィギュレーションされたサービス群のインベントリ・レポートを提供します。HTMLフォーマットで生成されたレポートは、アーキテクチャ・チームによるサービス要件のマップアウトと依存関係の特定を支援します。

JDBC

バージョン10.xのWebLogicにおいて、各JDBCリソースはそのドメインのconfig.xmlの中に<jdbc-system-resource>インサーションとしてコンフィギュレーションが記述されています。XMLの<target> では、そのJDBCコネクション・プールがどのサーバやクラスタに実装されるのか、そして、<descriptor-file-name>にはそのコネクション・プールのコンフィギュレーションの詳細が記述されています。WebLogic 10.xでは一般的に、JDBCコネクション・プールのコンフィギュレーションの詳細は、そのドメインのコンフィギュレーション・ディレクトリ配下のjdbcディレクトリに置かれています。

JBossでは、poolName-ds.xmlファイルの中や、各名前にマッチする*-ds.xmlファイルの中に、各コネクション・プールに対するデータソースXMLスニペットを作成するだけです。JBossのこれらデータソースXMLのコンテンツは、データソースのトランザクションにおける振る舞いやコネクションの詳細によって異なります。これらの詳細のほとんどは、そのWebLogicドメインのconfig/jbdcディレクトリ配下に置かれている、各々の*-jdbc.xmlファイルに記述されています。データベースに対するパスワードは暗号化されているため、マイグレーションは完全には自動化できません。適切な*-ds.xmlが提供されていた場合、これらは該当するJBossサーバやクラスタに反映され、同等のJBoss環境が提供されます。

JMS

10.xではより詳細なJMSコンフィギュレーションが行えるようになり、また、特定のJMSサーバのグループ化が可能になっています。この中には、JBoss内の各々のデスティネーションに対して割当てることが可能な、デスティネーションに対する永続化ストアなどが含まれています。WebLogicに含まれるJMSリソースは、config.xmlファイルに<jms-system-resource>インサーションとしてコンフィギュレーションが記述されています。XMLの<target> では、そのJMSリソースがどのサーバやクラスタに実装されるのか、そして、<descriptor-file-name>にはコネクション・ファクトリーや実際のデスティネーションを含むそのJMSのコンフィギュレーションの詳細が記述されています。

WebLogic 10.xでは一般的に、JMSリソースのコンフィギュレーションの詳細はそのドメインのconfigディレクトリ配下のjmsディレクトリに置かれています。通常、JBossにおいてJMSコネクション・ファクトリーは、そのJBossサーバのdeploy/jboss-messaging.sar/

connection-factories-service.xmlにファイルでコンフィギュレーションが記載されていますが、様々なサービスの実装アーカイブの一部としてコンフィギュレーションを保存することも可能です。デスティネーション（キューやトピック）では、各アプリケーションをサポートするためにコンフィギュレーションが必要となるのが一般的です。

JBossでは、自らのestination-service.xmlファイル中や、各名前にマッチする*-service.xmlファイルの中に、各々のキューやトピックに対するJMSデスティネーションXMLスニペットを作成するだけです。JBossのこれらデータソースXMLのコンテンツは、データソースのトランザクションにおける振る舞いやコネクションの詳細によって異なります。JBossのこれらのデスティネーションXMLファイルはMBean実装ファイルと似ており、MBeanコードは必要に応じてQueueServiceもしくはTopicServiceとなります。



デスティネーション・コンフィギュレーションの詳細は、そのWebLogicドメインのconfig/jmsディレクトリ内の各名前にマッチする*-ds.xmlファイルの中に記述されています。WebLogicにおいて、各々のキューやトピックのサーバやクラスタへの実装は、メインのコンフィギュレーションXMLファイル中の<sub-deployment>で指定されます。JBossサーバやクラスタでは、サーバの実装ディレクトリもしくはクラスタのメンバ・ファーム・ディレクトリへ対応するデスティネーションXMLファイルを格納することで実装が可能です。

クラスタリング

コンセプトとその目的はとても似通ったものであるにもかかわらず、WebLogicとJBossでクラスタリングのコンフィギュレーション方法は大きく異なります。

WebLogicのクラスタリングは、クラスタ・メンバシップとコンフィギュレーションの詳細の両面において、非常に静的なビューを提供します。コンフィギュレーションのオプションは限られており、クラスタリングにおける大部分がブラックボックス化されています。これによって生まれるシンプルさを求めているユーザも存在しますが、この範囲に納まらない要件を持つユーザにとって、これは非常にコスト高な結果となります。クラスタそのものは、各メンバのアドレスと共に管理サーバで静的に定義されています。

JBossにおいてクラスタはとても動的な存在で、名前とマルチキャスト・アドレスもしくはユニキャスト・アドレスによって定義されます。JBossインスタンスは、コミュニケーションのためのアドレスと当該クラスタ名を提供するこで、特定のクラスタに加えることができます。動的なプロビジョニング・シナリオを想定している場合、これにより非常に柔軟なクラスタ定義が可能になります。また、JBossのクラスタリングは、柔軟なコンフィギュレーションを実現し、コンフィギュレーション・パラメータをクラスタ・ユーザに公開するJGroupsを基に開発されています。様々なフレームワーク・テクノロジーもサポートしており、クラスタ・パフォーマンスのより詳細なチューニングも可能です。

キャッシュ・レプリケーション

クラスタ環境では、データ・インテグリティを保つために必要に応じたキャッシュが提供されていなければなりません。もっとも注目すべきは、HTTPセッションとエンティティ・ビーンのキャッシュです。JBossがオープンなスタックを採用し、非常に柔軟にコンフィギュレーションを可能にしているにもかかわらず、WebLogicはキャッシュ・コンフィギュレーションにおいてもブラックボックス・アプローチを取っています。

JBoss Cacheは、分散型トランザクショナル・キャッシュをエンティティ・ビーンとHTTPセッションへ提供するために使われます。様々なコンフィギュレーション・オプションを備えており、ニーズに応えるキャッシュ環境を提供できます。AOPを介したノン・シリアライゼーション・ベースのレプリケーションのような先進テクノロジーも、POJOキャッシュ機能によって利用可能です。通信のためのプロトコルもコンフィギュレーションが可能で、同期／非同期のレプリケーションや無効化にも対応しています。

マイグレーションにおける実装シナリオ

スループットとレイテンシのいずれを優先するのか

高スループットのためのサーバと低いレイテンシのアプリケーション・サーバとでは、そのコンフィギュレーションが大きく異なるため、高スループットを求めるアプリケーションと、低いレイテンシを求めるアプリケーションを分けることはとても重要です。タイムアウトや最大スレッド数、そしてその他の基本的なオプションは全く正反対の性質を持ち、各々混在させることはできません。



高いスループットを目標とした場合、システムのパフォーマンス全体を優先させます。この場合、各々のクライアントのリクエストには注目が払われません。例えば、4つのプロセッサコアのみを持つシステムにおいて、200の同時リクエストが1秒間における最適な平均並列処理数だとします。この場合、これよりも低い値ではシステムの稼働率が下がり、また、これよりも多くの同時リクエストがあった場合には過剰なコンテクスト・スイッチングが生まれ、全体のスループットが下がってしまいます。

スループットを前提にした場合、上述をふまえると同時リクエストの上限は200となります。300の同時リクエストが発生した場合、残りの同時リクエストを待ち状態にし、処理中のグループに続いてバッチ的に処理を行います。この方法を鑑みれば、2つ目のバッチに含まれるリクエストは、最初のものに比べてほぼ2倍の処理時間が必要になってしまいます。これによってレイテンシが発生し、2つ目のバッチからのリクエストはSLA（サービスレベル・アグリーメント）に違反することになります。レイテンシを発生させないことを優先するのであれば、システムが300の同時リクエストを受け付けられるようコンフィギュレーションも可能です。

仮説として、平均の処理時間が1.7秒になってしまうことが予想されるとし、2つ目のバッチが2秒ではなく1.7秒で終わっていればSLA

に違反していないとします。しかしながら、これではスループットは200tpsから176.5tpsにまで下がってしまい、また、継続的に300の同時リクエストがあった場合、システムが処理できる数は時間と共に減少していきます。

JBossは、無数の同時リクエストを処理可能な、大規模サーバ・ファームを構築できる堅牢なプラットフォームを提供します。

低いレイテンシ高いスループット



物理実装モデル

• 物理的に分かれたマシンにおけるWebサーバやアプリケーション・サーバ

Webサーバとアプリケーション・サーバ（サーブレット・コンテナ）の分離を推奨しているミドルウェア・ベンダーも存在します。高いライセンス費用と、これを避けるためのシンプルかつ安価なサーブレット・コンテナという課題は、これまでも頻繁に取りあげられてきました。

JBossはWebサーバをアプリケーション・サーバにエンベッドしているため、ライセンスに関する課題を考える必要のないオープンソース・モデルの恩恵を享受しつつ、ハードウェアの更なる有効活用を実現できます。ライセンシングの制限がない点を考慮すれば、プレゼンテーションとビジネスの両方のティアに物理的な個別のレイヤを設けることは再検討されるべきです。

これにより、JBossはハードウェア・リソースの更なる効率利用を実現できるため、場合によっては同じワークロードに応えつつ、ハードウェア要件を最大50%削減可能になります。またこれは、ハードウェアの選択とワークロードのマッチングにも柔軟に対応できることを意味します。セキュリティやコンフィギュレーションの分離、そして堅牢性の面など、物理的に分けられたティアが推奨される場合も少なくないことは、言及するまでもありません。

アプリケーション・サーバ

動的なWebサーバ(Tomcat)

アプリケーション・サーバ

動的なWebサーバ(Tomcat)



• アプリケーション毎に1つのアプリケーション・サーバを用意

この実装は以下のような場合の利用が考えられます：

• アプリケーションが、アプリケーション・サーバに対して特殊なコンフィギュレーションを求める場合

• 32bitのOSやJVMを利用しつつ、1つのアプリケーションにメモリサイズの上限まで割当てたい場合（32bitのJVMでは4GBが上限）

• 64bitのOSとJVM、より高度な分離環境を実現するコンフィギュレーションでは、複数のアプリケーションを1つのサーバへ実装することが推奨される

• ITガバナンスや規定によりアプリケーション毎にサーバを用意するのが好ましいとされる場合

スイッチ

サーバ 1

アプリケーション 1

サーバ 2


サーバ 3


サーバ 4


24



• 複数のアプリケーションで1つのアプリケーション・サーバを利用

様々な観点で、これはより効率的な実装であるということができます。分離された各々のインスタンスにメモリ割当てないため、各アプリケーションは未使用のメモリを有効に利用でき、レイテンシの最小化とアプリケーションのピーク時の利用に対応することが可能になります。特に他のアプリケーションのピーク時のワークロードを考慮する必要はありません。

• 複数のアプリケーション・サーバで1台のマシンを利用

1台のマシンに複数のJBossインスタンスを実装することも可能です。比較的一般的な実装モデルとしては、32bitのOSを持つマルチCPUのシステムにおいて、1つのJVMに対してより多くのメモリを割当てることができます。また、ハードウェア規模の制限や特殊なコンフィギュレーションを必要とする複数のアプリケーション、そしてフェイルオーバーが必要な場合にも利用されます。

ステートフルWebアプリケーションとステートレスWebアプリケーション

ステートフルWebアプリケーションは、ステータスを保存するためにコンテナで管理されたHTTPセッションを利用し、また、必要なHTTPセッションのレプリケートはアプリケーション・サーバ上でコンフィギュレーションされます。

負荷分散

サーバ 1





サーバ 2





サーバ 3





サーバ 4





90% 60% 90% 30%



JBossはステート・レプリケーションにも柔軟に対応します。クラスタード・キャッシュの標準のコンフィギュレーションにおいては、ステータスのレプリケーションはノード単位となります。Buddy Replicationを用いればより高度な設定ができ、ノードを1つ以上のBuddyに参加させ、フェイルオーバーの際に備えてステータスをバックアップ可能になります。これは、各ノードから他の全てのノードに対してステータスのレプリケーションが行われ、極めて多くのメモリを消費し、また管理が容易でない大規模クラスタで特に有効です。

ステート・レプリケーションは同期／非同期のいずれでもコンフィギュレーション可能です。前者は信頼性を、後者はパフォーマンスを優先します。

ステートレス・アプリケーションも、単にレプリケーション機能を利用せずにステートフル・アプリケーションと同じサーバ上で稼働させることができます。レプリケーションには一定のオーバーヘッドと、アプリケーションの状態で可変するオーバーヘッドが含まれていますが、ステートレス・アプリケーションの数の影響は受けません。

ハードウェア・マイグレーション

アプリケーション・サーバが、何らかの形でOSやハードウェアの縛りを受けていることもあり、クライアントは望むと望まざると、同じベンダーから提供されているアプリケーション・プラットフォームとOSやハードウェアを利用していることが考えられます。このような状況下では、JBossのマイグレーションに合わせてハードウェア・マイグレーションが行われることも少なくありません。

ハードウェアやOSのマイグレーションが必要なくとも、検討だけでも試みる価値はあります。また、アプリケーション・プラットフォームと同時にハードウェアやOS、もしくはその両方をマイグレーションすることには、賛否両論があります：

利点：

• 管理要員やテクニカル要員、QA環境やテストで利用するネットワークリソース等、ソフトウェアとハードウェアの両方のマイグレーションにおいてリソースの共有が可能

• 重複するテスト作業をなくし、時間と経費を節約可能。ハードウェア・マイグレーションで必要とする包括的なテストと環境の検証などのタスクは、プラットフォームのマイグレーションで既に必要となっている

不利な点：

• 2つのマイグレーションを同時進行させることは、それらを個別に行うのに比べてリスクを増大させるかどうかについては議論の余地があるが、明らかに1種類のマイグレーションを行うよりリスクは大きく、許容閾値を押し上げてしまう

• 2種類のマイグレーションを一緒に行うと変更箇所が曖昧になり、そのため、潜在的な問題の原因が容易に究明できなくなってしまう。同様の理由により、パフォーマンスの向上／阻害がどちらの影響によるものなのかの特定が難しくなる

ハードウェア・マイグレーションが必要なのか選択肢の1つなのかはさておき、それが行われる際には、コスト削減や、様々なメリットを生み出すサーバの物理的な実装アーキテクチャを再設計できるチャンスが存在します。

基本的に、コンソリデーション、分散、アグリゲーション、クラウド・マイグレーションの4種類の実装シナリオが存在します。これらのシナリオは互いに優劣を持つわけではなく、大規模なマイグレーションでは、特定のワークロードに応じて機能や運用上の特徴を適切なバランスで提供するために組み合わせて行われます。



ハードウェア要件

必用とされているのはハードウェア・マイグレーションなのか、もしくはソフトウェア要件の変更に伴うものなのかにかかわらず、まず、アプリケーションによる制約や要件を鳥瞰し直し、適切なハードウェアを選ぶことが大切です。要件には以下のようなものが含まれます：

• そのアプリケーションはミッションクリティカルなものか？

• どのようなSLAを維持するべきなのか？

• 保存されるデータはどの程度クリティカルなものか。また、どのようなストレージや冗長構成が求められているのか？

• そのアプリケーションにはどのようなネットワーク・トポロジが適切なのか。また、その通信環境の要件はどのようなものか？

• 必用とされている帯域幅は？

• JBossにはどのような種類のキャッシング機能を実装すべきか？

• JBossには、その他にどのような最適化やチューニングを施すべきか？

• レイテンシ対スループットにおいて、最適値は？

• メモリ容量はどの程度必要なのか。また、1つのJVMに対するメモリ容量はいくらなのか？

ハードウェアとその実装環境は、パフォーマンスに直接影響を与えます。例えば、仮想化は高いスループットや稼働率を実現し、その反面、レイテンシを増大させるのが一般的です。メモリヒープが大きくなれば、ガベージ・コレクションに必用な時間も増えてしまいます。このような場合には、より進んだガベージ・コレクション技術で対応することも可能です。

コンソリデーション

コンソリデーションというシナリオでは、数多くの稼働率の低いサーバ上のワークロードをより少ないシステムへと統合します。各々のワークロードを受け持つために、これらの新しいシステムではオープン・スタンダード・ベースのOSを走らせる仮想マシンを利用します。このタイプのシナリオは、戦略的な観点からシステムの仮想化に取り組んできたユーザの間で多く見受けられます。このシナリオでは、ユーザは仮想化テクノロジーを利用してシステム・リソースへのアクセスを管理します。

Red Hat Enterprise Linuxと x86

Red Hat Enterprise Linuxと x86

Sun 420R Sun 420R

Sun 420R Sun 420R

Sun 420R

Sun 420R

Sun 420R

Sun 420R Sun 420R

コンソリデーション・シナリオ



利点：

• ハードウェアの運用コストの削減

• データセンターの占有スペースを削減

• 仮想化の推進によりROIを向上

不利な点：

• プロプライエタリな仮想化テクノロジーに対する取得コストや、新たなベンダーロックインの発生の可能性

分散

分散というシナリオでは、大規模なシステム上の1つ以上のワークロードをオープン・スタンダード・ベースのOSが稼働する小規模なシステムへと分散します。このタイプのシナリオは、Enterprise Linux®の導入が進んでいる環境において多くとられます。ユーザは、小規模なユニットを用いて分散的にハードウェア・リソースを複数のデータセンターへ拡張できます。ラックマウント型の1U～4Uのシステムがよく利用されていましたが、現在ではブレード型のものの利用が増えてきています。

利点：

• 最新のx86ハードウェア・テクノロジーによる卓越したパフォーマンスを享受可能

• ハードウェア・リソースの拡張に対する投資額が低い

• リソースを柔軟に実装／再実装可能

不利な点：

• 適切に計画が立てられていないと、このシナリオでは運用コストが増大する

分散・シナリオ

Sun E25K Red Hat Enterprise Linux

と x86

Red Hat Enterprise Linux

と x86


と x86


と x86



アグリゲーション

アグリゲーションというシナリオでは、様々なサイズの多くのシステムのワークロードを、Enterprise Linuxを起動させることが可能な耐障害性を備えた大規模な1つのハードウェア・プラットフォームへマイグレーションします。このタイプのシナリオは、ユーザが既に特定のハードウェアへの大きな投資を行っており、また、そのプラットフォームを更に有効に活用し、Enterprise Linuxを運用している既存のプラットフォームを集約したいと考えている場合に多くみられます。ユーザはシステム・リソースのアクセス管理に、ハードウェア（LPARによるパーティショニング）を利用するのか、ソフトウェア（KVMやXenによる仮想化）を利用するかを選択できます。

例として以下のような3つがあげられます：

• Linux（IFL）セントラル・プロセッサ用の統合ファシリティを利用するIBM® System z®

• HP® Superdome®（インテル Itaniumベース）

• Fujitsu® Primequest®（インテル Itaniumベース）

利点：

• ハードウェア運用コストの削減

• データセンターの占有スペースの削減

• 既存のハードウェアを利用することROIを向上

不利な点：

• プラットフォームに対する投資が適切でないと、ハードウェア・コストが高いものとなってしまう

アグリゲーション・シナリオ

HP Superdome とRed Hat Enterprise Linux

Sun Fire V890 Sun Fire V890





クラウド・マイグレーション

クラウド・マイグレーションというシナリオでは、クラウド・コンピューティング環境上で稼働するオープンソース・ベースのOSへ、ワークロードをその数に関係なくマイグレーションします。クラウドそのものは、ユーザによって構築されたプライベート・クラウドもしくはAmazonやRackspaceが提供しているパブリック・クラウドを利用することになります。このタイプのシナリオはユーザにとってまだ新しいもので、自らの運用環境の全てをクラウド・コンピューティング環境へ移行しているユーザは極めて少数です。クラウド上では、各々のワークロードへ提供されるリソースに対し、非常に詳細な管理を行うことが可能です。

利点：

• 各々のワークロードに対し、必用に応じて柔軟にリソースを割当て可能

• ハードウェア・コストが不要（パブリック・クラウドの場合）

• 投資コストの低減により迅速なROIを実現（パブリック・クラウドの場合）

• ハードウェアの稼働率向上により、ハードウェアに対するROIを改善

• シンプルなクラウド環境により運用コストを低減可能

不利な点：

• クラウドそのものやネットワークの障害により運用環境へアクセスできなくなる可能性がある（パブリック・クラウドの場合）

• ユーザが所有していないシステム上でクリティカルなデータを保存し運用されるため、コンプライアンスや監査証跡の記録などが課題となる（パブリック・クラウドの場合）

クラウド・マイグレーション・シナリオ

Red HatEnterprise Linux-

based cloud

Sun Fire V890


Sun 420R Sun 420R

Sun 420R Sun 420R

Sun Fire V890



その他のコンソリデーション

Java仮想マシンによる実装との違い

理論的に、JVMによる様々な実装は同じ仕様を持っており、そのため、1つのJVM上で開発と検証が行われたアプリケーション・サーバは、シームレスに他のJVM上でも稼働させることが可能です。これはほとんどの場合あてはまる事実ですが、中には実装状態の違いで問題が発生する場合もあります。これらは、ベンダーによる仕様の誤った解釈や、解決策が用意されていない未知の問題に起因するものです。またそこには、仕様を正しく理解していない開発者の存在があります。予想していなかったJVMの振る舞いに直面した際、開発者は実際の振る舞いをテストしながら、その結果に基づいた予測によって開発を進めることが少なくありません。残念なことに、そのような予測が当てはまるのはその時点で開発者が目にしているJVMベンダーが提供しているそのバージョンだけに当てはまるものであり、仕様に沿うように厳格な検証が行われていません。JVMの実装における変更は多くの場合これらの予測を覆し、アプリケーションの予期せぬ挙動の原因となってしまいます。

クラスローダーの存在

Java EEの仕様ではクラスローダーと呼ばれる機能が用意されていますが、これがJava EEの移植性を妨げる原因にもなっています。最近ではほとんどの場合においてそれらの振る舞いをコンフィギュレーション可能であるにもかかわらず、Java EEの仕様ではホストしているアプリケーションがデフォルトでどのクラスをロードするかに対して自律的に管理します。デフォルトの振る舞いの違いだけでも多くの混乱が生まれてしまい、原因の究明には日数を要することとなります。

例えば、JBossにおけるクラスローダーモデルでは各々のライブラリの中に同じクラスがバンドルされた2つのWebアプリケーションを生み出せ、実際にはそのクラスのインスタンスを共有させることができてしまいます。これは、2つの異なったクラスローダーによってロードされるこの全く同じクラスが、実際には2つの異なるクラスとして扱われるWebLogicのデフォルトのクラスローダーとは全く異なります。

JBossにおいて2つのWebアプリケーションの2つのクラス間の静的なコンテクストは共有されますが、WebLogicでは別個のものとして認識されます。これらの振る舞いの異なりは、容易にトレースができない大きな問題を含んでいます。

関連した問題にはサードパーティ製ライブラリのバージョンのミスマッチがあります。アプリケーションには、すでにアプリケーション・サーバに搭載されているライブラリがバンドルされていることが少なくありません。しかしながらクラスローダーの振る舞いにより、バンドルされているバージョンが利用されたか否かが異なります。

少数のクラス構成の場合におけるエクセプションでは、ペアレント・ファーストがクラスローダーにおいて最も一般的な委譲の方法であることが忘れられがちです。これは、開発者がアプリケーション・サーバに異なるバージョンのそれらのライブラリがエンベッドされていることに気付かず、特定の例外処理を行うためにHibernateやStrutsなどの一般的に利用されているライブラリの特定のバージョンをバンドルし、結果として子となるクラスローダーがオーバーライドされてしまうことを意味します。この問題はライブラリのバージョン毎のファンクションの細微な違いで発生し、トラブルシュートは極めて難しいものです。



3. 戦略的マイグレーション・プロセス

マイグレーション・プロセスの概要

フェーズ内容成果物必要な期間

フェーズ I：サーバ・アーキテクチャと実装モデル

このフェーズでは既存のサーバやネットワーク基盤、そしてアプリケーションの検証を行う。ここでは、既存の機能やワークロードに関するキャパシティのベースラインを明確にする。

アプリケーション・サーバの利用方法とコンフィギュレーション、ネットワークのコンフィギュレーション、ハードウェアの種類や数。

2～4週

フェーズ II：アプリケーション・マイグレーション・アセスメント

このフェーズでは各々のアプリケーションの移行についてのアセスメントを行う。プロプライエタリなライブラリに対する依存性と、仕様に対する適応性を検証。

マイグレーションに適したアプリケーションのリスト化と優先順位付。アプリケーションが利用しているプロプライエタリなライブラリ。マイグレーションに必用な環境の仕様。

2～12週（アプリケーション数や複雑性により大きく変わる）

フェーズ III：必要な作業とリスクのアセスメント

このフェーズでは、アプリケーション・サーバとそれらのコンフィギュレーション、そして実装されているサービスを検証する。これにより、サーバのリプレイスに伴って必要となる機能が明確になる。各々のアプリケーションの移行において必用となる作業量とリスクをアセスメント。

サーバによってコンフィギュレーションされているサービスのリスト化。定義されているクラスタおよび各々のクラスタのコンフィギュレーション。各アプリケーションのマイグレーションに必用な労力の算出。各々のアプリケーションにおける主要なリスク要因の特定。

4～6週

フェーズ IV：サーバとアプリケーションのマイグレーション・プラン

このフェーズではサーバとアプリケーションのマイグレーション・プランを練る。ここでは先のフェーズで得られた情報をもとに、サーバとアプリケーションのマイグレーションに関するロードマップを作成する。ここにはプロプライエタリなライブラリやサービスに置き換わるオープンソース・ソリューションの定義も含む。

サーバのマイグレーション・プランでは各々のサーバ／クラスタにマイグレーションが行われるよう、サービスとコンフィギュレーションの詳細を確認。アプリケーションのマイグレーション・プランでは、各々のアプリケーションにおけるライブラリとコードの変更に関する詳細を確認。

5～8週

フェーズ V：マイグレーションの実施

このフェーズでは、新しい環境への実際のマイグレーションと実装を行う。Red Hat Consultingでは、実装と戦略的マイグレーション・プランを支援する様々なワークショップやトレーニング、そしてサービスを提供。

マイグレーションの完了 TBD



フェーズ I：サーバ・アーキテクチャと実装モデル

このフェーズでは既存のサーバやネットワーク基盤、そしてアプリケーションの検証を行います。これにより、既存の機能やワークロードに関するキャパシティのベースラインが明確になります。

基盤環境の分析

基盤環境にはアプリケーション・サーバの運用が行われている全てのエコシステムが含まれます。

• データセンター：どれだけの数の、どのようなミッションを持ったデータセンターがあるのか。またそれらは相互接続しているのか。データセンター間でフェイルオーバーを行っているのか

• ハードウェア：サーバ、ロードバランサ、ネットワーク・ルータ（クラスタ構成の場合）、データベース・サーバ、ファイル・サーバ

• ソフトウェア：ロードバランサ、静的／動的コンテンツを提供するWebサーバ、GUIなど

• その他のサービス：メッセージング、ポータル、AOP、インジェクション、キャッシングなど

• 開発環境：どのようなIDEをどのように利用しているのか。採用しているメソドロジーは何か

• アプリケーション：どのようなアプリケーションがサーバ上で稼働しており、どれがビジネス・クリティカルなのか

基盤に含まれるエレメント

データセンター 1つなのか複数なのか

ネットワークプロトコル、ルータ、DMZ

サーバ・ハードウェアロードバランサ、データベース、アプリケーション、Web

アプリケーション Web、Java EE、SOA

開発環境 Eclipse、JBoss Developer Studio、WebLogic Workshop等

ソース・コントロール CVS、SVN、GIT、ClearCase

ビルド Ant、Maven

フェーズ II：アプリケーション・マイグレーション・アセスメント

マイグレーションの全容をつかむためには、現在、アプリケーションやマイグレーション・ターゲットによってどのようなテクノロジーが利用されているのかを把握することが大切です。一般的なエンタープライズ・アプリケーションでは、セキュリティやキャッシング、そしてインジェクションで複数のテクノロジーを利用していることが少なくありません。これらのテクノロジーの多くは一般のアプリケーション開発者の目に触れるこが少ないため、開発者もその存在を意識することがありません。しかしこれらはアプリケーションのパフォーマンスとスケーラビリティに大きな影響を及ぼします。

これらのテクノロジーのマイグレーション・プランに失敗するとは、大きな問題につながります。これらの問題は、一般的にマイグレーション・プロジェクトの最終局面でパフォーマンス・テストが行われた後で表面化します。これらを考慮すると、単にテクノロジーのアセスメントを行うだけでなく、利用されている機能を確認して、最も適した代替ソリューションを見つけ出すことが大切です。



一般的なアプリケーション・サーバ・マッピング

コンポーネント考慮点 JBoss EAP

監視と管理リモートからのコントロールとコンフィギュレーション、閾値を超えた場合のアラートなど

JBossアドミン・コンソールによる標準JMXインタフェースの提供と、スラッシュホールド・アラート

Webサーバーサーブレット・コンテナ、ステート・レプリケーション TomcatへのJSPとサーブレットの仕様のインプレメンテーション、詳細なインメモリのレプリケーション

メッセージングトランザクションへの影響度合、メッセージングの持続性、クラスタ外部でのブリッジング、JMSの仕様

JBossメッセージングによるメッセージ配信とリバンランシング、持続性と安定したトランザクションの実現

キャッシングトランザクション、分散型、オブジェクト・グラフのサポート

JBossキャッシュによるシリアライズとAOPベースのレプリケーション

クラスタリングとレプリケーションレイヤード・レプリケーション、トランザクション・セーフ・レプリケーション、詳細な調整

JBossクラスタとJGroupsの組み合わせによるコンフィギュレーションのレプリケーション

接続性サポートしているデータベースやファイルシステム、ハイブリッド・データストア、トランザクションのサポート、データベース機能のサポート

JDBCコネクション・プール、Hibernate、セキュリティ・データストア、トランザクショナル・データストア

セキュリティ認証と承認、シングル・サインオン、JAAS/JACCのサポート、証明書のサポート

JAASに準拠したログイン・メソド、フラットファイル、データベースとLDAPのサポート、SSOのサポート

アスペクト・オリエンテッド・プログラミング

様々な要件を視野に入れる JBoss AOP

インジェクション標準インジェクション・サポート Java EEインジェクション規格のサポート

プレゼンテーション・レイヤ：JSP、JSF、Facelets、タグ・ライブラリ

プレゼンテーション・レイヤ規格との互換性とサポート標準規格や仕様のサポートおよびインプレメンテーション

トランザクション・マネージャ信頼性を備えたトランザクション・ビヘビア、分散型、最新テクノロジーのサポート

JBossトランザクションによる、信頼性の高いトランザクション、分散型、Webサービスにおけるトランザクション規格のサポート

アプリケーションの開発中に利用されたプロプライエタリなライブラリの特定は、アプリケーションのマイグレーションにおける重要なエレメントの1つです。JBossは、オープンソースのライブラリへと移行が可能なプロプライエタリなコードの量を調査するMAT

（Migration Analysis Tool）を提供しています。このツールは下記のURLから行えます：

http://community.jboss.org/wiki/JBossMASS-MigrationAssesmentTool-GettingStarted

詳細な情報は、下記のWebページを参照してください：

http://www.jboss.org/mass/MAT .html

次のステップは、必用なコンフィギュレーションの明確化、そして既存の機能とオープンソースが提供できる機能とのギャップの明確化です。ほぼ全ての場合において、そのまま、もしくは比較的マイナーなカスタマイズで、同様の機能を提供できるオープンソースが存在します。

アセスメントは各アプリケーションのマイグレーションにおける阻害要素に焦点を当て行うことが重要です。マイグレーション・プロセスは簡単なものから最も難しいものへとプランされるべきです。最も簡単なものから手をつけることにより、ナレッジが培われ、実施チームの間にも自信が生まれます。



フェーズ III：必要な作業とリスクのアセスメント

実装アーキテクチャを推考し、マイグレーションに含まれるアプリケーションとテクノロジーを把握した後、いよいよマイグレーションにおいて必要となる作業とリスクのアセスメントに入ります。テクニカル面と組織面の両方のコンポーネントが、必要な作業とリスクのアセスメントの対象となります。

先のセクションにおけるテクニカル・アナリシスを利用して、技術面における必用作業とリスクのアセスメントを行います。

焦点となるのは：

1. テクニカル・アナリシス

• スコープ

• マイグレーションに含まれるサーバ数、データセンター数、アプリケーション数

• テクノロジーのギャップに対するアナリシス

• オープンソースの代替ソリューションにそのままでマッピングできない機能

• コンフィギュレーション要件の矛盾点

• アプリケーションの仕様

• プロプライエタリなライブラリをエンベッドするIDEの使用

• ライブラリの選択

2. 組織面のアナリシス

組織面での要素は、一般的にテクニカル面での様々な要素に影響を及ぼしています。テクニカル面での要素は比較的容易に特定が可能ですが、組織面における要素はなかなか表面化しないため、問題になることが少なくありません。一見容易に見えるハードルも、組織側が何も対応策を用意していなかったり、変更を望んでいなかったりした場合には、大きな障害になってしまうこともあります。様々な課題に対応できるプランニングでなければ、組織は短期的な視野に入ってくるマイナーな問題点だけに焦点をあわせてしまいがちで、オープンソースへのマイグレーションによって得られる、長期的なメリットを見逃してしまいます。

組織面におけるリスク要因に対応するための最初のステップは、組織が抱えいる問題点とそれに付随するリスクの分析です。これによって、マイグレーションのために組織がどのような準備をすれば良いのかのロードマップを得ることができます。組織は以下の点に考慮を払う必用があります：

• ナレッジ・ギャップとトレーニング • カルチャー面に関して

• スタッフはテクノロジーに対して精通しているのか、それとも単に既存のツールに慣れているだけなのか？

• 開発ソフトウェアと実装ソフトウェアの運用についての組織の受け入れ態勢は？

• 意思決定のボトムアップ vs トップダウン• 必用経費に関する品質重視 vs コスト重視• 最新テクノロジー vs 枯れたテクノロジー

• ワークロードに関して • 予算

• 現在のスタッフは今の業務をこなしながら、トレーニングやマイグレーション作業に従事できるのか？

• 実装に必用となる充分なハードウェアが用意されているか実稼働ラインへ新しいサーバを投入する前に検証はできるか？

• 設備投資（CAPEX） vs 運営費（OPEX）• 総所有コスト（TCO） vs 投資回収率（ROI）



これらの考慮点をマイグレーション・プランの中に加味しておくことで不慮の問題の発生を防ぐことができ、円滑なマイグレーションが可能になります。

SWOT（Strength／Weakness／Opportunity／Threats）アナリシスは、組織のマイグレーションへの準備の度合を見極めるのに役立ちます。組織自体の強さ（Strength）と弱さ（Weakness）、機会（Opportunity）と脅威（Threats）を比較し、組織自体の強さを活かして弱さを克服できるプランの開発を可能にします。

SWOTアナリシス

STRENGTH

• ITスタッフが、関連した規格／仕様やテクノロジーに対するトレーニングを受けた

• ITスタッフのJBossに対する造詣が深くなっていっている• アプリケーションがWARやEARに則ったフォーマットになっている• オープンなIDEで開発を行っている

WEAKNESSES

• 予算の削減• プロプライエタリなIDEに依存した開発

OPPORTUNITIES

• 予算のカット• ライセンスの更新が近づいている• 現在のライセンスの範囲を超えたキャパシティ増強が求められている• 企業買収や標準化推進によって、複数プラットフォームの統合が求められている

THREATS

• 実装における標準化が行われていない• トレーニングのための予算がない• 現在、全てリソースが完全に利用されてしまっている• マイグレーションのためのキャパシティ拡張に充てる予算がない

3. マイグレーション・リスクのアセスメント

あらゆるマイグレーションにリスクは付き物です。リスクを正しく理解して予めそれに備えることで、マイグレーション作業を阻害するリスクを最少化できます。JBossでは、マイグレーションに必用なトレーニングとコンサルティング、そしてツールを提供しています。

マイグレーションに必用なスキルは、インターナルで培ってもあまり有益なものではありません。マイグレーションに必用な作業は、単にインターナル・チームをその遂行のためにトレーニングするだけでも非常に負荷のかかるものであるため、企業は社外の専門家に依頼するのが一般的です。

リスク発生する可能性インパクト戦略

トレーニング予算高高マイグレーション作業をサポートするためのトレーニングやワークショップの提供

ステージング・ハードウェア

中中コンフィギュレーション、アプリケーション、インストレーションを検証するためには、実稼働ラインと同等／同様のハードウェアを用意することが求められる

プロプライエタリなIDEツールの利用

中高 WebLogicやWebSphereが提供するツールは、プロプライエタリなライブラリを多用する。これらがコードを生成する際は、プロプライエタリなクラスをエクステンド／インプレメントしたクラスを生成するJBoss MASSプロジェクトとMATを利用すれば、プロプライエタリなライブラリ等に起因する課題を特定可能



フェーズ IV：サーバとアプリケーションのマイグレーション・プラン

マイグレーションにおける作業内とリスクが明確になった後は、SOE（Standard Operating Environment）をどのように設計していくかを考えることが、とても重要になります。SOEはコアとなるOSやミドルウェアのインプレメンテーションに際しての、組織における標準仕様です。この中には、基本となるOS、Java EEコンテナ、独自のコンフィギュレーション、組織で利用される標準アプリケーション、ソフトウェア・アップデート、サービス・パックなどが含まれることになります。

アプリケーション・セットの定義が終わると、円滑かつ一貫性を保った実装を実現するために、SOEアプローチに基づいて標準化されたコンフィギュレーションが作成されます。SOEコンフィギュレーションには、検証済みのハードウェアとソフトウェア、そしてJBoss環境内へ実装する際のコンフィギュレーションが含まれています。SOEコンフィギュレーションはテクニカル要件やビジネス要件に完全に沿ったものとなっているため、実装に必用な時間の大幅短縮ができるだけでなく、保守の簡素化、安定性の向上、サポートと管理コストの削減に貢献します。

場合によっては複数のSOEが必用になる場合もあり、マイグレーション・プランの次のステップでは、マイグレーションしなければならいアプリケーションに合わせて、異なるいくつのサーバ・コンフィギュレーションが必要なのかを見極める必用があります。スループット対レイテンシ、特定の実装要件、特定のワークロードに対応するための特殊なハードウェアの必要性など、アプリケーション毎で競合するコンフィギュレーションを持つ場合があるため、複数のサーバ・コンフィギュレーションが必用になることは少なくありません。重要な点は、システム環境における機能面、そして機能面以外での要件を満たしながら、コンフィギュレーションの数を可能な限り少数に収めることです。

必用となるコンフィギュレーション数が確定した後は、どのアプリケーションをどのサーバに実装するかを決めることになります。この時点で、各々のアプリケーションのコンフィギュレーションが実際に始まります。各アプリケーションは、異なるクラスローダー、インターセプタ・スタック、URL、その他多くの構成オプションを用いて、コンフィギュレーションされます。

先のアセスメントの結果で得られた、ナレッジ・ギャップを埋めるためにスタッフに提供するトレーニングのプランも行います。アプリケーションのマイグレーション・スケジュールを確定する際には、そのマイグレーション作業に必用となるナレッジに対するトレーニングもその中に含んでおくべきです。トレーニングを予めスケジュールの中に含んでおけば、問題に遭遇したマイグレーション・チームも当面の対処が行え、その後で関連したテクノロジーに対するトレーニングを受ければ、マイグレーションをより効果的に進めていくことが可能になります。

次に行うのがコストの算出とタイムラインの最終確定です。コストの算出は以下の点に着目して行います：

• サーバやコンフィギュレーションの検証で利用される、ステージング用ハードウェアに関するコスト

• プロプライエタリなソフトウェアから移行した際のギャップを埋めるために必用な、既存のオープンソース・ソフトウェア用の拡張機能の開発コスト

• マイグレーションするアプリケーションは、ソースコードの変更が必用なのか、それともコンフィギュレーションの変更だけで対応できるのかに分けてグループ化してコストを算出する。

• トレーニング・コスト

• ソフトウェア数の削減によって節約できる金額

• ハードウェアを再実装によって節約できる金額



フェーズ V：マイグレーションの実施

マイグレーション・プランが確立された後、関連した1つ以上のプロジェクト・プランを策定し、実施するのが有効です。マイグレーションで必用となるトレーニングと利用可能なリソースを確保しながら、マイグレーション・プランを確実に消化していくために、それらプロジェクト・プラン中のメジャー・マイルストーンは重要な役目を果たします。

レッドでは開発や製品、そしてサポートやコンサルティングだけでなく、マイグレーションを成功に導くための支援や一般／独自のトレーニングを提供しています。

4. エンタープライズ・サービス

現在のような経済状況では実装されている既存のテクノロジーを最大限に活かし、更にコストを削減することがとても重要です。投資の速やかな回収や、より円滑なマイグレーションを実現できるよう、Red Hat Enterprise Consulting Servicesでは、専門家の手配やナレッジ・トランスファーを提供しています。

専門家によるエンタープライズ・クラスのコンサルティングの提供

Red Hat Consultingは、実績のあるベスト・プラクティスと豊富な経験を持つレッドハットのコンサルタントが提唱する移行手法で、ニーズに応えるミドルウェア・マイグレーションを実現します。レッドハットをご利用いただくことで、リスクや移行に必用となる時間の削減が可能となり、結果としてマイグレーションに必要なコストが削減できます。レッドハットのコンサルタントはマイグレーション・チームへ必用なナレッジを確実に提供し、IT運用への影響を最小限に抑えることを念頭にして対応します。

Red Hat Consultingは、サブスクリプション契約を最大限に活かし、More with Lessを実現するための豊富な経験と実績を備えています。レッドハットのコンサルティング・チームには、世界中のアーキテクトと、JBoss製品に特化したエンジニアが含まれています。これまで何年にもわたってJBoss Application Serverを様々な環境に導入してきたこれらのエンジニアが、常に最高のパフォーマンスと投資効果を引き出すお手伝いをします。

生産性とパフォーマンス向上のためのトレーニング

ITスタッフの経験値向上のための投資によって、システム・パフォーマンスの最適化と生産性の向上、そしてマイグレーション・リスクの削減が実現します。数々の称賛を受けているレッドハットのトレーニングが、ITスタッフのスキルを向上し、オープンソースの実装に対する深い造詣と確かな技術を培います。

ミドルウェア・コンサルティング・サービス

Red Hat Consulting Servicesと契約を結ぶことで、レッドハットが長年培ってきた、オープンソースやプロプライエタリなソフトウェア・プラットフォームへのJavaベースのミドルウェアの開発と実装の経験値の恩恵を享受することが可能になります。特にプロプライエタリなミドルウェア・プラットフォームに関する知識と経験は、既存のポートフォリオからJBossプラットフォームへ移行する際、Red Hat

Consultingがアプリケーションのポーティングにおける潜在リスクとコストの特定を可能にします。Red Hat Consultingは、JBossプラットフォームに対する独自の経験値を有しており、マイグレーション後のアプリケーションが現在だけでなく、将来のバージョンのJBossプラットフォームでも動作するこを確実にします。



Red Hat Consultingでは、JBossプラットフォームへのマイグレーションに関連した以下のような様々なサービスを提供しています：

• マイグレーション・アセスメント：既存のアプリケーションを全て検証し、コストの算出とリスクの特定、そしてJBossプラットフォームへ移行するのに必要な詳細な見積りを作成します。

• アプリケーションのマイグレーション：プロプライエタリなミドルウェア・システム上の既存のアプリケーションを、ライセンス費用の削減、ベンダーロックインの最小化、オープンスタンダードへの準拠を推進する、オープンなJBossプラットフォーム上で利用できるように変換します。

• アーキテクチャのレビューと推奨要件の定義：JBossの利用とアプリケーション開発に関するガイダンスを継続して提供します。将来のバージョンのJBossプラットフォームでの採用が予定されている機能や仕様に準拠していけるよう、テクニカル・ロードマップの作成を支援します。

マイグレーションに求められている要件は千差万別であるため、Red Hat Consultingではお客様の既存の環境の理解に努め、お客様が現在お使いのアプリケーションをJBossへ確実に移行し、将来にわたって利用／拡張し続けていけるよう、最適なスコープでのマイグレーションを提案します。Red Hat Consultingは、開発ツールと実績を備えた方法論、そして数多くの実際のマイグレーションで培ってきた経験値をもとに、円滑かつ安全なプロセスでお客様のマイグレーションを成功へと導きます。

プラットフォーム・コンサルティング・サービス

マイグレーション作業においては、拡張性を提供可能な堅牢な基盤環境を用意することが最初のステップとなります。レッドハットの基盤環境マイグレーション・プランニング・サービスでは既存のIT環境を詳細に検証し、お客様がマイグレーションする際に、そのIT基盤を簡素化できる最善の推奨環境を提案します。

レッドハットでは、お客様の環境をビジネスに応じて確実に成長できるよう、マイグレーションを成功に導く堅牢な基盤環境をSOEアプローチに基づいて提供します。

SOEのメリット

• アーキテクチャの簡素化：異なるブランチやサービスに実装可能なOne Codebaseで、同じビルド・プロセスを用いて異なるプラットフォーム（ワークステーション、サーバ、）をサポート

• 柔軟かつ迅速な実装：ベアメタル状態から10分以内に完全にコンフィギュレーションや全く同じコンフィギュレーションを保証し、また、異常の発生や、各マシンの比較を容易に行える集中管理用GUIインタフェースを提供

• セキュリティ：異なるマシンや分散したデータセンターにセキュリティ・ポリシーを適用

• カスタマイズ可能な管理環境：異なる機能を有する異なるタイプのマシンをリモートから管理可能。また、属性に応じて権限を委譲する機能も提供

コンフィギュレーションの集中管理：コンフィギュレーションの適用、コンフィギュレーションの定期アップデート、コンフィギュレーションの比較、現在コンフィギュレーションの確認機能を提供



システム管理：既存のシステム管理基盤の評価とドキュメント化を図ります。マイグレーション後のシステムとソフトウェアの管理、そしてRed Hat Enterprise Linuxが既存の変更管理プロセスやシステムと連携していくかを基に、推奨要件が提案されます。

サービスには以下が含まれます：

• ベアメタル・プロビジョニングと仮想プラットフォームのプロビジョニング

• Linuxソフトウェアのビルドと実装

• 監視、パフォーマンスの管理

アイデンティティ管理：既存のアイデンティティ管理ポリシーの内容確認とドキュメント化を行います。Red Hat Enterprise Linuxを既存の認証と承認基盤へ統合、また既存のディレクトリ・ソリューションをオープンソース・ソフトウェアへマイグレーションするための、推奨要件が提案されます。


• userおよびgroupの管理

• PKI基盤

• ポリシーの策定と適用

データ管理：マイグレーションされるサービスの可用性に対する要件について、内容確認とドキュメント化を行います。アーキテクトがストレージとクラスタリング技術を組み合わせ、要件に応えられる戦略を練ります。

システム管理アイデンティティ管理

データ管理セキュリティ管理

SOE（Standard Operating Environment）の構成図




• 高可用クラスタ

• 分散型ファイルシステム

• 負荷分散ソリューション

• ディザスタリカバリ

• システムおよびデータのバックアップ

• データ・リカバリ

• ベアメタル・リカバリ

セキュリティ管理：マイグレーションするサービスとLinux環境に向けて、既存のセキュリティ・プラクティスとセキュリティ製品の検証とドキュメント化を行います。エンドユーザ対するセキュリティ要件の網羅的な理解が求められます。


• OSの強化

• 緊急のセキュリティ・エラータに対するパッチ適用

• セキュリティ監査とレポート

• 法令遵守に対する取り組みと対応策の提供

上述の各エリアにおいて、Red Hat Enterprise Linux OSがサポートしているプロセスと、既存のインフラストラクチャに含まれている他のOSがサポートしているプロセスのアセスメントとギャップ・アナリシスが行われます。このアナリシスは、業界規格に基づいたプラクティスと実績を備えたメソドにて行われます。

これらによって享受できる大きなメリットの1つは、レッドハットがお客様のチームと共に直接のナレッジ提供やリアルでのナレッジ共有、そして、問題が発生した場合や質問があった場合に、貴重なガイダンスをその場で提供できることにあります。

Red Hat Consultingではあらゆるニーズに応えられるソリューションを包括的に提供し、実装ライフサイクルのどのようなフェーズにあろうとも、ビジネスが逸早く投資を回収できるようにします。

Red Hat Consultingソリューション概要

アセスメント実績あるベスト・プラクティスとRed Hat Consultantsの専門家が安全で確実なマイグレーションの計画を行います

クイック・スタートプロジェクトを速やかに進め、貴重な時間を節約します。

インプレメンテーションインストールやコンフィギュレーション、そして実装の全てを行います。

ヘルスチェックビジネスに対する問題が発生しないか、インストールとコンフィギュレーションの検証を行います。

最適化生産性の向上とコストの削減を目指し、トラブルシュートと問題の解決に取り組んでいきます。



お客様がすでにマイグレーションをご検討中であれば、メールでご連絡ください。レッドハットがどのように、ベストなサポートをご提供させていただくか、詳しくご説明差し上げます。

[email protected]

トレーニング

マイグレーションの際、当初の実装状態から最高のパフォーマンスへと導くためには、スタッフが適切なスキルを備えていることが重要な鍵となります。フェイス・トゥ・フェイスでトレーニングを実施すれば、企業に応じた最適な管理テクニックや効果的なトラブルシュートを提供することができ、また、システム全体を包括的に保守することで生産性を向上することが可能になります。トレーニングは迅速かつ最適な実装を実現し、スタッフの皆様が必用なナレッジを確実に手にしてIT部門が円滑に機能できるよう支援します。

レッドハットでは、教室、企業のオンサイト、オンラインでJBoss Enterprise Middlewareに対するトレーニングを包括的に提供しています。全てのコースはJBCI（JBoss Certified Instructors）によって基本的なコンセプト・ベースのレクチャーから、実際の現場における実作業やプロジェクトの遂行に根ざしたものまで、バランスのとれた授業が進められます。経験値の度合いや最終的なゴールに関係なく、Red Hat Trainingでは業界内で培ってきた経験を伸ばし、そして活かす、適切なコースとトレーニング・パスを提供します。

提供方法：

レッドハットのパフォーマンス・ベースのトレーニングは、ITプロフェッショナルがオープンソースを利用した基盤環境を設計、運用、保守する際に必用となる、実際の現場に根ざしたスキルをフェイス・トゥ・フェイスで提供します。

詳細は www.jp.redhat.com/training をご参照ください。

認定資格：認定資格は実際にどれだけのことに応えられるかの指標となり、また、経験を備えたプロフェッショナルとして、マイグレーション戦略をより強固なものへと変えます。JBCAA（JBoss Certified Application Administrator）は、このカテゴリにおける唯一のパフォーマンス・ベースの認定資格で、直接のスキル・アセスメントでITプロフェッショナルのスキルのベンチマークを行います。

詳細は www.jp.redhat.com/training/certification/jbcaa/ をご参照ください。



コース：以下の表は、Red Hat for JBoss Enterprise Middleware向けに一般に提供されているコースの一覧です。お客様のニーズの応じたカスタマイズコースも賜っております。

コース

JBoss Application Administration (JB336)

レッドハットの最もポピュラーなJBossコースであるJBoss Application AdministrationコースはJBoss Application Serverのインストールと実装、また実稼働ラインでの運用に向けたコンフィギュレーションについて焦点を当てたコースです。

JBoss Enterprise Application Development: (JB295)

エントリーレベル～ミドルレベルのJava開発者向けのJBoss Enterprise Application Developmentコースは、JBoss Java EEフレームワーク、仕様、APIについての知識を提供します。

Advanced JBoss Enterprise Development (JB325)

Advanced JBoss Enterprise Developmentコースでは、Java EE APIの高度な利用に焦点を当て、JBoss Enterprise Application Platform（EAP）のより進んだ利用方法について学びます。

JBoss Seam Development (JB311)

JBoss Seam Developmentコースは、どのようにすればJBoss Seamを効果的にインテリジェントな方法でコンポーネントを連携させることができるか、そして、複雑化が進むITシステムをいかに効率的に管理できるかについて学ぶ、経験を持ったJava開発者向けのコースです。

JBoss Hibernate Technology (JB297)

JBoss Hibernate Technologyコースでは、パワフルなJava Hibernate Application Stackを使いこなすための知識とスキルを提供するJava開発者向けのコースです。

JBoss Enterprise SOA (JB341)

JBoss Enterprise SOAコースでは、実際の現場における例や統合パターン、そして標準化されたサービス・ベースのアーキテクチャスタイルを利用してエンタープライズ・システムとレガシ・アプリケーションとを統合するための方法を開発者に提供します。

レッドハットのトレーニングの専門家がスタッフの皆様にどのようなレベルの、どのようなトレーニングが必用かを見い出すためのお手伝いをします。お客様のニーズに応じたトレーニング・プランの作成は [email protected] までお問い合わせください。



5. 最後に

そのサイズやスコープに関係なく、全てのマイグレーション・プロジェクトを成功に導くためには詳細な計画を立てることが重要です。プロジェクトで得られた純粋な改善の度合いや、IT投資に対するROIを正確に知るためには、リスクや節約できる経費、またマイグレーション・プロジェクトにおけるコスト・ストラクチャを理解することが重要となります。

このガイドブックで詳説されている検討課題やプロセスは、マイグレーションで享受できるメリットを明確化し、様々なマイグレーション・シナリオに関連したリスクの特定、ビルドの標準化、そして包括的かつ戦略的なマイグレーション・プランの策定を支援します。

正式なプランニングに先駆け、IT部門は、各マイグレーション・シナリオにおける有利な点と不利な点を理解しておくことはもとより、なぜマイグレーションなのかの意図を正しく理解しておく必用があります。これらの理解がないということは、プランニング・プロセス全体を通じて求められている意思決定とトレードオフに対する準備ができてないことになります。どのような意図があるのかが明確になった後、IT部門はこのガイドブックで詳説した戦略的マイグレーション・プロセスの5つのフェーズを順を追って進めていきます。これらのフェーズは：

1. 既存のミドルウェア・アーキテクチャの検証と、JBoss Enterprise Applicationプラットフォームが提供可能な同等の機能の見極め

2. サードパーティ製のファンクションやビジネス・アプリケーションの検証と、JBossプラットフォームとの互換性た代替の可能性の見極め

3. マイグレーションや、それに付随したリスクに対する組織の準備状態の見極め

4. 詳細なロードマップと見積り計算書を含む戦略的マイグレーション・プランの策定

5. 戦略的マイグレーション・プランを実行に移し、インプレメンテーション・サポート戦略を取り入れる

このガイドブックとレッドハットのサービスを利用すれば、どのような企業や組織も、マイグレーションのプランニングやインプレメンテーションに必要なツールを手にすることができます。テクノロジー、トレーニング、ナレッジの提供をワンストップ・チャネルから得られ、開発における複雑性やリスクを削減できるだけでなく、より速やかにITへの投資を回収することが可能になります。

もしもお客様がミドルウェアのマイグレーションをご検討中であれば、ぜひともレッドハットまでご連絡ください。計画の当初から、私たちがどのようしてリスクの削減や実装したテクノロジーの効率化を図っていくか、詳細にご説明させていただきます。

Copyright© 2010 Red Hat, Inc. All rights reserved.LINUX は米国及びその他の国におけるLinus Torvaldsの登録商標です。RED HATとShadowman logoは米国およびそのほかの国において登録されたRed Hat, Inc. の商標です。その他、記載されている会社及び製品の名称は、各社の商標または登録商標です。本紙の情報は、2010年8月現在のものです。実際の製品、サービス等とは内容が異なる場合があります。

www.jp.redhat.com/JBoss

#2894087_0710

jb weblogic guide - jp.redhat.com · 戦略的マイグレーションガイド weblogicからjboss...

Documents