AWS における Dunelm のマイクロフロントエンドジャーニー

Dunelm Group plc は、イギリスの大手家庭用品小売業者であり、イギリス全土のスーパマーケットとデジタルプラットフォーム上で消費者向けの専門的な商品を扱っています。毎年 4 億回以上のセッションが発生する Dunelm のウェブサイトは、会社の収益の約 35% を生みだしています。

組織が拡大するにつれ、その拡大に一致するように組織構造とソフトウェアアーキテクチャを変革する必要があります。多くの場合、最初に思いつくのは、現在のアーキテクチャから分散システムに移行することです。バックエンドには、マイクロサービスのような統合アーキテクチャがあります。しかし、フロントエンド層、特にそこから高収益を生み出す企業に対してはどう対応したらよいでしょうか？

このブログでは、Dunelm が顧客体験を向上させ、組織を拡大するために、マイクロフロントエンド・アーキテクチャを使用してデジタルプラットフォームを革新している方法について説明します。

ジャーニーの始まり

Dunelm と Amazon Web Services (AWS) とのジャーニーは、2018 年に既存の E コマースウェブサイトをイベント主導型サーバーレスマイクロサービスアーキテクチャで再構築を始めた時から始まりました。このジャーニーから TCO の削減やビジネスの俊敏性の向上など、数多くのメリットがもたらされました。

しかし、モノリシックで、シングルページアプリケーションとして開発されたフロントエンドには、いくつかの課題がありました。

フロントエンドを変更する場合、アプリケーション全体を一度にテストおよびデプロイする必要がありました。つまり、どんな変更でも高いリスクが伴い、ウェブサイトのどの部分であれ影響が及ぶ可能性がありました。
Dunelm では複数のチームが同時にウェブサイトで作業を行うにつれ、スケールアップの際に問題が起きていました。つまり、オーナーシップの設定や、チーム間のコミュニケーション共有が困難になっていました。
ウェブサイトが複雑になり、1 つのチームがセクションすべてを知悉することが難しくなりました。このため、変更を行う際の不確実性が高まり、予期しない問題に対処するために費やす時間が増加することになりました。

こうした課題のために、Dunelm ではウェブサイト変更に費やすリードタイムが徐々に長くなっていき、従来の 2 倍にもなりました。ビジネスがオポチュニティに迅速に適応し対応するためには、新しいパラダイムを考える必要がありました。

再構築の目的

こうした課題を克服するために、Dunelm は機能開発計画や顧客体験を損なうことなく、ウェブサイトを部分的に再構築することが必要と判断しました。この再構築には相当なコストと労力が必要と思われました。

Dunelm は、再構築によって以下のようなメリットを実現できる見込みがあると想定しています。

チームがウェブサイトの特定の領域のオーナーシップを持つことを可能にする。
変更にかかわるリードタイムを短縮し、より多くのリリースを可能にする。
新入社員のオンボーディング時間を短縮する。
開発者体験を改善し、生産性を高め、イノベーションを促進する。
ウェブサイトパフォーマンスの改善により、コンバージョンレートを高め、直帰率を低減させる。
ユーザー体験の改善により、ウェブサイトのアクセシビリティを向上させる。
ウェブサイトプロジェクトに留まらない、Dunelm における一貫したグラフィック UI を作成する。

今ある選択肢を評価すると、Dunelm はマイクロフロントエンド (MFE) アーキテクチャが最良の選択であることが分かりました。これによって、期待されたメリットはそのほとんどが実現できるはずでしたが、最後の 3 つ (ウェブサイトユーザー体験に関連するもの )は、MFE アーキテクチャによって直接実現できるものではありませんでした。

しかし、マイクロフロントエンドとは何でしょうか? マイクロフロントエンドとは、ユーザーインターフェースへの分散システムアプローチです。ここではマイクロサービスと同じ原則、つまり独立したデプロイ、エラーの影響範囲の縮小、チームの認知負荷の軽減、システムの進化の加速などをアプローチの目的としています。

慎重に評価した後、Dunelm は MFE アーキテクチャを実装することを決定しました。これにより、フロントエンドを独立してテストおよびデプロイできるセクションに分割することが可能になります。MFE アーキテクチャにより、Dunelm はオーナーシップ割り当てが困難であることとリードタイムの増大という 2 つの大きな課題を解決できるようになりました。

MFE アーキテクチャによって、フロントエンドの個々のセクションにおける互いの依存関係から来る並行処理の滞留が減り、チームが個々のウェブサイトセクションで完全なオーナーシップを持つことを可能にします。これにより、開発者はコードを深く理解できるので自信を持って変更を行うことができ、テストが少なくて済み、フィードバックループが速くなります。チームの取り組みがより小さなセクションに限定されるので、変更を行うのに必要な認知的複雑さが減るという付加的なメリットがあり、開発者体験が向上します。

