Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

2022/3/30 JAWS-UG 名古屋

B1dca90d4b3ffd2ccd918774e1ba170d?s=128

hmatsu47
PRO

March 30, 2022
Tweet

More Decks by hmatsu47

Other Decks in Technology

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