Mezzalira氏のQCon London講演:「マイクロフロントエンド〜設計から企業メリットと社内実装まで〜」

作者:

• Olimpiu Pop

翻訳者

• Kazuki.Shimatani

原文リンク(2025年04月30日)

QCon Londonでのプレゼンテーションで、AWSのプリンシパルアーキテクトLuca Mezzalira氏は、理想的なマイクロフロントエンドプラットフォームを構築する中で得られた知見を共有した。また、マイクロフロントエンドと自社の適性を判断するヒントや、個別ユースケースに最適なアーキテクチャを設計するために押さえておきたい基本原則、分散型アーキテクチャのデプロイ戦略も紹介されている。

プレゼンテーションの冒頭は、マイクロフロントエンドをコンセプト化した当初を振り返る内容であった。ちょうど、スポーツ試合のライブ配信中のことだったという。マイクロフロントエンドの定義を述べる中で、同氏は開発者の億劫さ(「...いったいどこが億劫だというのだか...。」)に着目した。

Mezzalira氏: マイクロフロントエンドはビジネスにおけるサブドメインをテクノロジーで表した形です。マイクロフロントエンド単位での管理を導入すれば、依存関係の有無にとらわれることなく、異なるテクノロジーを用いた実装が可能です。つまり、マイクロフロントエンド化で、一つのチームに管理権限が限定されたサブドメインで共有・管理するコードをできるだけ減らしていくことができるということです。

続いて、Mezzalira氏は、取り組みの中で得られた一連の知見を披露した。開発者にマイクロフロントエンドワークフレームを奨励し、コンポーネント分割との違いを明らかにしていく内容であった。コンポーネント分割では再利用する場合にも多くのプロパティが公開され、格納コンテナによる権限の制御が生じる。だが、マイクロフロントエンドを利用すればドメイン情報とステータスのカプセル化が可能だ。API提供を最小限に抑えることで、再利用性よりも各チームの自律性や独立性を優先した手法だと言えるだろう。

Neil Ford氏: 再利用は結合の一種だと言えます。

Mezzalira氏の知見:

1. コンテナに連携するAPIは最小限に(通常、APIやプロパティは最大2個までとすること)

2. マイクロフロントエンドはコンテキスト認識が可能(ステータスはマイクロフロントエンド内部で管理。外部依存関係はなし。)

3. 最適化の目的は、再利用性ではない(再利用性より、フローの高速化が優先)

4. コンポーネント分割よりも粒度が粗め(「ランタイムマイクロフロントエンドを25個処理する場合、分散モノリスを操作する感覚と似ている」とのこと)

さらに、マイクロフロントエンドは企業と共に進化(「...[マイクロフロントエンド]境界は絶対的なものではない」)しており、構造変化に順応していくとの見解を主張する。Mezzalira氏は、コンウェイの法則やチームトポロジーを引用しながら、階層型組織からより分散された自律的なユニットの集まりへと移行するように企業組織の体制変化を促している。マイクロフロントエンドを組織に導入する利点には、集団としての段階的なアップグレードが挙げられる。重要な機能に対するフィードバックループの迅速化、チームの認知負荷の軽減、テクノロジーと組織の円滑なスケーリングが可能になる。

開発者の設計判断の参考にと、Mezzalira氏自身の意思決定フレームワークも共有されている。

1. 分割:フロントエンドの分割方法の決定 - 水平分割(ヘッダーや製品詳細などのUIセクション単位)か垂直分割(ページ単位)かの選択

2. 構成:クライアントサイド組織(シェルを使用)かサーバーサイド組織(レンダリング処理されたフラグメントを使用)かの決定

3. ルート化:ルート化処理の決定 - 通常はシェルで処理実行

4. 通信: マイクロフロントエンド同士の通信方法の選択(イベントエミッター、カスタムイベント、または非同期処理ストリームの選択。いづれの場合もイベントエミッターを推奨。)

Mezzalira氏は、これら4点は、SSR(サーバーサイドレンダリング)、CSR(クライアントサイドレンダリング)、ESR(エッジサイドレンダリング)のどのマイクロフロントエンドアーキテクチャを使用する場合でも、常に考慮すべき項目であると力説する。マイクロフロントエンドを採用するなら、これらの4項目においてチームの意思決定が不可欠である。だが、同時に「技術選定から始めないこと」というのが同氏からのアドバイスだ。第一にすべきは、求められるアーキテクチャ設計とチームごとのコンテキスト制約を把握することだという。フレームワーク選択においては、要件定義に沿ったフレームワーク選択をすべきであり、フレームワーク選択に要件定義が縛られることがあってはならないからだ。くわえて、Mezzalira氏は、Thoughtworks社が「Technology Radar」で提唱した「マイクロフロントエンドのアナーキー状態」に言及し、技術選定の重要性を強調した。

Mezzalira氏:「フレームワーク選択よりも、注目すべきはコンテキスト把握です。」

プラットフォームチームはシェルの管理を通して、可能な限り簡易な状態を維持することが求められる。コンテキストを把握し、公開するものは初期設定のものに留めておけば、驚くほどの軽量さを維持したうえでルート化処理とコーディング処理の両方が可能になる。マイクロフロントエンドの変更は、シェルと独立した形で行われるようにするのが重要だ。もし変更が同期されていれば、マイクロソフトエンドとシェルの境界定義が曖昧になっており、ドメインからの情報漏洩が懸念される。

分散システムの設計時の大きな考慮材料の一つがデプロイ工程である。マイクロフロントエンドを使用する場合は、段階的または高い頻度でのデプロイ実装、ほかとの依存関係にないデプロイが推奨されている。検索エンジンを活用すれば、カナリア版のシームレスなリリース、対象を絞ったロールアウト、再構築が不要な迅速なロールバックも可能だ。こうすることで、チームでデプロイ工程をしっかりと管理しながら、一貫したユーザーエクスペリエンスの提供が可能になるということだ。今回発表されたアプローチの標準実装に向けて、Mezzalira氏は、マイクロフロントエンドフレームワークの最大手リリース企業と連携を進めてきた。その結果誕生したのが、フロントエンド検索スキーマとフロントエンド検索サービスである。こうした新規機能の実装により、マイクロフロントエンドのデプロイにおけるCL(継続的インテグレーション)ツール制限が解消された形だ。

マイクロフロントエンドのデプロイが成功するには、チームごとの権限範囲やプラットフォームの用途を明らかにしたうえで、バリューストリーム管理やフィードバックループの迅速化を行い、分散型マインドセットを意識することが重要になる。こうしたマイクロフロントエンドプラットフォーム構築の側面に配慮することで、経験を重ねたチームでも陥りがちな失敗を予防することが可能だという。Mezzalira氏は、写真左側のCL(継続的インテグレーション)パイプラインから、写真右側の反復作業の迅速化ができる状態にシフトしていくことを奨励して、講演を締めくくった。最後に、パフォーマンス、デジタルフットプリント、セキュリティなどで問題が生じる場合には、初期対応がベストである点に触れておきたい。

作者について

このコンテンツのトピックは QCon です。