ターゲットアーキテクチャの設計と移行戦略

図 1 – マイクロフロントエンド・フラグメントとその配置

ウェブサイトのアーキテクチャを設計するにあたって、Dunelm はページグループごとに垂直フラグメントに分割し、インクリメンタルな移行を可能にし、チーム設定と整合するようにしました。水平フラグメントについては、以下の 3 つにまとめることにしました。

一貫したヘッダー
一貫したフッター
フレキシブルなページグループ・フラグメント

このアプローチでは、垂直フラグメントごとにポリリポジトリを採用し、ウェブサイト上で自らに割り当てられたオーナーシップのある領域に対して、チームがより制御を働かすことができるようにします。

ページグループ・フラグメントを実装するという決断は、それによって Dunelm の組織構造とのシナジーを生み出すことを理由としています。Dunelm のエンジニアリングチームは、ウェブサイトの特定の垂直領域全体に対してオーナーシップをとるように構成されています。たとえば、専用のチームがカートとその関連サービスを監督し、別のチームは注文データとチェックアウトページおよびサービスを注視しています。このような組織の整合した対応のため、専門化されたチームによる個別のウェブサイト機能の効率的な管理とオーナーシップの引き受けが確実に可能になります。

専用のコンポーネントライブラリは、ポリリポ (poly-repo)・マイクロフロントエンド間で効率的にコードを共有するために作成され、プロジェクト間で一貫したユーザーインターフェースを提供することを目的としています。Dunelm は、「デフォルトで共有しない」という原則を徹底し、必要に応じてのみ共有ライブラリにコンポーネントを追加するようにしています。これにより、効率性とカプセル化のバランスが取れます。

図 2 -セカンドアプローチにおけるハイレベルアーキテクチャ図

Dunelm のハイレベルマイクロフロントエンドアーキテクチャーを掘り下げると、コンテンツデリバリーネットワーク (CDN) 内に Compute を導入しています。これにより、カスタムコード実行が可能になり、入力リクエストが充実します。

各実行 Compute は、ウェブサイトのテストのためにサードパーティのサービスである Launch Darkly から機能フラグを取得し、アプリケーションシェルまたはレガシーウェブサイトへのルーティングを決定します。アプリケーションシェルは、動的コード共有パターンを活用したモジュールフェデレーションホストとして機能します。これにより、フラグメントからのコンテンツのプルインとその共通依存関係の共有が可能になります。また、ページをロードするために必要な JavaScript が減り、ページパフォーマンスが大幅に向上します。

各フラグメントはモジュールフェデレーションリモートとして機能し、アプリケーションシェルに必要な部分を公開できます。フラグメントの変更時には、ビルドプロセスがアセットをまとめ、リモートエントリファイルで参照される S3 バケットに格納します。フラグメントは、必要に応じてダウンストリームサービス、サードパーティ、共有コンポーネントライブラリと通信します。

図3 – Strangler 移行パターン図

Dunelm は「Strangler 移行パターン」を用いた反復的な移行戦略を採用しました。このパターンは、モノリシックなアーキテクチャからマイクロサービスアーキテクチャへの移行に使用されることで広く知られています。また、マイクロフロントエンドの構築にも適しています。Dunelm は、既存のモノリシックなアーキテクチャのサイズを徐々に縮小しながらマイクロフロントエンドの数を増やしていくために、1つのページグループずつ移行する計画です。最終的にはシステム全体が新しいアーキテクチャになるまでこの作業を続けます。

安定性を高め、ガバナンスをより良く実装するために、Dunelm は CDN、Compute、アプリケーションシェルなどの主要コンポーネントを管理するためのイネーブルメントチームを戦略的に設立しました。このチームは、これらのコンポーネントが確実に円滑に機能するようにするだけでなく、プラットフォーム内での質の高いソリューションの開発と統合に関する専門知識の共有を積極的に行います。さらに、作業の複雑さを軽減し、www.dunelm.com 上で作業する数多くのチームの全体的な開発者体験を向上させることを目的としたツールやガードレールを作成します。

可観測性を容易にするために、Dunelm は RUM (リアルユーザーモニタリング) データを注意深く追跡し、ブラウザやデバイスの種類に基づいて分類およびレポートを行います。合成アラートは、メトリクスが許容範囲を下回った場合に適切なチームにすぐに通知が行くように設計されています。さらに、Dunelm は新しく構築されたウェブサイト機能のパフォーマンスへの影響を確認するために、本番環境に入る前に内部で行う事前テストを構築しました。これにより、問題は本番環境にデプロイされる前に検出されるため、最適なパフォーマンスが確実に実現されます。

結果

