Amazon で Oracle から WebLogic Apache Tomcat (TomEE ) に移行する ECS

作成者: Anya Epishcheva (AWS) と Harshad Gohil (AWS）

R タイプ：リプラットフォーム	ソース: コンテナ	ターゲット: Amazon での Apache Tomcat (TomEE ) ECS
作成者: AWS	環境：PoC またはパイロット	テクノロジー: コンテナとマイクロサービス、移行
ワークロード: Oracle	AWS サービス: Amazon ECS

[概要]

このパターンでは、Oracle を実行しているオンプレミスの Oracle Solaris SPARCシステムを、Amazon Elastic Container Service (Amazon ) で Apache TomEE (コンテナサポートを追加した Apache Tomcat) を実行している WebLogic Docker コンテナベースのインストールに移行する手順について説明しますECS。

Oracle から WebLogic Tomcat に移行するアプリケーションに関連付けられているデータベースの移行については、このカタログのデータベース移行パターンを参照してください。

ベストプラクティス

Java および Java Enterprise Edition (Java EE) ウェブアプリケーションを移行する手順は、アプリケーションが使用するコンテナ固有のリソースの数によって異なります。Spring ベースのアプリケーションは、デプロイメントコンテナへの依存関係が少ないため、通常は移行が容易です。対照的に、エンタープライズ JavaBeans （EJBs) と、スレッドプール、Java Authentication and Authorization Service (JAAS）、Container-Managed Persistence (CMP) などのマネージドコンテナリソースを使用する Java EE アプリケーションには、より多くの労力が必要です。

Oracle Application Server 向けに開発されたアプリケーションでは、Oracle Identity Management スイートがよく使用されます。オープンソースのアプリケーションサーバーに移行するお客様は、 SAMLベースのフェデレーションを使用してアイデンティティとアクセス管理を再実装することを頻繁に選択します。Oracle Identity Management スイートからの移行がオプションでない場合、Oracle HTTP Server Webgate を使用する人もいます。

Java および Java EE ウェブアプリケーションは、AWSFargate や Amazon などの Docker ベースの AWS サービスへのデプロイに最適ですECS。お客様は、ターゲットアプリケーションサーバー (TomEE など) の最新バージョンと Java Development Kit (JDK) がプリインストールされた Docker イメージを頻繁に選択します。ベース Docker イメージの上にアプリケーションをインストールし、Amazon Elastic Container Registry (Amazon ECR) レジストリに公開し、AWSFargate または Amazon にアプリケーションをスケーラブルにデプロイするために使用しますECS。

アプリケーションのデプロイには伸縮性があること、つまり、トラフィックやワークロードに応じてアプリケーションインスタンスの数をスケールインまたはスケールアウトできるのが理想的です。これは、需要に応じて容量を調整するためには、アプリケーションインスタンスをオンラインにするか終了する必要があることを意味します。

Java アプリケーションをに移動するときはAWS、ステートレスにすることを検討してください。これは、コンテナ化を使用して水平スケーリングを可能にする AWS Well-Architected フレームワークの主要なアーキテクチャ原則です。たとえば、ほとんどの Java ベースのウェブアプリケーションはユーザーセッション情報をローカルに保存します。Amazon Elastic Compute Cloud (Amazon EC2) での自動スケーリングやその他の理由でアプリケーションインスタンスの終了を生き残るには、ウェブアプリケーションユーザーがウェブアプリケーションに再接続したり再ログインしたりすることなくシームレスかつ透過的に作業を継続できるように、ユーザーセッション情報をグローバルに保存する必要があります。このアプローチには、Amazon ElastiCache for Redis やグローバルデータベースへのセッション状態の保存など、いくつかのアーキテクチャオプションがあります。TomEE などのアプリケーションサーバーにはプラグインがあり、Redis、データベース、その他のグローバルデータストアを介してセッションの保存と管理を可能にします。

Amazon および AWS X-Ray と簡単に統合できる、共通の一元化されたログ記録 CloudWatch およびデバッグツールを使用します。移行は、アプリケーションのライフサイクル機能を向上させる機会となります。たとえば、継続的な統合や継続的なデリバリー (CI/CD) パイプラインを使用して変更を簡単に行えるように、ビルドプロセスを自動化したい場合です。そのためには、ダウンタイムなしでデプロイできるようにアプリケーションを変更する必要があるかもしれません。

前提条件と制限

前提条件

アクティブなAWSアカウント
ソース Java コードと JDK
Oracle で構築されたソースアプリケーション WebLogic
ID とアクセス管理用の定義済みソリューション (SAML または Oracle Webgate)
アプリケーションセッション管理用の定義済みソリューション (Amazon でまたはを移動 like-for-likeするか ElastiCache、必要に応じてアプリケーションをステートレスにする）
チームが Apache TomEE に移植できるように J2EE 固有のライブラリをリファクタリングする必要があるかどうかの理解 (Apache ウェブサイトの「Java EE 7 実装状況」を参照)
セキュリティ要件に基づいて強化された TomEE イメージ
ターゲット TomEE がプリインストールされたコンテナイメージ
アプリケーションの修正 (ログ、デバッグビルド、認証など) が合意され、必要に応じて実施されている

製品バージョン

Oracle WebLogic OC4J、9i、10g
Tomcat 7 (Java 1.6 以降を搭載)

アーキテクチャ

ソーステクノロジースタック

Oracle を使用して構築されたウェブアプリケーション WebLogic
Oracle Webgate またはSAML認証を使用するウェブアプリケーション
Oracle Database バージョン 10g 以降に接続されているウェブアプリケーション

ターゲットテクノロジースタック

Amazon で実行されている TomEE (コンテナサポートを追加した Apache Tomcat) ECS (Amazon での ECS Java ウェブアプリケーションと Java マイクロサービスのデプロイも参照）
Amazon Relational Database Service (Amazon RDS) for Oracle。Amazon でサポートされている Oracle バージョンについてはRDS、「Amazon RDS for Oracle 」を参照してください。

ターゲットアーキテクチャ

AWS クラウド architecture diagram showing VPC, application subnets, and shared services integration.

ツール

TomEE で動作させるには、Java アプリケーションを .war ファイルに再構築する必要があります。TomEE 上でアプリケーションを操作するためにアプリケーションの変更が必要な場合があります。必要な構成オプションと環境プロパティが正しく定義されていることを確認してください。

また、Java 命名およびディレクトリインターフェイス (JNDI) ルックアップと JavaServer ページ (JSP) 名前空間を正しく定義する必要があります。組み込み T ライブラリとの命名衝突を避けるため、アプリケーションで使用されるファイル名を確認することを検討してください。例えば、 persistence.xml は、設定目的で Apache OpenJPA フレームワーク (TomEE の OpenEJB にバンドルされています) で使用されるファイル名です。の persistence.xml ファイルPUIには、Spring framework bean 宣言が含まれています。

TomEE バージョン 7.0.3 以降 (Tomcat 8.5.7 以降) は、特殊文字URLsを含む raw (エンコードされていない) の HTTP 400 レスポンス (不正なリクエスト) を返します。サーバーからの応答は、エンドユーザーには空白ページとして表示されます。TomEE および Tomcat の以前のバージョンでは、でエンコードされていない特定の特殊文字の使用が許可されましたURLsが、CVE-2016-6816 ウェブサイトに記載されているように、安全ではないと見なされます。URL エンコードの問題を解決するには、を介してブラウザに直接URLs渡されたを、raw 文字列としてではなく、エンコード URI() メソッドでエンコード JavaScript する必要があります。

.war ファイルを TomEE にデプロイした後、Linux cat の起動ログをモニタリングして、見つからない共有ライブラリや Oracle 固有の拡張機能がないかを確認し、Tomcat ライブラリから不足しているコンポーネントを追加してください。

一般的な手順

TomEE 上でアプリケーションを構成します。
アプリケーションサーバー固有の構成ファイルとリソースを特定し、ソースからターゲット形式まで再構成します。
JNDI リソースを特定して再設定します。
EJB 名前空間とルックアップを、ターゲットアプリケーションサーバーに必要な形式 (該当する場合) に調整します。
JAAS アプリケーションコンテナ固有のセキュリティロールとプリンシパルマッピング (該当する場合) を再設定します。
アプリケーションと共有ライブラリを.war ファイルにパッケージ化します。
指定の Docker コンテナを使用して、.war ファイルを TomEE にデプロイします。
開始ログをモニタリングして、見つからない共有ライブラリとデプロイメント記述子の拡張子がないか確認します。見つかった場合は、最初のタスクに戻ってください。
復元された Amazon RDS データベースに対して、インストールされたアプリケーションをテストします。
「Deploy Docker Containers 」の手順に従って、ロードバランサーと Amazon ECSクラスターで完全なアーキテクチャを起動します。
ロードバランサーを指すURLsようにを更新します。
設定管理データベース () を更新しますCMDB。

エピック

タスク	説明	必要なスキル
アプリケーションの検出 (現在の状態フットプリントとパフォーマンスベースライン) を行います。		BA、移行リーダー
ソースとターゲットのデータベースのバージョンとエンジンを検証します。		DBA
ソースとターゲットのアプリケーション設計 (ID とセッション管理) を検証します。		DBA、移行エンジニア、アプリケーション所有者
ターゲットサーバーインスタンスのハードウェア要件とストレージ要件を特定します。		DBA, SysAdmin
容量、ストレージ機能、ネットワーク機能に基づき、適切なインスタンスタイプを選択します。		DBA, SysAdmin
ソースとターゲットデータベースのネットワークアクセスセキュリティ要件を特定します。		DBA, SysAdmin
アプリケーション移行戦略とツールを特定します。		DBA、移行リード
アプリケーションの移行設計と移行ガイドを完成させます。		ビルドリード、移行リード
アプリケーション移行ランブックを完成させます。		ビルドリード、カットオーバーリード、テストリード、移行リード

タスク	説明	必要なスキル
仮想プライベートクラウド () を作成しますVPC。		SysAdmin
セキュリティグループを作成します。		SysAdmin
Amazon RDS DB インスタンスを設定して起動します。		DBA, SysAdmin
Amazon ECSデプロイを設定します。		SysAdmin
アプリケーションを Docker イメージとしてパッケージ化します。		SysAdmin
イメージを Amazon ECRレジストリにプッシュする (またはこのステップをスキップして Amazon ECSクラスターにプッシュする）。		SysAdmin
アプリケーションと Amazon ECSサービスオプションのタスク定義を設定します。		SysAdmin
クラスターを設定し、セキュリティ設定を確認し、AWSアイデンティティとアクセス管理 (IAM) ロールを設定します。		SysAdmin
セットアップを起動し、アプリケーション移行ランブックに従ってテストを実行します。		SysAdmin

タスク	説明	必要なスキル
セキュリティ保証チームのアクセス許可を取得して、本番データをに移動しますAWS。		DBA、移行エンジニア、アプリケーション所有者
エンドポイントを作成してアクセスし、データベースのバックアップファイルを取得します。		DBA
ネイティブデータベースエンジンまたはサードパーティツールを使用して、データベースオブジェクトとデータを移行します。		DBA
アプリケーション移行ランブックから必要なテストを実行して、データ移行が成功したことを確認します。		DBA、移行エンジニア、アプリケーション所有者

タスク	説明	必要なスキル
移行用の変更リクエスト (CR) を作成します。		カットオーバーリード
移行のためのCR 承認を得ます。		カットオーバーリード
アプリケーション移行ランブックに記載されているアプリケーション移行戦略に従います。		DBA、移行エンジニア、アプリケーション所有者
アプリケーションをアップグレードします (必要な場合)。		DBA、移行エンジニア、アプリケーション所有者
機能、非機能、データ検証、SLA、およびパフォーマンステストを完了します。		テストリード、アプリオーナー、アプリユーザー

タスク	説明	必要なスキル
アプリ所有者またはビジネスオーナーから承認を得ます。		カットオーバーリード
テーブルトピックの演習を実施して、カットオーバーランブックのすべてのステップを順を追って説明します。		DBA、移行エンジニア、アプリケーション所有者
アプリケーションクライアントを新しいインフラストラクチャに切り替えます。		DBA、移行エンジニア、アプリケーション所有者

タスク	説明	必要なスキル
一時AWSリソースをシャットダウンします。		DBA、移行エンジニア、 SysAdmin
プロジェクト文書を確認して検証する。		移行リード
移行の所要時間、手動とツールの比率、コスト削減などのメトリクスを収集します。		移行リード
プロジェクトを終了し、フィードバックを提供します。		移行リーダー、アプリ所有者