WebSphere アプリケーションを Azure 仮想マシン に移行する

このガイドでは、WebSphere Application Server (WAS) traditional アプリケーションを移行して Azure 仮想マシン で実行する場合に知っておくべきことについて説明します。 Azure Marketplace で利用可能な WAS traditional ソリューションの概要については、Azure で IBM WebSphere 製品ファミリーを実行するためのソリューションとは何ですか?を参照してください。

移行前

移行を確実に成功させるには、開始する前に、次のセクションで説明する評価とインベントリの手順を完了します。

"移行の完了" が意味することを定義する

このガイドおよび対応する Azure Marketplace オファーが、Azure への WAS traditional ワークロードの移行を促進するための出発点となります。 移行作業の範囲を定義することが重要です。 たとえば、既存のインフラストラクチャから Azure 仮想マシン に厳密な "リフト アンド シフト" を行うのでしょうか。 その場合、移行の際に多少の "リフト アンド改良" を取り入れたくなる可能性があります。

このガイドで詳しく説明されている必要な変更を考慮して、できるだけ純粋な "リフ トアンド シフト" に近づけることをお勧めします。 このマイルストーンに到達したことがわかるように、"移行の完了" が意味することを定義してください。 移行が完了したら、仮想ハード ディスクのスナップショットを作成する で説明されているとおり、仮想マシンのスナップショットを取得できます。 スナップショットから正常に復元できることを確認した後は、これまでに達成した移行の進捗を無駄にする心配なしに、安心して機能強化を行えます。

ターゲットが移行作業に適したターゲットであることを確認する

WAS アプリケーションを Azure に正常に移行する最初の手順は、最も適切な移行ターゲットを選択することです。

WAS traditional は、Azure 仮想マシン で適切に実行されます。 仮想マシン (VM) ターゲットは、オンプレミスのデプロイに最も近いため、最も簡単な選択です。 仮想マシンの管理とデプロイのエクスペリエンスは、オンプレミスにあるものと類似します。

もう 1 つのオプションは、WAS traditional ワークロードをアプリケーション コンテナーに変換してコンテナーに移行することです。 コンテナー ターゲットは、Azure Kubernetes Service (AKS) と Azure Red Hat OpenShift で実行できます。 この容易さのトレードオフは、経済的コストです。

一般に、VM ベースのソリューションの 1 分あたりのコストは、コンテナーと比較して高くなります。 コンテナーベースのソリューションの実行コストは低くなりますが、コンテナー オーケストレーション プラットフォームの要件に合わせてアプリケーションを制限する必要があります。

変更を最小限に抑えることが移行作業の最も重要な要素である場合は、VM ベースの移行を検討してください。 この場合は、WebSphere アプリケーションを Azure 仮想マシン に移行するを参照してください。

ランタイム コストを削減するために、アプリケーションをコンテナー内で実行するように変換することが許容できる場合、AKS ベースまたは Azure Red Hat OpenShift ベースの移行を検討します。

AKS ベースの移行では、Free 階層を使用できます。 無料のクラスター管理を取得して、仮想マシン、関連ストレージ、消費したネットワーク リソースに対してのみ料金を支払います。 この場合は、「WebSphere アプリケーションを Azure Kubernetes Service に移行する」を参照してください。

Azure Red Hat OpenShift ベースの移行の場合、コンピューティングとインフラストラクチャのコストに加えて、アプリケーション ノードにはOpenShift ライセンス コンポーネントの別のコストがあります。 このコストは、アプリケーション ノード数とインスタンスの種類に基づいて課金されます。 ワークロードやビジネスのニーズに合わせて、オンデマンドの価格または予約インスタンスのいずれかを使用できます。 この場合は、WebSphere アプリケーションを Azure Red Hat OpenShift に移行するを参照してください。

Azure Red Hat OpenShift ドキュメントの攻略ガイドでは、移行に関連するいくつかの側面について説明しています。 ハウツー ガイドの完全な一覧は、Azure Red Hat OpenShift ドキュメントを参照してください。

