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

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

sainu
March 30, 2023

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

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

sainu

March 30, 2023
Tweet

Other Decks in Programming

Transcript

  1. 基盤システムへのマイクロ
    フロントエンドの活用事例
    2023/03/30
    @sainu(株式会社マネーフォワード)

    View Slide

  2. 自己紹介

    View Slide

  3. 自己紹介
    ● sainu / 道祖克理(さいのうかつとし)
    ● Ruby, TypeScript
    ● マネーフォワードでは基盤プロダクトを開発
    ● 2022/09〜 岐阜市に移住
    冷やしたぬきそば / 更科 みそベトコンラーメン / 香楽 カプサイメン / カプサイメン
    岐阜タンメンも良いが...

    View Slide

  4. このスライドについて
    全てを話すには時間が足りないので、薄く広くなってしまいました 🙏
    消化不良の方はこちら👇
    マイクロサービスのその先へ。マネーフォワードのビジネスを加速するマイクロフロントエンドという選

    ただ、記事に書けてないことも話します 🤭

    View Slide

  5. 目次
    ● 解決したい課題
    ● マイクロフロントエンドとは
    ● どのように実践したか
    ● 課題
    ● 所感

    View Slide

  6. 解決したい課題

    View Slide

  7. 解決したい課題
    ● マネーフォワードクラウドのサービス数が毎年増え続ける 📈

    View Slide

  8. 解決したい課題
    ● マネーフォワードクラウドのサービス数が毎年増え続けた 📈
    ● これらサービスの基盤となる機能がサービスに個別最適化さ
    れリリース🚢

    View Slide

  9. 解決したい課題
    ● マネーフォワードクラウドのサービス数が毎年増え続ける 📈
    ● これらサービスの基盤となる機能がサービスに個別最適化さ
    れリリース🚢
    ● 各サービスで似たような機能がリリースされても複数サービス
    を併用するユーザーは少なかった

    View Slide

  10. 解決したい課題
    ● マネーフォワードクラウドのサービス数が毎年増え続ける 📈
    ● これらサービスの基盤となる機能がサービスに個別最適化さ
    れリリース🚢
    ● 各サービスで似たような機能がリリースされても複数サービス
    を併用するユーザーは少なかった
    ● が...事業が成長しサービスを併用するするユーザーが増えて
    課題が顕著に
    ○ サービス間でデータが同期されておらず、持っている
    データ構造が違うために、 ユーザーが複数のサービス
    でデータを同期する手間が繰り返し発生 😇

    View Slide

  11. 解決したい課題
    ● マネーフォワードクラウドのサービス数が毎年増え続ける 📈
    ● これらサービスの基盤となる機能がサービスに個別最適化さ
    れリリース🚢
    ● 各サービスで似たような機能がリリースされても複数サービス
    を併用するユーザーは少なかった
    ● が...事業が成長しサービスを併用するするユーザーが増えて
    課題が顕著に
    ○ サービス間でデータが同期されておらず、持っている
    データ構造が違うために、 ユーザーが複数のサービス
    でデータを同期する手間が繰り返し発生 😇
    ● いくつもの開発チームが同じ機能を繰り返し開発するコストが
    発生。UI/UX、品質がバラバラ

    View Slide

  12. 解決したい課題
    ● マネーフォワードクラウドのサービス数が毎年増え続ける 📈
    ● これらサービスの基盤となる機能がサービスに個別最適化さ
    れリリース🚢
    ● 各サービスで似たような機能がリリースされても複数サービス
    を併用するユーザーは少なかった
    ● が...事業が成長しサービスを併用するするユーザーが増えて
    課題が顕著に
    ○ サービス間でデータが同期されておらず、持っている
    データ構造が違うために、 ユーザーが複数のサービス
    でデータを同期する手間が繰り返し発生 😇
    ● いくつもの開発チームが同じ機能を繰り返し開発するコストが
    発生。UI/UX、品質がバラバラ
    ● 今後も新規サービスに同様の開発が発生することが想定

    View Slide

  13. 解決したい課題
    ● マネーフォワードクラウドのサービス数が毎年増え続ける 📈
    ● これらサービスの基盤となる機能がサービスに個別最適化さ
    れリリース🚢
    ● 各サービスで似たような機能がリリースされても複数サービス
    を併用するユーザーは少なかった
    ● が...事業が成長しサービスを併用するするユーザーが増えて
    課題が顕著に
    ○ サービス間でデータが同期されておらず、持っている
    データ構造が違うために、 ユーザーが複数のサービス
    でデータを同期する手間が繰り返し発生 😇
    ● いくつもの開発チームが同じ機能を繰り返し開発するコストが
    発生。UI/UX、品質がバラバラ
    ● 今後も新規サービスに同様の開発が発生することが想定
    なんとかせにゃいかん!!

    View Slide

  14. マイクロフロントエンドとは

    View Slide

  15. マイクロ
    フロントエンド
    複数の小さなフロントエンドアプリケー
    ションを組み合わせて大きなアプリ
    ケーションを構築するアーキテクチャ
    パターン

    View Slide

  16. マイクロフロントエンドの利点
    1.開発速度向上
    開発・デプロイが独立したことで開発速度が向上
    2.技術異質性
    サービスに適した言語で開発が可能に
    3.障害の局所化
    障害時に影響範囲が限定的に
    4.変更容易性
    バグ修正や機能追加が容易に
    5.再利用性
    サービスが他のプロジェクトで再利用できる 出典: micro-frontends.org

    View Slide

  17. マイクロフロントエンドの統合パターン
    ビルドタイム ランタイム
    アプローチ コンテナアプリのビルド時にマイクロフロント
    エンドをインストールする
    独立して配置されたマイクロフロント
    エンドを動的にロードする
    パフォーマンス ⚠(重複リソースをバンドルしないように注
    意)

    セキュリティ ✅ ⚠(適切なセキュリティポリシーや
    CORS設定を適用する)
    技術スタックの柔軟さ ❌ ✅
    デプロイ ❌ ✅高いスケーラビリティ
    依存管理の複雑さ ✅ ⚠(マイクロフロントエンド間の互換
    性を保つためのガバナンスやコミュニ
    ケーションが必要)
    ユーザーに一つのアプリケーションとして見せるために ...

    View Slide

  18. マイクロフロントエンドの分割パターン
    1.水平分割
    画面内の要素で分割、 1つの画面上に複数のフロントエンドアプリケーションが同居
    例 Spotify、マクアケ
    2.垂直分割
    ルーティング単位で分割、 1画面に1アプリケーション
    例 CircleCI、日経電子版
    出典: マイクロフロントエンド

    View Slide

  19. 思うに...

    View Slide

  20. 「こうあるべき」という形は無い

    View Slide

  21. 「こうあるべき」という形は無い
    0か100かでもない

    View Slide

  22. 型にハメる必要はない
    コンテナ
    アプリ
    水平分割なら...
    構成要素は全てマイクロフロントエンドになっ
    ているのが理想!
    そんなことは無い
    󰢁
    マイクロフロント
    エンド
    マイクロフロント
    エンド
    マイクロフロント
    エンド
    マイクロフロント
    エンド

    View Slide

  23. 型にハメる必要はない
    ページ 垂直分割なら...
    全てのページがマイクロフロントエンドとして分
    離されているのが理想!
    そんなことは無い
    󰢁
    ページ
    ページ
    ページ
    ページ
    ページ
    ページ
    マイクロフロントエ
    ンド

    View Slide

  24. サービス特性や規模、抱えている課題、開発組織の文化や状況
    置かれている状況によって解は違う

    View Slide

  25. 今自分が置かれている状況で
    どうあるべきかを柔軟に考えるのが大事

    View Slide

  26. どのように実践したか

    View Slide

  27. 分割、統合
    分割
    ● 特定URLのコンテンツ(垂直)
    ● あるボタン(水平)
    ● 画面の一部のUI(水平)
    水平or垂直はあまり意識せず、どの機能をどういう形で提供すべきか?で考えた
    統合方法
    ● ビルドタイム? ランタイム? 👉 ランタイム
    ○ デプロイの独立性を優先
    ● iframe? JS? web components? FW? SSI? 👉 web components
    ○ Web標準API
    ○ 属性値の変更検知やライフサイクルをサポート
    ● クライアント? サーバー? エッジ? 👉 クライアント
    ○ SSOの要件なし
    ○ CSRやSSR様々なアプリがある

    View Slide

  28. どう実装したか
    ● アプリケーションはReactで開発
    ● Reactアプリをカスタム要素として登録する
    JSを配信
    ● コンテナアプリはHTMLにカスタム要素を記述しJSを読み込むことでランタイム統合を実現
    ● 後方互換性のない変更に備えて
    JSのURLにバージョンを含める
    (https://path/to/v1/xxx.js )
    ● サービスのバックエンドをAPI Gateway兼認証サーバーとしてリクエストを認証
    ● マイクロフロントエンド間のデータ共有
    ○ URLのクエリ
    ○ CustomEventで変更通知
    詳しくはzennの記事に書いてます
    👉マイクロサービスのその先へ。マネーフォワードのビジネスを加速するマイクロ
    フロントエンドという選択

    View Slide

  29. 意識したこと
    ● なるべく特定フレームワークに依存せずに
    Web標準APIで作ること。
    ● 統合されるサービス数が多く、使われている技術も多種多様。
    ● サービスチームに統合のために新たなツールの導入をさせない。

    View Slide

  30. 課題

    View Slide

  31. 課題
    ● フロントエンドとバックエンドを統合テストするために統合レイヤーとなるサービス
    をセットアップする必要がある。
    ○ マイクロフロントエンド単体でエンドツーエンドの開発ができる状態が理想
    ...

    View Slide

  32. 所感

    View Slide

  33. 所感
    1. 特定領域の開発をUIからインフラまで専門チームに移譲することには成功した
    2. たくさんの製品を抱えるマネーフォワードクラウドにおいては、共通基盤機能を
    UI/UXごと再利
    用性を持たせて切り出せるマイクロフロントエンドは、ビジネスとの相性は良いと思った。
    3. システムの作りが複雑化することは避けられないので、それなりに組織やシステムが大きくなけ
    れば、得られる価値よりも運用コストの方が高そう。
    4. マイクロフロントエンドに、ベストプラクティスが
    あるない󰢁
    5. 1チームで複数のマイクロフロントエンドを管理するような状態は間違っている
    6. 異なるチームのマイクロフロントエンドでブラウザ上の通信が必要な時は慎重に
    a. 依存関係の管理が必要になって運用難易度が上がる
    b. データの同期はバックエンドで行う

    View Slide

  34. ご清聴ありがとう
    ございました

    View Slide