Micro Frontendsで築いた 共通基盤と運用の試行錯誤 / Building a Shared Platform with Micro Frontends: Operational Learnings

Transcript

1. Micro Frontendsで築いた 共通基盤と運用の試行錯誤 Building a Shared Platform with Micro Frontends: Operational Learnings 金子 優斗 (@kyntk_1128) Yuto Kaneko
2. Survey 󰢧 • ｢マイクロフロントエンド｣って聞いたことあるかた? 
 Have you heard of “Micro Frontends” before?
 
 • マイクロフロントエンドを採用したことがあるかた?
 Have you ever used Micro Frontends?

3. → Solution: Micro Frontends (MFE)
 巨大化したフロントエンドをどう分割するか How do we break down a growing frontend? 出典: Micro Frontends - extending the microservice idea to frontend development
4. 金子 優斗 (@kyntk_1128) Yuto Kaneko • 2024/05 Money Forward Join • Nagoya Branch • Running 󰝊 • Coffee ☕ • 最近の目標 / My recent goal ｢懸垂ができるようになりたい｣ I want to be able to do pull-ups.
5. Agenda ❏ マネーフォワード クラウドについて 
 ❏ マイクロフロントエンドとは 
 ❏ 導入の目的 
 ❏ MFE のデリバリー方法 
 ❏ 運用で見えてきた課題と学び 
 ❏ 未解決の課題と今後 
 ❏ About Money Forward Cloud
 ❏ What Micro Frontends Are
 ❏ Why We Adopted Micro Frontends
 ❏ How We Deliver Micro Frontends
 ❏ Challenges and Learnings
 ❏ Unresolved Challenges and What’s Next

6. Agenda ❏ マネーフォワード クラウドについて 
 ❏ マイクロフロントエンドとは 
 ❏ 導入の目的 
 ❏ MFE のデリバリー方法 
 ❏ 運用で見えてきた課題と学び 
 ❏ 未解決の課題と今後 
 ❏ About Money Forward Cloud
 ❏ What Micro Frontends Are
 ❏ Why We Adopted Micro Frontends
 ❏ How We Deliver Micro Frontends
 ❏ Challenges and Learnings
 ❏ Unresolved Challenges and What’s Next

7. マネーフォワード クラウドとは 出典元 : 株式会社マネーフォワード 会社紹介資料 法人向け バックオフィス向け　 SaaS ファイナンスサービス 個人向け 金融機関等向け PFM（家計簿・資産管理）サービス Fintech推進・DX支援 金融機関・特定サービス向け マネーフォワード デジタル通帳・かんたん通帳 Money Forward Cloud is a SaaS for businesses
8. マネーフォワード クラウドの共通基盤を開発 Developing the shared platform for Money Forward Cloud 等
 通知基盤 / Notification Platform 契約基盤 / Contract Platform 認証基盤 / Authentication Platform 承認ワークフロー基盤 / Approval Workflow Platform
9. 申請内容入力
 Enter application details
 申請、承認のステップ Enter application details 申請内容･承認者確認、提出 
 Review details and approvers, then submit
 承認
 Approval

10. Agenda ❏ マネーフォワード クラウドについて 
 ❏ マイクロフロントエンドとは 
 ❏ 導入の目的 
 ❏ MFE のデリバリー方法 
 ❏ 運用で見えてきた課題と学び 
 ❏ 未解決の課題と今後 
 ❏ About Money Forward Cloud
 ❏ What Micro Frontends Are
 ❏ Why We Adopted Micro Frontends
 ❏ How We Deliver Micro Frontends
 ❏ Challenges and Learnings
 ❏ Unresolved Challenges and What’s Next

11. 巨大化したフロントエンドをどう分割するか How can we split a growing / monolithic frontend? 出典: Micro Frontends - extending the microservice idea to frontend development
12. MFE：マイクロサービスの思想をフロントエンドに拡張 Extending the microservices mindset to the frontend 出典: Micro Frontends - extending the microservice idea to frontend development A B C TeamA 󰞵󰞵󰞵󰞵󰞵 TeamB 󰠁󰠁󰠁 TeamC 󰳕󰳕󰳕󰳕 複数のチームで開発し、統合

13. ❏ About Money Forward Cloud
 ❏ What Micro Frontends Are
 ❏ Why We Adopted Micro Frontends
 ❏ How We Deliver Micro Frontends
 ❏ Challenges and Learnings
 ❏ Unresolved Challenges and What’s Next
 Agenda ❏ マネーフォワード クラウドについて 
 ❏ マイクロフロントエンドとは 
 ❏ 導入の目的 
 ❏ MFE のデリバリー方法 
 ❏ 運用で見えてきた課題と学び 
 ❏ 未解決の課題と今後 

