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

  • [アーティクル]

このガイドでは、既存の WebLogic アプリケーションを移行して Azure Virtual Machines で実行する場合に知っておくべきことについて説明します。 Azure Marketplace で入手できる WebLogic Server ソリューションの概要については、「Azure Virtual Machines で Oracle WebLogic Server を実行するためのソリューションとは?」を参照してください。

移行前

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

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

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

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

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

WLS アプリケーションを Azure に正常に移行する最初の手順は、最も適切な移行ターゲットを選択することです。 WLS は、Azure 仮想マシン (VM) または Azure Kubernetes Service (AKS) で適切に実行されます。 VM ターゲットは、オンプレミスのデプロイに最も近いため、最も簡単な選択です。 仮想マシンの管理とデプロイのエクスペリエンスは、オンプレミスにあるものに非常に似ています。 この容易さのトレードオフは、経済的コストです。 一般に、VM ベースのソリューションの 1 分あたりのコストは、AKS と比較して高くなります。 AKS ベースのソリューションの実行コストは低くなりますが、AKS の要件に合わせてアプリケーションを制限する必要があります。 変更を最小限に抑えることが移行作業の最も重要な要素である場合は、VM ベースの移行を検討してください。 この場合は、「WebLogic Server のアプリケーションを Azure Virtual Machines に移行する」を参照してください。 Kubernetes 内で実行するようにアプリケーションを変換してランタイム コストを削減できる場合は、AKS ベースの移行を検討してください。 この場合は、「WebLogic Server アプリケーションを Azure Kubernetes Service に移行する」に進みます。

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

Oracle と Microsoft は提携して、Azure への移行を円滑に進めるための Azure ソリューション テンプレートを Azure Marketplace で提供しています。 「Oracle Fusion Middleware」ドキュメントでオファーの一覧を参照し、既存のデプロイに最も適合するものを選択してください。 オファーの一覧は、概要記事の「Azure の Oracle WebLogic Server とは」で確認できます。

既存のオファーがいずれも適切な開始点でない場合は、Azure 仮想マシンのリソースを使用して手動でデプロイを再現する必要があります。 ステップ バイ ステップのガイドについては、「Azure Virtual Machines に Oracle WebLogic Server を手動でインストールする」を参照してください。 詳細については、「IaaS とは」を参照してください。

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

既存の WebLogic バージョンは、IaaS オファーのバージョンと互換性がある必要があります。 WebLogic バージョン 12.2.1.4 のオファーを確認するには、Azure Marketplace で Oracle WebLogic 12.2.1.4 を検索してください。 既存の WebLogic バージョンがそのバージョンと互換性がない場合は、Azure IaaS リソースを使用して手動でデプロイを再現する必要があります。 詳細については、Azure のドキュメントを参照してください。

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

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

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

Azure Key Vault などの "サービスとしての構成" テクノロジが登場する前に、"シークレット" の明確に定義された概念はありませんでした。 代わりに、現在 "シークレット" を呼ばれるものとして効果的に機能する、さまざまな種類の構成設定のセットがありました。 WebLogic Server などのアプリ サーバーでは、これらのシークレットは多くの異なる構成ファイルと構成ストアにあります。 すべてのシークレットとパスワードについて、実稼働サーバー上のすべてのプロパティと構成ファイルを確認します。 必ず、WAR 内の weblogic.xml を確認してください。 また、パスワードや資格情報を含む構成ファイルがアプリケーション内に見つかる場合もあります。 詳細については、「Azure Key Vault の基本的な概念」をご覧ください。

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

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

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

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

Azure への WebLogic の移行パスのすべてにおいて、パスごとに異なる特定の Java バージョンが必要です。 そのサポートされているバージョンを使用してアプリケーションを正常に実行できることを検証する必要があります。

Note

現在のサーバーがサポートされていない JDK (Oracle JDK や IBM OpenJ9 など) で実行されている場合、この検証が特に重要です。

現在の Java バージョンを取得するには、実稼働サーバーにサインインし、次のコマンドを実行します。

java -version

Note

Azure 仮想マシン上の WLS に移行する場合、特定の Java バージョンの要件は、仮想マシンにプレインストールされている Java によって決まります。 AKS 上の WLS に移行する場合、特定の Java バージョンは、選択したコンテナー イメージによって決まります。 さまざまな選択肢がありますが、それらはすべて Oracle JDK を使用します。

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