事前構築済みの Azure Marketplace オファーが適切な出発点であるかどうか判断する

IBM と Microsoft は提携して、Azure ソリューション テンプレートのセットを Azure Marketplace に導入し、Azure への移行の確固たる出発点を提供しています。 オファーの一覧については、 「Microsoft Azure で WebSphere 製品ファミリと Liberty を実行する」を参照し、既存のデプロイに最も近いものを選択します。 オファーの一覧は、概要記事「Azure で IBM WebSphere 製品ファミリーを実行するためのソリューションにはどのようなものがありますか」で確認できます。

既存のオファーがいずれも適切な開始点でない場合は、Azure 仮想マシンのリソースを使用して手動でデプロイを再現する必要があります。 チュートリアル: Azure 仮想マシン に IBM WebSphere Application Server Network Deployment 従来版を手動でインストールする に、手順ガイドがあります。 詳細については、IaaS とは? を参照してください。

WAS traditional バージョンに互換性があるかどうか確認する

既存の WAS traditional バージョンは、IaaS オファーのバージョンと互換性がある必要があります。 バージョン情報は 「Azure VM の IBM WebSphere Application Server Single Instance」 および 「Azure VM の IBM WebSphere Application Server Cluster」の概要ページで確認できます。 既存の WAS traditional バージョンがそのバージョンと互換性がない場合は、Azure IaaS リソースを使用して手動でデプロイを再現する必要があります。 詳細については、IaaS とはを参照してください。

サーバー容量をインベントリする

現在の実稼働サーバーのハードウェア (メモリ、CPU、ディスク) と、平均およびピーク時の要求数とリソース使用率を文書化します。 この情報により、VM サイズの選択がわかります。 詳細については、Cloud Services のサイズを参照してください。

すべてのシークレットをインベントリする

Azure Key Vault などの "サービスとしての構成" テクノロジが登場する前に、"シークレット" の明確に定義された概念はありませんでした。 代わりに、現在 "シークレット" を呼ばれるものとして効果的に機能する、さまざまな種類の構成設定のセットがありました。 WAS などのアプリ サーバーでは、これらのシークレットは多くの異なる構成ファイルと構成ストアにあります。 すべてのシークレットとパスワードについて、実稼働サーバー上のすべてのプロパティと構成ファイルを確認します。 また、パスワードや資格情報を含む構成ファイルがアプリケーション内に見つかる場合もあります。 WAS は、構成データを複数のドキュメントのカスケード階層のディレクトリに格納します。 ほとんどの構成ドキュメントには XML コンテンツがあります。 詳細については、構成ドキュメントおよびAzure Key Vault の基本概念を参照してください。

すべての証明書をインベントリする

パブリック SSL エンドポイントで使用されるすべての証明書を文書化します。 次のコマンドを実行して、運用サーバー上のすべての証明書を表示できます。

keytool -list -v -keystore <path to keystore>

詳細については、IBM の資料 SSL における証明書管理 を参照してください。

サポートされている Java バージョンが正しく動作することを検証する

Azure 仮想マシン で WAS を使用するには、特定のバージョンの Java が必要です。そのため、サポートされているバージョンを使用してアプリケーションが正しく動作することを確認する必要があります。

IBM Java 8 には WAS9 ディストリビューションが付属しています。 IBM 提供の Java JRE を使用することをお勧めします。 詳細については、WebSphere Application Server traditional V9 の Java SE 8を参照してください。

別の Java SDK に切り替える場合は、IBM の文書 WebSphere Application Server で Java SDK を切り替える に従ってください。

JNDI リソースをインベントリする

