JavaのレガシーなWebアプリをECS Fargateを使って段階的に作り直し／マイグレーションする話

Java のレガシーな Web アプリケーションを ECS Fargate を使って 段階的に作り直し／マイグレーションする話 JAWS-UG 名古屋 JAWS-UG 名古屋 コンテナを語ろう！！ 2022/3/30 まつひさ（hmatsu47）

自己紹介 松久裕保（@hmatsu47） ● https://qiita.com/hmatsu47 ● 現在のステータス： ○ 名古屋で Web インフラのお守り係をしています ○ Aurora MySQL v1 → v3 絶賛移行準備中！ ■ https://zenn.dev/hmatsu47/articles/aurora-mysql3-001-top ほか 2

• https://qiita.com/hmatsu47
• https://zenn.dev/hmatsu47/articles/aurora-mysql3-001-top

本日のネタ タイトルでほぼ説明してしまっていますが、 ● EC2 に同居する複数の Java Web アプリケーションを ● 「えいや」で全部マイグレーションするのではなく、 ● 個々に作り直したり構造を変えたりしながら ● 段階的な移行を進めるのに ECS Fargate を使っている 話です。 3

作り直し／マイグレーション前のアプリケーション ● 全て Java 8 & Apache Tomcat 8.5 のアプリケーション ○ プラットフォームとしての Java / Apache Tomcat は共通 ○ 同じ構成の EC2（複数台）上に同居させて稼働 ■ 以降、「作り直し／マイグレーション」を単に「移行」と表記 ■ 同様に「Apache Tomcat」を「Tomcat」と表記 4

Java のバージョン事情 ● 現在の最新は Java 18（2022/3/22 リリース） ○ Java 9 以降、6 ヶ月サイクルでのリリースに ● LTS 最新は Java 17（2021/9/14 リリース） ○ LTS : 長期サポートバージョン ○ Java 17 までは 3 年サイクルのリリース ■ 今後は 2 年サイクルにしたい、と Oracle が提案（次は Java 21） ○ Java 17 は Java 8 の 2 つ後の LTS（8 → 11 → 17） 5

Java のバージョン事情（LTS のみ） バージョン GA 日 プレミアサポート期限 延長サポート期限 8 2014/03 2022/03 2030/12（仮） 11 2018/09 2023/09 2026/09 17 2021/09 2026/09（仮） 2029/09（仮） 21 2023/09 2028/09 2031/09 出典 : https://www.oracle.com/jp/java/technologies/java-se-support-roadmap.html ※Oracle 以外の OpenJDK ディストリビューター各社のサポート期間は異なる 例 : Amazon Corretto 8 の EoL は 2026/05、Corretto 11 の EoL は 2027/09 6

• https://www.oracle.com/jp/java/technologies/java-se-support-roadmap.html

Java の互換性問題 ● Java の後方互換性は高い ● ただし Java 8 → 9 には以前と比べて大きな壁がある ○ モジュール・システム導入による内部クラスの隠蔽強化など ■ ディープ・リフレクション禁止 ■ Java 9 時点ではまだ設定で回避可能→後のバージョンで完全に廃止 ● Java 8 に止まるシステムが多いのはこれが一因 ○ 実際には Java 9 以降ですんなり動くこともよくある 7

Tomcat と Java EE / Jakarta EE の関係 ● Tomcat : Web（Servlet / JSP など）コンテナ ○ 注 : コンテナといっても Docker などとは別の文脈 ○ 完全準拠ではないが Java EE / Jakarta EE の一部がベース ○ Tomcat 10.0 から Jakarta EE ベースに変わった ● Tomcat 8.5 は Java EE 7 ベース ○ Java EE ベースの最終版は Tomcat 9.0（Java EE 8 ベース） 8

Java EE と Jakarta EE の関係 ● Java EE : Java Platform, Enterprise Edition ○ Servlet / JSP などは Java EE の一部 ● 2017 年に開発が Oracle からコミュニティベースへ ○ Apache Software Foundation に移管、Jakarta EE になった ● 現在の最新は 2021/5 リリースの Jakarta EE 9.1 ○ Jakarta EE 9 は 2020/12 リリース ○ 次期バージョンの Jakarta EE 10 は 2022/5 リリース予定 9

Jakarta EE 時代の Tomcat はどうなる？ ● Tomcat コミッタの藤野圭一さんのブログ記事より ○ https://future-architect.github.io/articles/20210630a/ 10

• https://future-architect.github.io/articles/20210630a/

Jakarta EE 時代の Tomcat はどうなる？ ● Tomcat コミッタの藤野圭一さんのブログ記事より ○ https://future-architect.github.io/articles/20210630a/ EE 9 → 10 のリリース間隔から 考えると 2023Q4 あたり？ 11

• https://future-architect.github.io/articles/20210630a/

