Azure に Java アプリケーションを移行する
この記事では、Java アプリケーションを Azure に移行する場合に推奨されている方法について概要を示します。
この移行ガイダンスは、Azure 上の Java のメインストリームのシナリオを取り上げ、高度な計画の推奨事項と考慮事項を提供するように設計されています。 Microsoft Java on Azure チームと特定の Java アプリの移行シナリオについて検討したい場合は、次のアンケートにご記入ください。担当者からお客様にご連絡いたします。
アプリケーションの種類の特定
Java アプリケーションのクラウドの移行先を選択する前に、アプリケーションの種類を特定する必要があります。 ほとんどの Java アプリケーションは、次のいずれかの種類になります。
- Spring アプリケーション:
- Java EE アプリケーション
- Web アプリケーション
- バッチ/スケジュールされたジョブ
以降のセクションでは、ここに挙げた種類について説明します。
Spring Boot/JAR アプリケーション
新しい多くのアプリケーションは、コマンド ラインから直接呼び出されます。 その場合でもこれらのアプリケーションは Web 要求を処理しますが、アプリケーション サーバーに依存して HTTP 要求の処理を行うのではなく、HTTP 通信と他のすべての依存関係を直接アプリケーション パッケージに組み込みます。 このようなアプリケーションは、多くの場合、Spring Boot、Dropwizard、Micronaut、MicroProfile、Vert.x などのフレームワークを使用して構築されます。
これらのアプリケーションは、 .jar 拡張子 (JAR ファイル) を使用してアーカイブにパッケージ化されます。
Spring Cloud ミドルウェア モジュールを使用する Spring アプリケーション
"マイクロサービス アーキテクチャ スタイル" は、1 つのアプリケーションを小さなサービスのスイートとして開発するアプローチです。 各サービスは独自のプロセス内で実行され、軽量なメカニズム (多くの場合、HTTP リソース API) を使って通信します。 これらのサービスはビジネス機能を基に作成され、完全に自動化されたデプロイ メカニズムによって個別にデプロイできます。 これらのサービスは、さまざまなプログラミング言語で記述され、さまざまなデータ ストレージ テクノロジを使用している可能性があり、最小限の集中管理が行われます。 こうしたサービスは、多くの場合、Spring Cloud などのフレームワークを使用して作成されます。
これらのサービスは、 .jar 拡張子 (JAR ファイル) を使用して複数のアプリケーションにパッケージ化されます。
Java EE アプリケーション
Java EE アプリケーション (J2EE アプリケーションや、さらに最近では Jakarta EE アプリケーションとも呼ばれます) は、Web アプリケーションの一部またはすべての要素を含む場合や、まったく含んでいない場合があります。 これらのアプリケーションには、 Jakarta EE 仕様で定義されているように、さらに多くのコンポーネントを格納して使用することもできます。
Java EE アプリケーションは、 .ear 拡張子 (EAR ファイル) を使用してアーカイブとしてパッケージ化することも、 .war 拡張子 (WAR ファイル) を使用してアーカイブとしてパッケージ化することもできます。
Java EE アプリケーションは、Java EE 準拠のアプリケーション サーバー (Oracle WebLogic Server、IBM WebSphere、JBoss EAP、GlassFish、Payara など) にデプロイする必要があります。
Java EE 仕様によって提供される機能のみに依存するアプリケーション (つまり、アプリ サーバー非依存アプリケーション) は、準拠アプリケーション サーバー間で移行できます。 アプリケーションが特定のアプリケーション サーバーに依存している (アプリ サーバー依存) 場合は、そのアプリケーション サーバーをホストすることが許可される Azure サービス移行先を選択することが必要になる可能性があります。
Web アプリケーション
Web アプリケーションは、 サーブレット コンテナー内で実行されます。 これらのアプリケーションの中には、サーブレット API を直接使用するものもありますが、多くは、Apache Struts、Spring MVC、JavaServer Faces (JSF) など、サーブレット API をカプセル化するその他のフレームワークを使用します。
Web アプリケーションは、 .war 拡張子 (WAR ファイル) を使用してアーカイブにパッケージ化されます。
バッチ/スケジュールされたジョブ
アプリケーションによっては、要求やユーザー入力を待機するのではなく、短時間だけ実行し、特定のワークロードを実行して終了することを意図したものがあります。 場合によっては、このようなジョブは 1 回だけ、または一定のスケジュールされた間隔で実行する必要があります。 オンプレミスでは、多くの場合、このようなジョブはサーバーの crontab から呼び出されます。
これらのアプリケーションは、 .jar 拡張子 (JAR ファイル) を使用してアーカイブにパッケージ化されます。
Note
アプリケーションでスケジューラ (Spring Batch や Quartz など) を使用してスケジュールされたタスクを実行する場合は、このようなタスクがアプリケーションの外部で実行されるようにすることを強くお勧めします。 アプリケーションをクラウド内の複数のインスタンスにスケーリングすると、同じジョブが複数回実行されます。 さらに、スケジュール メカニズムでホストのローカル タイム ゾーンが使用されている場合、複数のリージョンにまたがってアプリケーションをスケーリングすると、望ましくない動作が生じる可能性があります。
対象の Azure サービスの移行先を選択する
以降のセクションでは、どのサービス移行先がアプリケーションの要件を満たしているか、およびどのような役割が必要になるかを示します。
ホスティング オプション グリッド
次のグリッドを使用して、アプリケーションの種類で考えられる宛先を特定します。 ご覧のとおり、Azure Kubernetes Service (AKS) と Azure Virtual Machines ではすべての種類のアプリケーションがサポートされていますが、次のセクションで示すように、チームはより多くの責任を負う必要があります。
| 移行先 → アプリケーションの種類 ↓ |
アプリ サービス Java SE |
アプリ サービス Tomcat |
アプリ サービス JBoss EAP |
Azure Container Apps | AKS | 仮想 マシン |
|---|---|---|---|---|---|---|
| Spring Boot/JAR アプリケーション | ✔ | ✔ | ✔ | ✔ | ||
| Spring Cloud アプリケーション | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Web アプリケーション (WAR) | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Java EE アプリケーション (WAR | EAR) | ✔ | ✔ | ✔ | ✔ | ||
| 商用アプリケーション サーバー (Oracle WebLogic Server や IBM WebSphere など) |
✔ | ✔ | ✔ | |||
| アプリケーション サーバー レベルのクラスタリング | ✔ | ✔ | ✔ | |||
| バッチ/スケジュールされたジョブ | ✔ | ✔ | ✔ | |||
| VNet 統合/ハイブリッド接続 | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Azure リージョンの利用可能性 | 詳細 | 詳細 | 詳細 | 詳細 | 詳細 | 詳細 |
継続的な役割グリッド
次のグリッドを使用して、移行後に各移行先によってチームに課せられる役割を把握してください。
示されるタスクの全体または対部分は、Azure が管理します。 チームは、 で示されるタスクを継続的に担います。 これらすべての役割を果たすために、堅牢で高度に自動化されたプロセスを実装することをお勧めします。
Note
これは、すべての役割を網羅したリストではありません。
| 移行先 → タスク ↓ |
アプリ サービス |
Azure コンテナー アプリ |
AKS | 仮想 マシン |
|---|---|---|---|---|
| ライブラリを更新する (脆弱性の修復を含む) |
👉 | 👉 | 👉 | 👉 |
| アプリケーション サーバーを更新する (脆弱性の修復を含む) |
|
👉 | 👉 | 👉 |
| Java ランタイムを更新する (脆弱性の修復を含む) |
|
👉 | 👉 | 👉 |
| Kubernetes の更新をトリガーする (手動トリガーを使用して Azure によって実行) |
該当なし | |
👉 | 該当なし |
| ディザスター リカバリー | |
👉 | 👉 | |
| 下位互換性のない Kubernetes API の変更を調整する | 該当なし | 👉 | 👉 | 該当なし |
| コンテナーの基本イメージを更新する (脆弱性の修復を含む) |
該当なし | 👉 | 👉 | 該当なし |
| オペレーティング システムを更新する (脆弱性の修復を含む) |
|
|
1 |
👉 |
| 失敗したインスタンスを検出して再起動する | |
|
|
👉 |
| 更新のためのドレインとローリング再起動を実施する | |
|
|
👉 |
| インフラストラクチャ管理 | |
👉 | 👉 | 👉 |
| 監視とアラート管理 | 👉 | 👉 | 👉 | 👉 |
1 一部のセキュリティ更新プログラムでは、ノードの再起動が必要になる場合があり、これは自動的には実行されません。 詳細については、「Azure Kubernetes Service (AKS) の Linux ノードにセキュリティとカーネルの更新を適用します」を参照してください。
アプリケーションの一部としてサーブレット コンテナー (Spring Boot など) をデプロイする場合は、それをライブラリであると考える必要があるため、常にご自身の責任となります。
オンプレミスの接続を確保する
アプリケーションからオンプレミスのサービスのいずれかにアクセスする必要がある場合、Azure の接続サービスの 1 つをプロビジョニングする必要があります。 詳しくは、「オンプレミス ネットワークの Azure への接続」をご覧ください。 または、オンプレミスのリソースで公開されている一般公開の API を使用するように、アプリケーションをリファクタリングする必要があります。
移行を開始する前に、この作業を完了しておく必要があります。
現在の容量とリソースの使用状況をインベントリする
現在の実稼働サーバーのハードウェア、および平均とピーク時の要求数とリソース使用率を文書化します。 この情報は、サービス移行先にリソースをプロビジョニングするために必要になります。
移行ガイダンス
以下のグリッドを使用して、アプリケーションの種類と対象の Azure サービスの移行先ごとの移行ガイダンスを確認してください。
Java アプリケーション
次の行では Java アプリケーションの種類を確認し、列ではアプリケーションをホストする Azure サービス移行先を確認します。
App Service 上の Tomcat に JBoss EAP アプリを移行する場合は、まず、Tomcat 上で実行されている Java Web Apps (サーブレット) に Java EE アプリを変換し、次に示すガイダンスに従ってください。
| 移行先 → アプリケーションの種類 ↓ |
アプリ サービス Java SE |
アプリ サービス Tomcat |
アプリ サービス JBoss EAP |
Azure コンテナー アプリ |
AKS | 仮想 マシン |
|---|---|---|---|---|---|---|
| Spring Boot/ JAR アプリケーション |
該当なし | 該当なし | 該当なし | 該当なし | 該当なし | 該当なし |
| Spring Cloud/ カスタムライン |
該当なし | 該当なし | 該当なし | 該当なし | ガイダンス 予定 |
ガイダンス 予定 |
| Web アプリケーション (Tomcat 上) |
該当なし | ガイダンス | 該当なし | ガイダンス | ガイダンス | ガイダンス 予定 |
Java EE アプリケーション
次の行では、特定のアプリ サーバーで実行されている Java EE アプリケーションの種類を確認します。 列では、アプリケーションをホストする Azure サービス移行先を確認します。
| 移行先 → アプリ サーバー ↓ |
アプリ サービス Java SE |
アプリ サービス Tomcat |
アプリ サービス JBoss EAP |
Azure コンテナー アプリ |
AKS | 仮想 マシン |
|---|---|---|---|---|---|---|
| WildFly/ JBoss AS |
該当なし | 該当なし | ガイダンス | 該当なし | ガイダンス | ガイダンス 予定 |
| Oracle WebLogic Server | 該当なし | 該当なし | ガイダンス | 該当なし | ガイダンス | ガイダンス |
| IBM WebSphere | 該当なし | 該当なし | ガイダンス | 該当なし | ガイダンス | ガイダンス 予定 |
| Red Hat JBoss EAP | 該当なし | 該当なし | ガイダンス | 該当なし | ガイダンス | ガイダンス |