技術領域 - AWS 規範ガイダンス
1. セッション状態2. [エージェント]3. アプリケーションサーバー4. ファイルストア5. 構築とデプロイのプロセス6. データベースアクセス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

技術領域

このセクションでは、コンテナ化の主な技術領域の概要を説明します。以下の図は、従来の Java EE アプリケーションのアーキテクチャを示しています。

リファクタリングされた Java EE アプリケーション

以下の図は、コンテナ化された Java EE アプリケーションのアーキテクチャを示しています。

リファクタリングされた Java EE アプリケーション

1. セッション状態

ほとんどの場合、Java EE アプリケーションには、サーブレットや Enterprise Java Beans (EJB) ステートフルセッションの Cookie など、ユーザー要求に関連するセッションデータが保存されています。コンテナはステートレスに保つ必要があるため、状態情報は Java 仮想マシン (JVM) メモリに保存しないことをお勧めします。ディスポーザビリティの原則に関する詳細は、Red Hat ドキュメントの「Principles of container-based application design」を参照してください。Java EE には、2 種類のセッションデータがあります。HTTP セッションデータと EJB セッションデータです。HTTP と EJB のセッションデータは、アプリケーションサーバーで保持することができます。RedHat JBoss の Infinispan や IBM WebSphere Application Server の Data Replication Service など、複数の従来アプリケーションサーバーがメモリレプリケーションをサポートすることで、このセッションデータの可用性を高めています。

メモリレプリケーションのメカニズムは、特定のサーバーセットが常にクラスター内に存在するか、少数のサーバーがクラスターに参加、またはクラスターから離脱することを前提としています。これはコンテナ環境とは互換性がないため、メモリレプリケーションのメカニズムを削除することをお勧めします。コンテナ環境では、コンテナイメージの新しいバージョンが構築されるとアプリケーションサーバーが再デプロイされます。つまり、複製されたメモリデータもすべて消去されます。

2. [エージェント]

通常、次のような自動化タスクやユーティリティタスクを実行する複数のエージェントプロセスが、1 台の物理サーバーまたは仮想サーバー上で実行されています。

  1. 監視 — 従来の Java EE アプリケーション環境では、通常、監視専用のエージェントが使用されます。これらのエージェントは、サーバーの CPU、メモリ、ディスク使用量、JVM 内のメモリ使用量、ログメッセージなどを監視する役割を担います。ただし、コンテナ環境で監視エージェントを直接実行することはできません。監視エージェントは、Amazon CloudWatch や Amazon CloudWatch Logs など、コンテナプラットフォームが提供するモニタリングメカニズムに置き換える必要があります。

  2. ジョブ (スケジュールされたタスク) — 従来の Java EE アプリケーション環境では、ジョブ実行環境はアプリケーションサーバーと同じサーバー上にあることが多く、ユーザー要求とは別に長時間実行されるバッチプロセスを処理します。例えば、ジョブコントローラによって制御されるバッチプロセスは、データベースにアクセスしてデータを取得し、レポートを作成します。このような複数のワークロードはコンテナ環境では共存できないため、ジョブとバッチの実行環境はコンテナ環境とは別に構築する必要があります。

  3. ファイル転送 — ファイル転送エージェントは通常、Java EE アプリケーション環境ではそれほど一般的ではありませんが、外部アプリケーションとの間でファイルを交換する独立したプロセスとして、Java アプリケーションと同じオペレーティングシステム上で実行されることがあります。例えば、他のアプリケーションが使用するデータは毎日ファイルに転送され、データベースに反映されます。ファイル転送エージェントは、コンテナ以外で実行することはできませんが、データベースとファイルにアクセスできる別のサーバー上で実行する必要があります。

3. アプリケーションサーバー

コンテナ化における最も大きな課題は、アプリケーションサーバーの変更です。従来の Java EE 準拠のアプリケーションサーバーは、静的なコンピューティング環境を前提としているため、コンテナ環境での実行には適していない場合があります。つまり、物理サーバーまたは仮想サーバーは Java EE アプリケーションのコンピューティング環境のエンティティとして見なされます。例えば、IBM の WebSphere Application Server traditional (tWAS) や Oracle WebLogic Server など、独自の Java EE アプリケーションサーバーには、独自のアプリケーションデプロイメカニズムがあります。

コンテナ環境の場合は状況が異なります。この環境では、コンテナにはアプリケーションのビルドパッケージ (.war ファイルや.jar ファイルなど) を含むアプリケーションサーバーとランタイムが含まれており、Amazon ECS や Amazon EKS などのコンテナプラットフォームにデプロイされます。アプリケーションを環境にデプロイするには、コンテナプラットフォームメカニズムを使用することをお勧めします。アプリケーションサーバーはコンテナとともにデプロイされることが多いため、サイズが小さく (500 MB 未満)、すぐに起動できるものでなければなりません。この要件を満たすには、従来のアプリケーションサーバーを変更して、よりコンテナに対応したアプリケーションサーバーに移行する必要があります。IBM WebSphere Application Server から IBM WebSphere Liberty、または JBoss Enterprise Application Platform (EAP) から WildFly への移行が必要になる可能性があります。

アプリケーションサーバーの変更には、以下のような影響の可能性があることにご留意ください。

  1. 環境変数による構成インジェクション (web.xml のような構成をファイルに保存する従来の Java EE アプリケーションとは異なります)

  2. Java EE 機能との互換性

  3. JVM バージョン

4. ファイルストア

従来の Java EE アプリケーションで最も一般的に使用されているファイルストアは、ローカルファイルシステムです。最も一般的な使用例は、アプリケーションログファイル、ビジネスレポートなどのアプリケーション生成ファイル、ユーザーがアップロードしたコンテンツなどがあります。コンテナはステートレスであり、コンテナ化するにはファイルストアを外部化する必要があるため、コンテナ内にファイルを保存しないことをお勧めします。

以下のコンテナ化オプションをご検討ください。

  1. Amazon Elastic File System (Amazon EFS) — Amazon EFS は、コンテナからアクセスできるマネージド型 NFS サービスです。Amazon EFS は Amazon ECS および Amazon EKS に統合されています。Amazon EFS を使用する場合は、EFS ボリュームをコンテナにマウントするためのカスタムスクリプトは記述する必要はありません。このオプションでは最初に、読み取りや書き込みに使用されるアプリケーションのすべてのファイルシステムパスを一覧表示します。保持するファイルシステムパスを特定したら、そのファイルシステムパスを EFS ファイルシステムパスにマッピングすることができます。詳細については、Amazon ECS ドキュメントの「Tutorial: Using Amazon EFS file systems with Amazon ECS」を参照してください。すべてのパス (特にアプリケーションログファイル) を保持する必要はありません。ほとんどのエンタープライズアプリケーションは、ログファイルをローカルファイルシステムに書き込みます。コンテナ化プロセスの一環として、標準出力と標準エラーを使用するようにロギング先の変更を検討することをお勧めします。こうすることで、ログストレージのサイズやパフォーマンスを管理しなくても、CloudWatch Logs への出力をすべてキャプチャすることができます。Amazon ECS でのログ記録に関する詳細は、Amazon ECS ドキュメントの「Using the awslogs log driver」を参照してください。

  2. Amazon Simple Storage Service (Amazon S3) — Amazon S3 は Amazon EFS よりも安価で、かつ広い帯域幅に対応していますが、Amazon S3 では Amazon EFS よりも幅広いアプリケーションコードの変更が必要です。これは、Amazon S3 がファイルシステムではないためです。

5. 構築とデプロイのプロセス

コンテナ化プロセスには、アプリケーション配信プロセスの変更と拡張があります。従来の環境では、アプリケーション配信プロセスは主に Java アーティファクト (.war ファイルや .ear ファイルなど) が含まれます。コンテナ環境では、コンテナイメージが配信ユニットです。既存の Java アーティファクトを構築するプロセスに加えて、Docker コンテナの構築と配信プロセスを構築する必要があります。パイプラインプロセスの詳細については、 AWS 「 規範ガイダンス」ドキュメントの「CI/CD パイプラインを使用して Java アプリケーションを自動的にビルドして Amazon EKS にデプロイする」を参照してください。

6. データベースアクセス

従来のアプリケーションのコンテナ化は、多くの場合、データベースの移行が伴います。移行リスクを軽減するために、リレーショナルデータベースの移行戦略 (AWS 規範ガイダンス) に従うことをお勧めします。コンテナ化された環境では、データベース接続文字列を含む外部設定が必要です。Spring Cloud Config (GitHub リポジトリ) などのツールを使用して、分散環境の Java アプリケーション設定を外部化することができます。