WebLogicからJBoss Enterprise Application Platformへ

戦略的マイグレーションガイド
WebLogicからJBoss Enterprise Application Platformへ
戦略的マイグレーションガイド
WebLogicからJBoss Enterprise Application Platformへ
www.jp.redhat.com/JBoss
戦略的戦略的マイグレーションガイド
目次
1.
2.
3.
4.
5.
2
はじめに
3
プリプランニング
3
マイグレーション・プランニング・プロセス
4
マイグレーションにおける考慮点
4
マイグレーションの動機
4
マイグレーションにおいて考えられるシナリオ
5
コンフィギュレーションされたサービス群
7
マイグレーションにおける実装シナリオ
9
ハードウェア・マイグレーション
14
その他のコンソリデーション
19
戦略的マイグレーションの概要
20
マイグレーション・プロセス・オーバービュー
20
フェーズ I：サーバ・アーキテクチャと実装モデル
21
フェーズ II：アプリケーション・マイグレーション・アセスメント
21
フェーズ III：必要な作業とリスクのアセスメント
23
フェーズ IV：サーバとアプリケーションのマイグレーション・プラン
25
フェーズ V：マイグレーションの実施
26
エンタープライズ・サービス
26
ミドルウェア・コンサルティング・サービス
26
プラットフォーム・コンサルティング・サービス
27
トレーニング
30
最後に
32
www.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への移行によるメリットを明確にするためには、マイグレーションを行う環境を完全に把握しつくすことが最初の重要なステッ
プとなります。
それらが選択肢、
メリット、
トレードオフに大きく影響を及ぼすため、実際に業務で利用されているソフトウェア・プラット
フォームをなぜマイグレーションするのかを充分に検討する必要があります。
また、実装時のシナリオを明確にすれば、様々な障害や
問題、
そして将来のニーズを把握することも可能になります。
www.jp.redhat.com/JBoss
3
戦略的戦略的マイグレーションガイド
マイグレーション・プランニング・プロセス
レッドハットでは、
マイグレーションによって得られるメリットの明確化、様々なマイグレーションのシナリオに関連したリスクの特定、
エ
ンタープライズ環境の標準化、
そして包括的かつ戦略的なエンタープライズ向けマイグレーション・プランの構築を実現するために5つ
のプロセスを確立しました。
このプロセスを使えば、企業のIT部門は以下が可能になります：
1. 既存のアプリケーション・サーバとプラットフォームの検証と、同等の環境を実現可能なJBoss EAPエコシステムの明確化
2. プロプライエタリな機能やネイティブ機能の検証と、JBoss EAPで提供できる同等の機能の明確化
3. 企業としての受け入れ状態と、マイグレーション・リスクの包括的な把握
4. 詳細なロードマップとコストの見積りを含む、戦略的マイグレーション・プランの作成
5. 戦略的マイグレーション・プランの導入と、サポート戦略の適用
この後、JBoss Enterprise Application Platformへの移行において必要となる検討事項とプロセスについて、詳細をご説明差し上げ
ます。ぜひともこれらをチームの皆様でご共有いただき、
マイグレーション・プランニングにお役立てください。
レッドハットでは、
これら
の情報提供を通じ、皆様のマイグレーション・プランニングを成功に導くためのお手伝いをできればと考えております。
2. マイグレーションにおける考慮点
1つのアプリケーション・サーバから他のアプリケーション・サーバへの移行を企業が決定する際、その裏側には幾つかの動機があると
考えれられます。
コスト面での考慮やより多くのイノベーションの創出、
また、異なるテクノロジーを備えたデータセンターの統合など
が一般的なものでしょう。
マイグレーションの動機
4
• コスト
• 柔軟性の提供
• アプリケーションを備えた分散型サーバの顧客への提供
• アウトソーシングの失敗
• CPU毎のライセンス費用の排除
• 企業統合や企業買収
• より安価なハードウェアと堅牢なクラスタ環境の採用
• データセンター統合
• サポートコストの低減
• RADテクニックの採用
• ハードウェアの拡張
• 最新技術や機能の利用
• 標準仕様への準拠
• パフォーマンス向上
• 統合やカスタマイズ
• スケーラビリティの改善
www.jp.redhat.com/JBoss
戦略的戦略的マイグレーションガイド
その動機がどのようなものであれ、
マイグレーション・プランニングの際はそれを念頭に置き、忘れないことが大切です。動機は実際の
移行の際の優先順位付けや方法論の決定に役立ちます。動機は、
マイグレーションにおいてどのようなシナリオを描き、
いかにして実
装するかを決定づける際の重要な要素です。
もしも最新技術や機能の利用によるメリットの享受が主な動機なのであれば、
マイグレー
ション・プロジェクトにおいて求めている機能を描き出し、構成を変更することでどれを実現できるか、
また、
どれがソースコードのアッ
プデートを必要としているかを見極める必要があります。
マイグレーションにおいて考えられるシナリオ
一般的なWebアプリケーションのマイグレーション
サーブレットやJava EEの仕様に則って構築された一般的なWebアプリケーションのマイグレーションは、
もっと容易で、費用対効果に
も優れたスタート地点となります。
また、必要となる事柄を見極める上での良い例にもなります。
もしそのアプリケーションが、Eclipse
などのオープンな仕様に基づいたIDEで開発されていたなら、
マイグレーションは極めてスムーズに行えるはずです。
プロプライエタリ
なIDEはプロプライエタリなライブラリへのリンクを設けるため、
マイグレーションの際にも更なる課題が浮上する可能性があります。
JBOSS
既存環境
オープンな仕様
JMS 、EJB 、JPA 等
オープンな仕様
アプリケーションから
プロプライエタリなインポートを
取り除いてマイグレーション
フレームワーク
フレームワーク
Hibernate 、Spring 、Seam 、Flex 、
Struts 、JBPM 、ルール・エンジン、
必要なJARをディレクトリ
もしくはEARへ追加
ワークフロー・エンジン
標準仕様に則ったWebアプリケーションにはweb.xmlと呼ばれる実装ディスクリプタが含まれています。
アプリケーション・サーバは
通常シンタクスとノーテーションを用いて制御を行っており、
これはポーティングできません。
レッドハットではこれらのドキュメント化
に努め、特手のアプリケーション・サーバからJBossソリューションへのマイグレーションの際に変更が必要な箇所をリストアップ済み
です。
また、付加価値的な機能を提供するために、
ほとんどのアプリケーション・サーバに標準仕様に基づかない二次的な独自の実装ディス
クリプタが含まれています。
この二次的なディスクリプタは、WebLogic Server (WLS)ではweblogic.xml、JBossではjboss-web.xml
と呼ばれます。
レッドハットでは、他のベンダーのディスクリプタにおいて特徴や機能がオーバーラップしている箇所をJBossがサポート
しているjboss-web.xmlへ変換するためのXMLスタイルシートの保守を行っています。
www.jp.redhat.com/JBoss
5
戦略的戦略的マイグレーションガイド
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 データベース
等
6
www.jp.redhat.com/JBoss
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の管理者として振る舞うことができます。
これらサービス・コンフィギュレーションは最終的にはアプリケーション要件によって異なり、物理的にも論理的にもアプリケー
ションそのものとは分離されています。通常、
アプリケーションの開発者はサービスの依存関係をドキュメント化しており、管理者
はそのドキュメントに則って必要なサービスを設定し、
アプリケーションが適切に稼働するようにします。
www.jp.redhat.com/JBoss
7
戦略的戦略的マイグレーションガイド
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となります。
8
www.jp.redhat.com/JBoss
戦略的戦略的マイグレーションガイド
デスティネーション・コンフィギュレーションの詳細は、その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キャッシュ機能によって利用可能です。通信のためのプロトコル
もコンフィギュレーションが可能で、同期／非同期のレプリケーションや無効化にも対応しています。
マイグレーションにおける実装シナリオ
スループットとレイテンシのいずれを優先するのか
高スループットのためのサーバと低いレイテンシのアプリケーション・サーバとでは、
そのコンフィギュレーションが大きく異なるため、
高スループットを求めるアプリケーションと、低いレイテンシを求めるアプリケーションを分けることはとても重要です。
タイムアウトや
最大スレッド数、
そしてその他の基本的なオプションは全く正反対の性質を持ち、各々混在させることはできません。
www.jp.redhat.com/JBoss
9
戦略的戦略的マイグレーションガイド
高いスループットを目標とした場合、
システムのパフォーマンス全体を優先させます。
この場合、各々のクライアントのリクエストには注
目が払われません。例えば、4つのプロセッサコアのみを持つシステムにおいて、200の同時リクエストが1 秒間における最適な平均並
列処理数だとします。
この場合、
これよりも低い値ではシステムの稼働率が下がり、
また、
これよりも多くの同時リクエストがあった場合
には過剰なコンテクスト・スイッチングが生まれ、全体のスループットが下がってしまいます。
スループットを前提にした場合、上述をふまえると同時リクエストの上限は200となります。300の同時リクエストが発生した場合、残
りの同時リクエストを待ち状態にし、処理中のグループに続いてバッチ的に処理を行います。
この方法を鑑みれば、2つ目のバッチに含
まれるリクエストは、最初のものに比べてほぼ 2 倍の処理時間が必要になってしまいます。
これによってレイテンシが発生し、2つ目の
バッチからのリクエストはSLA（サービスレベル・アグリーメント）
に違反することになります。
レイテンシを発生させないことを優先する
のであれば、
システムが300の同時リクエストを受け付けられるようコンフィギュレーションも可能です。
仮説として、平均の処理時間が1.7 秒になってしまうことが予想されるとし、2つ目のバッチが2 秒ではなく1.7 秒で終わっていればSLA
に違反していないとします。
しかしながら、
これではスループットは200tpsから176.5tpsにまで下がってしまい、
また、継続的に300の
同時リクエストがあった場合、
システムが処理できる数は時間と共に減少していきます。
低いレイテンシ
高いスループット
JBossは、無数の同時リクエストを処理可能な、大規模サーバ・ファームを構築できる堅牢なプラットフォームを提供します。
10
www.jp.redhat.com/JBoss
戦略的戦略的マイグレーションガイド
物理実装モデル
• 物理的に分かれたマシンにおけるWebサーバやアプリケーション・サーバ
Webサーバとアプリケーション・サーバ（サーブレット・コンテナ）の分離を推奨しているミドルウェア・ベンダーも存在します。高い
ライセンス費用と、
これを避けるためのシンプルかつ安価なサーブレット・コンテナという課題は、
これまでも頻繁に取りあげられて
きました。
JBossはWebサーバをアプリケーション・サーバにエンベッドしているため、ライセンスに関する課題を考える必要のないオープン
ソース・モデルの恩恵を享受しつつ、ハードウェアの更なる有効活用を実現できます。
ライセンシングの制限がない点を考慮すれ
ば、
プレゼンテーションとビジネスの両方のティアに物理的な個別のレイヤを設けることは再検討されるべきです。
動的なWebサーバ
(Tomcat)
アプリケーション・サーバ
アプリケーション・サーバ
動的なWebサーバ
(Tomcat)
これにより、JBossはハードウェア・リソースの更なる効率利用を実現できるため、場合によっては同じワークロードに応えつつ、
ハードウェア要件を最大 50% 削減可能になります。
またこれは、ハードウェアの選択とワークロードのマッチングにも柔軟に対応
できることを意味します。
セキュリティやコンフィギュレーションの分離、
そして堅牢性の面など、物理的に分けられたティアが推奨
される場合も少なくないことは、言及するまでもありません。
www.jp.redhat.com/JBoss
11
戦略的戦略的マイグレーションガイド
• アプリケーション毎に1つのアプリケーション・サーバを用意
スイッチ
2
4
サーバ 1
サーバ 2
サーバ 3
サーバ 4
アプリケーション 1
アプリケーション 2
アプリケーション 3
アプリケーション 4
この実装は以下のような場合の利用が考えられます：
アプリケーション・サーバに対して特殊なコンフィギュレーションを求める場合
• アプリケーションが、
• 32bitのOSやJVMを利用しつつ、1つのアプリケーションにメモリサイズの上限まで割当てたい場合（32bitのJVMでは
4GBが上限）
より高度な分離環境を実現するコンフィギュレーションでは、複数のアプリケーションを1つのサー
• 64bitのOSとJVM、
バへ実装することが推奨される
• ITガバナンスや規定によりアプリケーション毎にサーバを用意するのが好ましいとされる場合
12
www.jp.redhat.com/JBoss
戦略的戦略的マイグレーションガイド
• 複数のアプリケーションで1つのアプリケーション・サーバを利用
負荷分散
90%
60%
90%
30%
サーバ 1
サーバ 2
サーバ 3
サーバ 4
アプリケーション 1
アプリケーション 1
アプリケーション 1
アプリケーション 1
アプリケーション 2
アプリケーション 2
アプリケーション 2
アプリケーション 2
アプリケーション 3
アプリケーション 3
アプリケーション 3
アプリケーション 3
アプリケーション 4
アプリケーション 4
アプリケーション 4
アプリケーション 4
様々な観点で、
これはより効率的な実装であるということができます。分離された各々のインスタンスにメモリ割当てないため、各
アプリケーションは未使用のメモリを有効に利用でき、
レイテンシの最小化とアプリケーションのピーク時の利用に対応すること
が可能になります。特に他のアプリケーションのピーク時のワークロードを考慮する必要はありません。
• 複数のアプリケーション・サーバで1台のマシンを利用
1台のマシンに複数のJBossインスタンスを実装することも可能です。比較的一般的な実装モデルとしては、32bitのOS
を持つマルチCPUのシステムにおいて、1つのJVMに対してより多くのメモリを割当てることができます。
また、ハード
ウェア規模の制限や特殊なコンフィギュレーションを必要とする複数のアプリケーション、そしてフェイルオーバーが
必要な場合にも利用されます。
ステートフルWebアプリケーションとステートレスWebアプリケーション
ステートフルWebアプリケーションは、
ステータスを保存するためにコンテナで管理されたHTTPセッションを利用し、
ま
た、必要なHTTPセッションのレプリケートはアプリケーション・サーバ上でコンフィギュレーションされます。
www.jp.redhat.com/JBoss
13
戦略的戦略的マイグレーションガイド
JBossはステート・レプリケーションにも柔軟に対応します。クラスタード・キャッシュの標準のコンフィギュレーションにおいては、ステー
タスのレプリケーションはノード単位となります。Buddy Replicationを用いればより高度な設定ができ、
ノードを1つ以上のBuddyに
参加させ、
フェイルオーバーの際に備えてステータスをバックアップ可能になります。
これは、各ノードから他の全てのノードに対してス
テータスのレプリケーションが行われ、極めて多くのメモリを消費し、
また管理が容易でない大規模クラスタで特に有効です。
ステート・レプリケーションは同期／非同期のいずれでもコンフィギュレーション可能です。前者は信頼性を、後者はパフォーマンスを
優先します。
ステートレス・アプリケーションも、単にレプリケーション機能を利用せずにステートフル・アプリケーションと同じサーバ上で稼働させ
ることができます。
レプリケーションには一定のオーバーヘッドと、
アプリケーションの状態で可変するオーバーヘッドが含まれていま
すが、
ステートレス・アプリケーションの数の影響は受けません。
ハードウェア・マイグレーション
アプリケーション・サーバが、何らかの形でOSやハードウェアの縛りを受けていることもあり、
クライアントは望むと望まざると、同じベ
ンダーから提供されているアプリケーション・プラットフォームとOSやハードウェアを利用していることが考えられます。
このような状
況下では、JBossのマイグレーションに合わせてハードウェア・マイグレーションが行われることも少なくありません。
ハードウェアやOSのマイグレーションが必要なくとも、検討だけでも試みる価値はあります。
また、
アプリケーション・プラットフォーム
と同時にハードウェアやOS、
もしくはその両方をマイグレーションすることには、賛否両論があります：
利点：
• 管理要員やテクニカル要員、QA環境やテストで利用するネットワークリソース等、ソフトウェアとハードウェアの両方のマイグレー
ションにおいてリソースの共有が可能
• 重複するテスト作業をなくし、時間と経費を節約可能。ハードウェア・マイグレーションで必要とする包括的なテストと環境の検証
などのタスクは、
プラットフォームのマイグレーションで既に必要となっている
不利な点：
• 2つのマイグレーションを同時進行させることは、それらを個別に行うのに比べてリスクを増大させるかどうかについては議論の余
地があるが、明らかに1種類のマイグレーションを行うよりリスクは大きく、許容閾値を押し上げてしまう
• 2種類のマイグレーションを一緒に行うと変更箇所が曖昧になり、そのため、潜在的な問題の原因が容易に究明できなくなってし
まう。同様の理由により、
パフォーマンスの向上／阻害がどちらの影響によるものなのかの特定が難しくなる
ハードウェア・マイグレーションが必要なのか選択肢の1つなのかはさておき、
それが行われる際には、
コスト削減や、様々なメリットを
生み出すサーバの物理的な実装アーキテクチャを再設計できるチャンスが存在します。
基本的に、
コンソリデーション、分散、
アグリゲーション、
クラウド・マイグレーションの4種類の実装シナリオが存在します。
これらのシナ
リオは互いに優劣を持つわけではなく、大規模なマイグレーションでは、特定のワークロードに応じて機能や運用上の特徴を適切なバ
ランスで提供するために組み合わせて行われます。
14
www.jp.redhat.com/JBoss
戦略的戦略的マイグレーションガイド
ハードウェア要件
必用とされているのはハードウェア・マイグレーションなのか、
もしくはソフトウェア要件の変更に伴うものなのかにかかわらず、
まず、
アプ
リケーションによる制約や要件を鳥瞰し直し、適切なハードウェアを選ぶことが大切です。
要件には以下のようなものが含まれます：
• そのアプリケーションはミッションクリティカルなものか？
• どのようなSLAを維持するべきなのか？
• 保存されるデータはどの程度クリティカルなものか。また、どのようなストレージや冗長構成が求められているのか？
• そのアプリケーションにはどのようなネットワーク・トポロジが適切なのか。また、その通信環境の要件はどのようなものか？
• 必用とされている帯域幅は？
• JBossにはどのような種類のキャッシング機能を実装すべきか？
• JBossには、その他にどのような最適化やチューニングを施すべきか？
• レイテンシ対スループットにおいて、最適値は？
• メモリ容量はどの程度必要なのか。また、1つのJVMに対するメモリ容量はいくらなのか？
ハードウェアとその実装環境は、
パフォーマンスに直接影響を与えます。例えば、仮想化は高いスループットや稼働率を実現し、
その反
面、
レイテンシを増大させるのが一般的です。
メモリヒープが大きくなれば、
ガベージ・コレクションに必用な時間も増えてしまいます。
このような場合には、
より進んだガベージ・コレクション技術で対応することも可能です。
コンソリデーション
コンソリデーションというシナリオでは、数多くの稼働率の低いサーバ上のワークロードをより少ないシステムへと統合します。各々の
ワークロードを受け持つために、
これらの新しいシステムではオープン・スタンダード・ベースのOSを走らせる仮想マシンを利用します。
このタイプのシナリオは、戦略的な観点からシステムの仮想化に取り組んできたユーザの間で多く見受けられます。
このシナリオでは、
ユーザは仮想化テクノロジーを利用してシステム・リソースへのアクセスを管理します。
コンソリデーション・シナリオ
Sun 420R
Sun 420R
Sun 420R
Red Hat Enterprise Linux
と x86
Sun 420R
Sun 420R
Sun 420R
Sun 420R
Sun 420R
Sun 420R
Red Hat Enterprise Linux
と x86
www.jp.redhat.com/JBoss
15
戦略的戦略的マイグレーションガイド
利点：
• ハードウェアの運用コストの削減
• データセンターの占有スペースを削減
• 仮想化の推進によりROIを向上
不利な点：
• プロプライエタリな仮想化テクノロジーに対する取得コストや、新たなベンダーロックインの発生の可能性
分散
分散というシナリオでは、大規模なシステム上の1つ以上のワークロードをオープン・スタンダード・ベースのOSが稼働する小規模なシ
ステムへと分散します。
このタイプのシナリオは、Enterprise Linux®の導入が進んでいる環境において多くとられます。
ユーザは、小規
模なユニットを用いて分散的にハードウェア・リソースを複数のデータセンターへ拡張できます。
ラックマウント型の1U ∼ 4Uのシステ
ムがよく利用されていましたが、現在ではブレード型のものの利用が増えてきています。
分散・シナリオ
Sun E25K
Red Hat
Enterprise Linux
と x86
Red Hat
Enterprise Linux
と x86
Red Hat
Enterprise Linux
と x86
Red Hat
Enterprise Linux
と x86
利点：
• 最新のx86ハードウェア・テクノロジーによる卓越したパフォーマンスを享受可能
• ハードウェア・リソースの拡張に対する投資額が低い
• リソースを柔軟に実装／再実装可能
不利な点：
• 適切に計画が立てられていないと、このシナリオでは運用コストが増大する
16
www.jp.redhat.com/JBoss
戦略的戦略的マイグレーションガイド
アグリゲーション
アグリゲーションというシナリオでは、様々なサイズの多くのシステムのワークロードを、Enterprise Linuxを起動させることが可能な
耐障害性を備えた大規模な1つのハードウェア・プラットフォームへマイグレーションします。
このタイプのシナリオは、ユーザが既に
特定のハードウェアへの大きな投資を行っており、
また、
そのプラットフォームを更に有効に活用し、Enterprise Linuxを運用している
既存のプラットフォームを集約したいと考えている場合に多くみられます。
ユーザはシステム・リソースのアクセス管理に、
ハードウェア
（LPARによるパーティショニング）
を利用するのか、
ソフトウェア
（KVMやXenによる仮想化）
を利用するかを選択できます。
例として以下のような3つがあげられます：
• Linux（IFL）セントラル・プロセッサ用の統合ファシリティを利用するIBM® System z®
® インテル Itaniumベース）
• HP® Superdome（
® インテル Itaniumベース）
• Fujitsu® Primequest（
アグリゲーション・シナリオ
Sun Fire V490
Sun Fire V490
Sun Fire V890
Sun Fire V490
HP Superdome と
Red Hat Enterprise Linux
Sun Fire V890
Sun Fire V490
利点：
• ハードウェア運用コストの削減
• データセンターの占有スペースの削減
• 既存のハードウェアを利用することROIを向上
不利な点：
• プラットフォームに対する投資が適切でないと、ハードウェア・コストが高いものとなってしまう
www.jp.redhat.com/JBoss
17
戦略的戦略的マイグレーションガイド
クラウド・マイグレーション
クラウド・マイグレーションというシナリオでは、
クラウド・コンピューティング環境上で稼働するオープンソース・ベースのOSへ、
ワー
クロードをその数に関係なくマイグレーションします。
クラウドそのものは、
ユーザによって構築されたプライベート・クラウドもしくは
AmazonやRackspaceが提供しているパブリック・クラウドを利用することになります。このタイプのシナリオはユーザにとってまだ
新しいもので、
自らの運用環境の全てをクラウド・コンピューティング環境へ移行しているユーザは極めて少数です。
クラウド上では、
各々のワークロードへ提供されるリソースに対し、非常に詳細な管理を行うことが可能です。
クラウド・マイグレーション・シナリオ
Sun 420R
Sun 420R
Sun Fire V890
Sun 420R
Sun 420R
Sun Fire V490 Sun Fire V490
Red Hat
Enterprise Linuxbased cloud
Sun Fire V890
利点：
• 各々のワークロードに対し、必用に応じて柔軟にリソースを割当て可能
• ハードウェア・コストが不要（パブリック・クラウドの場合）
• 投資コストの低減により迅速なROIを実現（パブリック・クラウドの場合）
• ハードウェアの稼働率向上により、ハードウェアに対するROIを改善
• シンプルなクラウド環境により運用コストを低減可能
不利な点：
• クラウドそのものやネットワークの障害により運用環境へアクセスできなくなる可能性がある（パブリック・クラウドの場合）
• ユーザが所有していないシステム上でクリティカルなデータを保存し運用されるため、コンプライアンスや監査証跡の記録などが
課題となる
（パブリック・クラウドの場合）
18
www.jp.redhat.com/JBoss
戦略的戦略的マイグレーションガイド
その他のコンソリデーション
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などの一般的に利用されているライブラリの特定のバージョンを
バンドルし、結果として子となるクラスローダーがオーバーライドされてしまうことを意味します。
この問題はライブラリのバージョン毎
のファンクションの細微な違いで発生し、
トラブルシュートは極めて難しいものです。
www.jp.redhat.com/JBoss
19
戦略的戦略的マイグレーションガイド
3. 戦略的マイグレーション・プロセス
マイグレーション・プロセスの概要
フェーズ
内容
成果物
必要な期間
フェーズ I：
サーバ・アーキテクチャ
このフェーズでは既存のサーバやネットワーク基盤、
そし
アプリケーション・サーバの利用方法とコンフィギュ
2∼4週
てアプリケーションの検証を行う。
ここでは、既存の機能
レーション、
ネットワークのコンフィギュレーション、
と実装モデル
やワークロードに関するキャパシティのベースラインを
ハードウェアの種類や数。
明確にする。
フェーズ II：
このフェーズでは各々のアプリケーションの移行につい
マイグレーションに適したアプリケーションのリスト
アプリケーション・マイグ
てのアセスメントを行う。
プロプライエタリなライブラリ
化と優先順位付。
レーション・アセスメント
に対する依存性と、仕様に対する適応性を検証。
アプリケーションが利用しているプロプライエタリ
ン数や複雑性によ
なライブラリ。
り大きく変わる）
2∼12週
（アプリケーショ
マイグレーションに必用な環境の仕様。
フェーズ III：
このフェーズでは、
アプリケーション・サーバとそれらの
サーバによってコンフィギュレーションされている
必要な作業とリスクの
コンフィギュレーション、
そして実装されているサービス
サービスのリスト化。
アセスメント
を検証する。
これにより、
サーバのリプレイスに伴って必
定義されているクラスタおよび各々のクラスタのコ
要となる機能が明確になる。各々のアプリケーションの
ンフィギュレーション。
4∼6週
移行において必用となる作業量とリスクをアセスメント。各アプリケーションのマイグレーションに必用な労
力の算出。
各々のアプリケーションにおける主要なリスク要因
の特定。
フェーズ IV：
このフェーズではサーバとアプリケーションのマイグレー
サーバのマイグレーション・プランでは各々のサー
サーバと
ション・プランを練る。
ここでは先のフェーズで得られた
バ／クラスタにマイグレーションが行われるよう、
アプリケーションの
情報をもとに、サーバとアプリケーションのマイグレー
サービスとコンフィギュレーションの詳細を確認。
マイグレーション・プラン
ションに関するロードマップを作成する。
アプリケーションのマイグレーション・プランでは、
ここにはプロプライエタリなライブラリやサービスに置き
各々のアプリケーションにおけるライブラリとコー
換わるオープンソース・ソリューションの定義も含む。
ドの変更に関する詳細を確認。
フェーズ V：
このフェーズでは、
新しい環境への実際のマイグレーショ
マイグレーションの完了
マイグレーションの実施
ンと実装を行う。
Red Hat Consultingでは、実装と戦略的マイグレーショ
ン・プランを支援する様々なワークショップやトレーニン
グ、
そしてサービスを提供。
20
www.jp.redhat.com/JBoss
5∼8週
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：アプリケーション・マイグレーション・アセスメント
マイグレーションの全容をつかむためには、現在、
アプリケーションやマイグレーション・ターゲットによってどのようなテクノロジーが
利用されているのかを把握することが大切です。一般的なエンタープライズ・アプリケーションでは、
セキュリティやキャッシング、そし
てインジェクションで複数のテクノロジーを利用していることが少なくありません。
これらのテクノロジーの多くは一般のアプリケー
ション開発者の目に触れるこが少ないため、開発者もその存在を意識することがありません。
しかしこれらはアプリケーションのパ
フォーマンスとスケーラビリティに大きな影響を及ぼします。
これらのテクノロジーのマイグレーション・プランに失敗するとは、大きな問題につながります。
これらの問題は、一般的にマイグレー
ション・プロジェクトの最終局面でパフォーマンス・テストが行われた後で表面化します。
これらを考慮すると、単にテクノロジーのアセ
スメントを行うだけでなく、利用されている機能を確認して、最も適した代替ソリューションを見つけ出すことが大切です。
www.jp.redhat.com/JBoss
21
戦略的戦略的マイグレーションガイド
一般的なアプリケーション・サーバ・マッピング
JBoss EAP
コンポーネント
考慮点
監視と管理
リモートからのコントロールとコンフィギュレーション、 JBossアドミン・コンソールによる標準JMXインタフェースの提
閾値を超えた場合のアラートなど
Webサーバー
サーブレット・コンテナ、
ステート・レプリケーション
供と、
スラッシュホールド・アラート
TomcatへのJSPとサーブレットの仕様のインプレメンテーショ
ン、
詳細なインメモリのレプリケーション
メッセージング
キャッシング
クラスタリングとレプリケーション
接続性
トランザクションへの影響度合、
メッセージングの持続
JBossメッセージングによるメッセージ配信とリバンランシング、
性、
クラスタ外部でのブリッジング、
JMSの仕様
持続性と安定したトランザクションの実現
トランザクション、分散型、オブジェクト・グラフのサ
JBossキャッシュによるシリアライズとAOPベースのレプリケー
ポート
ション
レイヤード・レプリケーション、
トランザクション・セーフ・ JBossクラスタとJGroupsの組み合わせによるコンフィギュレー
レプリケーション、
詳細な調整
ションのレプリケーション
サポートしているデータベースやファイルシステム、
ハイ
JDBCコネクション・プール、Hibernate、セキュリティ・データス
トランザクショナル・データストア
ブリッド・データストア、
トランザクションのサポート、トア、
データベース機能のサポート
セキュリティ
アスペクト・オリエンテッド・プログ
認証と承認、シングル・サインオン、J A A S/J ACC のサ
J A A S に準拠したログイン・メソド、フラットファイル、データ
ポート、証明書のサポート
ベースと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
次のステップは、必用なコンフィギュレーションの明確化、
そして既存の機能とオープンソースが提供できる機能とのギャップの明確化
です。ほぼ全ての場合において、そのまま、
もしくは比較的マイナーなカスタマイズで、同様の機能を提供できるオープンソースが存在
します。
アセスメントは各アプリケーションのマイグレーションにおける阻害要素に焦点を当て行うことが重要です。
マイグレーション・プロセ
スは簡単なものから最も難しいものへとプランされるべきです。最も簡単なものから手をつけることにより、ナレッジが培われ、実施
チームの間にも自信が生まれます。
22
www.jp.redhat.com/JBoss
戦略的戦略的マイグレーションガイド
フェーズ III：必要な作業とリスクのアセスメント
実装アーキテクチャを推考し、
マイグレーションに含まれるアプリケーションとテクノロジーを把握した後、
いよいよマイグレーション
において必要となる作業とリスクのアセスメントに入ります。
テクニカル面と組織面の両方のコンポーネントが、必要な作業とリスクの
アセスメントの対象となります。
先のセクションにおけるテクニカル・アナリシスを利用して、技術面における必用作業とリスクのアセスメントを行います。
焦点となるのは：
1. テクニカル・アナリシス
• スコープ
• マイグレーションに含まれるサーバ数、データセンター数、アプリケーション数
• テクノロジーのギャップに対するアナリシス
• オープンソースの代替ソリューションにそのままでマッピングできない機能
• コンフィギュレーション要件の矛盾点
• アプリケーションの仕様
• プロプライエタリなライブラリをエンベッドするIDEの使用
• ライブラリの選択
2. 組織面のアナリシス
組織面での要素は、一般的にテクニカル面での様々な要素に影響を及ぼしています。テクニカル面での要素は比較的容易に特定
が可能ですが、組織面における要素はなかなか表面化しないため、問題になることが少なくありません。一見容易に見えるハードル
も、組織側が何も対応策を用意していなかったり、変更を望んでいなかったりした場合には、大きな障害になってしまうこともあり
ます。様々な課題に対応できるプランニングでなければ、組織は短期的な視野に入ってくるマイナーな問題点だけに焦点をあわせ
てしまいがちで、
オープンソースへのマイグレーションによって得られる、長期的なメリットを見逃してしまいます。
組織面におけるリスク要因に対応するための最初のステップは、組織が抱えいる問題点とそれに付随するリスクの分析です。
これに
よって、
マイグレーションのために組織がどのような準備をすれば良いのかのロードマップを得ることができます。組織は以下の点
に考慮を払う必用があります：
• ナレッジ・ギャップとトレーニング
• スタッフはテクノロジーに対して精通しているのか、それと
も単に既存のツールに慣れているだけなのか？
• 開発ソフトウェアと実装ソフトウェアの運用についての組
• カルチャー面に関して
• 意思決定のボトムアップ vs トップダウン
• 必用経費に関する品質重視 vs コスト重視
• 最新テクノロジー vs 枯れたテクノロジー
織の受け入れ態勢は？
• ワークロードに関して
• 現在のスタッフは今の業務をこなしながら、トレーニング
やマイグレーション作業に従事できるのか？
• 予算
• 設備投資（CAPEX）vs 運営費（OPEX）
• 総所有コスト（TCO）vs 投資回収率（ROI）
• 実装に必用となる充分なハードウェアが用意されている
か実稼働ラインへ新しいサーバを投入する前に検証はで
きるか？
www.jp.redhat.com/JBoss
23
戦略的戦略的マイグレーションガイド
これらの考慮点をマイグレーション・プランの中に加味しておくことで不慮の問題の発生を防ぐことができ、円滑なマイグレーションが
可能になります。
SWOT（Strength／Weakness／Opportunity／Threats）アナリシスは、組織のマイグレーションへの準備の度合を見極めるのに役
立ちます。組織自体の強さ
（Strength）
と弱さ
（Weakness）、機会（Opportunity）
と脅威（Threats）
を比較し、組織自体の強さを活かし
て弱さを克服できるプランの開発を可能にします。
SWOTアナリシス
STRENGTH
• ITスタッフが、関連した規格／仕様やテクノロジーに対するトレーニング
を受けた
WEAKNESSES
• 予算の削減
• プロプライエタリなIDEに依存した開発
• ITスタッフのJBossに対する造詣が深くなっていっている
• アプリケーションがWARやEARに則ったフォーマットになっている
• オープンなIDEで開発を行っている
OPPORTUNITIES
• 予算のカット
• ライセンスの更新が近づいている
• 現在のライセンスの範囲を超えたキャパシティ増強が求められている
• 企業買収や標準化推進によって、複数プラットフォームの統合が求めら
THREATS
• 実装における標準化が行われていない
• トレーニングのための予算がない
• 現在、全てリソースが完全に利用されてしまっている
• マイグレーションのためのキャパシティ拡張に充てる予算がない
れている
3. マイグレーション・リスクのアセスメント
あらゆるマイグレーションにリスクは付き物です。
リスクを正しく理解して予めそれに備えることで、
マイグレーション作業を阻害す
るリスクを最少化できます。JBossでは、
マイグレーションに必用なトレーニングとコンサルティング、
そしてツールを提供しています。
マイグレーションに必用なスキルは、
インターナルで培ってもあまり有益なものではありません。
マイグレーションに必用な作業は、
単にインターナル・チームをその遂行のためにトレーニングするだけでも非常に負荷のかかるものであるため、企業は社外の専門
家に依頼するのが一般的です。
リスク
発生する可能性
インパクト
戦略
トレーニング予算
高
高
マイグレーション作業をサポートするためのトレーニングやワークショップの提
供
ステージング・ハード
中
中
ウェア
プロプライエタリな
コンフィギュレーション、
アプリケーション、
インストレーションを検証するため
には、
実稼働ラインと同等／同様のハードウェアを用意することが求められる
中
IDEツールの利用
高
WebLogicやWebSphereが提供するツールは、
プロプライエタリなライブラリ
を多用する。
これらがコードを生成する際は、
プロプライエタリなクラスをエク
ステンド／インプレメントしたクラスを生成する
JBoss MASSプロジェクトとMATを利用すれば、
プロプライエタリなライブラリ
等に起因する課題を特定可能
24
www.jp.redhat.com/JBoss
戦略的戦略的マイグレーションガイド
フェーズ IV：サーバとアプリケーションのマイグレーション・プラン
マイグレーションにおける作業内とリスクが明確になった後は、SOE（Standard Operating Environment）
をどのように設計していく
かを考えることが、
とても重要になります。SOEはコアとなるOSやミドルウェアのインプレメンテーションに際しての、組織における標準
仕様です。
この中には、基本となるOS、Java EEコンテナ、独自のコンフィギュレーション、組織で利用される標準アプリケーション、
ソフ
トウェア・アップデート、
サービス・パックなどが含まれることになります。
アプリケーション・セットの定義が終わると、円滑かつ一貫性を保った実装を実現するために、SOEアプローチに基づいて標準化され
たコンフィギュレーションが作成されます。SOEコンフィギュレーションには、検証済みのハードウェアとソフトウェア、
そしてJBoss環境
内へ実装する際のコンフィギュレーションが含まれています。SOEコンフィギュレーションはテクニカル要件やビジネス要件に完全に
沿ったものとなっているため、実装に必用な時間の大幅短縮ができるだけでなく、保守の簡素化、安定性の向上、
サポートと管理コス
トの削減に貢献します。
場合によっては複数のSOEが必用になる場合もあり、
マイグレーション・プランの次のステップでは、
マイグレーションしなければなら
いアプリケーションに合わせて、異なるいくつのサーバ・コンフィギュレーションが必要なのかを見極める必用があります。
スループット
対レイテンシ、特定の実装要件、特定のワークロードに対応するための特殊なハードウェアの必要性など、
アプリケーション毎で競合
するコンフィギュレーションを持つ場合があるため、複数のサーバ・コンフィギュレーションが必用になることは少なくありません。重要
な点は、
システム環境における機能面、そして機能面以外での要件を満たしながら、
コンフィギュレーションの数を可能な限り少数に
収めることです。
必用となるコンフィギュレーション数が確定した後は、
どのアプリケーションをどのサーバに実装するかを決めることになります。
この
時点で、各々のアプリケーションのコンフィギュレーションが実際に始まります。各アプリケーションは、異なるクラスローダー、イン
ターセプタ・スタック、URL、
その他多くの構成オプションを用いて、
コンフィギュレーションされます。
先のアセスメントの結果で得られた、ナレッジ・ギャップを埋めるためにスタッフに提供するトレーニングのプランも行います。
アプリ
ケーションのマイグレーション・スケジュールを確定する際には、そのマイグレーション作業に必用となるナレッジに対するトレーニン
グもその中に含んでおくべきです。
トレーニングを予めスケジュールの中に含んでおけば、問題に遭遇したマイグレーション・チームも
当面の対処が行え、
その後で関連したテクノロジーに対するトレーニングを受ければ、
マイグレーションをより効果的に進めていくこと
が可能になります。
次に行うのがコストの算出とタイムラインの最終確定です。
コストの算出は以下の点に着目して行います：
• サーバやコンフィギュレーションの検証で利用される、ステージング用ハードウェアに関するコスト
• プロプライエタリなソフトウェアから移行した際のギャップを埋めるために必用な、既存のオープンソース・ソフトウェア用の拡張機
能の開発コスト
• マイグレーションするアプリケーションは、ソースコードの変更が必用なのか、それともコンフィギュレーションの変更だけで対応で
きるのかに分けてグループ化してコストを算出する。
• トレーニング・コスト
• ソフトウェア数の削減によって節約できる金額
• ハードウェアを再実装によって節約できる金額
www.jp.redhat.com/JBoss
25
戦略的戦略的マイグレーションガイド
フェーズ 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プラットフォームでも動作するこを確実にします。
26
www.jp.redhat.com/JBoss
戦略的戦略的マイグレーションガイド
Red Hat Consultingでは、JBossプラットフォームへのマイグレーションに関連した以下のような様々なサービスを提供しています：
• マイグレーション・アセスメント：既存のアプリケーションを全て検証し、コストの算出とリスクの特定、そしてJBossプラットフォー
ムへ移行するのに必要な詳細な見積りを作成します。
• アプリケーションのマイグレーション：プロプライエタリなミドルウェア・システム上の既存のアプリケーションを、ライセンス費用
の削減、ベンダーロックインの最小化、
オープンスタンダードへの準拠を推進する、
オープンなJBossプラットフォーム上で利用でき
るように変換します。
• アーキテクチャのレビューと推奨要件の定義：JBossの利用とアプリケーション開発に関するガイダンスを継続して提供します。将
来のバージョンのJBossプラットフォームでの採用が予定されている機能や仕様に準拠していけるよう、
テクニカル・ロードマップ
の作成を支援します。
マイグレーションに求められている要件は千差万別であるため、Red Hat Consultingではお客様の既存の環境の理解に努め、
お客
様が現在お使いのアプリケーションをJBossへ確実に移行し、将来にわたって利用／拡張し続けていけるよう、最適なスコープでのマ
イグレーションを提案します。Red Hat Consultingは、開発ツールと実績を備えた方法論、
そして数多くの実際のマイグレーションで
培ってきた経験値をもとに、円滑かつ安全なプロセスでお客様のマイグレーションを成功へと導きます。
プラットフォーム・コンサルティング・サービス
マイグレーション作業においては、拡張性を提供可能な堅牢な基盤環境を用意することが最初のステップとなります。
レッドハットの基
盤環境マイグレーション・プランニング・サービスでは既存のIT環境を詳細に検証し、
お客様がマイグレーションする際に、
そのIT基盤
を簡素化できる最善の推奨環境を提案します。
レッドハットでは、お客様の環境をビジネスに応じて確実に成長できるよう、
マイグレーションを成功に導く堅牢な基盤環境をSOEア
プローチに基づいて提供します。
SOEのメリット
• アーキテクチャの簡素化：異なるブランチやサービスに実装可能なOne Codebaseで、同じビルド・プロセスを用いて異なるプラッ
トフォーム
（ワークステーション、
サーバ、）
をサポート
• 柔軟かつ迅速な実装：ベアメタル状態から10分以内に完全にコンフィギュレーションや全く同じコンフィギュレーションを保証し、
また、異常の発生や、各マシンの比較を容易に行える集中管理用GUIインタフェースを提供
• セキュリティ：異なるマシンや分散したデータセンターにセキュリティ・ポリシーを適用
• カスタマイズ可能な管理環境：異なる機能を有する異なるタイプのマシンをリモートから管理可能。また、属性に応じて権限を委
譲する機能も提供
コンフィギュレーションの集中管理：コンフィギュレーションの適用、
コンフィギュレーションの定期アップデート、
コンフィギュレーショ
ンの比較、現在コンフィギュレーションの確認機能を提供
www.jp.redhat.com/JBoss
27
戦略的戦略的マイグレーションガイド
SOE（ Standard Operating Environment ）の構成図
システム管理
アイデンティティ管理
データ管理
セキュリティ管理
システム管理：既存のシステム管理基盤の評価とドキュメント化を図ります。
マイグレーション後のシステムとソフトウェアの管理、
そし
てRed Hat Enterprise Linuxが既存の変更管理プロセスやシステムと連携していくかを基に、推奨要件が提案されます。
サービスには以下が含まれます：
• ベアメタル・プロビジョニングと仮想プラットフォームのプロビジョニング
• Linuxソフトウェアのビルドと実装
• 監視、パフォーマンスの管理
アイデンティティ管理：既存のアイデンティティ管理ポリシーの内容確認とドキュメント化を行います。Red Hat Enterprise Linuxを
既存の認証と承認基盤へ統合、
また既存のディレクトリ・ソリューションをオープンソース・ソフトウェアへマイグレーションするため
の、推奨要件が提案されます。
サービスには以下が含まれます：
• userおよびgroupの管理
• PKI基盤
• ポリシーの策定と適用
データ管理：マイグレーションされるサービスの可用性に対する要件について、内容確認とドキュメント化を行います。
アーキテクトが
ストレージとクラスタリング技術を組み合わせ、要件に応えられる戦略を練ります。
28
www.jp.redhat.com/JBoss
戦略的戦略的マイグレーションガイド
サービスには以下が含まれます：
• 高可用クラスタ
• 分散型ファイルシステム
• 負荷分散ソリューション
• ディザスタリカバリ
• システムおよびデータのバックアップ
• データ・リカバリ
• ベアメタル・リカバリ
セキュリティ管理：マイグレーションするサービスとLinux環境に向けて、既存のセキュリティ・プラクティスとセキュリティ製品の検証
とドキュメント化を行います。
エンドユーザ対するセキュリティ要件の網羅的な理解が求められます。
サービスには以下が含まれます：
• OSの強化
• 緊急のセキュリティ・エラータに対するパッチ適用
• セキュリティ監査とレポート
• 法令遵守に対する取り組みと対応策の提供
上述の各エリアにおいて、Red Hat Enterprise Linux OSがサポートしているプロセスと、既存のインフラストラクチャに含まれている
他のOSがサポートしているプロセスのアセスメントとギャップ・アナリシスが行われます。
このアナリシスは、業界規格に基づいたプラ
クティスと実績を備えたメソドにて行われます。
これらによって享受できる大きなメリットの1つは、
レッドハットがお客様のチームと共に直接のナレッジ提供やリアルでのナレッジ共
有、
そして、問題が発生した場合や質問があった場合に、貴重なガイダンスをその場で提供できることにあります。
Red Hat Consultingではあらゆるニーズに応えられるソリューションを包括的に提供し、実装ライフサイクルのどのようなフェーズに
あろうとも、
ビジネスが逸早く投資を回収できるようにします。
Red Hat Consultingソリューション概要
アセスメント
実績あるベスト・プラクティスとRed Hat Consultantsの専門家が安全で確実なマイグレーションの計画を行います
クイック・スタート
プロジェクトを速やかに進め、貴重な時間を節約します。
インプレメンテーション
インストールやコンフィギュレーション、そして実装の全てを行います。
ヘルスチェック
ビジネスに対する問題が発生しないか、
インストールとコンフィギュレーションの検証を行います。
最適化
生産性の向上とコストの削減を目指し、
トラブルシュートと問題の解決に取り組んでいきます。
www.jp.redhat.com/JBoss
29
戦略的戦略的マイグレーションガイド
お客様がすでにマイグレーションをご検討中であれば、
メールでご連絡ください。
レッドハットがどのように、ベストなサポートをご提供
させていただくか、詳しくご説明差し上げます。
[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/ をご参照ください。
30
www.jp.redhat.com/JBoss
戦略的戦略的マイグレーションガイド
コース：以下の表は、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] までお問い合わせください。
www.jp.redhat.com/JBoss
31
戦略的戦略的マイグレーションガイド
5. 最後に
そのサイズやスコープに関係なく、全てのマイグレーション・プロジェクトを成功に導くためには詳細な計画を立てることが重要です。
プロジェクトで得られた純粋な改善の度合いや、IT投資に対するROIを正確に知るためには、
リスクや節約できる経費、
またマイグレー
ション・プロジェクトにおけるコスト・ストラクチャを理解することが重要となります。
このガイドブックで詳説されている検討課題やプロセスは、
マイグレーションで享受できるメリットを明確化し、様々なマイグレーショ
ン・シナリオに関連したリスクの特定、
ビルドの標準化、
そして包括的かつ戦略的なマイグレーション・プランの策定を支援します。
正式なプランニングに先駆け、IT部門は、各マイグレーション・シナリオにおける有利な点と不利な点を理解しておくことはもとより、
な
ぜマイグレーションなのかの意図を正しく理解しておく必用があります。
これらの理解がないということは、
プランニング・プロセス全体
を通じて求められている意思決定とトレードオフに対する準備ができてないことになります。
どのような意図があるのかが明確になっ
た後、IT部門はこのガイドブックで詳説した戦略的マイグレーション・プロセスの5つのフェーズを順を追って進めていきます。
これらの
フェーズは：
1. 既存のミドルウェア・アーキテクチャの検証と、JBoss Enterprise Applicationプラットフォームが提供可能な同等の機能の見極め
2. サードパーティ製のファンクションやビジネス・アプリケーションの検証と、JBossプラットフォームとの互換性た代替の可能性
の見極め
3. マイグレーションや、それに付随したリスクに対する組織の準備状態の見極め
4. 詳細なロードマップと見積り計算書を含む戦略的マイグレーション・プランの策定
5. 戦略的マイグレーション・プランを実行に移し、インプレメンテーション・サポート戦略を取り入れる
このガイドブックとレッドハットのサービスを利用すれば、
どのような企業や組織も、
マイグレーションのプランニングやインプレメン
テーションに必要なツールを手にすることができます。テクノロジー、
トレーニング、
ナレッジの提供をワンストップ・チャネルから得ら
れ、開発における複雑性やリスクを削減できるだけでなく、
より速やかにITへの投資を回収することが可能になります。
もしもお客様がミドルウェアのマイグレーションをご検討中であれば、ぜひともレッドハットまでご連絡ください。計画の当初から、私た
ちがどのようしてリスクの削減や実装したテクノロジーの効率化を図っていくか、詳細にご説明させていただきます。
32
www.jp.redhat.com/JBoss
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

Download Report