WebSphere アプリケーションを Azure Virtual Machines に移行する

  • [アーティクル]

このガイドでは、WebSphere Application Server (WAS) traditional アプリケーションを移行して Azure Virtual Machines で実行する場合に知っておくべきことについて説明します。 Azure Marketplace で使用できる WAS traditional ソリューションについては、「Azure で IBM WebSphere 製品ファミリを実行するためのソリューションとは」を参照してください。

移行前

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

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

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

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

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

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

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

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

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

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

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

AKS ベースの移行では、Free 階層を使用できます。 無料のクラスター管理を取得して、仮想マシン、関連ストレージ、消費したネットワーク リソースに対してのみ料金を支払います。 この場合は、「WebSphere applications を 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 サイズの選択がわかります。 詳細については、「クラウド サービスのサイズを構成する」を参照してください。

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

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 Standard Edition 8」を参照してください。

別の Java SDK に切り替える場合は、IBM ドキュメント「WebSphere Application Server で Java SDK を切り替える」の手順を実行します。

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

すべての JNDI リソースをインベントリします。 たとえば、データベースなどのデータソースには、関連付けられている JNDI 名が存在することがあります。これによって、JPA が特定のデータベースに EntityManager のインスタンスを正しくバインドできます。 JNDI リソースとデータベースの詳細については、IBM ドキュメントの「WebSphere データ・ソース」を参照してください。 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 コンポーネントが自動的に起動するように、systemd などの OS レベルのファシリティを使用していますか?

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

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

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

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

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

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 に依存するコードが含まれている場合は、それをリファクタリングしてそれらの依存関係を削除する必要があります。 たとえば、ファイル システムのパスで / または \ を使用している場合、File.Separator または Paths.get に置き換えることが必要になる可能性があります。

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 CDN を追加することを検討できます。 詳細については、「Azure Storage での静的 Web サイト ホスティング」と「クイック スタート:Azure ストレージ アカウントと Azure CDN との統合」を参照してください。 また、Azure Spring Apps Enterprise プランのアプリに静的コンテンツを直接デプロイすることもできます。 詳細については、「Web の静的ファイルのデプロイ」を参照してください。

動的に公開される静的コンテンツ

アプリケーションによってアップロードまたは生成されるが、作成後に変更できない静的コンテンツをアプリケーションで許可する場合は、前述のように Azure Blob Storage と Azure CDN を使用し、Azure Function でアップロードと CDN の更新を処理します。 「Azure Functions を使用した静的コンテンツのアップロードと CDN の事前読み込み」で、ご利用いただけるサンプルの実装を提供しています。 また、Azure Spring Apps Enterprise プランのアプリに静的コンテンツを直接デプロイすることもできます。 詳細については、「Web の静的ファイルのデプロイ」を参照してください。

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

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

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

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

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

認証と認可の考慮

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

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

多くの場合、高可用性を実現するために、アプリケーションは複数の WAS サーバーにデプロイされています。 これらのクラスターをオンプレミスのインストールから Azure Virtual Machines で実行されている WAS に直接移行できます。 詳細については、IBS ドキュメントにある「WebSphere Application Server Network Deployment」を参照してください。

負荷分散の要件の考慮

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

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

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

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

移行

Azure Virtual Machines オファーで WAS traditional を選択する

Azure Virtual Machines 上の WAS については、次のオファーを利用できます。

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

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

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

  • Azure VM 上の IBM WebSphere Application Server クラスター

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

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

開始するオファーを選択したら、「Azure 仮想マシンで (従来の) WebSphere Application Server クラスターをデプロイする」の手順を実行し、そのオファーをプロビジョニングします。

プロファイルを移行する

オファーをプロビジョニングしたら、プロファイル構成を確認できます。 詳細については、IBS ドキュメントにある「プロファイルのコンセプト」を参照してください。

データベースへの接続

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

キーストアの考慮

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

JMS ソースの接続

データベースに接続したら、IBS ドキュメントにある「IBM WebSphere Application Server で JMS を設定する」の手順を実行して、JMS を構成します。

認証と認可の考慮

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

ログの考慮

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

アプリケーションの移行

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

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

テスト

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

移行後

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