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

2022/3/30 JAWS-UG 名古屋

Transcript

1. Java のレガシーな Web アプリケーションを ECS Fargate を使って 段階的に作り直し／マイグレーションする話 JAWS-UG 名古屋 JAWS-UG 名古屋 コンテナを語ろう！！ 2022/3/30 まつひさ（hmatsu47）
2. 自己紹介 松久裕保（@hmatsu47） • https://qiita.com/hmatsu47 • 現在のステータス： ◦ 名古屋で Web インフラのお守り係をしています ◦ Aurora MySQL v1 → v3 絶賛移行準備中！ ▪ https://zenn.dev/hmatsu47/articles/aurora-mysql3-001-top ほか 2
3. 本日のネタ タイトルでほぼ説明してしまっていますが、 • EC2 に同居する複数の Java Web アプリケーションを • 「えいや」で全部マイグレーションするのではなく、 • 個々に作り直したり構造を変えたりしながら • 段階的な移行を進めるのに ECS Fargate を使っている 話です。 3
4. 作り直し／マイグレーション前のアプリケーション • 全て Java 8 & Apache Tomcat 8.5 のアプリケーション ◦ プラットフォームとしての Java / Apache Tomcat は共通 ◦ 同じ構成の EC2（複数台）上に同居させて稼働 ▪ 以降、「作り直し／マイグレーション」を単に「移行」と表記 ▪ 同様に「Apache Tomcat」を「Tomcat」と表記 4
5. 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
6. Java のバージョン事情（LTS のみ） 6 出典 : 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 バージョン 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
7. Java の互換性問題 • Java の後方互換性は高い • ただし Java 8 → 9 には以前と比べて大きな壁がある ◦ モジュール・システム導入による内部クラスの隠蔽強化など ▪ ディープ・リフレクション禁止 ▪ Java 9 時点ではまだ設定で回避可能→後のバージョンで完全に廃止 • Java 8 に止まるシステムが多いのはこれが一因 ◦ 実際には Java 9 以降ですんなり動くこともよくある 7
8. 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
9. 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
10. Jakarta EE 時代の Tomcat はどうなる？ • Tomcat コミッタの藤野圭一さんのブログ記事より ◦ https://future-architect.github.io/articles/20210630a/ 10
11. Jakarta EE 時代の Tomcat はどうなる？ • Tomcat コミッタの藤野圭一さんのブログ記事より ◦ https://future-architect.github.io/articles/20210630a/ 11 EE 9 → 10 のリリース間隔から 考えると 2023Q4 あたり？
12. Java EE / Jakarta EE と Tomcat の互換性問題 • Java EE → Jakarta EE では名前空間の変更あり ◦ 商標の関係で javax が使えなくなったので jakarta へ ▪ ツールはあるが変換作業はそれなりに大変 • Tomcat 9.0 以前→ 10.0 以降の移行でこれに引っ掛かる ◦ 当面は実行時に自動変換する機能が提供される ▪ 時限措置なのでいつかは廃止される 12
13. その他の事情 • 個々のアプリケーション開発時期はまちまち ◦ リアルにレガシーな（ものを増改築した）アプリケーション ◦ 使用技術だけがレガシーなアプリケーション • 対応方針はそれぞれ ◦ フレームワークを変えたいアプリケーション ◦ 一部を SPA 化したいアプリケーション ◦ マイグレーションだけ実施したいアプリケーション 13
14. まとめると • 色々な組み合わせの稼働環境が必要になった ◦ Java / Tomcat の複数のバージョンが混在 ▪ なんなら一部は Java / Tomcat ですらない • すべて EC2 で同居 or 別居させるのはつらい ◦ Java も Tomcat もリリースサイクルが速くなる気配 ▪ EoL もすぐにやってくる（Java 8 や Tomcat 9.0 以前が異常に長いだけ） ▪ 「手I／手D」には限界→ CI/CD できる環境が必要 ◦ コンテナ化が自然な流れ 14
15. 結果として • EC2 は移行前アプリケーション稼働環境用に残す ◦ 移行の進捗にあわせて台数を減らす（最後は廃止） • 移行後アプリケーション稼働環境に ECS Fargate を用意 ◦ アプリケーション別に順次コンテナ化＆移行 • あわせて CI/CD パイプラインを用意（テスト環境用） ◦ https://zenn.dev/hmatsu47/articles/73c624fb5730dd ◦ 本番環境へのデプロイにはテスト済みのイメージを使う 15
16. Before（本番環境のみ） • すべてのアプリケーション が EC2 上に同居 • 複数台の同一構成の EC2 で負荷分散 16
17. After（本番環境） • 移行対象アプリケーション の稼働環境を ECS Fargate で切り出し • テスト環境からレプリケー ションした ECR 内にある イメージを使用 ◦ ecspresso でデプロイ （図では省略） 17
18. After（テスト環境） • モノレポの GHE に Push が発生すると、Webhook から API Gateway 経由で Lambda 関数を呼び出し • Lambda で対象を判別して CodePipelineを並列呼び出 し 18
19. テスト環境用の CodePipeline • GHE リポジトリにデプロイ用ブランチを設置 ◦ Push → Lambda で振り分け→対象となる CodePipeline が走る • Dockerfile・builespec.yml は GHE リポジトリに配置 ◦ 一部の Tomcat 設定ファイルは S3 バケットに配置 • CodeBuild でビルド ◦ Maven でテストコード実行＆ビルド、その後イメージビルド • CodeDeploy で ECS クラスタにデプロイ 19
20. ECS を選択した理由 • 書籍を参考にして短期間で完成させたかった ◦ AWS コンテナ設計・構築［本格］入門 ◦ https://www.sbcr.jp/product/4815607654/ • EC2 で使っている ALB をシンプルに共用したかった ◦ 既存 ALB : Blue / Green デプロイに対応できない状態 ▪ ECS でこの ALB を共用 :（Blue / Green デプロイを諦めれば）簡単 ◦ LB の多段化などによる構成の複雑化を避けたかった 20
21. Fargate を選択した理由 • EC2 の管理台数を増やしたくなかった ◦ OS 層の面倒まで見たくない ◦ 移行の進捗がどうなるか不透明なのでサイジングも難しい • 特権コンテナを作り（作らせ）たくなかった 21
22. 出てきた問題 • Tomcat アプリケーションの起動が遅い ◦ デプロイ後にタイムアウト→再デプロイを繰り返す ▪ 「タイムアウト設定 5 分」に延ばさないといけないとかつらい ◦ メモリを増やして対処 ▪ コストが… ◦ Auto Scaling の閾値調整が難しい ▪ 必ずしも CPU バウンドじゃなさそうだし 22
23. その他の課題 • CI/CD パイプラインの課題 ◦ 主にアプリケーション構成の関係で処理が冗長な部分がある ▪ 処理に時間がかかる ▪ ¥ もかかる ◦ テストコードがまだ少ない 23
24. 余談：App2Container • Java / ASP.NET アプリケーションコンテナ化ツール ◦ https://aws.amazon.com/jp/app2container/ ◦ 移行を試した話 ▪ https://dev.classmethod.jp/articles/app2container-for-tomcat/ ◦ 割と fat なコンテナが出来上がる模様 ▪ 起動時間が心配 24
25. 最後に • Java の世界も常に進化しています ◦ まだの方、そろそろ Java 8 → 9 の壁を超えましょう ◦ Java EE → Jakarta EE の壁も超えましょう • レガシー環境を放置せず、便利な仕組みを利用しながら マイグレーションを進めましょう 25