すべての JNDI リソースをインベントリします。 たとえば、データベースなどのデータソースには、関連付けられている JNDI 名が存在することがあります。これによって、JPA が特定のデータベースに EntityManager のインスタンスを正しくバインドできます。 JNDI リソースとデータベースの詳細については、Oracle ドキュメントの「WebLogic Server データ・ソース」を参照してください。 JMS メッセージ ブローカーなど、その他の JNDI 関連リソースには、移行または再構成が必要になる場合があります。 JMS の構成の詳細については、Oracle WebLogic Server 12.2.1.4.0 を参照してください。

ドメインの構成を検査する

WebLogic Server の主な構成単位は、ドメインです。 そのため、config.xml ファイルには、移行のために慎重に検討する必要がある多数の構成が含まれています。 このファイルには、サブディレクトリに格納されている追加の XML ファイルへの参照が記載されています。 Oracle では、通常、[管理コンソール] を使用して WebLogic Server の管理可能なオブジェクトとサービスを構成し、WebLogic Server で config.xml ファイルを保守できるようにすることを推奨しています。 詳細については、「ドメイン構成ファイル」を参照してください。

アプリケーション内

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

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

Oracle の Coherence*Web の有無にかかわらず、アプリケーションがセッション レプリケーションに依存している場合は、次の 3 つの選択肢があります。

  • Coherence*Web は、Azure 仮想マシンで WebLogic Server と共に実行できますが、オファーをプロビジョニングした後に、このオプションを手動で構成する必要があります。 スタンドアロン Coherence を使用している場合は、Azure の仮想マシンでそれを実行することもできますが、オファーをプロビジョニングした後に、このオプションを手動で構成する必要があります。
  • セッション管理にデータベースを使用するようにアプリケーションをリファクターします。
  • Azure Redis サービスへのセッションを外部化するようにアプリケーションをリファクターします。 詳細については、「Azure Cache for Redis」を参照してください。

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

データソースの文書化

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

  • データソース名
  • 接続プールの構成
  • JDBC ドライバーの JAR ファイルの場所

WebLogic の JDBC ドライバーの詳細については、「WebLogic Server での JDBC ドライバの使用方法」を参照してください。

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

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

  • スタートアップ スクリプトは変更されていますか? このようなスクリプトには、setDomainEnv、commEnv、startWebLogic、stopWebLogic などがあります。
  • JVM に渡される特定のパラメーターはありますか?
  • サーバーのクラスパスに追加された JAR はありますか?

REST 経由の管理が使用されているかどうか確認する

アプリケーションのライフサイクルに REST 経由の管理の使用が含まれている場合は、REST API にアクセスするために使用されているポートを把握し、それらがどのように認証され、公開されているかを確認する必要があります。 移行後、アプリケーションのライフサイクルが移行前と同様の方法で動作できるように、これらの同じポートと認証メカニズムが公開されていることを確認する必要があります。 詳細については、「RESTful 管理サービスによる Oracle WebLogic Server の管理」を参照してください。

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

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

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

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

JMS 永続ストアが構成されている場合は、それらの構成を把握して、移行後に適用する必要があります。

Oracle メッセージ ブローカーを使用している場合は、このソフトウェアを Azure 仮想マシンに移行し、そのまま使用できます。

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

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

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

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

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

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

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

Oracle Service Bus が使用されているかどうか確認する

アプリケーションが Oracle Service Bus (OSB) を使用している場合は、OSB がどのように構成されているかを把握する必要があります。 詳細については、「Oracle Service Bus のインストールについて」を参照してください。

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

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

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

アプリケーションが EAR ファイルとしてパッケージ化されている場合は、必ず application.xml および weblogic-application.xml ファイルを調べて、その構成を把握してください。

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

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

WebLogic Scripting Tool (WLST) を使用しているかどうか確認する

現在、WLST を使用してデプロイを実行している場合は、実行内容を評価する必要があります。 WLST がデプロイの一部としてアプリケーションの (ランタイム) パラメーターを変更している場合は、移行後にアプリケーションをテストする際、この動作が引き続き機能することを確認する必要があります。

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

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

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

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

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

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

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

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

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

  • このリファレンスは、「Fast Track Deployment Guide」にある、Azure へのネットワーク トポロジの移行に関連するトピックの概要を列挙しています。
  • このリファレンスでは、「WebLogic Server Clustering」にある、ネットワーク トポロジに影響を与えるクラスタリングに関する重要事項について説明しています。
  • データ ソースは WebLogic システム内の別々のサーバーであるため、ネットワークト ポロジ分析の一部としてそれらを考慮する必要があります。 「WebLogic Server データ・ソース」。
  • メッセージング ソースも別々のサーバーです。 「WebLogic Sever メッセージング」
  • 負荷分散は、基本要件です。 このリファレンスでは、「Load Balancing in a Cluster」にある、負荷分散の WebLogic Server 側について説明しています。