Java EE / Jakarta EE と Tomcat の互換性問題 ● Java EE → Jakarta EE では名前空間の変更あり ○ 商標の関係で javax が使えなくなったので jakarta へ ■ ツールはあるが変換作業はそれなりに大変 ● Tomcat 9.0 以前→ 10.0 以降の移行でこれに引っ掛かる ○ 当面は実行時に自動変換する機能が提供される ■ 時限措置なのでいつかは廃止される 12

その他の事情 ● 個々のアプリケーション開発時期はまちまち ○ リアルにレガシーな（ものを増改築した）アプリケーション ○ 使用技術だけがレガシーなアプリケーション ● 対応方針はそれぞれ ○ フレームワークを変えたいアプリケーション ○ 一部を SPA 化したいアプリケーション ○ マイグレーションだけ実施したいアプリケーション 13

まとめると ● 色々な組み合わせの稼働環境が必要になった ○ Java / Tomcat の複数のバージョンが混在 ■ なんなら一部は Java / Tomcat ですらない ● すべて EC2 で同居 or 別居させるのはつらい ○ Java も Tomcat もリリースサイクルが速くなる気配 ■ EoL もすぐにやってくる（Java 8 や Tomcat 9.0 以前が異常に長いだけ） ■ 「手I／手D」には限界→ CI/CD できる環境が必要 ○ コンテナ化が自然な流れ 14

結果として ● EC2 は移行前アプリケーション稼働環境用に残す ○ 移行の進捗にあわせて台数を減らす（最後は廃止） ● 移行後アプリケーション稼働環境に ECS Fargate を用意 ○ アプリケーション別に順次コンテナ化＆移行 ● あわせて CI/CD パイプラインを用意（テスト環境用） ○ https://zenn.dev/hmatsu47/articles/73c624fb5730dd ○ 本番環境へのデプロイにはテスト済みのイメージを使う 15

• https://zenn.dev/hmatsu47/articles/73c624fb5730dd

Before（本番環境のみ） ● すべてのアプリケーション が EC2 上に同居 ● 複数台の同一構成の EC2 で負荷分散 16

After（本番環境） ● 移行対象アプリケーション の稼働環境を ECS Fargate で切り出し ● テスト環境からレプリケー ションした ECR 内にある イメージを使用 ○ ecspresso でデプロイ （図では省略） 17

After（テスト環境） ● モノレポの GHE に Push が発生すると、Webhook から API Gateway 経由で Lambda 関数を呼び出し ● Lambda で対象を判別して CodePipelineを並列呼び出 し 18

テスト環境用の CodePipeline ● GHE リポジトリにデプロイ用ブランチを設置 ○ Push → Lambda で振り分け→対象となる CodePipeline が走る ● Dockerfile・builespec.yml は GHE リポジトリに配置 ○ 一部の Tomcat 設定ファイルは S3 バケットに配置 ● CodeBuild でビルド ○ Maven でテストコード実行＆ビルド、その後イメージビルド ● CodeDeploy で ECS クラスタにデプロイ 19

ECS を選択した理由 ● 書籍を参考にして短期間で完成させたかった ○ AWS コンテナ設計・構築［本格］入門 ○ https://www.sbcr.jp/product/4815607654/ ● EC2 で使っている ALB をシンプルに共用したかった ○ 既存 ALB : Blue / Green デプロイに対応できない状態 ■ ECS でこの ALB を共用 :（Blue / Green デプロイを諦めれば）簡単 ○ LB の多段化などによる構成の複雑化を避けたかった 20

• https://www.sbcr.jp/product/4815607654/

Fargate を選択した理由 ● EC2 の管理台数を増やしたくなかった ○ OS 層の面倒まで見たくない ○ 移行の進捗がどうなるか不透明なのでサイジングも難しい ● 特権コンテナを作り（作らせ）たくなかった 21

出てきた問題 ● Tomcat アプリケーションの起動が遅い ○ デプロイ後にタイムアウト→再デプロイを繰り返す ■ 「タイムアウト設定 5 分」に延ばさないといけないとかつらい ○ メモリを増やして対処 ■ コストが… ○ Auto Scaling の閾値調整が難しい ■ 必ずしも CPU バウンドじゃなさそうだし 22

その他の課題 ● CI/CD パイプラインの課題 ○ 主にアプリケーション構成の関係で処理が冗長な部分がある ■ 処理に時間がかかる ■ ¥ もかかる ○ テストコードがまだ少ない 23

余談：App2Container ● Java / ASP.NET アプリケーションコンテナ化ツール ○ https://aws.amazon.com/jp/app2container/ ○ 移行を試した話 ■ https://dev.classmethod.jp/articles/app2container-for-tomcat/ ○ 割と fat なコンテナが出来上がる模様 ■ 起動時間が心配 24

• https://aws.amazon.com/jp/app2container/
• https://dev.classmethod.jp/articles/app2container-for-tomcat/

最後に ● Java の世界も常に進化しています ○ まだの方、そろそろ Java 8 → 9 の壁を超えましょう ○ Java EE → Jakarta EE の壁も超えましょう ● レガシー環境を放置せず、便利な仕組みを利用しながら マイグレーションを進めましょう 25