Uber の Domain-Oriented Microservice Architecture

 (eng.uber.com)
20 ポイント 投稿者 xguru 2020-08-03 | 5件のコメント | WhatsAppで共有

DOMA は、2,200 個のマイクロサービスを持つ Uber が、MSA の柔軟性を維持しながら複雑さを減らすために採った方法

  • DDD、SOA、OO、CA などから取り入れ、大規模組織の大規模分散システムに合わせて設計

  • かなり長期間 MSA を運用してきた Uber の豊富な経験が凝縮された記事

DOMA の基本原則

  1. Domain 単位でマイクロサービスをコレクションとしてまとめる

  2. Layer と呼ばれるドメインコレクションを作り、各レイヤー内では依存関係を持てるようにする → Layer Design

  3. 各コレクションに対する単一の入口として、クリーンなインターフェースを提供する Gateway を作る

  4. 各ドメインは他のドメインに対して独立しているべき。ただし、他ドメインのロジックを含める必要がある場合が多いため、これをうまく支える Extension アーキテクチャを提供

** Uber の実装

  • Domains

→ 論理的にグループ化された 1 つ以上のマイクロサービスの集合。

→ ドメインごとにサービスが 10 個以上ある場合もあれば、1 個だけの場合もある

→ 例) 地図検索、料金、マッチングプラットフォーム（ライダーとドライバー）などが 1 つのドメイン

→ 会社の組織構造には従っておらず、Uber の地図関連組織は 3 つのドメイン、80 個のマイクロサービス、3 つのゲートウェイで構成されている

  • Layer Design

→ 「どのサービスが他のサービスを呼べるのか？」への答え

→ 「separation of concerns at scale」または「dependency management at scale」

→ Uber は 5 つの Layer で構成

  1. Infrastructure : すべての組織が使える機能。ストレージ/ネットワーキングなど

  2. Business : ビジネス単位で使える機能。特定の製品カテゴリや Rides、Eats、Freight などの LOB(Line Of Business) に限定されない

  3. Product : 特定の製品カテゴリおよび LOB に関連する機能だが、複数アプリで共通利用する「Request a ride」のようなものも含む

  4. Presentation : ユーザー向けアプリケーション関連機能（モバイル / Web）

  5. Edge : Uber のサービスを外部に安全に公開すること。モバイルアプリケーションとも連携

  • Gateways

→ マイクロサービスの API Gateway と大きくは変わらない。ただし、Domain につながる単一の入口（Single Entry-point）として捉える

→ 内部では外部に対する単一の依存関係を持つことになるため、マイグレーション、ディスカバリー、システム複雑性が全体的に減少

  • Extensions

→ サービスの実装を変更したり安定性に影響を与えたりせずに、ドメインを拡張するメカニズム

  1. Logic 拡張 : Provider または Plugin パターンを使ってサービスロジックを拡張

  2. Data 拡張 : コアデータの肥大化を防ぐために任意データを接続するメカニズム。Protobuf の Any 型を活用

  3. Custom 拡張 : ドメインに合わせて各チームが適切なパターンで拡張

オンボーディング時間を 25〜50% 短縮する効果

2,200 個のマイクロサービスを 70 のドメインに分離した。

Uber ではマイクロサービスの半減期は 1.5 年と算出された。つまり、1.5 年ごとにマイクロサービスの 50% が消える。

ゲートウェイがなければ、こうして消えるたびにマイグレーション地獄が発生する。

Uber では DOMA を使って設計されたプラットフォームの方が、はるかに拡張しやすく、保守もしやすいことが実証された。

他社向けの実践的アドバイス

  • スタートアップ :

→ 「MSA をいつ採用すべきか？」 「自社組織で使う価値があるか？」という問いが重要。

→ MSA は多くのエンジニアがいる組織には運用上の利点があるが、複雑性を増し、機能開発を難しくすることがある

→ 小規模組織では、運用上の利点よりもアーキテクチャ複雑性の増加だけをもたらし、コストが高くなることもある。

→ ゆっくり導入しても問題はなく、MSA に進むと決めたなら「大規模分散プログラム」として捉え、マイクロサービス間を分離すべき。

→ 最初のマイクロサービス群は、ビジネスの中核機能を表す際に重要であり、長く存続するものになる

  • 中規模企業 :

→ 会社が複数チームに分かれ、プラットフォーム間で関心事の分岐が始まると、MSA はより有用になる

→ この段階では、マイクロサービス間の階層構造を検討でき、より多くのサービスが利用されるにつれて依存関係管理が重要になる

→ まだマイクロサービス数は多くないためクラスタリングに意味がないこともあるが、ドメイン指向で考えるのは有用

  • 大企業 :

→ 大規模エンジニアリング組織には数百人のエンジニア、マイクロサービス、依存関係があるため、DOMA は完全に有用

→ ゲートウェイを持つドメインへ容易にグループ化でき、レガシーをリファクタリングまたは再実装する際にもゲートウェイが役立つ

Uber でも DOMA を徐々に多くのチームが導入している。（Uber の全組織から約 60 人が参加して 2 年かけて作られたとのこと）

関連記事

5件のコメント

 
algedian 2020-08-10

https://eng.uber.com/microservice-architecture/

今はちゃんと見られるようですが.. Wayback Machine にあるものでは図が少し違うようです
 
xguru 2020-08-10

あっ、また復活しましたね（笑）。元に戻しておきました。

詳細なサービス名が見えていた図が問題だったようですね。
 
jaeyeonling 2020-08-04

記事は削除されたようですね T.T
 
xguru 2020-08-04

あっ、本当ですね。ひとまず Wayback マシンでは見ることができます。

https://web.archive.org/web/20200803012939/…
 
jaeyeonling 2020-08-04

ありがとうございます :)