すべての JNDI リソースをインベントリします。 たとえば、データベースなどのデータソースには、関連付けられた JNDI 名を持つ場合があり、これにより JPA は のインスタンスを特定のデータベースに正しくバインドできます。 JNDI リソースおよびデータベースの詳細については、IBM の資料の WebSphere Data Sources を参照してください。 JMS メッセージ ブローカーなど、その他の JNDI 関連リソースには、移行または再構成が必要になる場合があります。 JMS 構成について詳しくは、JMS リソースの使用を参照してください。

プロファイルの構成を検査する

WAS の主要な構成単位は、プロファイルです。 そのため、 resources.xml ファイルには、移行のために慎重に検討する必要がある多数の構成が含まれています。 このファイルには、サブディレクトリに格納されている追加の XML ファイルへの参照が記載されています。 IBM は通常、 IBM コンソール を使用して WAS の管理可能なオブジェクトとサービスを構成し、WAS に [プロファイル/プロファイル名] フォルダーの維持を許可することを推奨しています。 詳しくは、分散オペレーティング・システムおよび IBM i オペレーティング・システムでのプロファイルの管理を参照してください。

アプリ内

deployment.xml ファイルおよび WEB-INF/web.xml ファイルを調べます。

セッション レプリケーションが使用されているかどうか確認する

アプリケーションがセッション レプリケーションに依存している場合は、次のオプションがあります。

  • HTTP セッションの場合、セッション管理のレベルに応じて、メモリまたはデータベースを使用してセッションデータを保存できます。
  • 分散セッションでは、データベースによるセッション永続化を使用して、セッションをデータベースに保存できます。
  • 動的キャッシュ では、メモリ間レプリケーションまたはデータベースでセッションデータを管理できます。
  • セッション管理にデータベースを使用するようにアプリケーションをリファクターします。
  • Azure Redis サービスへのセッションを外部化するようにアプリケーションをリファクターします。 詳細については、Azure Cache for Redis を参照してください。

これらすべてのオプションにおいて、WAS が HTTP セッション状態レプリケーションを行う方法を習得することをお勧めします。 詳しくは、IBM のドキュメントの 「セッション Bean の管理」 を参照してください。

データソースの文書化

アプリケーションでデータベースを使用する場合は、次の情報を把握する必要があります。

  • データソース名
  • 接続プールの構成
  • JDBC ドライバーの JAR ファイルはどこにありますか?

WAS における JDBC ドライバーの詳細については、WebSphere Application Server で JDBC ドライバーを使用するを参照してください。

WAS がカスタマイズされているかどうか確認する

次のうち、どのカスタマイズが行われたかを確認し、作業内容を把握します。

  • スタートアップ スクリプトは変更されていますか? このようなスクリプトには、 wsadmin、 AdminControl、 AdminConfig、 AdminApp および AdminTask が含まれます。
  • JVM に渡される特定のパラメーターはありますか?
  • サーバーのクラスパスに追加された JAR はありますか?
  • サーバーの再起動後に WAS コンポーネントが自動的に起動するように、 などの OS レベルの機能が使用されていますか?

これらの質問に対する回答に応じて、移行に関する考慮事項を考慮する必要があります。

オンプレミスへの接続が必要かどうかを判断する

アプリケーションからオンプレミスのサービスのいずれかにアクセスする必要がある場合、Azure の接続サービスの 1 つをプロビジョニングする必要があります。 詳しくは、オンプレミス ネットワークを Azure に接続するをご覧ください。 または、オンプレミスのリソースで公開されている一般公開の API を使用するように、アプリケーションをリファクタリングする必要があります。

Java Message Service (JMS) キューまたはトピックが使用中かどうか確認する

アプリケーションで JMS キューまたはトピックを使用している場合は、外部でホストされている JMS サーバーにそれらを移行する必要があります。 JMS を使用する方法の 1 つとして、Azure Service Bus と Advanced Message Queuing Protocol の使用が挙げられます。 詳細については、Azure Service Bus Standard と AMQP 1.0 で Java Message Service 1.1 を使用するを参照してください。

JMS パーシステンス ストアを構成した場合、構成をキャプチャして、移行後に適用する必要があります。

