移行アプローチ

このセクションでは、 AWS クラウドで従来の Java EE アプリケーションをコンテナ化するためのアプローチについて説明します。より一般的な移行ガイドラインについては、 AWS 「 規範ガイダンス」ドキュメントの「組織を動員して大規模な移行を加速する」を参照してください。

検出と計画のプロセスを開始する

Java EE アプリケーションの移行には、詳細なアプリケーションの検出が必要です。検出と計画プロセスの一環として、Java EE アプリケーションで次の項目を確認することをお勧めします。

• CPU の数

• メモリ要件とディスク要件

• Java EE、Java 開発キット (JDK)、およびアプリケーションサーバーのバージョン (Oracle WebLogic Server 10 など)

高い可用性とスケーラビリティを実現するクラスタリングオプションを理解する

より多くの従来の Java EE アプリケーションが、アプリケーションの可用性とスケーラビリティを向上させるベンダー固有のクラスタリングシステム上で実行されています。コンテナ化されたアプローチでは、Amazon ECS や Amazon EKS などのコンテナオーケストレーションプラットフォームによって、クラスタリングが実行されます。コンテナオーケストレーションプラットフォームによって実行されるクラスタリングと、現在のアプリケーションプラットフォームで実行されるクラスタリングの違いを理解しておくことをお勧めします。

ベンダー固有のパッケージにおける互換性を評価する

アプリケーションサーバーのベンダーは、独自の Java EE パッケージを提供することができます。コンテナ化された環境との互換性を確保するために、お客様のアプリケーションがアプリケーションサーバーのベンダーが提供する Java EE パッケージを使用しているかどうかを確認してください。

ターゲットコンテナプラットフォームを選択する

ビジネスニーズに基づいて、Java EE に適したコンテナプラットフォームを選択します。一般的には、Docker Hub (GlassFish サーバーや WildFly、Open Liberty など) で配布されている、コンテナに対応したオープンソース (場合によっては軽量) の Java EE プラットフォームが好まれます。本番稼働レベルのテクニカルサポートとライセンスを提供する、コンテナプラットフォームを検討することをお勧めします。

自動化テストに備える

Java EE アプリケーションを新しいアプリケーションサーバーに移行するには、ビジネスロジック以外のコードまたは設定の変更が必要になります。現在のアプリケーションのテストおよび構築プロセスが自動化されていなければ、コードや設定の変更が既存のビジネスロジックを損なわないことを検証することはできません。プロジェクトの最初のフェーズで、構築とテストのパイプラインを自動化することをお勧めします。これには、手動のテストプロセスや管理されていないアプリケーションのビルド設定 (Apache Ant の build.xml など) を Maven (Apache Maven ドキュメント) や Gradle (Gradle ドキュメント) などのメインストリームビルドツールを使って最新化することが含まれます。詳細については、 AWS 「 規範ガイダンス」ドキュメントの「CI/CD パイプラインを使用して Java アプリケーションを自動的に構築して Amazon EKS にデプロイする」を参照してください。