Uberのドメイン駆動型マイクロサービスアーキテクチャ

約 transl。：Uber Engineeringの最近の記事では、この大企業がマイクロサービスアーキテクチャの改良版に向けて進んだことについて説明しています。一部のインターネットユーザーは、新しいアプローチを「マイクロサービスにDDDの原則を適用するだけ」と考えていましたが、この記事は開発者コミュニティや他のエンジニアから大きな関心を集めました。そのため、habrのために特別に用意されたロシア語版をご紹介できることをうれしく思います。

前書き

最近、サービス指向アーキテクチャ、特にマイクロサービスアーキテクチャ（MA）の欠点が活発に議論されています。ほんの数年前、独立した展開という形での柔軟性、透過的な所有権、システムの安定性の向上、懸念事項のより良い分離など、多くの利点があるため、多くの人がMAに移行することをいとわなかった。ただし、最近状況が変化しました。マイクロサービスアプローチは、複雑さが大幅に増加する傾向があることで批判され始めており、些細な機能でも実装が困難な場合があります。（これについては、「マイクロサービス：Kubernetesを使用している場合でも、サイズが重要」という講演で話しました-約Transl。）



Uberには現在約2,200の重要なマイクロサービスがあり、このアプローチのすべての長所と短所を自分たちで経験しました。過去2年間、Uberは、アーキテクチャの利点を維持しながら、マイクロサービスランドスケープの複雑さを軽減しようと試みてきました。この投稿では、ドメイン指向マイクロサービスアーキテクチャ（DOMA）と呼ばれるマイクロサービスアーキテクチャへの一般的なアプローチを紹介する予定です。



近年、マイクロサービスアーキテクチャの欠点を批判することは一般的ですが、完全に放棄すべきであるとあえて宣言する人はほとんどいません。それらの運用上の利点はすべて非常に重要です。さらに、このアプローチに代わるものはない（または非常に限られている）ようです。私たちの一般的なアプローチの目標は、MAの柔軟性を維持しながら、システム全体の複雑さを軽減したい組織を支援することです。



この記事では、DOMA、Uberでこのアプローチにつながった課題、プラットフォームおよび製品チームにとっての利点、そして最後に、このアーキテクチャへの移行を検討している人のためのヒントについて説明します。

マイクロサービスとは何ですか？

マイクロサービスは、サービス指向のアーキテクチャの拡張です。 2000年代のかなり大きな「サービス」とは異なり、マイクロサービスは特定の狭いタスクを実行します。これらのアプリケーションはホストされ、ネットワーク経由でアクセス可能であり、明確に定義されたインターフェイスを提供します。他のアプリケーションは、リモートプロシージャコール（RPC）を使用してこのインターフェイスにアクセスします。



MAの重要な特徴は、コードの投稿、呼び出し、および展開の方法です。大規模なモノリシックアプリケーションは通常、明確に定義されたインターフェイスを備えたカプセル化されたコンポーネントに分割されます。これらのインターフェイスは、ネットワーク経由ではなく、プロセス内から直接呼び出されます。この意味で、マイクロサービスは、その関数のいずれかを呼び出すときに、パフォーマンスが低い一種のライブラリと見なすことができます（ネットワークの遅延と時間のシリアル化/逆シリアル化への影響のため）。



このようにマイクロサービスを考えると、なぜマイクロサービスアーキテクチャが必要なのか疑問に思うかもしれません。この質問に対する古典的な答えは、個々のコンポーネントを個別に展開し、それらを簡単にスケーリングできるためです。..。大規模なモノリシックアプリケーションの場合、組織はすべてのコードを同時に展開またはリリースする必要があります。その結果、新しいバージョンごとに多くの変更が加えられています。展開にはリスクと時間がかかります。間違いがあると、システム全体がダウンする可能性があります。



したがって、企業はパフォーマンスを犠牲にしながら使いやすさのためにマイクロサービスに移行しています。また、マイクロサービスに必要なインフラストラクチャを維持するための追加コストも負担する必要があります。経験によれば、多くの状況でそのような妥協は理にかなっています。同時に、それはMAへの時期尚早な移行に対する強力な議論です。

動機