IBM MQ を使用している場合は、このソフトウェアを Azure 仮想マシンに移行してそのまま使用します。

Microsoft には、IBM MQ と Logic Apps を統合するソリューションがあります。 詳細については、Azure Logic Apps のワークフローから IBM MQ サーバーに接続するを参照してください。

独自に作成したカスタム共有 Java EE ライブラリを使用しているかどうか確認する

共有 Java EE ライブラリ機能を使用している場合は、次の 2 つの選択肢があります。

  • アプリケーション コードをリファクターして、ライブラリへの依存関係をすべて削除し、代わりにその機能をアプリケーションに直接組み込みます。
  • サーバーのクラスパスにそれらのライブラリを追加します。

OSGi バンドルが使用されているかどうか確認する

WAS に追加された OSGi バンドルを使用している場合、Web アプリケーションに同様の JAR ファイルを直接追加する必要があります。

アプリケーションに OS 固有のコードが含まれているかどうかを判断する

アプリケーションにホスト OS に依存するコードが含まれている場合は、それをリファクタリングしてそれらの依存関係を削除する必要があります。 たとえば、アプリケーションが Windows 上で実行されている場合、ファイルシステム パス内で使用されている または を または に置き換える必要がある場合があります。

IBM Integration Bus が使用中かどうかを判断する

アプリケーションが IBM Integration Bus を使用している場合は、IBM Integration Bus がどのように構成されているかを把握する必要があります。 詳細については、IBM Integration Bus の資料を参照してください。

アプリケーションが複数の WAR で構成されているかどうか確認する

アプリケーションが複数の WAR で構成されている場合は、これらの各 WAR を個別のアプリケーションとして扱い、それぞれについてこのガイドに従う必要があります。

アプリケーションが EAR としてパッケージ化されているかどうか確認する

アプリケーションが、EAR ファイルとしてパッケージ化されている場合は、 application.xml、 ibm-application-bnd.xmi、 ibm-application-ext.xmi ファイルを調べて、構成をキャプチャします。 詳細については、WebSphereでのエンタープライズ・アーカイブ（EAR）パッケージのビルドを参照してください。

実稼働サーバーで実行されているすべての外部プロセスとデーモンを特定する

デーモンの監視など、アプリケーション サーバーの外部で実行されているプロセスがある場合は、それらを削除するか、別の場所に移行する必要があります。

ファイル システムが使用されているかどうかとその使用方法を判断する

VM ファイルシステムは、永続化、スタートアップ、およびシャットダウンに関して、オンプレミスのファイルシステムと同じように動作します。 それでも、ファイルシステムのニーズを認識し、VM のストレージ サイズとパフォーマンスが十分に確保されていることを確認することが重要です。

読み取り専用の静的コンテンツ

アプリケーションが現在静的コンテンツを提供している場合は、別の場所が必要です。 グローバルに高速ダウンロードするには、静的コンテンツを Azure Blob Storage に移動し、Azure Front Door を追加することを検討する必要があります。 詳細については、「Azure Storage での静的な Web サイトホスティング」を参照し、Azure Storage アカウントを Azure Front Door と統合します。

ネットワーク トポロジを決定する

Azure Marketplace オファーの現在のセットが、移行の出発点となります。 移行する必要があるアーキテクチャの側面がオファーに含まれていない場合は、既存のデプロイのネットワーク トポロジをキャプチャする必要があります。 その後、ソリューション テンプレートの 1 つを使用して基本オファーを立ち上げた後でも、そのネットワーク トポロジを Azure で再現する必要があります。

