43.1K Views
April 16, 22
スライド概要
2022/3/30 JAWS-UG 名古屋
Qiita や Zenn でいろいろ書いてます。 https://qiita.com/hmatsu47 https://zenn.dev/hmatsu47 MySQL 8.0 の薄い本 : https://github.com/hmatsu47/mysql80_no_usui_hon Aurora MySQL v1 → v3 移行計画 : https://zenn.dev/hmatsu47/books/aurora-mysql3-plan-book
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
本日のネタ タイトルでほぼ説明してしまっていますが、 ● 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
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
Jakarta EE 時代の Tomcat はどうなる? ● Tomcat コミッタの藤野圭一さんのブログ記事より ○ https://future-architect.github.io/articles/20210630a/ EE 9 → 10 のリリース間隔から 考えると 2023Q4 あたり? 11
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
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
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
最後に ● Java の世界も常に進化しています ○ まだの方、そろそろ Java 8 → 9 の壁を超えましょう ○ Java EE → Jakarta EE の壁も超えましょう ● レガシー環境を放置せず、便利な仕組みを利用しながら マイグレーションを進めましょう 25