14. 自社が抱えていた問題：似た機能が個別実装されていた Our internal issue: similar features were implemented separately across products Product A
 ⚙ 承認ワークフロー A Product B
 ⚙ 承認ワークフロー B TeamA 󰞵󰞵󰞵󰞵󰞵 TeamB 󰠁󰠁󰠁 データの二重管理、UI/UXの不統一などの問題
 Duplicated data management and inconsistent UI/UX

15. • プロダクト側での開発・保守の負荷を大幅に軽減
 Big reduction in product-side workload
 • 切り出されたチームが自律的に改善
 Dedicated team improves autonomously
 マイクロサービスとして切り出し、UI も含めて提供 Extracted as a microservice and provided with its UI as well Team MFE 󰳕󰳕󰳕 ⚙ 承認ワークフロー 基盤 ⚙ 承認ワークフロー 基盤 ⚙ 承認ワークフロー 基盤 Product A
 Product B

16. なぜ UI も提供するのか / Why provide the UI, too? 1. 承認ワークフローの UI は非常に複雑なため / UI is complex
 2. 全プロダクトで同じ UI を使い、一貫したUXを実現するため / Consistent UX across products
 3. 価値を届けるスピードを上げるため / Faster delivery of value

17. 複数チームが独立して開発・運用しながら 共通機能や UI を共有したい
 Independent teams need to share features/UI
 どのようなときにMFEを導入するか / When to use MFE UIが複雑で、各プロダクトが個別に実装す る負荷が高い (※後で補足)
 UI is complex and costly to build per product
 
 
 A B C TeamA 󰞵󰞵󰞵󰞵󰞵 TeamB 󰠁󰠁󰠁 TeamC 󰳕󰳕󰳕󰳕 ⚙ 承認ワークフロー A ⚙ 承認ワークフロー B 󰷺 󰷺
18. ❏ About Money Forward Cloud
 ❏ What Micro Frontends Are
 ❏ Why We Adopted Micro Frontends
 ❏ How We Deliver Micro Frontends
 ❏ Challenges and Learnings
 ❏ Unresolved Challenges and What’s Next
 Agenda ❏ マネーフォワード クラウドについて 
 ❏ マイクロフロントエンドとは 
 ❏ 導入の目的 
 ❏ MFE のデリバリー方法 
 ❏ 運用で見えてきた課題と学び 
 ❏ 未解決の課題と今後 

19. 垂直統合 / Vertical Composition
 垂直統合 vs 水平統合 水平統合 / Horizontal Composition
 Team A Team B https://xxx/feat-a https://xxx/feat-b Team A Team A https://xxx/feat-a https://xxx/feat-b Team C Team B Team C Team B
20. ビルドタイム統合/Build-time Composition
 ランタイム統合/Runtime Composition
 ⚙ 承認ワークフロー 基盤 Host Product ⚙ 承認ワークフロー 基盤 Host Product 👍即時展開 & 👎障害対応責任
 Instant rollout & Owns failure handling
 ビルドタイム統合 vs ランタイム統合
21. Shadow Dom Web Componentsを利用 <workflow-seting> • Shadow DOM によるスタイルの独立性
 Style isolation with Shadow DOM
 • フレームワークに依存しない柔軟性
 Framework-agnostic flexibility

22. • マイクロフロントエンド (MFE) とは
 ◦ マイクロサービスの考え方をフロントエンドにも拡張し、 
 各チームが独立して機能を開発・提供できるようにするアーキテクチャ 
 • なぜMFEを選択したか
 ◦ プロダクト側での開発負荷を大幅に軽減するため 
 ◦ 小さいチームで自律的に高速に価値を届けるため 
 ◦ 1ページ内でシームレスな体験を実現するため 
 ◦ プロダクトをまたいで一貫した UXを実現するため
 • MFE のデリバリー方法
 ◦ 水平統合
 ◦ ランタイム統合
 ◦ Web Components
 ここまでのまとめ / Summary
23. ❏ About Money Forward Cloud
 ❏ What Micro Frontends Are
 ❏ Why We Adopted Micro Frontends
 ❏ How We Deliver Micro Frontends
 ❏ Challenges and Learnings
 ❏ Unresolved Challenges and What’s Next
 Agenda ❏ マネーフォワード クラウドについて 
 ❏ マイクロフロントエンドとは 
 ❏ 導入の目的 
 ❏ MFE のデリバリー方法 
 ❏ 運用で見えてきた課題と学び 
 ❏ 未解決の課題と今後 

