BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース リテールモノリスからマイクロサービスへの移行 - Sebastian Gauder氏のMicroXchg Berlinでの講演より

リテールモノリスからマイクロサービスへの移行 - Sebastian Gauder氏のMicroXchg Berlinでの講演より

ブックマーク

原文(投稿日:2019/04/07)へのリンク

ベルリンのMicroXchgで行ったプレゼンテーションの中で、Sebastian Gauder氏は、氏と氏のチームが、ドイツの大企業であるREWEにおいて、それまでの食品小売用モノリスを、270のマイクロサービスからなる複数のビジネスドメインに移行し、チーム数を2から50近くに拡大した方法について解説するとともに、これを可能にするために設定した、さまざまな設計上の目標と規則について論じた。

REWE digitalのソフトウェアアーキテクトであるGauder氏の講演は、2014年に氏らが、2つのチームで既存のモノリスを引き継いだことをきっかけとして、氏らのプロジェクトが立ち上げられた状況を説明することから始まった。20~30チームへの拡大を可能にするため、氏らは、マイクロサービスアーキテクチャへの移行を決定した。しかしこれは、システムに従事するチーム数を増やすことを可能にすることが理由であって、テクノロジの観点からはクールではなかった、と氏は強調した。2016年までに、チーム数は20程度まで増加し、Eコマースプロセス全体をサポートするアプリのリリースが可能になった。2018年になると、48のチームがシステム全体に関与するようになった。これは現在のチーム数でもある。チーム数が増えるに従って、サービスの数も1から270までになった。

マイクロサービスに着手した時、氏らは2つの大きな目標を置いた。

  • 分散化。他のすべてのチームから独立して開発し、デプロイし、運用することの可能な、ソフトウェアの理想的なユニット。
  • 垂直方向のバウンダリ。フロントエンド、バックエンド、データストレージといった技術的レイヤを各サービスが処理することで、各レイヤの技術チームがすべてのサービスで作業することを回避したい、という考えがあった。

アーキテクチャおよびドメインの観点から、氏らはドメイン、サブドメイン、コンテキスト境界といった、ドメイン駆動アーキテクチャ(DDD)の主要な概念を採用した。これらはそれぞれ、共通のプラットフォームをベースとしたサービスを使って実装されている。組織的にはSpotifyのコンセプトを使用して、Tribe(部族)、Squad(部隊)、チームをベースとしている。

Architectural and organisational model

システム内のバウンダリを定義するために、氏らは、顧客の旅行(訳注:REWEはスーパーマーケットおよび観光グループ)にサブドメインを定義し、それを元にEコマース内に、"顧客チェックイン"、"プロダクト検索"、"チェックアウト"、"履行"の4領域を定義した。また最終的に、他のどれにも当てはまらないもののために、共通サブドメインとして、"プロダクト情報"、"バックオフィス"、およびモバイルアプリケーション用のドメインを用意した。

後になって、"履行"サブドメインが大きくなり過ぎていることが分かったため、Eコマースドメインから取り出して新たな"履行"コアドメインを作成し、商品の顧客への提供状況に応じて、商品の入庫、在庫、出庫、顧客への納品という4つのサブドメインを作成した。このドメインにも、マスタデータやバックオフィスといった、いくつかの共通ブロックが用意されている。

与えられた状況の中で、約50チームがそれぞれ、フロントエンドからデータストレージまでのテクノロジスタック全体に取り組む上で重要なのは、すべてのサービスが確実に連携することだ。これを達成するために、氏らは、いくつかの保護規則を作成した。

  • 設計目標(前述)。
  • アーキテクチャの原則。自律性、自動化、通信に関わる9つの基本ルールで構成されている。
  • ガイド。イベント処理やREST、認証といった共通タスクの実行方法を解説している。

自立性の原則には、チームが独立的に開発およびデプロイ可能であることが含まれている。他チームを待機したり、同期を取る必要があってはならない。実装の詳細を他のチームから隠蔽し、障害をサービス内に隔離することにより、 レジリエンスを実現している。各データストレージには必ずひとつのサービスが責任を持たなければならない、という原則もある。

自動化に関する最初の原則は、スケーリングは水平方向に、かつ自動的に実施されなければならない、というものだ。自動化の文化を受け入れて、テストやデプロイ、運用を可能な限り自動化することも必要である。早期かつ頻繁なデプロイも導入しているが、エラー時には迅速にロールバックできなければならない。そのためには、サービスに高度な可観測性が必要になる。

すべてのチームに対して、通信は標準化され、可能な部分については非同期化されている。同期通信にはREST(ハイパーメディアを除く成熟度レベル2)、非同期通信にはKafkaを使用する。Gauder氏は、開発時に学ぶべき3つのレッスンを指摘している。

  • イベントとRESTはAPIの異なるビューであり、どちらも当初から実装されなければならない。イベントもAPIと同様に動作し、互換性を損なう変更は回避する必要がある。
  • 汎用的なAPIを書くのは難しく、モバイルアプリのように、特定のクライアントをターゲットにしたAPIが作成されることが多い。
  • 互換性を損なう変更は、新たなエンドポイントやトピックの導入で解決されなければならない。

すべてのサービスに対するフロントエンドを開発するため、氏らは、各サービスが責務を持つデータを提供する動的構成を採用している。この方法によってデータは、完全に機能するWebページとして構成される。この方法によってチームは、事前にフロントエンドチームからの承諾を待つことなく、新たな機能を自由にデプロイできる、とGauder氏は記している。これを実現したのは、氏らがNode.jsで開発した、Dynamic UI Composition(DUC)コンポーネントだ。リクエストが到着すると、そのロールに対応するテンプレートが読み込まれて、テンプレートに含まれるサービスからのデータが読み出されて、最終的にページが生成されてユーザに返される。これはモノリシックなフロントエンドに比較すると、よりDDDに近いソリューションだと、Gauder氏は考えている。さらに氏は、データの解析の最適化作業とキャッシングを使用した結果、よりパフォーマンスの優れたWebサイトを実現することができた、とも記している。氏らはこの統合パターンをリポジトリに公開するとともに、今年後半にはDUCライブラリをオープンソースにしたいと考えている。

プレゼンテーションのスライドが公開されている。また、カンファレンスのプレゼンテーションの大部分は録画されており、今後数ヶ月中に公開される予定である。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT