WebSphere アプリケーションを Azure App Service 上の JBoss EAP に移行する
このガイドでは、既存の WebSphere アプリケーションを移行し、JBoss EAP を使用して Azure App Service で実行する場合に知っておくべきことについて説明します。
移行前
移行を確実に成功させるには、開始する前に、次のセクションで説明する評価とインベントリの手順を完了します。
サーバー容量をインベントリする
現在の実稼働サーバーのハードウェア (メモリ、CPU、ディスク) と、平均およびピーク時の要求数とリソース使用率を文書化します。 この情報は、選択した移行パスに関係なく必要になります。 たとえば、App Service プランの選択をガイドするのに役立ちます。
使用可能な App Service プラン レベルの一覧には、メモリ、CPU コア、ストレージ、および価格情報が表示されます。 App Service 上の JBoss EAP は、Premium V3 および Isolated V2 App Service プラン レベルでのみ使用できます。
すべてのシークレットをインベントリする
すべてのシークレットとパスワードについて、実稼働サーバー上のすべてのプロパティと構成ファイルを確認します。 必ず、WAR 内の ibm-web-bnd.xml を確認してください。 また、パスワードや資格情報を含む構成ファイルがアプリケーション内に見つかる場合もあります。 これらには、Spring Boot アプリケーションの場合は application.properties または application.yml ファイルなどがあります。
すべての証明書をインベントリする
パブリック SSL エンドポイントで使用されるすべての証明書を文書化します。 次のコマンドを実行して、運用サーバー上のすべての証明書を表示できます。
keytool -list -v -keystore <path to keystore>
サポートされている Java バージョンが正しく動作することを検証する
Azure App Service 上の JBoss EAP では、Java 8 と 11 がサポートされています。 したがって、そのサポートされているバージョンを使用してアプリケーションを正常に実行できることを検証する必要があります。 現在のサーバーでサポートされていない JDK (Oracle JDK や IBM OpenJ9 など) を使用している場合、この検証が特に重要です。
現在の Java バージョンを取得するには、実稼働サーバーにサインインし、次のコマンドを実行します。
java -version
JNDI リソースをインベントリする
すべての JNDI リソースをインベントリします。 JMS メッセージ ブローカーなどいくつかのリソースでは、移行または再構成が必要になる場合があります。
アプリケーション内
WEB-INF/ibm-web-bnd.xml ファイルおよび WEB-INF/web.xml ファイルを調べます。
データベースが使用されているか確認する
アプリケーションでデータベースを使用する場合は、次の情報を把握する必要があります。
- データソース名。
- 接続プールの構成。
- JDBC ドライバー JAR ファイルの場所。
ファイル システムが使用されているかどうかとその使用方法を判断する
アプリケーション サーバーでファイル システムを使用する場合は、再構成や、まれにアーキテクチャの変更が必要になります。 ファイル システムは、WebSphere 共有モジュールまたはアプリケーション コードによって使用される場合があります。 次のシナリオの一部または全部を確認できます。
読み取り専用の静的コンテンツ
現在、アプリケーションで静的コンテンツを提供している場合は、そのための別の場所が必要になります。 静的コンテンツを 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 Storage を App Service ファイル システムにマウントできます。 詳細については、「Linux 上の App Service 内の Azure Storage からコンテンツを提供する」を参照してください。
スケジュールされたジョブにアプリケーションが依存しているかどうかを判断する
スケジュールされたジョブ (Quartz Scheduler タスクや Unix cron ジョブなど) は、Azure App Service では使用しないでください。 Azure App Service では、スケジュールされたタスクを含むアプリケーションの内部でのデプロイが妨げられることはありません。 ただし、アプリケーションをスケールアウトすると、同じスケジュールされたジョブが、スケジュールされた期間に複数回実行されることがあります。 このような場合、意図しない結果になることがあります。
スケジュールされたジョブを Azure で実行するには、Azure Functions をタイマー トリガーとともに使用することを検討してください。 詳しくは、「Azure Functions のタイマー トリガー」を参照してください。 ジョブ コード自体を関数に移行する必要はありません。 この関数では、アプリケーションで URL を呼び出すだけでジョブをトリガーできます。
Note
悪意のある使用を防ぐために、ジョブの呼び出しエンドポイントで資格情報が求められるようにする必要があります。 この場合、トリガー関数が資格情報を提供する必要があります。
オンプレミスへの接続が必要かどうかを判断する
アプリケーションからオンプレミスのサービスのいずれかにアクセスする必要がある場合、Azure の接続サービスの 1 つをプロビジョニングする必要があります。 詳しくは、「オンプレミス ネットワークを Azure に接続するためのソリューションを選択する」をご覧ください。 または、オンプレミスのリソースで公開されている一般公開の API を使用するように、アプリケーションをリファクタリングする必要があります。
Java Message Service (JMS) キューまたはトピックが使用中かどうか確認する
アプリケーションで JMS キューまたはトピックを使用している場合は、外部でホストされている JMS サーバーにそれらを移行する必要があります。 Azure Service Bus と Advanced Message Queuing Protocol (AMQP) は、JMS を使用している場合の優れた移行方法となります。 詳細については、「Azure Service Bus と AMQP 1.0 で Java Message Service (JMS) を使用する」を参照してください。
JMS 永続ストアが構成されている場合は、それらの構成を把握して、移行後に適用する必要があります。
アプリケーションで WebSphere 固有の API が使用されているかどうかを判断する
アプリケーションで WebSphere 固有の API が使用されている場合は、アプリケーションで使用されないようにリファクタリングする必要があります。 Red Hat Migration Toolkit for Apps は、これらの依存関係の削除とリファクタリングに役立ちます。
アプリケーションで Entity Beans または EJB 2.x スタイルの CMP Beans が使用されているかどうかを判断する
アプリケーションで Entity Beans または EJB 2.x スタイルの CMP Beans が使用されている場合は、アプリケーションをリファクタリングしてこれらの依存関係を削除する必要があります。
Java EE アプリケーション クライアント機能が使用されているか確認する
Java EE アプリケーション クライアント機能を使用して (サーバー) アプリケーションに接続するクライアント アプリケーションがある場合は、HTTP API を使用するようにクライアント アプリケーションと (サーバー) アプリケーションの両方をリファクタリングする必要があります。
アプリケーションに OS 固有のコードが含まれているかどうかを判断する
アプリケーションにホスト OS に依存するコードが含まれている場合は、それをリファクタリングしてそれらの依存関係を削除する必要があります。 たとえば、ファイル システムのパスで /
または \
を使用している場合、File.Separator
または Paths.get
に置き換えることが必要になる可能性があります。
EJB タイマーが使用中かどうかを判断する
アプリケーションで EJB タイマーを使用する場合は、EJB タイマー コードが各 JBoss EAP インスタンスによって個別にトリガーできることを確認する必要があります。 この検証が必要なのは、App Service を水平方向にスケーリングすると、各 EJB タイマーが独自の JBoss EAP インスタンスでトリガーされるためです。
JCA コネクタが使用されているかどうかを判断する
アプリケーションで JCA コネクタを使用する場合は、JBoss EAP 上で JCA コネクタを使用できることを確認する必要があります。 JCA の実装が WebSphere に関連付けられている場合は、JCA コネクタでその依存関係を削除するようにアプリケーションをリファクタリングする必要があります。 JCA コネクタを使用できる場合は、サーバー クラスパスに JAR を追加する必要があります。 また、必要な構成ファイルを JBoss EAP サーバー ディレクトリ内の適切な場所に配置して使用できるようにする必要があります。
JAAS が使用されているかどうかを判断する
アプリケーションで JAAS が使用されている場合は、JAAS がどのように構成されているかを把握する必要があります。 データベースを使用している場合は、それを JBoss EAP 上の JAAS ドメインに変換できます。 カスタム実装の場合は、それを JBoss EAP で使用できるかどうかを確認する必要があります。
アプリケーションでリソース アダプターが使用されるかどうかを判断する
アプリケーションでリソース アダプター (RA) が必要な場合、JBoss EAP と互換性がある必要があります。 JBoss EAP のスタンドアロン インスタンスで RA が正常に機能するかどうかを確認するには、それをサーバーにデプロイし、適切に構成します。 RA が適切に機能する場合、JAR を App Service インスタンスのサーバー クラスパスに追加し、必要な構成ファイルを JBoss EAP サーバー ディレクトリ内の適切な場所に配置して使用できるようにする必要があります。
アプリケーションが複数の WAR で構成されているかどうか確認する
アプリケーションが複数の WAR で構成されている場合は、これらの各 WAR を個別のアプリケーションとして扱い、それぞれについてこのガイドに従う必要があります。
アプリケーションが EAR としてパッケージ化されているかどうか確認する
アプリケーションが EAR ファイルとしてパッケージ化されている場合は、必ず application.xml および ibm-application-bnd.xml ファイルを調べて、その構成を把握してください。
実稼働サーバーで実行されているすべての外部プロセスとデーモンを特定する
デーモンの監視など、アプリケーション サーバーの外部で実行されているプロセスがある場合は、それらを削除するか、別の場所に移行する必要があります。
移行
Red Hat Migration Toolkit for Apps
Red Hat Migration Toolkit for Applications は、Visual Studio Code 用の無料の拡張機能です。 この拡張機能は、アプリケーション コードと構成を分析して、独自の API との依存関係の削除など、Jakarta EE アプリケーションを他のアプリ サーバーから JBoss EAP に移行するためのレコメンデーションを提供します。 この拡張機能では、オンプレミスからクラウドに移行する場合のレコメンデーションも提供されます。 詳細については、「Migration Toolkit for Applications の概要」を参照してください。
このガイドの内容は、移行の過程における他のコンポーネントの処理に役立ちます (適切な App Service プラン タイプの選択、セッション状態の外部化、EAP インスタンスの管理に JBoss 管理インターフェイスではなく Azure を使用するなど)。
App Service プランをプロビジョニングする
利用可能なサービス プランの一覧から、仕様が現在の実稼働ハードウェアの仕様を満たしているか超えているプランを選択します。
Note
ステージング/カナリア デプロイを実行する場合、またはデプロイ スロットを使用する場合は、App Service プランにその追加容量が含まれている必要があります。 Java アプリケーションでは、Premium 以上のプランを使用することをお勧めします。
Web アプリを作成してデプロイする
App Service プランでは、JBoss EAP サーバーにデプロイされている WAR ファイルごとに Web アプリを作成する必要があります。
Note
1 つの Web アプリに複数の WAR ファイルをデプロイすることは可能ですが、非常に望ましくない操作です。 1 つの Web アプリに複数の WAR ファイルをデプロイすると、各アプリケーションを独自の使用要件に従ってスケーリングできなくなります。 さらに、後続の配置パイプラインの複雑さも増大します。 1 つの URL で複数のアプリケーションを使用できるようにする必要がある場合は、Azure Application Gateway などのルーティング ソリューションの使用を検討してください。
Maven アプリケーション
アプリケーションが Maven POM ファイルから作成されている場合は、Maven 用の Webapp プラグインを使用して Web アプリを作成し、アプリケーションをデプロイします。 詳細については、「クイック スタート: Azure App Service 上で Java アプリを作成する」の「Maven プラグインの構成」セクションを参照してください。
Maven 以外のアプリケーション
Maven プラグインを使用できない場合は、次のような他のメカニズムを使用して Web アプリをプロビジョニングする必要があります。
Web アプリを作成したら、利用可能なデプロイ メカニズムのいずれかを使用してアプリケーションをデプロイします。 詳細については、「App Service へのファイルのデプロイ」を参照してください。
JVM ランタイムオプションを移行する
アプリケーションで特定のランタイム オプションが必要な場合は、最適なメカニズムを使用してそれらを指定します。 詳細については、「Azure App Service 用に Java アプリを構成する」の「Java ランタイム オプションの設定」セクションを参照してください。
シークレットを取り込む
アプリケーション固有のシークレットを格納するには、アプリケーション設定を使用します。 複数のアプリケーションで 1 もしくは複数の同じシークレットを使用する場合、またはきめ細かなアクセス ポリシーと監査機能が必要な場合は、代わりに Azure Key Vault 参照を使用します。 詳細については、「Azure App Service 用に Java アプリを構成する」の「KeyVault 参照の使用」セクションを参照してください。
カスタム ドメインと SSL を構成する
アプリケーションをカスタム ドメインに表示する場合は、Web アプリケーションをそれにマップする必要があります。 詳細については、「チュートリアル: 既存のカスタム DNS 名を Azure App Service にマップする」を参照してください。
その後に、そのドメインの TLS/SSL 証明書を App Service Web アプリにバインドする必要があります。 詳細については、「Azure App Service で TLS/SSL バインディングを使用してカスタム DNS 名をセキュリティで保護する」を参照してください。
データソース、ライブラリ、および JNDI リソースを移行する
データ ソースを移行するには、「Azure App Service 用に Java アプリを構成する」の「データ ソースの構成」セクションの手順に従います。
「Azure App Service 用に Java アプリを構成する」の「JBoss EAP」セクションの手順に従って、追加のサーバー レベルのクラスパス依存関係を移行します。
その他の共有サーバー レベルの JDNI リソースを移行します。 詳細については、「Azure App Service 用に Java アプリを構成する」の「JBoss EAP」セクションを参照してください。
Note
アプリケーションごとに 1 つの WAR という推奨アーキテクチャに従っている場合は、サーバー レベル クラスパス ライブラリと JNDI リソースをアプリケーションに移行することを検討してください。 これにより、コンポーネントのガバナンスと変更管理が大幅に簡素化されます。 アプリケーションごとに複数の WAR をデプロイする場合は、このガイドの冒頭で説明したコンパニオン ガイドの 1 つを確認する必要があります。
スケジュールされたジョブを移行する
少なくとも、スケジュールされたジョブを Azure VM に移動して、それらがアプリケーションに含まれないようにする必要があります。 または、Azure Functions、SQL Database、Event Hubs などの Azure サービスを使用して、それらをイベント ドリブン Java に最新化することもできます。
再起動とスモーク テスト
最後に、Web アプリを再起動してすべての構成の変更を適用する必要があります。 再起動が完了したら、アプリケーションが正しく実行されていることを確認します。
移行後
アプリケーションを Azure App Service に移行したので、期待どおりに動作することを確認する必要があります。 これを完了したら、アプリケーションをよりクラウド ネイティブにするための推奨事項がいくつかあります。
推奨事項
ファイル ストレージ用に /home ディレクトリを使用することを選択した場合は、それを Azure Storage に置き換えることを検討してください。 詳細については、「App Service のカスタム コンテナーでローカル共有として Azure Storage をマウントする」を参照してください。
接続文字列、SSL キー、およびその他の機密情報が含まれている /home ディレクトリ内に構成がある場合、可能であれば、Azure Key Vault とアプリケーション設定を使用するパラメーター インジェクションとを組み合わせて使用することを検討してください。 詳細については、「App Service と Azure Functions の Key Vault 参照を使用する」および「App Service アプリを構成する」を参照してください。
ダウンタイムなしで信頼性の高いデプロイを行うには、デプロイ スロットの使用を検討してください。 詳細については、「Azure App Service でステージング環境を設定する」を参照してください。
DevOps の戦略を設計し、実装します。 信頼性を維持しながら開発速度を向上させるには、Azure Pipelines を使用してデプロイとテストを自動化することを検討してください。 詳細については、「ビルドと Java Web アプリへのデプロイ」を参照してください。 デプロイ スロットを使用している場合は、スロットへのデプロイと後続のスロット スワップを自動化できます。 詳細については、「Azure Web アプリをデプロイする」の「スロットにデプロイする」セクションを参照してください。
事業継続とディザスター リカバリー戦略を設計し、実装します。 ミッション クリティカルなアプリケーションの場合は、複数リージョン デプロイのアーキテクチャを検討してください。 詳細については、「可用性の高い複数リージョンの Web アプリケーション」を参照してください。