24. ✅ プロダクト側での開発負荷を大幅に軽減する
 Big reduction in product workload
 ✅ 小さいチームで自律的に高速に価値を届ける
 Small teams ship value fast
 ✅ 1ページ内でシームレスな体験を実現する
 Seamless in-page experience
 ✅ プロダクトをまたいで一貫したUXを実現する
 Seamless in-page experience
 当初の目的はすべて達成 / We achieved all initial goals
25. ⚠ 拡張性と組み込みコストのトレードオフ
 Trade-off: flexibility vs integration cost
 ⚠ 疎結合設計とその限界
 Limits of loose coupling
 ⚠ 認証・認可のアーキテクチャの課題と、変更
 Auth architecture issues & changes
 ⚠ UIの一貫性
 Consistent UI within the same page
 見えてきた課題 / Challenges uncovered
26. コンポーネントをホストプロダクト側で拡張をしたい要望 
 Requests to extend components on the host side
 課題1. UI をどこまで共通化すべきか / How far should UI be shared? あるステップに 設定追加したい 独自の条件で 承認者を選びたい カラムを 追加したい ラベルを変えたい 承認前に コールバックを 挟みたい
27. MFEが適している 範囲 Where MFE is suitable 拡張の必要性が低く、実装難易度が高いもの Low need for extension, high implementation cost プロダクト独自の拡張性 Product-specific extensibility 実装難易度 Implementation difficulty プロダクト独自の拡張が増えると 保守が大変 実装難易度が低いものは 提供価値が高くない
28. ⚠ 拡張性と組み込みコストのトレードオフ
 Trade-off: flexibility vs integration cost
 ⚠ 疎結合設計とその限界
 Limits of loose coupling
 ⚠ 認証・認可のアーキテクチャの課題と、変更
 Auth architecture issues & changes
 ⚠ UIの一貫性
 Consistent UI within the same page
 見えてきた課題 / Challenges uncovered
29. 疎結合設計: Custom Eventを用いた伝達 Loose coupling: communication via Custom Events Host product MFE component MFE component Props 1 2
30. 不採用の案: Callbackを用いたコミュニケーション Rejected approach: communication via callbacks Host product MFE component MFE component Callback Call Callback Call Callback関数を渡す方式だと、
 拡張時にホスト側の修正が必要になる
 Callbacks require host changes whenever extensions are needed

31. Event Bus Pattern EventをPublish, Subscribe
 することで、
 お互いを知らずに情 報をやりとり
 MFE component MFE component Event Bus By publishing / subscribing events, they can exchange data without knowing each other

32. CustomEvent設計の課題 1: 描画タイミングの問題 Send State MFE component MFE component Route Component Submit Button Component ❌ 描画タイミングによっては、
 Stateの同期に失敗する
 Depending on render timing, state sync can fail

33. CustomEvent設計の課題 1: 描画タイミングの問題 Stateの再送 レンダリング 完了通知 レンダリング完了のイベントを送信
 Stateを再送するようにした
 Send a “rendered” event and resend state after that
 MFE component MFE component 描画タイミングによっては、
 Stateの同期に失敗する
 Depending on render timing, state sync can fail

34. コールバック関数も受け取れるように
 Added support for callbacks
 CustomEvent設計の課題 2: イベント駆動の限界 特定のイベント前に、
 同期的に処理を挟む必要が出てきた
 Needed synchronous processing before certain events
 承認前に バリデーションを 挟みたい
35. ⚠ 拡張性と組み込みコストのトレードオフ
 Trade-off: flexibility vs integration cost
 ⚠ 疎結合設計とその限界
 Limits of loose coupling
 ⚠ 認証・認可のアーキテクチャの課題と、変更
 Auth architecture issues & changes
 ⚠ UIの一貫性
 Consistent UI within the same page
 見えてきた課題 / Challenges uncovered
36. ログインはホストプロダクトでのみ行う / Login happens only on the host product
 ユーザーはログイン状態で MFEを利用する / Users access the MFE while already logged in
 課題3. 認証・認可のアーキテクチャの課題と、変更 Auth architecture issues & changes
37. 認証・認可のアーキテクチャv1 Auth architecture v1 Host product Frontend MFE Frontend Host product Backend MFE Backend Rendering API Request (Same Origin) Auth Authenticated request (with permissions) MFE Frontend からのリクエストはSame Origin扱い
 MFE Backend は認証済みのリクエストのみを扱える