ネットワーク トポロジは、非常に広範なトピックですが、次のリファレンスを使用すると、移行作業に多少の方向性を見出すことができます。

  • データ ソースは WAS システム内の別々のサーバーであるため、ネットワークト ポロジ分析の一部としてそれらを考慮する必要があります。 詳細については、WebSphere Application Server のデータ・ソースを参照してください。
  • メッセージング ソースも別々のサーバーです。 詳細については、ネットワーク・トポロジー: WebSphere MQ メッセージング・プロバイダーを使用した相互運用を参照してください。
  • 負荷分散は、基本要件です。 WAS 側の負荷分散については、次のリファレンスを参照してください: WebSphere Application Server Network Deployment 負荷分散クラスタリング。

JCA アダプターとリソース アダプターの使用に関する考慮事項

既存のアプリケーションが JCA アダプターまたはその他リソースの アダプターを使用して別のエンタープライズ システムに接続している場合は、Azure 仮想マシンで実行されている WAS へのこれらアーティファクトに対して構成を適用します。 詳細については、IBM の資料の リレーショナル・リソース・アダプターと JCA を参照してください。

認証と認可を考慮する

ほとんどのアプリケーションには、ある種の認証および認可が備わっています。 認証に OpenID を使用する場合は、Microsoft Entra ID を使用して OpenID 接続認証を構成できます。 詳細については、Microsoft Entra ID を使用した OpenID Connect 認証を参照してください。

WAS クラスタリングが使用されているかどうかを判断する

ほとんどの場合、高可用性を実現するために複数の WAS サーバーにアプリケーションをデプロイしました。 これらのクラスターをオンプレミスのインストールから Azure 仮想マシン で実行されている WAS に直接移行できます。 詳細については、IBM の資料の WebSphere Application Server Network Deployment を参照してください。

負荷分散の要件の考慮

負荷分散は、WAS クラスターの Azure への移行において不可欠な部分です。 最も簡単な方法は、IBM WebSphere Application Server Cluster 向けの Azure Marketplace オファーで提供される Azure Application Gateway または IBM HTTP Server の組み込みサポートを使用することです。

Azure Application Gateway の機能を他の Azure の負荷分散ソリューションと比較した概要については、負荷分散オプションを参照してください。

Java EE アプリケーション クライアント機能が使用されているかどうか確認する

アプリケーションで Java EE アプリケーション クライアント機能を使用している場合は、Azure 仮想マシン に移行した後も変更なしで引き続き機能するはずです。 詳細については、Java EEクライアント・アプリケーション・モジュールの使用を参照してください。

移行

Azure 仮想マシン オファーで WAS traditional を選択する

Azure 仮想マシン 上の WAS については、次のオファーを利用できます。

オファーのデプロイ中に、WAS ノードの仮想マシンのサイズを選択するよう求められます。 VM サイズを選択する際、サイズ設定 (メモリ、プロセッサ、ディスク) のすべての側面を考慮することが重要です。 詳細については、Cloud Services (クラシック) のサイズを参照してください。

  • Azure VM 上の IBM WebSphere Application Server の単一インスタンス

    このオファーでは、Azure 仮想マシンに単一の WebSphere インスタンスをプロビジョニングするための定型的な手順がほぼ自動化されます。 WAS 管理コンソールを使用してアプリケーション サーバー プロファイルを作成します。

  • Azure 仮想マシン上の IBM WebSphere Application Server クラスター

    このオファーでは、Azure VM に WebSphere クラスターをプロビジョニングするための定型的な手順がほぼ自動化されます。 WAS 管理コンソールを持つデプロイメント マネージャを Azure VM 上に作成し、必要な数のノード エージェントを別々の Azure VM 上に作成します。

オファーをプロビジョニングする

最初に使用するオファーを選択したら、Azure 仮想マシン 上に WebSphere Application Server (traditional) クラスターをデプロイするの手順に従って、そのオファーをプロビジョニングします。

プロファイルを移行する

オファーをプロビジョニングしたら、プロファイル構成を確認できます。 詳しくは、IBM の資料にあるプロファイルの概念を参照してください。

データベースへの接続

プロファイルを移行した後、IBM ドキュメントの 「WebSphere Application Server データ・ソースの構成」 の手順に従って、データベースを接続します。

キーストアのアカウント

アプリケーションで使用されるすべての SSL キーストアの移行を考慮する必要があります。 詳細については、IBM の資料の SSL のキーストア構成 を参照してください。

JMS ソースの接続

データベースを接続したら、IBM ドキュメントの 「IBM WebSphere Application Server での JMS のセットアップ 」の手順に従って JMS を構成します。

認証と認可の考慮

ほとんどのアプリケーションには、ある種の認証および認可が備わっています。 認証に OpenID を使用する場合は、Microsoft Entra ID を使用して OpenID 接続認証を構成できます。 詳細については、Microsoft Entra ID を使用した OpenID Connect 認証を参照してください。

ログ記録用アカウント

IBM のドキュメントにある Analyzing WebSphere Application Server logs with Elastic Stack の手順に従って、Elastic Stack を設定できます。 Azure では、Elastic のサポートが提供されています。 詳細については、「Elastic と Azure の統合とは」を参照してください。これら 2 つのリソースの知識を組み合わせることで、VM 上の WAS 向けに Azure に最適化されたログ ソリューションを実現できます。

アプリケーションの移行

開発チームからテスト、ステージング、および実稼働の各サーバーにアプリケーションをデプロイするために使用される手法は、状況に応じて大きく異なります。 場合によっては、高度に進化した CI/CD プラットフォームによって、アプリケーションが WebSphere Application Server にデプロイされるケースがあります。 また、プロセスがより手動的になる場合もあります。 Azure 仮想マシン を使用してクラウドに WAS traditional アプリケーションを移行する利点の 1 つは、既存のプロセスが引き続き機能することです。

CI/CD パイプラインまたは手動デプロイ システムからのアクセスを許可するように、オファーによってプロビジョニングされたネットワーク セキュリティ グループを構成する必要があります。 詳細については、ネットワーク セキュリティ グループを参照してください。

テスト

Azure 内で実行されている新規サーバーにアクセスできるように、アプリケーションに対してコンテナー内テストを構成する必要があります。 CI/CD に関する考慮事項と同様に、ネットワーク セキュリティ規則により、Azure にデプロイされたアプリケーションにテストでアクセスできるようにする必要があります。 詳細については、ネットワーク セキュリティ グループを参照してください。

移行後

「移行前」ステップで定義した移行の目標に到達したら、エンド ツー エンドの受け入れテストを実施して、すべてが予期したとおりに機能することを確認します。 移行後の拡張機能の可能性に関するガイダンスについては、次の推奨事項を参照してください。

  • Azure Storage を使用して、仮想マシンにマウントされた静的コンテンツを提供します。 詳細については、Azure DevTest Labs のラボの仮想マシンにデータ ディスクを接続または切断するを参照してください。

  • Azure DevOps を使用して、移行した WAS クラスターにアプリケーションをデプロイします。 詳細については、Azure DevOps ドキュメントの利用を開始するを参照してください。

  • WAS traditional を Azure Application Gateway と一緒にデプロイした場合、Application Gateway でさらに構成を行う必要がある場合があります。 詳細については、アプリケーション ゲートウェイ構成の概要を参照してください。

  • 高度な負荷分散サービスを使用してネットワーク トポロジを強化します。 詳細については、Azure で負荷分散サービスを使用する方法を参照してください。

  • Azure マネージド ID をマネージド シークレットに使用し、Azure リソースへのロール ベースのアクセス権を割り当てます。 詳細については、Azure リソースのマネージド ID とは?を参照してください。

  • WAS Java Enterprise Edition 認証と Microsoft Entra ID での認証を統合します。 詳細については、Microsoft Entra ID とアプリケーションの統合の入門ガイドを参照してください。

  • Azure Key Vault を使用して、"シークレット" として機能するすべての情報を格納します。 詳細については、Azure Key Vault の基本概念をご覧ください。

  • 最終更新: