Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
Javaのレガシーな Web アプリを ECS Fargate を使って段階的に作り直し/マイグレーションする話
hmatsu47
PRO
March 30, 2022
Technology
1
230
Javaのレガシーな Web アプリを ECS Fargate を使って段階的に作り直し/マイグレーションする話
2022/3/30 JAWS-UG 名古屋
hmatsu47
PRO
March 30, 2022
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
SolidJS で Supabase の Row Level Security を試してみた
hmatsu47
PRO
0
160
Aurora MySQL v1 → v3 の移行(調査・計画編)
hmatsu47
PRO
0
44
社内でスピードアップコンテスト開催に挑戦した話
hmatsu47
PRO
0
200
Aurora MySQL v1 → v3 の移行を準備する
hmatsu47
PRO
1
580
モノレポのGitHub(Enterprise)からCodePipelineを呼び出す小ネタ
hmatsu47
PRO
0
42
コミュニティとのゆるいつながりの中での恩送り
hmatsu47
PRO
0
31
FlutterでSupabaseのPostgreSQL with PostGISを試してみた
hmatsu47
PRO
0
330
RDS/Aurora関連アップデート(2021年版)
hmatsu47
PRO
0
74
FlutterでMapboxとSupabase(PostGIS)を使ってみた
hmatsu47
PRO
0
490
Other Decks in Technology
See All in Technology
IoTLT88-NTKanazawa-laundry-dry
yukima0707
0
220
GeoLocationAnchor and MKTileOverlay
toyship
0
110
Strategyパターン
hankehly
0
120
アーキテクチャを明文化して開発に臨んだ話
akihiyo76
0
270
セキュリティ 開運研修2022 / security 2022
cybozuinsideout
PRO
3
3.7k
Lessons Learned from Scaling Infrastructure as Code
joatmon08
0
790
Custom AppをIP制限ありのままで審査に通す方法
yusuga
0
670
20220622_FinJAWS_あのときにAWSがあったらこうできた
taketakekaho
0
110
ROS再入門-はじめてのSLAM-
miura55
0
400
JUnit5.7, 5.8の新機能紹介 #jjug_ccc #jjug_ccc_b / junit 5.7, 5.8 new features
kyonmm
PRO
2
420
機械学習システムアーキテクチャ入門 #1
asei
3
1.2k
SI企業が「アジャイル推し」になったら 幸せになれますか?/Can SI company be happy if it becomes “Agile stan” ?
chinmo
1
1.2k
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
85
3.9k
Product Roadmaps are Hard
iamctodd
34
6.5k
Adopting Sorbet at Scale
ufuk
63
7.6k
The Power of CSS Pseudo Elements
geoffreycrofte
47
3.9k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
39
13k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
237
19k
A Tale of Four Properties
chriscoyier
149
21k
Code Review Best Practice
trishagee
43
9.2k
Building an army of robots
kneath
299
40k
The Invisible Customer
myddelton
110
11k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
11
4.7k
Building a Scalable Design System with Sketch
lauravandoore
448
30k
Transcript
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 のみ) 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
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/
11 EE 9 → 10 のリリース間隔から 考えると 2023Q4 あたり?
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