基盤システムへのマイクロフロントエンドの活用事例

「Fintech SaaSにおける品質を高めるためのフロントエンド開発論」での発表で利用したスライドです。

Transcript

1. 基盤システムへのマイクロ フロントエンドの活用事例 2023/03/30 @sainu（株式会社マネーフォワード）
2. 自己紹介
3. 自己紹介 • sainu / 道祖克理（さいのうかつとし） • Ruby, TypeScript • マネーフォワードでは基盤プロダクトを開発 • 2022/09〜 岐阜市に移住 冷やしたぬきそば / 更科 みそベトコンラーメン / 香楽 カプサイメン / カプサイメン 岐阜タンメンも良いが...
4. このスライドについて 全てを話すには時間が足りないので、薄く広くなってしまいました 🙏 消化不良の方はこちら👇 マイクロサービスのその先へ。マネーフォワードのビジネスを加速するマイクロフロントエンドという選 択 ただ、記事に書けてないことも話します 🤭
5. 目次 • 解決したい課題 • マイクロフロントエンドとは • どのように実践したか • 課題 • 所感
6. 解決したい課題
7. 解決したい課題 • マネーフォワードクラウドのサービス数が毎年増え続ける 📈
8. 解決したい課題 • マネーフォワードクラウドのサービス数が毎年増え続けた 📈 • これらサービスの基盤となる機能がサービスに個別最適化さ れリリース🚢
9. 解決したい課題 • マネーフォワードクラウドのサービス数が毎年増え続ける 📈 • これらサービスの基盤となる機能がサービスに個別最適化さ れリリース🚢 • 各サービスで似たような機能がリリースされても複数サービス を併用するユーザーは少なかった
10. 解決したい課題 • マネーフォワードクラウドのサービス数が毎年増え続ける 📈 • これらサービスの基盤となる機能がサービスに個別最適化さ れリリース🚢 • 各サービスで似たような機能がリリースされても複数サービス を併用するユーザーは少なかった • が...事業が成長しサービスを併用するするユーザーが増えて 課題が顕著に ◦ サービス間でデータが同期されておらず、持っている データ構造が違うために、 ユーザーが複数のサービス でデータを同期する手間が繰り返し発生 😇
11. 解決したい課題 • マネーフォワードクラウドのサービス数が毎年増え続ける 📈 • これらサービスの基盤となる機能がサービスに個別最適化さ れリリース🚢 • 各サービスで似たような機能がリリースされても複数サービス を併用するユーザーは少なかった • が...事業が成長しサービスを併用するするユーザーが増えて 課題が顕著に ◦ サービス間でデータが同期されておらず、持っている データ構造が違うために、 ユーザーが複数のサービス でデータを同期する手間が繰り返し発生 😇 • いくつもの開発チームが同じ機能を繰り返し開発するコストが 発生。UI/UX、品質がバラバラ
12. 解決したい課題 • マネーフォワードクラウドのサービス数が毎年増え続ける 📈 • これらサービスの基盤となる機能がサービスに個別最適化さ れリリース🚢 • 各サービスで似たような機能がリリースされても複数サービス を併用するユーザーは少なかった • が...事業が成長しサービスを併用するするユーザーが増えて 課題が顕著に ◦ サービス間でデータが同期されておらず、持っている データ構造が違うために、 ユーザーが複数のサービス でデータを同期する手間が繰り返し発生 😇 • いくつもの開発チームが同じ機能を繰り返し開発するコストが 発生。UI/UX、品質がバラバラ • 今後も新規サービスに同様の開発が発生することが想定
13. 解決したい課題 • マネーフォワードクラウドのサービス数が毎年増え続ける 📈 • これらサービスの基盤となる機能がサービスに個別最適化さ れリリース🚢 • 各サービスで似たような機能がリリースされても複数サービス を併用するユーザーは少なかった • が...事業が成長しサービスを併用するするユーザーが増えて 課題が顕著に ◦ サービス間でデータが同期されておらず、持っている データ構造が違うために、 ユーザーが複数のサービス でデータを同期する手間が繰り返し発生 😇 • いくつもの開発チームが同じ機能を繰り返し開発するコストが 発生。UI/UX、品質がバラバラ • 今後も新規サービスに同様の開発が発生することが想定 なんとかせにゃいかん!!
14. マイクロフロントエンドとは
15. マイクロ フロントエンド 複数の小さなフロントエンドアプリケー ションを組み合わせて大きなアプリ ケーションを構築するアーキテクチャ パターン
16. マイクロフロントエンドの利点 1．開発速度向上 開発・デプロイが独立したことで開発速度が向上 2．技術異質性 サービスに適した言語で開発が可能に 3．障害の局所化 障害時に影響範囲が限定的に 4．変更容易性 バグ修正や機能追加が容易に 5．再利用性 サービスが他のプロジェクトで再利用できる 出典: micro-frontends.org
17. マイクロフロントエンドの統合パターン ビルドタイム ランタイム アプローチ コンテナアプリのビルド時にマイクロフロント エンドをインストールする 独立して配置されたマイクロフロント エンドを動的にロードする パフォーマンス ⚠（重複リソースをバンドルしないように注 意） ❌ セキュリティ ✅ ⚠（適切なセキュリティポリシーや CORS設定を適用する） 技術スタックの柔軟さ ❌ ✅ デプロイ ❌ ✅高いスケーラビリティ 依存管理の複雑さ ✅ ⚠（マイクロフロントエンド間の互換 性を保つためのガバナンスやコミュニ ケーションが必要） ユーザーに一つのアプリケーションとして見せるために ...
18. マイクロフロントエンドの分割パターン 1．水平分割 画面内の要素で分割、 1つの画面上に複数のフロントエンドアプリケーションが同居 例 Spotify、マクアケ 2．垂直分割 ルーティング単位で分割、 1画面に1アプリケーション 例 CircleCI、日経電子版 出典: マイクロフロントエンド
19. 思うに...
20. 「こうあるべき」という形は無い
21. 「こうあるべき」という形は無い 0か100かでもない
22. 型にハメる必要はない コンテナ アプリ 水平分割なら... 構成要素は全てマイクロフロントエンドになっ ているのが理想！ そんなことは無い 󰢁 マイクロフロント エンド マイクロフロント エンド マイクロフロント エンド マイクロフロント エンド
23. 型にハメる必要はない ページ 垂直分割なら... 全てのページがマイクロフロントエンドとして分 離されているのが理想！ そんなことは無い 󰢁 ページ ページ ページ ページ ページ ページ マイクロフロントエ ンド
24. サービス特性や規模、抱えている課題、開発組織の文化や状況 置かれている状況によって解は違う
25. 今自分が置かれている状況で どうあるべきかを柔軟に考えるのが大事
26. どのように実践したか
27. 分割、統合 分割 • 特定URLのコンテンツ（垂直） • あるボタン（水平） • 画面の一部のUI（水平） 水平or垂直はあまり意識せず、どの機能をどういう形で提供すべきか？で考えた 統合方法 • ビルドタイム? ランタイム? 👉 ランタイム ◦ デプロイの独立性を優先 • iframe? JS? web components? FW? SSI? 👉 web components ◦ Web標準API ◦ 属性値の変更検知やライフサイクルをサポート • クライアント? サーバー? エッジ? 👉 クライアント ◦ SSOの要件なし ◦ CSRやSSR様々なアプリがある
28. どう実装したか • アプリケーションはReactで開発 • Reactアプリをカスタム要素として登録する JSを配信 • コンテナアプリはHTMLにカスタム要素を記述しJSを読み込むことでランタイム統合を実現 • 後方互換性のない変更に備えて JSのURLにバージョンを含める （https://path/to/v1/xxx.js ） • サービスのバックエンドをAPI Gateway兼認証サーバーとしてリクエストを認証 • マイクロフロントエンド間のデータ共有 ◦ URLのクエリ ◦ CustomEventで変更通知 詳しくはzennの記事に書いてます 👉マイクロサービスのその先へ。マネーフォワードのビジネスを加速するマイクロ フロントエンドという選択
29. 意識したこと • なるべく特定フレームワークに依存せずに Web標準APIで作ること。 • 統合されるサービス数が多く、使われている技術も多種多様。 • サービスチームに統合のために新たなツールの導入をさせない。
30. 課題
31. 課題 • フロントエンドとバックエンドを統合テストするために統合レイヤーとなるサービス をセットアップする必要がある。 ◦ マイクロフロントエンド単体でエンドツーエンドの開発ができる状態が理想 ...
32. 所感
33. 所感 1. 特定領域の開発をUIからインフラまで専門チームに移譲することには成功した 2. たくさんの製品を抱えるマネーフォワードクラウドにおいては、共通基盤機能を UI/UXごと再利 用性を持たせて切り出せるマイクロフロントエンドは、ビジネスとの相性は良いと思った。 3. システムの作りが複雑化することは避けられないので、それなりに組織やシステムが大きくなけ れば、得られる価値よりも運用コストの方が高そう。 4. マイクロフロントエンドに、ベストプラクティスが あるない󰢁 5. 1チームで複数のマイクロフロントエンドを管理するような状態は間違っている 6. 異なるチームのマイクロフロントエンドでブラウザ上の通信が必要な時は慎重に a. 依存関係の管理が必要になって運用難易度が上がる b. データの同期はバックエンドで行う
34. ご清聴ありがとう ございました