マイクロサービスへの移行時（2012年から2013年頃）、Uberには2つの主要なモノリシックサービスがあり、マイクロサービスが正常に解決できる多くの運用上の問題に直面しました。

• 可用性のリスク。モノリスのコードベースに誤りがあると、システム全体（この場合はUber全体）がドロップする可能性があります。
• リスクとコストのかかる展開。それらは実行するのが非常に難しく、しばしば前のバージョンにロールバックしなければなりませんでした。
• 責任範囲の分離が不十分。巨大なコードベースで誰が何を担当したかを追跡することは非常に困難でした。指数関数的な成長に伴い、急いでロジックとコンポーネントの間の境界線がぼやけることがありました。
• 非効率的な作業。上記の問題が合わさって、チームが独立して、または互いに独立して作業することが困難になりました。

言い換えれば、Uberのエンジニア数が数十人から数百人に増加し、テクノロジースタックの独自の部分を所有する多数のチームが出現したことを背景に、モノリシックアーキテクチャはこれらのチームの運命をますます結び付け、チームが独立して作業することを許可しませんでした。



そのため、MAに切り替えることにしました。その結果、私たちのシステムはより柔軟になり、チームはより自律的になることができました。

• システムの信頼性。MAへの移行に伴い、システム全体の信頼性が向上します。個々のサービスは、システム全体をクラッシュさせるリスクを冒すことなく、クラッシュする可能性があります（以前のバージョンにロールバックすることもできます）。
• . - : « ?», — .
• . , . , , , , .
• . .
• . .

MAがなければ、Uberは現在の規模と品質レベルに到達できなかったと言っても過言ではありません。



しかし、会社が成長を続け、エンジニアの数が数百人から数千人に増えるにつれて、システムの大幅な複雑化に関連する多くの問題に気づき始めました。 MAの場合、機能がいつでも変更されて予期しない動作が発生する可能性がある多数の「ブラックボックス」と引き換えに、単一のモノリシックコードベースを犠牲にします。



たとえば、エンジニアは問題の根本を突き止めるために、12の異なるチームにわたって約50のサービスを分析する必要がありました。



サービス間の依存関係を理解することは、サービスが多くのレベルで相互に作用する可能性があるため、非常に困難になる可能性があります。 n番目の依存関係の遅延が急増すると、アップストリームサービスで問題が発生する可能性があります。さらに、適切なツールがなければ、何が起こったのかを理解することは不可能です。これらすべてがデバッグを非常に困難にします。





Jaegerによる2018年半ば現在のUberのマイクロサービスアーキテクチャ



最も単純な機能を実装するために、エンジニアは多くの場合、多くのサービスを操作する必要がありますが、完全に異なるチームと人々がそれらに責任を負います。その結果、チームワーク、会議、設計コンサルテーション、およびコードレビュー（コアレビュー）の整理に多くの時間が費やされます。チームが継続的に互いのサービスに侵入し、データモデルを変更し、さらにはサービス所有者に代わって展開するにつれて、所有権の透明性の最初の利点は徐々に曖昧になっています。これにより、サービスが独立しているように見えるネットワークモノリスを作成できますが、実際には、安全に変更を加えるには、サービスを一緒に展開する必要があります。





簡単に統合できる10個のタッチポイントを備えたUber（〜2018）のこのような複雑なシステムの例（DOMAの前でも）。



その結果、開発プロセスの速度が低下し、サービスオーナーが不安定になり、移行に時間がかかるなどの問題が発生します。残念ながら、すでにMAに切り替えた組織には後戻りはありません。この状況は、「彼らと一緒に暮らすことは不可能であり、彼らを撃つことはできない」というよく知られたフレーズによって完全に説明されています。

ドメイン固有のマイクロサービスアーキテクチャ

マイクロサービスをI / Oリンクライブラリと考え、マイクロサービスアーキテクチャを巨大な分散アプリケーションと考えてください。この場合、よく知られたアーキテクチャソリューションを使用して、コードを整理する最善の方法を考えることができます。



したがって、ドメイン指向のマイクロサービスアーキテクチャ（DOMA）は、ドメイン指向の設計、クリーンアーキテクチャ、サービス指向のアーキテクチャ、オブジェクト指向およびインターフェイス指向の開発パターンなど、確立されたコード編成方法に依存できます。DOMAは、大規模な組織のグローバルに分散されたシステムで既存の設計原則を活用する比較的新しい方法であるという意味で革新的であると考えています。



DOMAの基本的な概念と関連用語は次のとおりです。

1. 個々のマイクロサービスではなく、それらのグループを調べています。そして、それらをドメイン （ドメイン）と呼びます。
2. 次に、いわゆるレイヤー （レイヤー）のドメインを結合します。ドメインが属するレイヤーによって、そのドメインのマイクロサービスで使用できる依存関係が決まります。結果として得られるマルチレイヤーの アーキテクチャーを（レイヤーデザインの）と呼びます。
3. , . (gateways).
4. , , , 'hardcode' , . (, - ), (extension architecture) .

言い換えると、構造化アーキテクチャ、ドメインゲートウェイ、および事前に構築されたDOMA拡張ポイントは、マイクロサービスアーキテクチャを、複雑なものから具体的で具体的なもの、つまり柔軟で再利用可能な階層型コンポーネントの構造化されたセットに変換します。



この記事の残りの部分では、UberによるDOMAの実装とその利点に焦点を当てます。このアプローチを採用したい企業にも実践的なアドバイスが提供されます。

Uberでの実装

ドメイン

Uberドメインは、機能の論理的な組み合わせに基づいてリンクされた1つ以上のマイクロサービスのコレクションです。ドメインの大きさという疑問が自然に生じます。この場合、指示はありません。一部のドメインには数十のサービスを含めることができ、その他のドメインには1つだけを含めることができます。ここでは、各関連付けの論理的な役割について慎重に検討することが重要です。たとえば、地図上の検索サービス、運賃サービス、選択サービス（運転手と乗客の比較）を別々のドメインにグループ化しました。さらに、彼らは常に会社の組織構造を繰り返すわけではありません。Uber Mapsは3つのドメインに分割され、80のマイクロサービスが3つの異なるゲートウェイの背後に隠されています。

レイヤーベースのアーキテクチャ

多層アーキテクチャは、MAUberの境界内でどのサービスとどのサービスが通信できるかという問題に答えます。つまり、責任範囲のグローバルな分散、またはグローバルな依存関係管理のメカニズムと見なすことができます。



階層化されたアーキテクチャは、障害後の損傷の範囲を理解し、依存するサービスUberの数に関する製品の特異性を反映するのに役立ちます。あなたに下から上へと移動し、障害が発生した場合に影響を受けるサービスの数が減少し、アプリケーションが狭くの製品の範囲れます。逆に、より多くのサービスが下位レベルの機能に依存しているため、障害の結果としての損傷の範囲は原則として大きくなり、解決されるビジネスタスクの範囲は広くなります。次の図は、この概念を示しています。





上位レベルは特定の（狭い）ユーザーエクスペリエンスを担当する機能（モバイル機能など）に焦点を当てており、下位レベルにはよりグローバルなビジネス機能（アカウント管理やライドシェアリングマーケットプレイスの移動など）が存在することを想像できます。 ..。各レイヤーは、下にあるレイヤーのみに依存します。これにより、爆風半径やドメイン統合などの概念が明確になります。



このグラフでは、機能が狭いものから広いものへと下に移動することがよくあることに注意してください。要件が進化するにつれて、時間の経過とともにより重要になる（「プラットフォーム」）いくつかの単純な機能を想像することができます。実際、この種の下方移行が予想され、Uberのコアビジネスプラットフォームの多くは、ドライバーまたは乗客向けの機能として始まり、時間の経過とともに成長し、新しいビジネスライン（UberEatsやUberFreightなど）としてより一般化されました。 ）そしてより多くの依存関係をそれらに接続します。



Uber内では、次の5つのレベルを区別します。

1. . , . — Uber , .
2. -. , Uber , , Rides (), Eats ( ) Freight ( ).
3. . , , . , «request a ride» ( ) , Rides: Rider, Rider «Lite», m.uber.com, ..
4. . , (/), .
5. . Uber . .

ご覧のとおり、後続の各レベルは、機能のグループ化がますます狭くなり、ヒット半径が小さくなっています（つまり、このレイヤー内の機能に依存するコンポーネントが少なくなっています）。

ゲートウェイ

APIゲートウェイという用語は、マイクロサービスアーキテクチャですでに十分に確立されています。私たちの定義は、定評のある定義とそれほど変わりません。ただし、ゲートウェイを、対応するサービスグル​​ープ（ドメインと呼びます）への単一のエントリポイントと見なす傾向があります。ゲートウェイの成功は、適切に設計されたAPIアーキテクチャに依存します。





この図は、ゲートウェイの高レベルの設計を示しています。ドメインの内部構造の詳細（一連のサービス、データを含むテーブル、ETLパイプラインなど）から抽象化します。他のドメインは、インターフェイスにのみアクセスできます。メッセージングシステムでのリモートプロシージャ呼び出し、イベント、および要求用のAPIです。



アップストリームコンシューマーは1つのサービスでのみ実行されるため、ゲートウェイは、アップストリームサービスの依存関係が1つしかない場合（複数のダウンストリームサービスに依存するのではなく）、将来の移行、検出可能性、およびシステムの複雑さの全体的な削減という点で多くの利点を提供します。ドメインに存在する可能性があります）。OO設計の観点から見ると、ゲートウェイはインターフェイス定義であり、内部の「実装」（つまり、マイクロサービスのグループ）を使用して必要なことを実行できます。

拡張機能

拡張機能（拡張機能）は、その名前が示すように、ドメインを拡張するためのメカニズムです。このようなアドオンの基本的な定義は、サービスの内部を変更したり、全体的な信頼性に影響を与えたりすることなく、サービスの機能を拡張するためのメカニズムを提供することです。Uberには、ロジック （ロジック拡張）とデータベース （データ拡張）の2つの拡張モデルがあります。拡張コンセプトにより、複数のチームが互いに独立して作業できるようにアーキテクチャを拡張できました。

論理拡張

論理拡張は、サービスの基礎となるロジックを拡張するためのメカニズムを提供します。それらについては、サービスごとに個別に定義されたインターフェイスを備えた一種のプロバイダーまたはプラグインパターンを使用します。これにより、チームはインターフェイスのみを使用し、メインのプラットフォームコードに干渉することなくロジックを実装できます。



たとえば、ドライバーがオンラインであるとします。通常、さまざまなチェックを行って、オンラインステータス（セキュリティ、コンプライアンスなど）が許可されていることを確認します。それぞれに独自のチームがあります。これを行う1つの可能な方法は、各コマンドに同じエンドポイントでロジックを書き込むように強制することですが、これにより複雑さが増す可能性があります。各チェックには、異なる（そして完全に無関係な）ロジックが必要になります。オンラインにする



という論理エンドポイント拡張の場合各拡張機能が事前定義された要求および応答タイプに準拠することが期待されるインターフェースを定義します。各チームは、このロジックの実装を担当する拡張機能を登録します。この場合、ドライバーに関する情報を取得して論理値（bool）を返すだけで、ドライバーがオンラインステータスに「値する」かどうかを判断できます。そして、エンドポイント自体（オンラインになる）は、これらの回答を単純に繰り返し、それらのいずれかが偽であるかどうかを確認します。



このアプローチは、コアコードを拡張機能から分離し、それらを分離します。ただし、拡張機能は、実行されている他のロジックを認識していません。これにより、可観測性や機能のフラグ付けなど、追加の機能を簡単に作成できます。

データ駆動型拡張機能

このタイプの拡張機能は、基盤となるプラットフォームのデータモデルが不必要に肥大化するのを防ぐために、任意のデータをインターフェイスに添付するためのメカニズムを提供します。データ拡張では、ProtobufのAnyなどの機能を積極的に使用して、リクエストに任意のデータを追加できるようにします。多くの場合、サービスはこのデータを保存したり、論理拡張に渡したりするため、メインプラットフォームは、この任意のコンテキストについて逆シリアル化することはありません（したがって、何も「認識」しません）。どの実装でも、より強力な型指定と引き換えに、インフラストラクチャのオーバーヘッドが発生します。より簡単な代替手段は、任意のデータを表すJSON形式です。

任意の補足

ブール拡張とデータ拡張に加えて、Uberの多くのチームは、ドメインに一致するカスタム拡張テンプレートを開発しました。たとえば、プレゼンテーションアーキテクチャに関連する統合のほとんどは、DAGベースのタスク実行ロジックを使用します。

利点

DOMAは、ほぼすべての主要なUberビジネスにある程度影響を与えてきました。過去1年間、私たちは主にビジネス層に焦点を当ててきました。これは、企業のさまざまな事業分野に一般化されたロジックを提供します。



DOMAはUberにとって比較的新しいものであり、将来的には、より多くの情報とアーキテクチャの例を確実に共有する予定です。最初の結果は心強いものでした。開発者の作業が大幅に簡素化され、システムの全体的な複雑さが軽減されました。

製品とプラットフォーム

DOMAは、Uberのさまざまな製品チームとプラットフォームチーム間の共同作業の結果です。多くの場合、プラットフォームのサポートコストは大幅に減少しています。製品チームは、特異性と加速された開発の恩恵を受けています。



たとえば、拡張アーキテクチャの初期のプラットフォームコンシューマーは、コードのレビュー時間を短縮し、スケジュールを設定し、消費者教育を加速することで、新機能の優先順位付けと統合にかかる時間を3日から3時間に短縮できました。

複雑さの軽減

以前は、製品チームはドメイン内の多くのダウンストリームサービスと連携する必要がありましたが、現在は1つを呼び出すだけで済みます。新機能を導入する際のタッチポイントの数を減らすことで、実装時間が25〜30％短縮されました。さらに、70のドメインに2,200のサービスを配布することができました。それらの約半分は実装されており、大部分は何らかの形で実装する計画があります。

将来の移行

Uberでは、マイクロサービスの半減期は1。5年であると計算しています。言い換えれば、毎年半年、私たちのサービスの50％が関連性を失っています。ゲートウェイがないと、マイクロサービスアーキテクチャは移行の地獄になる可能性があります。絶えず変化するマイクロサービスには、絶え間ないアップストリームの移行が必要です。ゲートウェイを使用すると、チームはダウンストリームドメインサービスへの依存を回避できます。つまり、これらのサービスはアップストリームに移行しなくても変更できます。



過去1年間のUberの最大のプラットフォームアップグレードの2つは、ゲートウェイの背後で発生しました。これらのプラットフォームには何百もの依存サービスがあり、ゲートウェイがなければ、既存のすべての消費者を移行する必要があります。それは信じられないほど高価であり、プラットフォームの完全な再設計を非現実的にします。

新しい業種と製品

DOMAベースのフレームワークは、はるかに拡張性が高く、保守が容易であることが証明されています。DOMAに切り替えたUberのほとんどのチームは、新しい事業を維持するには費用がかかりすぎたために切り替えました。

実用的なアドバイス

このセクションでは、DOMAに関心があるかもしれない企業のためのいくつかの実用的なヒントをまとめました。ここでの指針となる原則は、私たちの経験では、成熟した思慮深いマイクロサービスアーキテクチャは、適切なタイミングで適切な方向に段階的にシフトすることに基づいているということです。実際には、MAを完全に「書き換える」ことはほとんど不可能です。



したがって、MAの進化は、「ヘッジを切る」一種のプロセスと見なされます。そのおかげで、MAは、1回限りの自発的な取り組みではなく、正しい方向に成長します。それは動的で段階的なプロセスです。

スタートアップ

ここでの重要な質問は、「いつMAに移行する必要があるか」です。および「これは私たちの組織にとって意味がありますか？」上で見たように、マイクロサービスは多数のエンジニアがいる組織で運用上の利点を提供しますが、全体的な複雑さを増し、新しい機能の実装を困難にする可能性もあります。



小規模な組織では、運用上の利点がアーキテクチャの複雑さの増大を補う可能性はほとんどありません。さらに、MAは通常、それらをサポートするために専用のエンジニアリングリソースを必要とします。これは、初期段階の企業には高すぎるか、優先順位付けの点で単に最適ではない可能性があります。



そうは言っても、マイクロサービスへの移行をしばらく延期するのが賢明かもしれません。組織がマイクロサービスに切り替えることを決定した場合は、大規模な分散アプリケーションのアナロジーを使用し、問題領域をサービス間で分割することを事前に検討することをお勧めします。また、最も初期のマイクロサービスは、ビジネスの重要な部分を説明しているため、最も重要で長寿命である可能性が高いことにも注意してください。

ミディアムビジネス

MAの有用性は、多くのチームを持つ中規模の企業で増加します。中規模の企業では、さまざまな機能やプラットフォーム間で責任の境界線が徐々に曖昧になっています。



ここから、マイクロサービスの階層について考え始めることができます。一部のサービスはビジネスの運営にとってはるかに重要になり、より多くのチームがそれらに依存するようになるため、依存関係の管理が前面に出てくる可能性があります。



プラットフォームへの初期の投資は、後で配当を支払うことができます。他の製品に依存しないビジネスプラットフォームを作成することで、技術的な負債の蓄積や、プラットフォームのメインサービスへの任意の製品ロジックの浸透を回避できます。おそらく、この目標を達成するために、この段階で拡張メカニズムを導入する必要があります。



マイクロサービスの数がまだ少ないことを考えると、それらを一緒にバンドルすることはまだ意味がないかもしれません。ただし、ここで注目に値するのは、UberでのDOMA実装のコンテキストのドメインには、単一のサービスが含まれている可能性があるため、「ドメイン指向」の一連の思考が害を及ぼすことはありません。

大企業

大規模なエンジニアリング組織には、何百ものスペシャリスト、マイクロサービス、および多くの依存関係があります。DOMAがその潜在能力を最大限に発揮するのは、このような状況です。確かに、そのような企業には、ゲートウェイが前にあるドメインに簡単に組み合わせることができるマイクロサービスの明らかなクラスターがあります。レガシーサービスでは、多くの場合、リファクタリング/書き換えとその後の移行が必要です。これは、ゲートウェイが移行の容易さの点でまもなく真のメリットをもたらし始めることを意味します（もちろん、ゲートウェイがすでに展開されている場合）。



透過的で理解しやすい階層の重要性も高まります。一部のサービスは特定の機能または機能のグループの「製品」になり、他のサービスは複数の製品をサポートして「プラットフォーム」として機能します。この段階では、プラットフォームチームへの多大な運用上のストレスを回避し、グローバルシステムの不安定性のリスクを最小限に抑えるために、任意の製品ロジックをプラットフォームから分離しておくことが重要です。

最終的な考え

Uberでは、より多くのチームがDOMAに移行するにつれて、積極的にDOMAを開発し続けています。 DOMAの背後にある主な考え方は、マイクロサービスアーキテクチャは1つの大きな分散プログラムにすぎないということです。そして、他のソフトウェアと同じ原則をその進化に適用することができます。 DOMAは、これらの原則について実践的に考えるための単なるアプローチです。お役に立てば幸いです。フィードバックをお待ちしております。



DOMA自体は、Uber全体からの60人近くのエンジニアによる機能横断的な取り組みの結果です。過去2年間、この作業に貢献してくれた以下の人々に特に感謝します。



Alex Zylman、Alexandre Wilhelm、Allen Lu、Ankit Srivastava、Anthony Tran、Anupam Dikshit、Anurag Biyani、Daniel Wolf、Deepti Chedda、Dmitriy Bryndin、Gaurav Tungatkar、Jacob Greenleaf、Jaikumar Ganesh、Jennie Ngyabuae、Joeoshier 、Kusha Kapoor、Linda Fu、Madan Thangavelu、Nimish Sheth、Parth Shah、Shawn Burke、Simon Newton、Steve Sherwood、Uday Kiran Medisetty、Waleed Kadous



謝辞：この作業は、業界の多くの既存の設計パターンを組み合わせてUberの問題を解決し、いくつかの新しいパターン（拡張機能など）も提案しました。私たちはそれらに取り組んでくれた業界に感謝しています。また、Superblocksの経験を私たちと共有してくれたLinkedinのエンジニアにも感謝します。

翻訳者からのPS

私たちのブログも読んでください：

• «: , Kubernetes»;
• « 2018 ».