

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

# Amazon ECS で Oracle WebLogic から Apache Tomcat (ToMee) に移行する
<a name="migrate-from-oracle-weblogic-to-apache-tomcat-tomee-on-amazon-ecs"></a>

*Amazon Web Services、Anya Epishcheva and Harshad Gohil*

## 概要
<a name="migrate-from-oracle-weblogic-to-apache-tomcat-tomee-on-amazon-ecs-summary"></a>

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

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

**ベストプラクティス**

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

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

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

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

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

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

## 前提条件と制限事項
<a name="migrate-from-oracle-weblogic-to-apache-tomcat-tomee-on-amazon-ecs-prerequisites-and-limitations"></a>

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

**製品バージョン**
+ Oracle WebLogic OC4J、9i、10g 
+ Tomcat 7 (Java 1.6 以降を搭載) 

## アーキテクチャ
<a name="migrate-from-oracle-weblogic-to-apache-tomcat-tomee-on-amazon-ecs-architecture"></a>

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

**ターゲットテクノロジースタック**
+ Amazon ECS 上で実行されている TomEE (コンテナサポートが追加された Apache Tomcat) (「[Deploying Java Web Applications](https://aws.amazon.com/answers/web-applications/aws-web-app-deployment-java/)」および 「[Java Microservices on Amazon ECS](https://aws.amazon.com/blogs/compute/deploying-java-microservices-on-amazon-ec2-container-service/)」も参照してください) 
+ Oracle 用の Amazon Relational Database Service (Amazon RDS)。Amazon RDS でサポートされている Oracle バージョンについては、[Amazon RDS for Oracle](https://aws.amazon.com/rds/oracle/) を参照してください****

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

![](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/patterns/images/pattern-img/d5e7b3fa-062f-4559-af56-aa6058f96755/images/762193cf-aa68-4195-b3c7-6541caee61c9.png)


 

## ツール
<a name="migrate-from-oracle-weblogic-to-apache-tomcat-tomee-on-amazon-ecs-tools"></a>

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

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

TomEE バージョン 7.0.3 以降 (Tomcat 8.5.7 以降) は、特殊文字を含む未加工の (エンコードされていない) URL に対して HTTP 400 レスポンス (不正リクエスト) を返します。サーバーからの応答は、エンドユーザーには空白ページとして表示されます。旧バージョンの TomEE と Tomcat では、URL にエンコードされていない一部の特殊文字を使用できました。ただし、[CVE-2016-6816 ウェブサイト](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6816)に記載されているように、安全ではないと見なされています。URL エンコーディングの問題を解決するには、JavaScript を介してブラウザに直接渡される URL を、未加工の文字列として使用するのではなく **encodeURI()** メソッドでエンコードする必要があります。

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

 

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

## エピック
<a name="migrate-from-oracle-weblogic-to-apache-tomcat-tomee-on-amazon-ecs-epics"></a>

### 移行を計画する
<a name="plan-the-migration"></a>


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

### インフラストラクチャを設定する
<a name="configure-the-infrastructure"></a>


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

### データを移行する
<a name="migrate-data"></a>


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

### アプリケーションを移行する
<a name="migrate-the-application"></a>


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

### カットオーバー
<a name="cut-over"></a>


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

### プロジェクトを閉じる
<a name="close-the-project"></a>


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

## 関連リソース
<a name="migrate-from-oracle-weblogic-to-apache-tomcat-tomee-on-amazon-ecs-related-resources"></a>

**リファレンス**
+ [Apache Tomcat 7.0 ドキュメント](https://tomcat.apache.org/tomcat-7.0-doc/realm-howto.html) 
+ [Apache Tomcat 7.0 インストールガイド](https://tomcat.apache.org/tomcat-7.0-doc/appdev/installation.html) 
+ [Apache Tomcat JNDI ドキュメント](https://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html) 
+ [Apache TomE ドキュメント](http://tomee.apache.org/) 
+ 「[Amazon RDS for Oracle](https://aws.amazon.com/rds/oracle/)」 
+ [Amazon RDS の価格設定](https://aws.amazon.com/rds/pricing/) 
+ [Oracleと ](https://aws.amazon.com/oracle/) 
+ [Amazon RDS に関するOracleのドキュメンテト](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Oracle.html) 
+ [Amazon RDS マルチ AZ 配置](https://aws.amazon.com/rds/details/multi-az/) 
+ [Amazon ECS の開始](https://aws.amazon.com/ecs/getting-started/)
+ [Amazon RDS の開始方法](https://aws.amazon.com/rds/getting-started/) 

**チュートリアルと動画**
+ [Best Practices for Running Oracle Databases on Amazon RDS](https://www.youtube.com/watch?v=j2wqT0EPDbw) (re:Invent 2018 presentation) 