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
310
Javaのレガシーな Web アプリを ECS Fargate を使って段階的に作り直し/マイグレーションする話
2022/3/30 JAWS-UG 名古屋
hmatsu47
PRO
March 30, 2022
Tweet
Share
More Decks by hmatsu47
See All by hmatsu47
RDS/Aurora バージョンアップのポイント
hmatsu47
PRO
8
1.6k
RDS / Aurora 関連アップデート 2022
hmatsu47
PRO
0
110
Supabase で TCE(透過的列暗号化)を試してみた
hmatsu47
PRO
0
110
Aurora MySQL のバージョンアップで Blue/Green デプロイを試してみた
hmatsu47
PRO
0
280
Aurora MySQL 一段飛ばしのバージョンアップとその他もろもろの話
hmatsu47
PRO
1
1.1k
Aurora MySQL v1 → v3 の移行完了報告
hmatsu47
PRO
1
290
Aurora MySQL v1 → v3 移行の経過報告
hmatsu47
PRO
0
750
社内スピードアップコンテスト お焚き上げ編
hmatsu47
PRO
0
170
他人の成長を見守りながら我が道を楽しむ生き方
hmatsu47
PRO
0
230
Other Decks in Technology
See All in Technology
20230121_BuriKaigi
oyakata2438
0
180
SignalR を使ったアプリケーション開発をより快適に!
nenonaninu
0
610
マイクロサービス宣言から8年 振り返りとこれから / Eight Years After the Microservices Declaration A Look Back and A Look Ahead
eisuke
2
150
IoT から見る AWS re:invent 2022 ― AWSのIoTの歴史を添えて/Point of view the AWS re:invent 2022 with IoT - with a history of IoT in AWS
ma2shita
0
250
LINE iOSエンジニアの日々 / LINE iOS Engineer Days
line_developers
PRO
1
150
「一通りできるようになった」その先の話
hitomi___kt
0
120
OCI DevOps 概要 / OCI DevOps overview
oracle4engineer
PRO
0
490
230125 古いタブレットの活用 かーでぃさん
comucal
PRO
0
15k
スクラム導入して変わったチーム、組織のありかた
yumechi
0
180
ユーザーテストガイドライン VERSION 2.0
kouzoukaikaku
0
1.2k
OpenShiftのリリースノートを整理してみた
loftkun
2
320
証明書って何だっけ? 〜AWSの中間CA移行に備える〜
minorun365
3
2.1k
Featured
See All Featured
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
44
14k
Why Our Code Smells
bkeepers
PRO
326
55k
Embracing the Ebb and Flow
colly
75
3.6k
Making Projects Easy
brettharned
102
4.8k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
109
16k
Reflections from 52 weeks, 52 projects
jeffersonlam
338
18k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
227
16k
The Power of CSS Pseudo Elements
geoffreycrofte
52
4.3k
The World Runs on Bad Software
bkeepers
PRO
59
5.7k
Designing for Performance
lara
600
65k
Mobile First: as difficult as doing things right
swwweet
213
7.8k
How GitHub (no longer) Works
holman
298
140k
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