レガシーフロントエンドからNext.jsへの段階移行を可能にするAWS構成

サービスの歴史が長い場合、既存のフロントエンドを一気にモダナイズ化することは現実的ではなく、一部の画面から徐々に移行していくアプローチが考えられます。
本セッションではMPA(Multi Page Application)で構築されたレガシーフロントエンドからNext.jsへの段階的な移行を可能にするためのAWSアーキテクチャについてご紹介します。

Transcript

1. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. レガシーフロントエンドからNext.jsへの 段階移行を可能にするAWS構成 水馬 拓也 (Mizuma Takuya) T R A C K A - 1 ウェルスナビ 株式会社 ソフトウェアエンジニア
2. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 水馬 拓也 (みずま たくや) ウェルスナビ株式会社 Software Engineer --- Ø 前職: アマゾンウェブサービスジャパン合同会社, Prototyping Solutions Architect Ø ウェルスナビ株式会社 Software Engineer 全自動資産運用サービス の開発に従事 ウェルスナビ開発者Blog 運営 : https://tech.wealthnavi.com/ Ø 好きなAWSサービス： AWS Amplify / Serverless 技術 Ø A student at University Of London / BSc Computer Science Twitter: @mizuma_t
3. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 免責事項 本セッションではウェルスナビ開発組織の取り組みから何かしらのヒントを得ていた だくことを目的としています。 全てのアーキテクチャで汎用的に適用できるベストプラクティスをお伝えするもので はありません。 掲載するアーキテクチャ図は、本資料の趣旨から逸脱しない範囲で抽象化、または実 際の構成とは異なる場合があります。 記載している情報は2022年11月時点の情報です。万が一AWS公式ドキュメントとの 内容に差異がある場合はAWS公式ドキュメントを正としてください。 ▪ AWS公式Webサイト https://aws.amazon.com
4. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 本セッションについて 想定聴講者： ・フロントエンド、AWSテクノロジーの両方に興味のある方 ・レガシーなフロントエンドの移行方針に悩まれている方 ゴール： ・難易度の高いレガシーフロントエンドの段階移行方法について何かし らのヒントを得ていただく
5. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Agenda • 代表的なフロントエンド構成のおさらい • フロントエンド移行の何が難しいのか？ • AWSのアーキテクチャでどのように課題を解決したのか？
6. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Agenda • 代表的なフロントエンド構成のおさらい • フロントエンド移行の何が難しいのか？ • AWSのアーキテクチャでどのように課題を解決したのか？
7. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Web/Mobile Multiple Page Application (MPA) Webサーバ リクエスト HTML
8. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Web/Mobile .js .html .css / Single Page Application (SPA)
9. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Web/Mobile / HTMLを作成 Server Side Rendering (SSR)
10. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. その他 • SSG (Static Site Generation) • ISR (Incremental Static Regeneration) • Streaming SSR
11. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. MPA構成でよくあがる課題 (≒ SPA/SSR移行のモチベーション) • サービスの成長に伴い、Viewと業務ロジックが密結合になりやすい • フロントエンドチームとバックエンドチームで並行開発が難しい • APIサーバとWebサーバで同じ業務ロジックを実装する必要がある これらの課題が MPA のメリットを上回り、開発の生産性を落として しまっている状態をこの資料では「レガシーフロントエンド」と定義 している。 ( MPAが必ずしも悪いわけではない！)
12. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Agenda • 代表的なフロントエンド構成のおさらい • フロントエンド移行の何が難しいのか？ • AWSのアーキテクチャでどのように課題を解決したのか？
13. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. フロントエンド移行の何が難しいのか？ (以下、MPA から SPAの移行に絞って議論) 【案1. ビッグバン移行】 User Application Load Balancer Amazon CloudFront Amazon S3 大量のエンジニアを投入し既存の アプリをSPAで作り直す Coming Soon…!! Step1. Developers MPA SPA app.example.com
14. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. フロントエンド移行の何が難しいのか？ (以下、MPA から SPAの移行に絞って議論) 【案1. ビッグバン移行】 User Application Load Balancer Amazon CloudFront Amazon S3 MPA SPA 大量のエンジニアを投入し既存の アプリをSPAで作り直す Developers New Release!! Step1. 完成したアプリにDNSを切り替える Step2. MPA SPA app.example.com
15. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. フロントエンド移行の何が難しいのか？ (以下、MPA から SPAの移行に絞って議論) 【案1. ビッグバン移行】 User Application Load Balancer Amazon CloudFront Amazon S3 MPA SPA 大量のエンジニアを投入し既存の アプリをSPAで作り直す Developers Mission Complete! Step1. 完成したアプリにDNSを切り替える Step2. 旧アプリを閉じる Step3. MPA SPA app.example.com
16. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. app.example.com フロントエンド移行の何が難しいのか？ (以下、MPA から SPAの移行に絞って議論) 【案1. ビッグバン移行】 User Application Load Balancer Amazon CloudFront Amazon S3 MPA SPA 大量のエンジニアを投入し既存の アプリをSPAで作り直す Developers Mission Complete! Step1. 完成したアプリにDNSを切り替える Step2. 旧アプリを閉じる Step3. MPA SPA 【この案の問題点】 ü SPA で作り直している間、新規機能開発を止めることになる (場合によっては年単位で) ü リリース時のリスク大 ü 撤退コスト大 (= それまでに実装したコスト + 既存の新規機能開発を止めた機会損失)
17. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. フロントエンド移行の何が難しいのか？ (以下、MPA から SPAの移行に絞って議論) 【案2. MPAからSPAを共存させながら段階的に移行する】 User Application Load Balancer Amazon CloudFront Amazon S3 modern.example.com legacy.example.com ・商品一覧 (/item/list) ・商品詳細 (/item/${id}) ・ユーザ一覧 (/user/list) ・ユーザ情報 (/user/${id}) 段階的に移行
18. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. フロントエンド移行の何が難しいのか？ (以下、MPA から SPAの移行に絞って議論) 【案2. MPAからSPAを共存させながら段階的に移行する】 User Application Load Balancer Amazon CloudFront Amazon S3 Ø 商品関連ページを閲覧するとき modern.example.com legacy.example.com ・商品一覧 (/item/list) ・商品詳細 (/item/${id}) ・ユーザ一覧 (/user/list) ・ユーザ情報 (/user/${id}) /item/list /item/123 legacy.example.com 段階的に移行
19. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. フロントエンド移行の何が難しいのか？ (以下、MPA から SPAの移行に絞って議論) 【案2. MPAからSPAを共存させながら段階的に移行する】 User Application Load Balancer Amazon CloudFront Amazon S3 Ø 商品関連ページを閲覧するとき modern.example.com legacy.example.com ・商品一覧 (/item/list) ・商品詳細 (/item/${id}) ・ユーザ一覧 (/user/list) ・ユーザ情報 (/user/${id}) /user/list /user/123 /item/list /item/123 legacy.example.com Ø ユーザ関連ページを閲覧する時 modern.example.com 段階的に移行
20. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. フロントエンド移行の何が難しいのか？ (以下、MPA から SPAの移行に絞って議論) 【案2. MPAからSPAを共存させながら段階的に移行する】 User Application Load Balancer Amazon CloudFront Amazon S3 Ø 商品関連ページを閲覧するとき modern.example.com legacy.example.com ・商品一覧 (/item/list) ・商品詳細 (/item/${id}) ・ユーザ一覧 (/user/list) ・ユーザ情報 (/user/${id}) /user/list /user/123 /item/list /item/123 legacy.example.com Ø ユーザ関連ページを閲覧する時 modern.example.com 移行完了！ Ø 旧アプリを閉じる
21. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. フロントエンド移行の何が難しいのか？ (以下、MPA から SPAの移行に絞って議論) 【案2. MPAからSPAを共存させながら段階的に移行する】 User Application Load Balancer Amazon CloudFront Amazon S3 Ø 商品関連ページを閲覧するとき modern.example.com legacy.example.com ・商品一覧 (/item/list) ・商品詳細 (/item/${id}) ・ユーザ一覧 (/user/list) ・ユーザ情報 (/user/${id}) /user/list /user/123 /item/list /item/123 legacy.example.com Ø ユーザ関連ページを閲覧する時 modern.example.com 移行完了！ Ø 旧アプリを閉じる 【この案の問題点】 ü ページ単位でSPAとMPAを切り替えるためクライアントのオーバーヘッドが大きい ü ドメインが異なるためCookieで保持しているセッション情報を共有できない → サブドメイン間でCookieを共有させることもできるがセキュリティレベルが落ちる ü 一般的にMPAとSPAでは認証方式が異なる. → MPA: Cookieにセッションの保持が一般的 → SPA: ステートレスなJWT (Json Web Token) を用いた認証が一般的
22. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめると・・ • そもそものアーキテクチャが異なるため段階的な移行が難しい Ø 初回リクエスト時にアプリケーション全体を取得する SPA と、ページごとにHTMLをリクエス トする MPA は基本的に共存できない。1ページずつ徐々にSPAの画面に置き換えていくといった アプローチが取れない • 認証の仕組みが異なる Ø Cookie にセッション情報を保持するのが一般的な MPA とは異なりSPAではステートレスな jwt (Json Web Token) を用いるのが一般的 Ø そもそもドメインが異なるのでCookieの中身が共有できない • ビッグバン移行はサービスの歴史が長ければ長いほど現実的ではない
23. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Agenda • そもそも「レガシーフロントエンド」とは何なのか？ • フロントエンド移行の何が難しいのか？ • AWSのアーキテクチャでどのように課題を解決したのか？
24. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Agenda • そもそも「レガシーフロントエンド」とは何なのか？ • フロントエンド移行の何が難しいのか？ • AWSのアーキテクチャでどのように課題を解決したのか？ ウェルスナビでは Disclaim er
25. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 移行前のウェルスナビの構成 (抽象化しています) User Application Load Balancer Amazon Elastic Container Service Java / SpringBoot / Thymeleaf Amazon CloudFront MPA Amazon S3
26. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行中のアーキテクチャ User Application Load Balancer Amazon ECS Amazon CloudFront Amazon CloudFront Amazon S3 Lambda@Edge AWS WAF xxx.wealthnavi.com レガシーフロントエンド 移行後のフロントエンド ページ単位で段階移行 レガシーなページへのリクエスト 移行後のページへのリクエスト Next.js (Server Side Rendering)
27. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行中のアーキテクチャ User Application Load Balancer Amazon ECS Amazon CloudFront Amazon CloudFront Amazon S3 Lambda@Edge AWS WAF Next.js (Server Side Rendering) xxx.wealthnavi.com レガシーフロントエンド 移行後のフロントエンド ページ単位で段階移行 レガシーなページへのリクエスト 移行後のページへのリクエスト ここから解説
28. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行を可能にする技術選定 Amazon CloudFront Ø パスごとにレガシーフロントエンドとNext.jsのリクエストを振り分ける レガシーフロントへのリクエスト(MPA) 新フロントエンドのリクエスト(Next.js) CloudFront のbehaviorにルーティング 設定を追加
29. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行を可能にする技術選定 Amazon CloudFront Ø パスごとにレガシーフロントエンドとNext.jsのリクエストを振り分ける Next.js が使用するパスは リクエスト先 のOriginにNext.jsが稼働するCloudFront を指定 それ以外のリクエストは全て レガシーフロントエンドのALBに ルーティングする
30. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行を可能にする技術選定 Next.jsとレガシーフロントエンドとで パスが被ってしまう場合は専用のprefix をつけることで競合を避ける 。 左の例では「modern」というprefixをつ けてレガシーフロントエンドとリクエス トパスが重複しないようにしている 重複する可能性のあるパス ・/api/* ・/static/* ・/img/* ・/api/modern/* ・/static/modern/* ・/img/modern/* Amazon CloudFront Ø パスごとにレガシーフロントエンドとNext.jsのリクエストを振り分ける
31. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行を可能にする技術選定 Ø Next.js からレガシーフロントエンドのCookie にアクセスすることができる Ø Cookieの情報から jwt を発行するAPIを用意す ることで、レガシーフロントエンドとNext.js で認証を共有できるようにした。 Amazon CloudFront Ø パスごとにレガシーフロントエンドとNext.jsのリクエストを振り分ける Ø レガシーフロントエンドとNext.jsでエンドポイントを1つにすることで Cookieを共有できる 認証共有案の例) ・ログイン時にjwtとMPA用のセッション両方を発行する ・jwtとMPAのセッションを変換する仕組みを構築する
32. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行を可能にする技術選定 Amazon CloudFront Ø パスごとにレガシーフロントエンドとNext.jsのリクエストを振り分ける Ø レガシーフロントエンドとNext.jsでエンドポイントを1つにすることで Cookieを共有できる Ø レガシーフロントエンドには手を加えていないため、 既存の アプリケーションへの影響を無くすことができた
33. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行中のアーキテクチャ (再掲) User Application Load Balancer Amazon ECS Amazon CloudFront Amazon CloudFront Amazon S3 Lambda@Edge AWS WAF Next.js (Server Side Rendering) xxx.wealthnavi.com レガシーフロントエンド 移行後のフロントエンド 段階移行 レガシーなページへのリクエスト 移行後のページへのリクエスト 次にここを解説
34. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行を可能にする技術選定 Next.js (Server Side Rendering) Ø SSRとMPAはどちらも「リクエストごとに サーバサイドでHTML全体を描画してクライ アントに返却する」という特徴を持ち、画面 単位の移行がやりやすかった Amazon S3 Lambda@Edge SSR処理 Ø ページ毎の認可チェックといったMPA的な 仕様を踏襲しやすかった
35. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Next.js (サーバサイド) の具体的な実装例 画面(HTML)の構築 (Lambda@Edge) Next.jsのサーバサイド (Lambda@Edge) (ここに絞ってもう少し解説)
36. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Next.js (サーバサイド) の具体的な実装例 ※ getTokenやAuthCheckProviderは自前で実装したものでNext .js が提供する関数ではありません 【認可チェック用の共通処理】 • この画面を見て良いユーザか？ • Tokenが期限切れになっていないか？ • 適切な順序を経て対象のページに辿り着いている か？ • その他、アクセスログの収集など..
37. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Next.jsのデプロイServerless Next.js Component Ø サーバレス関連のデプロイを行うServerless Framework のPlugin Ø Next.jsをサーバレス上に簡単にデプロイする ことができる Ø 生成されるAWSリソース Amazon S3 Lambda@Edge SSR処理 l Lambda@Edge・・・レンダリングサーバ l Amazon S3・・・静的ファイルの配置 l CloudFront・・・配信用CDN Ø Next.js v13 は未対応 (2022.11現在)
38. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行中のアーキテクチャ User Application Load Balancer Amazon ECS Amazon CloudFront Amazon CloudFront Amazon S3 Lambda@Edge AWS WAF Next.js (Server Side Rendering) xxx.wealthnavi.com レガシーフロントエンド 移行後のフロントエンド 段階移行 レガシーなページへのリクエスト 移行後のページへのリクエスト 最後にここを解説
39. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行を可能にする技術選定 AWS WAF Ø 前段のCloudFrontを経由することを担保する User Amazon CloudFront Amazon CloudFront Amazon S3 Lambda@Edge AWS WAF Next.js (Server Side Rendering) xxx.wealthnavi.com 移行後のページへのリクエスト ここに直接アクセスさせた くない
40. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行を可能にする技術選定 AWS WAF Ø 前段のCloudFrontを経由することを担保する User Amazon CloudFront Amazon CloudFront Amazon S3 Lambda@Edge AWS WAF Next.js (Server Side Rendering) xxx.wealthnavi.com 移行後のページへのリクエスト CloudFrontの中で ヘッダーを付与 key-header: hogehoge
41. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行を可能にする技術選定 AWS WAF Ø 前段のCloudFrontを経由することを担保する User Amazon CloudFront Amazon CloudFront Amazon S3 Lambda@Edge AWS WAF Next.js (Server Side Rendering) xxx.wealthnavi.com 移行後のページへのリクエスト 適切なヘッダが付与されて いない場合は403を返す key-header: hogehoge User
42. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 段階移行中のアーキテクチャ (再掲) User Application Load Balancer Amazon ECS Amazon CloudFront Amazon CloudFront Amazon S3 Lambda@Edge AWS WAF Next.js (Server Side Rendering) xxx.wealthnavi.com レガシーフロントエンド 移行後のフロントエンド 段階移行 レガシーなページへのリクエスト 移行後のページへのリクエスト
43. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 使用しなかった技術 ~AWS Amplify Hosting~ Øフロントエンドのマネージドホスティングサービス ü Git リポジトリと連携するだけでフロントエンドのホスティングが可能 ü 数クリックでエンドポイントの払い出し、CI/CD環境の構築 数クリック ソースリポジトリの選択 CI/CDパイプラインの構築 & デプロイ
44. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 使用しなかった技術 ~AWS Amplify Hosting~ Øホスティング以外にも・・ ü CDN, HTTPSのカスタムドメインの構築 ü branch の Autodetection ü Basic認証によるテスト環境の保護 ü Cypressを用いたE2Eテスト環境をデフォルトで提供 ü プルリクごとにプレビュー環境を構築 ü Amplify Studioと連携してFigmaでデザインしたUIをReactコンポーネントとして出力 ü etc.. Ø 2021.5 に AWS Amplify Hosting がSSRをサポート
45. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 使用しなかった技術 ~AWS Amplify Hosting~ User Amazon CloudFront AWS Amplify レガシーフロントエンド https://xxx.main.amplifyapp.com Amazon S3 Lambda@Edge ① ② ③ Server Side Rendering の場合 return 403 Ø1度のリクエストで3つ以上のCloudFrontを経由できないという制約に より Amplify Hosting の使用を断念
46. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 使用しなかった技術 ~AWS Amplify Hosting~ User Amazon CloudFront AWS Amplify レガシーフロントエンド https://xxx.main.amplifyapp.com ① ② Server Side Rendering ではない 場合 (これはOK) 1度に経由するCloudFrontが<3 となるため正常にリクエストが返却 される Ø1度のリクエストで3つ以上のCloudFrontを経由できないという制約に より Amplify Hosting の使用を断念
47. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 使用しなかった技術 ~Application Load Balancer~ CloudFront でルーティングしなくても ALB で同じことができたのでは？ Ø ALBでも同様のこと可能。前述したCloudFrontの制約を回避できるた めAmplify Hostingが使用できる Ø ウェルスナビでは元々前段にCloudFrontが配置されていたため前述し た構成をとった User Application Load Balancer AWS Amplify レガシーフロントエンド https://xxx.main.amplifyapp.com Amazon S3 Lambda@Edg e ① ②
48. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 選定観点 ALB CloudFront Amplify Hosting (SSR) 可 不可 WAFの利用 可 可 CloudFront Functions / Lambda@Edge 不可 可 本ユースケースにおける ALB vs CloudFront 使用しなかった技術 ~Application Load Balancer~
49. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. 今回のアーキテクチャでカバーできない点 Ø 今回の移行方針はパス単位でページ内の機能が完結していることを前 提としている. パスを跨いだ複雑なステート管理が必要な場合はある程 度大きな機能単位でリリースを覚悟する必要がある ⇨ 考えられる例) Vue2 から Next.js (SSR)に移行したい.. 等 Ø アプリケーションの特性やビジネスの前提条件によって最適な移行 方針は異なる. ⇨ ベストプラクティスに踊らされず自社の課題にあった技術選定を！ ⇨ 悩んだらSAに相談しよう！
50. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. その他 Ø インフラ、バックエンド、フロントエンドを横断的に見れる開発体制 だったのがよかった ⇨ 単体のチームだけでは今回の課題解決は難しかった 責任範囲を各チームの中にとどめず、プロダクト全体に Ownership を持てる体制が大事！
51. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. その他 https://speakerdeck.com/tamizuma/awswoyong-itahurontoentomonitarinkuru-men https://tech.wealthnavi.com/entry/20221005/1664955102 AWSでNext.jsをホスティングしたときのモニタリング手法について
52. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめ Ø フロントエンドの段階移行にはアーキテクチャ全体を見据えた工夫が 必要 (な場合が多い) Ø 一例としてウェルスナビの取り組みを紹介 ⇨ MPAの移行先にNext.js (SSR)を選択し、段階的に移行先のパ スにルーティング Ø ひとえにフロントエンドの移行と言ってもアプリケーションの特性や ビジネスの前提条件によって最善なアーキテクチャは異なる ⇨ 自社の課題にあった技術選定を！
53. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Thank you! © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.