次の方法で共有

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 アプリケーションを Azure Virtual Machinesに移行する」を参照してください。 Kubernetes 内で実行するようにアプリケーションを変換してランタイム コストを削減できる場合は、AKS ベースの移行を検討してください。 この場合は、「WebLogic Server アプリケーションをAzure Kubernetes Serviceに移行する」に進みます。

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

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

どの既存のオファーも適切な出発点でない場合は、Azure Virtual Machine リソースを使用して手動でデプロイを再現する必要があります。 詳細なガイダンスについては、「Azure Virtual Machines に Oracle WebLogic Server を手動でインストールする」を参照してください。 詳細については、「IaaS とは」を参照してください。

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

既存の WebLogic バージョンは、IaaS オファーのバージョンと互換性がある必要があります。 WebLogic バージョン 12.2.1.3 のオファーを確認するには、Oracle WebLogic 12.2.1.3 のAzure Marketplaceを照会します。 既存の 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 バージョンが必要です。 そのサポートされているバージョンを使用してアプリケーションを正常に実行できることを検証する必要があります。

注意

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

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

java -version

注意

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 と AMQP 1.0 で Java Message Service (JMS) を使用する」を参照してください。

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

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

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

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

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

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

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

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

アプリケーションにホスト OS に依存するコードが含まれている場合は、それをリファクタリングしてそれらの依存関係を削除する必要があります。 たとえば、ファイル システムのパスで / または \ を使用している場合、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 Spring Apps Enterprise プランのアプリに直接デプロイすることもできます。 詳細については、「 Web 静的ファイルをデプロイする」を参照してください。

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

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

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

現在の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 サーバー ノードの仮想マシン サイズを選択するように求められます。 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 Administering JMS Resources for Oracle WebLogic Server 」を参照してください。

認証と認可の考慮

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

ログの考慮

Oracle WebLogic Server マーケットプレース ソリューション テンプレートによって提供される 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 にデプロイされたアプリケーションにテストでアクセスできるようにする必要があります。 詳細については、「ネットワーク セキュリティ グループ」を参照してください。

移行後

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