Dunelm にとってこの戦略がなぜ有効なのかというと、別のアプリケーションで開発およびリファクタリングできるため、他のチームの作業を中断したり、消費者が購入を行う際に影響を与えることがないからです。マイクロフロントエンドをロールアウトする時は、そのページグループのみに影響が限定されるため、リリースのリスクが効果的に限定されます。

Dunelm は最近、製品詳細ページを新しいマイクロフロントエンドアーキテクチャに移行するという重要な目標の達成に成功しました。最初の移行では、60,000 超の品目を掲載する製品詳細ページがダウンタイムなしで正常に移行され、Compute を使用してトラフィックはアプリケーションシェルにルーティングされました。これらのページの最初のデプロイ後、Dunelm がモバイルデバイスで追跡しているすべてのコアウェブサイトの重要指標は、すべての測定で明らかな改善を示し、良好な状態になりました。

Dunelm は、レガシーウェブサイトと比較して、マイクロフロントエンドでは変更にかかる時間とリリースの速度が大幅に改善したことを確認しています。具体的には、パイプライン自体が数倍速くなり、ウェブサイトの変更に要するリードタイムが大幅に短縮されています。平均すると、Dunelm は新しいプラットフォームを通じて、すでにレガシープラットフォームの 2 倍の頻度でリリースしています。これは、ウェブサイトのさらなるセクションが新しいアーキテクチャに移行するにつれて、さらに改善する可能性が高いことを示唆しています。Dunelm が報告した改善の一部は以下のとおりです:

カートに商品を入れる割合が増加
直帰率が低下
1 セッションあたりの収益が増加
CI/CD パイプラインの平均ランタイムはレガシーウェブサイトの約 3 倍に加速
パイプラインの信頼性は 2 倍以上向上し、リリースはMFEで 2 倍に倍増

Dunelm の技術責任者である Warren Fitzpatrick (エンジニアリングチームをリードし、マイクロフロントエンドの移行と実行の指揮を担当) は次のように述べています。

「Dunelm は、今後数年間で製品カタログを大幅に拡充する計画です。この新しいアーキテクチャがあるおかげで、他のページやチームに影響を与えることなく、どのページでも完全に新しいマイクロフロントエンドにルーティングできるため、効率的に無限にスケールできます。私たちは、変化の姿がどうであれ、スケールし、変化の要求に対応できる準備ができていると感じています」。

Dunelm のエンジニアリングおよびアーキテクチャーディレクターである Paul Kerrison は次のように述べています。

「顧客体験の改善、デリバリーの加速化、イノベーションの実現のために『Strangle 移行パターン』を採用することは、極端なアプローチのように思われるかもしれませんが、そうして実現された柔軟性のおかげで、当社のウェブプラットフォームは力強く進化してきています。優れた技術者のチームによって構築されたマイクロフロントエンド、機能フラグ管理、一元化されたコンポーネントの組み合わせにより、Dunelm はホームウェアセクターのリーダーとしての地位を保つばかりでなく、消費者の変化するニーズに適応できるのです」。

まとめ

マイクロフロントエンドアーキテクチャにより、プロジェクトとリリースがデカップリングされているため、変更が他のチームにどのように影響するかをどのチームもあまり心配する必要がないことが分かりました。これにより、イノベーションの障壁が低くなり、チームは変更をより頻繁にリリースできるようになります。

次のステップ:

ビジネスを加速する具体的な方法については、AWS の担当者にお問い合わせください。
参考資料:

タグ: serverless

著者について

Alex McLeman

Alex McLeman は AWS のソリューションアーキテクトです。彼は小売業の事業変革を AWS サービスを用いて支援しています。彼は顧客をサポートし、技術の採用、俊敏性の向上、イノベーションの促進を容易にすることに喜びを覚えています。

Huma Zafar

Huma Zafar は AWS のアソシエイトソリューションアーキテクトです。彼女はビジネスのニーズと目標に合わせてカスタマイズされたソリューションを採用してもらうことで、ビジネスの変革を後押しすることに熱心に取り組んでいます。

Luca Mezzalira

Luca Mezzalira は AWS のプリンシパルソリューションアーキテクトで、グローバルで発言に影響力があり、著作もあります。過去 20 年間で、彼はフロントエンドからクラウドまでのソフトウェアアーキテクチャをマスターし、その時々の仕事のコンテキストに合った適切なソリューションを提供してきました。

Warren Fitzpatrick

Warren Fitzpatrick は Dunelm の技術責任者です。彼は Dunelm Digital Optimization 部門で働き、イノベーションと卓越した技術を生むよう組織を育成する一方で、Dunelm が自らの重要な顧客に対してシームレスでストレスのないショッピング体験を確実に提供できるようにしています。次世代技術に敏感な彼は、進化し続けるデジタルランドスケープにおいて最先端のソリューションを提供するという Dunelm のコミットメントを推進する存在です。

翻訳は PMO 村田が担当しました。原文はこちらです。

Amazon Web Services ブログ