38. 認証・認可のアーキテクチャv1の課題 Auth Architecture v1: Issues Host product Frontend MFE Frontend Host product Backend MFE Backend Auth 1. Host Backendのスレッド占有による、レイテンシ悪化
 2. API拡張の際 Host の更新に依存にする拡張性の制限
 MFE Backendの 処理待ちスレッド Host Backend による拡張制限 Host BE thread blocking → higher latency API extensions depend on host updates → limited flexibility
39. 要件に合わせて適切なアーキテクチャを設計する必要がある
 Architecture must fit the requirements
 認証・認可のアーキテクチャv2 Auth architecture v2 Host product Frontend MFE Frontend Host product Backend Rendering API Request (Cross Origin) MFE Backend Auth request Response with permissions
40. 見えてきた課題 / Challenges uncovered ⚠ 拡張性と組み込みコストのトレードオフ
 Trade-off: flexibility vs integration cost
 ⚠ 疎結合設計とその限界
 Limits of loose coupling
 ⚠ 認証・認可のアーキテクチャの課題と、変更
 Auth architecture issues & changes
 ⚠ UIの一貫性
 Consistent UI within the same page

41. UI をアップデートするのは各チーム依存のため
 ホストプロダクトと MFE の UI の不一致が発生
 Different team update timings cause UI mismatches between the host and the MFE on the same page.
 課題4. UIの一貫性 / Consistent UI within the same page MFE Team 󰳕󰳕󰳕 Button Product Team 󰳕󰳕󰳕 Button Design system v1 Design system v2 🚀 🚀
42. コンポーネントライブラリの活用推進 Promoting use of the component library MFE Team 󰳕󰳕󰳕 Product Team 󰳕󰳕󰳕 Button Design system v2 Component Library Team 󰳕󰳕󰳕 Build-time Composition Build-time Composition 🚀 🚀 コンポーネントライブラリを使うことで最新のデザインシステムに追従 
 Using the component library keeps us aligned with the latest design system

43. Agenda ❏ マネーフォワード クラウドについて 
 ❏ マイクロフロントエンドとは 
 ❏ 導入の目的 
 ❏ MFE のデリバリー方法 
 ❏ 運用で見えてきた課題と学び 
 ❏ 未解決の課題と今後 
 ❏ About Money Forward Cloud
 ❏ What Micro Frontends Are
 ❏ Why We Adopted Micro Frontends
 ❏ How We Deliver Micro Frontends
 ❏ Challenges and Learnings
 ❏ Unresolved Challenges and What’s Next

44. 書類提出までのステップで新たにDialog が追加された
 A new dialog was added in the submission flow
 • プロダクトに組み込んでのE2Eが必要
 E2E must run on each host product
 • プロダクトの変更によりE2Eがテストが落ちることもあり、修正が大変
 Host changes often break E2E, making fixes costly
 未解決の課題1: E2E テストのメンテナンスの課題 Unresolved Issue 1: E2E test maintenance
45. 未解決の課題2: アセットサイズの問題 Unresolved Issue 2: Asset size growth • Web Componentsはホスト、MFEで異なるライブラリを使える
 Host and MFE can use different libraries
 • ブラウザにダウンロードするアセットサイズが大きくなる
 Larger asset downloads
 • 十分にパフォーマンスの監視もできていない
 Performance monitoring is still limited
 v19.2.0 v18.3.1
46. • 対応がプロダクトごとに異なり、MFEと連携ができていない
 Different i18n approaches per product, not aligned with MFE
 • 仕組みの標準化に取り組んでいる
 Working on standardising the approach
 未解決の課題3: i18n の不統一 Unresolved Issue 3: Inconsistent i18n English 日本語
47. • 共通ライブラリの提供
 Providing shared libraries
 • 実装ガイドラインの策定
 Creating implementation guidelines
 MFEを実装するための仕組みを整えて、活用を促進
 Improving the foundation to make MFE easier to adopt
 今取り組んでいること: MFE の標準化 Current Focus: Standardizing MFE
48. できたこと
 ✅ プロダクト側での開発負荷軽減
 ✅ 小さいチームで自律的に価値提供
 ✅ 1ページ内でシームレスな体験を実現
 ✅ 一貫したUXを実現
 まとめ 学び
 🧠 UI の共通化範囲の判断
 🧠 CustomEvent設計の工夫
 🧠 認証アーキテクチャの変更
 🧠 UIの一貫性
 
 今後
 ▶ E2E テスト、アセットサイズ、i18n
 ▶ MFEの標準化