JCA アダプターとリソース アダプターの使用の考慮

既存のアプリケーションが、JCA アダプターやリソース アダプターを使用して他のエンタープライズ システムに接続している場合は、これらの成果物の構成が Azure Virtual Machines で実行されている WebLogic サーバーに適用されるようにしてください。 詳細については、「リソース・アダプタの作成と構成」を参照してください

カスタム セキュリティ プロバイダーと JAAS の使用の考慮

アプリケーションで JAAS を使用している場合は、セキュリティ プロバイダーの構成が正しく移行されていることを確認する必要があります。 詳細については、Oracle のドキュメントの「WebLogic セキュリティ・プロバイダの構成について」を参照してください。

WebLogic クラスタリングが使用されているかどうか確認する

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

負荷分散の要件の考慮

負荷分散は、Oracle WebLogic Server クラスターの Azure への移行において不可欠な部分です。 最も簡単な解決策は、Oracle WebLogic Server クラスター向けの Azure Marketplace オファーで提供される Azure Application Gateway の組み込みサポートを使用することです。 このトピックに関するチュートリアルについては、「チュートリアル: ロード バランサーとして Azure Application Gateway を使用して、Azure に WebLogic Server クラスターを移行する」を参照してください。

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

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

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

移行

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

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

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

管理サーバーのない WebLogic Server 単一ノード

このオファーでは、単一の VM が作成され、それに WebLogic がインストールされますが、ドメインは構成されません。これは、高度にカスタマイズされたドメイン構成を使用する場合に便利です。

管理サーバーがある WebLogic Server 単一ノード

このオファーでは、単一の VM がプロビジョニングされ、それに WebLogic Server がインストールされます。 ドメインが作成され、管理サーバーが起動されます。

WebLogic Server N ノード クラスター

このオファーでは、WebLogic Server VM の高可用性クラスターが作成されます。

WebLogic Server N ノード動的クラスター

このオファーでは、可用性が高くてスケーラブルな、WebLogic Server VM の動的クラスターが作成されます

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

開始するオファーを選択したら、オファーのドキュメントに記載されている手順に従って、そのオファーをプロビジョニングします。 既存のドメイン名と一致するドメイン名を必ず選択してください。 ドメイン パスワードを既存のドメイン パスワードと一致させることもできます。

ドメインの移行

オファーをプロビジョニングしたら、ドメインの構成を確認し、ドメインの移行方法の詳細についてこちらのガイダンスに従います。

データベースへの接続

ドメインを移行したら、オファーのドキュメントの手順に従うことで、データベースに接続できます。 これらの手順は、関連するデータベースのシークレットとアクセス文字列を適切に管理するのに役立ちます。

キーストアの考慮

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

JMS ソースの接続

データベースに接続したら、JMS を構成できます。 詳細については、WebLogic のドキュメントの「Fusion Middleware で Oracle WebLogic Server の JMS リソースを管理する」を参照してください。

認証と認可の考慮

ほとんどのアプリケーションには、ある種の認証および認可が備わっています。 認証に LDAP を使用する場合は、Secure LDAP を使用して Microsoft Entra Domain Services を設定し、WebLogic Server で LDAP 接続を構成できます。 詳細については、「Microsoft Entra Domain Services マネージド ドメインを作成して構成する」と「Microsoft Entra Domain Services マネージド ドメインの Secure LDAP を構成する」を参照してください。

ログの考慮

Oracle WebLogic Server の Marketplace ソリューション テンプレートによって提供される、Elastic on Azure との統合機能を使用します。 これはログを管理する最も簡単な方法です。 プランの一覧については、「Azure Virtual Machines で Oracle WebLogic Server を実行するためのソリューションとは?」を参照してください。Elastic を構成するための完全なチュートリアルは以下で提供されています。

Elastic 統合が適切でない場合は、ドメインを移行するときに既存のログ構成を引き継ぐ必要があります。 詳細については、Oracle ドキュメント内の「java.util.logging ロガー レベルの構成」および「Oracle WebLogic Server ログ ファイルの構成とログ メッセージのフィルタリング」を参照してください。

アプリケーションの移行

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

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

テスト

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

移行後

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