免責事項。 この記事は完全にUberの公開情報 — エンジニアリングブログ、カンファレンス講演、オープンソースリポジトリ、外部のケーススタディ — に基づいています。Uberの公式アーキテクチャドキュメントではありません。私たちは、4000サービスのスタックがC4モデルでどのように読みやすくできるかを示すために、公開されている内容をモデル化します。詳細がUberから明示されたものではなく推測である場合は、その旨を述べます。

ライドの解剖学:UberをArchylでC4モデリングする

雨の金曜日の夜、午後7時23分のマンハッタン。ライダーがUberXを呼ぶをタップする。8秒後、0.4マイル先のドライバーがライドを受諾し、ETAが計算されレンダリングされ、料金がロックされ、支払いが事前承認され、ライダーとドライバーの間で低レイテンシのリアルタイムチャネルが開く。彼が電話から目を上げる頃には、車はすでに彼の方へ動き始めている。

その単一のタップは、600以上の都市で1日3000万回以上繰り返され、ドライバーの画面にフレームゼロが届く前に、何十ものUberシステムと3つの外部ネットワークを通過する。

2024年、Uberのスタックは約4,000のマイクロサービスを稼働させ、モバイルクライアントへのピークで毎秒100万リクエストをはるかに超える量を処理し、独自のクラスタマネージャー上でコンピュートをスケジュールし、独自のMySQL派生ストレージレイヤで状態を永続化し、独自の六角形グリッドで地球をインデックス化し、独自のステートマシンエンジンで何百万ものトリップワークフローをオーケストレーションし、独自のMLプラットフォームでETAモデルを訓練していた。

これほど多くの可動部品を持つスタックをどう理解するか?StripeやNetflixのように、一度には理解しない。それこそがC4モデルが解決するために発明された問題だ。

この投稿では、1つのユーザーアクション — タップからドライバーが受諾するまでのライドリクエスト — を追い、Uberのアーキテクチャを4つのC4レベルで横断する様子を見る。すべての製品をカバーするわけではない。1つのライドを追跡し、途中で出会う選択を説明するADRを書き、各ボックスを所有するチームのマップで終わる。途中で、この種のモデル — そしてその周辺のポリシー — を実際にメンテナンス可能にするために、Archylが提供するすべての機能をツアーする。

レベル1 — システムコンテキスト:3つのプラットフォーム、1つのMarketplace

Uber C4 システムコンテキスト:Mobility, Delivery, Freight, Marketplace

システムコンテキストレベルでは、Uberは「配車アプリ」ではない。共有されたMarketplaceと横断的なFoundationシステムのスタックの上に座る3つのプロダクトプラットフォームだ:

  1. Mobility — UberX、Uber Black、Uber Pool、Uber Reserve、Comfort、SUV、Premier、タクシーパートナーシップ
  2. Delivery — Uber Eats(食事)、Uber Direct(サードパーティのdelivery-as-a-service)、Postmates、アルコール、食料品
  3. Freight — 長距離トラック輸送、Uber Freight Loadbuilder、ブローカーツール

その下、Marketplaceプラットフォームが実際の頭脳だ — マッチングエンジン、ディスパッチオプティマイザー、ダイナミックプライシングシステム、需給フォーキャスター。Marketplaceがライドリクエストをライドにする。

すべての下にFoundationプラットフォームが座る:Maps(ルーティング、ETA、距離/時間マトリックス、トラフィック)、Payments、Identity & Risk、Communications(プッシュ、SMS、アプリ内メッセージ)、Notifications、MLプラットフォーム(Michelangelo)、Workflowエンジン(Cadence/Temporal)、Storageプラットフォーム(Schemaless、Docstore、Cassandra、RocksDBベースのストア)、Streamingプラットフォーム(Kafka、uReplicator、Flink)、Observabilityスタック(M3メトリクス、Jaegerトレーシング、ELKログ)、Computeプラットフォーム(歴史的にMesos + Aurora → Peloton → 今日はKubernetesベース)。

その周りに外部アクター:ライダー、ドライバー、eaters、配達員、マーチャント、シッパーとキャリア、地図プロバイダー(自社+フォールバック用サードパーティ)、決済ネットワークとアクワイアリング銀行、身元確認プロバイダー、SMSと音声のための通信キャリア、クラウドプロバイダー(Uberはハイブリッドで動く:自社データセンター+特定ワークロード用のAWS/GCP)、都市レベルの規制当局。

3つのプロダクトプラットフォーム。1つのMarketplace。10のFoundationプラットフォーム。それ以外はすべて詳細だ。

これがレベル1の贈り物:システムコンテキストでは、Mobilityが200のマイクロサービスであることを知る必要はない。それが存在し、Marketplaceと話し、MarketplaceがMapsと話し、Cadenceがその下で長いトリップワークフローをオーケストレーションすることを知る必要がある。図は会話の出発点であり、目録ではない。

Archyl機能。 Archylのシステムコンテキスト図は、自動レイアウト、コンテナへのクリックスルーナビゲーション、サブセットをミュート/ハイライトできるオーバーレイ(例えば「Foundationプラットフォームのみ表示」)を備えた単一のC4レベル1ビューだ。外部アクターは独自のタイプを持つ第一級のC4要素なので、はっきりとレンダリングされる。

ADR-001 · 地理空間インデックス用のH3六角形グリッド

ステータス · 受諾(2018、オープンソース化、2026年も依然アクティブ)

コンテキスト · Marketplaceのマッチングエンジンは「どのドライバーがこのライダーの近くにいるか?」をミリ秒で、都市規模のコンカレンシーで答えながら、サージゾーン、ETA、サプライフォーキャスティングのような分析もサポートしなければならない。古典的な選択肢は矩形タイリング(Z-order、geohash、GoogleのS2セル)だったが、矩形にはこのドメインに対する根本的な欠陥がある:各矩形は複数の近隣距離を持つ — 角は辺より遠く、不均等な距離近似と非対称な「近くに何があるか」クエリを生む。

決定 · 代わりに地球を六角形でタイリングする。大陸スケールから~1m²までの16解像度の階層的な六角形グリッド(H3)を構築する。各六角形は6つの等距離隣接を持ち、最近傍とリングクエリを対称的かつ高速にする。パートナーとUberエンジニアが同じグリッドを共有できるよう、ライブラリをオープンソース化する。

結果 · H3はMarketplace、Maps、ETA、サージ、分析を横断するUberの空間プリミティブになった。同じH3Indexがディスパッチホットパスとオフラインフォーキャスティングジョブで使われる。Foursquare、DoorDash、AT&T、無数のジオスタートアップで使われる、Uberで最も成功したオープンソースプロジェクトの一つでもある。六角形が綺麗にタイリングできない数少ないケース(20面体の12個の五角形アンカー)は文書化され、本番コードで回避される。

Archylでは、これがADRが場所を獲得する方法だ:境界がなぜそのような形なのかを説明する。地理空間状態に触れる任意のコンテナをクリックすれば、H3 ADRはワンクリック先にある。

Archyl機能。 ArchylのADRは特定のC4要素にリンクされた第一級のレコードだ。関連するボックス上にカードとして表示され、ステータス(proposed、accepted、deprecated、superseded)でフィルタ可能で、コードと並んで生きるようYAMLとしてgitに送られる。2030年に誰かがH3の置き換えを提案するとき、既存のADRが関連コンテキストとして自動的に表示される。

レベル2 — コンテナ:Marketplaceのディスパッチパスをズーム

Uber C4 コンテナ:Marketplaceディスパッチ内部

ライダーのタップはAPIエッジに着地する。箱を開けてみよう。

ディスパッチパスは以下のようなコンテナを通過する:

  • Edgeゲートウェイ — 歴史的にはTChannel + Thrift IDL、今日はモバイルクライアント向けのgRPC + HTTP/2エッジ。auth、レート制限、リクエスト整形、ルーティングを行う。
  • Tripオーケストレータ — 長寿命のCadence/Temporalワークフローとして動作。トリップは決定論的状態遷移を持つワークフローインスタンスだ:requested → matched → arriving → on-trip → completed。冪等リトライとタイマー駆動のエスカレーションは組み込みプリミティブで、bespokeコードではない。
  • マッチングエンジン(DISCO) — 実際のマーケットプレイスオプティマイザー。ライダーリクエストといくつかのH3リング距離内のライブドライバーサプライを与えると、各ティックで制約付き割り当て問題を解く。
  • 動的価格設定サービス — リアルタイムサプライ/デマンドシグナルを組み合わせて、H3セルごとのサージ乗数を計算する。リクエスト時にロックされる料金見積もりを出力。
  • ETAサービス — ルート、トラフィック、到着予測のためにMaps + MLモデルを供給。UberのETAモデルは2018年頃にディープラーニングに移行し、それ以来毎年改良されている。
  • Mapsプラットフォーム — Uber自社のルーティングエンジン、距離マトリックスサービス、トラフィック取り込みパイプライン。一部の市場では外部地図プロバイダーにフォールバック。
  • Driver stateサービス — 各ドライバーの現在の状態(オフライン、オンライン、トリップ中)、位置、受諾行動を追跡。カスタムジオストア経由でホットパスの位置データを読み書き。
  • Schemaless / Docstore — UberのMySQLバックエンドのシャードストレージ。Schemalessは古い方;Docstoreは新しい、マルチリージョン、トランザクショナルな後継者。トリップ状態、支払い、ユーザープロファイル、ほとんどのライン・オブ・ビジネスデータがここに住む。
  • Kafkaクラスタ — 各状態遷移はイベントを発行する。Marketplaceは分析のために購読;ダウンストリームサービスはファンアウト(通知、不正、会計)のために購読。
  • リアルタイムチャネル — マッチング後、位置更新とチャットのためのライダーとドライバーアプリ間の低レイテンシ双方向チャネル。下にlong-poll/WebSocketゲートウェイとKafkaが支える。

このレベルの技術スタック:Goがほとんどの新しい高スループットサービス、Javaが古いマーケットプレイスコード、PythonがMLパイプラインとopsスクリプト、Node.jsが一部のエッジレイヤ、gRPCが現代的RPCプロトコル(TChannel/Thriftが前任者)、CassandraとRedisがホットパスレイテンシ、MySQLがSchemaless/Docstoreの下、Hadoop/HDFS/Hive/Prestoがデータウェアハウス、Spark/Flinkがバッチ&ストリーミングコンピュート。

典型的なライドリクエストはEdgeゲートウェイ → Tripオーケストレータ(Cadence) → マッチングエンジン(DISCOがDriver stateに対するH3リングクエリ) → 動的価格設定 → ETA → 通知ファンアウト(ドライバーへプッシュ) → driver-acceptコールバック → リアルタイムチャネル確立、に触れる。すべてリトライ付きで、Jaeger経由でエンドツーエンドに計装され、M3経由で計測される。

Archyl機能。 コンテナレベル図は各コンテナ、そのタイプ(api / service / database / message_queue / cache / worker / gateway / library / infrastructure)、その技術(組織ごとの技術カタログから取得)、ラベル付き関係を示す。APIコントラクトは任意のコンテナに添付され、インラインでレンダリングできる — UberはトリップオーケストレーションのためのgRPC .protoをTripオーケストレータコンテナに直接リンクするだろう。

ADR-002 · Cadence(Temporal) — ワークフローエンジンを構築し、ステートフルマイクロサービスを積み上げない

ステータス · 受諾(~2017、Cadenceとしてオープンソース化;Temporalとしてスピンオフ)

コンテキスト · 2017年までに、Uberは長時間実行のステートフルなビジネスプロセスを実装する数百のマイクロサービスを持っていた — トリップ、注文、サインアップフロー、ドライバーオンボーディング、不正レビュー。それぞれが独自のアドホックなステートマシンを、タイマー、リトライ、冪等性、リカバリコードと共に育てていた。結果:すべてのチームが分散システム税を支払い、障害は頻繁にリトライ/タイムアウトロジックの微妙なバグから来た。

決定 · 各チームにステートマシンを発明するよう求めない。決定論的リプレイ、永続的タイマー、自動リトライ、シグナル処理、ワークフローコードがシーケンシャルなビジネスロジックのように読める汎用ワークフローエンジンを構築する。Cadenceとしてオープンソース化。トリップ、サインアップ、不正レビュー、資金移動ワークフローを数年かけて移行。

結果 · Cadence(およびそのフォークTemporal、現在Uber内外で使用)はUberのすべての長時間実行ステートフルフローの基板となった。「トリップはワークフロー」抽象化は、何千行ものbespokeリトライコードを少数の十分に型付けされたアクティビティに崩壊させる。エンジンはまた業界で最も採用されたオープンソースワークフロープロジェクトの一つになった。パスデペンデントの教訓:10のチームが独立して同じプリミティブを再実装しているとき、プリミティブを構築せよ。

Archyl機能。 Cadenceのような決定はモデル全体に波及する。ArchylではADRは複数のC4要素を同時にリンクできる — 1つの決定、多くの影響を受けるボックス。モデル全体で「workflow」を検索すると、Cadenceコンシューマーとして注釈された各コンテナが浮上する。

レベル3 — コンポーネント:マッチングエンジンの内部

Uber C4 コンポーネント:DISCOマッチングエンジン

Uberのスタックのすべてのコンポーネントの中で、マッチングエンジン — 内部的にはDISCO — はカンファレンス講演とエンジニアリング投稿で最もよく文書化されている。

単一のライドリクエストがマッチングエンジンに到達すると、これらのコンポーネントを通過する:

  1. Request normalizer — ライダーの座標を複数の解像度のH3インデックスに変換する(典型的にはホットパス用のres 9、リング拡張用のres 6)。
  2. Supply scanner — 初期H3リング(~500m)内のすべての適格ドライバーについて、ライブドライバー状態インデックスをクエリ。車両タイプ、ドライバー受諾率、最近の拒否行動でフィルタ。
  3. Ring expander — 内側のリングに適格なドライバーが存在しない場合、候補セットが形成されるか最大距離の境界に達するまで、同心円状のH3リングで外側に拡張する。Uberはこの拡張戦略の複数のイテレーションを発表しており、ドライバーの可能性のある経路を予測するMLドリブンの拡張も含む。
  4. Candidate ranker — 各候補をピックアップまでのETA、マーケットプレイス効率(このドライバーをこの近隣に保ちたいか?)、このライダー/ドライバーペアの過去の受諾確率でスコア付け。
  5. Assignment solver — マッチング問題をローカルサプライプール上の制約付き最適化として定式化。ソルバーは継続的に動作し、貪欲な最初最良マッチにコミットせず、近くのリクエストをバッチ処理する。
  6. Notification dispatcher — マッチした候補に短い受諾ウィンドウのプッシュ通知を送る。受諾/拒否をdriver-stateに記録。
  7. フォールバックパス — ソルバータイムアウトまたは適格な候補がない場合、緩和された制約(より広い車両タイプ、より長いETA)でリトライ、またはサージへエスカレーション。

パターンは見れば残酷なほどシンプル:すべての空間クエリはH3リング;すべてのビジネス決定はスコア付きの候補;すべてのマッチはローカル貪欲決定ではなく、グローバルソルバー実行の出力。この形は、ナイーブなディスパッチシステムを悩ませる「最初のドライバーが料金をつかむ」アンチパターンのクラス全体を排除する。

これがコンポーネントレベルC4の見た目だ:「ここにコードがある」ではなく、「ここにビジネス的に意味のあるプリミティブのチェーンがあり、各々所有され、各々置換可能、各々測定可能」。

Archyl機能。 コンポーネント図はコンテナがどう構築されているかを示す。各コンポーネントはタイプ(controller / service / repository / handler / module / job / workflow / activity / entity)、ファイルパス、所有者、技術を持つ。コンポーネントはUser Flowに構成される — Archylのフロー機能はライダーの旅をコンポーネント呼び出しの順序付きシーケンスとして著作し、ステップバイステップ図としてレンダリングできる。

ADR-003 · SchemalessとDocstore — ストレージ層を購入するのではなく所有する

ステータス · 受諾(Schemaless:~2014;Docstore:~2020以降)

コンテキスト · 2014年までに、Uberのライドボリュームは単一のPostgreSQLインスタンスを上回り、当時のオフザシェルフのNoSQLオプション(Cassandra、Couchbase、MongoDB)はトリップと支払いデータに対してUberが受け入れたくない運用上の癖を持っていた。トリップ状態は強整合性のマルチリージョン書き込み、低p99レイテンシ、ゼロダウンタイムのシャーディングを必要とする。2014年の業界の答えは*「NoSQLを選んでトレードオフと共に生きる」*だった。

決定 · MySQLを耐久性のある基盤として扱い、その上に構築する。Schemalessはトリガーレスのアペンドオンリーログ、自動再シャーディング、JSONドキュメントAPIでシャードされたMySQLをラップする。数年後、Docstoreは同じMySQL基板の上に強整合性のマルチリージョントランザクショナルドキュメントストアを重ね — 新しいプロダクトデータのデフォルトになる。

結果 · Uberは類似サイズの複数の企業を襲った「NewSQLに移行する」/「Postgresに戻す」のブームバストサイクルから外れたままだった。パスは漸進的:新しいワークロードはDocstoreを得る;成熟したワークロードは移行されるまでSchemalessに留まる。両方とも深いMySQL専門知識を持つ小さなプラットフォームチームによって運用される。Uberが完全にCassandraに行ったという噂?彼らはCassandraを使うが、トリップのシステムオブレコードだったことはない。

このADRはパスデペンデントアーキテクチャの素晴らしい例だ:2014年、正解はMySQLを拡張することであり、そこから移行することではなかった。

Archyl機能。 ドリフト検出がここで最も重要だ。新しいサービスが「Schemaless」に書き込み始めるが、C4モデルがまだ「PostgreSQL」と言うとき、Archylはコードベースに対するドリフトスコアを計算し、毎週フラグを立てる。ADRは次のドリフトを防ぐ:新しいデータストアに書き込む新しいチームは、変更を提案するADRを提出する必要があり、プラットフォームチームはそれを承認または拒否できる。

Archylでレンダリングされた3つのUber ADRカード

3つの決定。Archylの3つのカード、各々それが形作るC4要素にリンク — H3はすべての空間コンテナに、Cadenceはすべての長時間実行ワークフローに、Schemaless/Docstoreはデータ層に。図は現在形;ADRはなぜ。

オーナーシップ:モデルを説明責任に変える

Uberオーナーシップマップ:システムにマップされたチーム

C4モデルは、チームをマッピングするまでは静的なアーティファクトだ。Uberはエンジニアリング構造について公に発信している:強力なFoundationグループ(Storage、Compute、Networking、Observability、Security、ML Platform、Maps)、Mobility、Delivery、Freightにアラインしたプロダクト組織、そしてクロスプロダクトの経済エンジンを所有する中央Marketplace組織。

これらをC4モデルに落とす:

  • MarketplaceはDISCO、動的価格設定サービス、サージ、ETAプラットフォーム、需給フォーキャスターを所有
  • Mobility Engineeringはライダー&ドライバーアプリ、トリップオーケストレータ、評価&チップフロー、安全ツールキットを所有
  • Delivery EngineeringはEatsの注文オーケストレーション、配達員マッチング(DISCOプリミティブを再利用)、マーチャントツール、メニュー/在庫プラットフォームを所有
  • Freight Engineeringは長距離特有のワークフローを所有:ロードマッチング、ブローカーツール、決済
  • Mapsはルーティング、ETAモデル、トラフィック取り込み、H3ライブラリを所有
  • **ML Platform (Michelangelo)**はモデル訓練、フィーチャーストア、オンラインサービング、ML可観測性スタックを所有
  • Storage PlatformはSchemaless、Docstore、Cassandra、バックアップ/リストアツーリングを所有
  • Compute PlatformはKubernetes時代のクラスタマネージャーとAurora/Pelotonの後継者を所有
  • ObservabilityはM3(メトリクス)、Jaeger(トレーシング)、ログパイプラインを所有
  • Security & IdentityはRisk、IAM、シークレットプラットフォーム、Marketplaceと共有される乱用/不正シグナルを所有
  • Cadence/Workflow Platformはすべての製品で使われる耐久性のあるワークフローランタイムを所有

システム、コンテナ、コンポーネントがチーム所有者を持つと、ドリフト検出は説明責任を持つようになる。新しいサービスがコミットに現れて図に存在しないとき、特定のチームが質問を受ける。コンプライアンスルールが違反されたとき — 「Marketplaceサービスのみがサージキャッシュに書き込める」 — 誰かの受信箱に名前がある。

Archylでは、オーナーシップマップはドキュメントツールがガバナンスツールに変わる瞬間だ。

Archyl機能。 すべてのC4要素はowners.teamsとowners.usersをサポートする。オーナーシップマップビューはカバレッジをロールアップするので、誰も所有していないボックスを見ることができる(そして修正できる)。このサイズのシステムでカバレッジギャップは受け入れられない — それがオンコールが誰も応答しないSlackチャネルにエスカレーションする方法だ。

ドリフト、コンプライアンス、4000サービス問題

4000のマイクロサービスを持つモデルはドリフトする。激しく。Mobilityが機能をリリース;新しいマイクロサービスが現れる;Marketplaceデータコントラクトが進化する;2019年に非推奨にされたサービスがついに引退する。すべてのチーム、すべての四半期で掛け算する。

Archylは毎週ドリフトスコアを計算する:文書化されたC4モデルと現在コードベースにあるものとの間のギャップ。数値は0と100の間に制限される。ドリフトスコア12は、まだモデルにない6つの新しいサービス、削除されたエンドポイントを指す図中の3つの関係、実際のスタックともはや一致しない技術でタグ付けされた一握りのコンテナを意味するかもしれない。

コンプライアンスルールはポリシー層を追加する。Marketplace組織が書くかもしれない例:

  • Marketplaceサービスのみがサージキャッシュから読める
  • PIIを扱うすべてのコンテナはpii:trueタグを持ち、Identity ADRを参照する必要がある
  • すべての公開APIにはOpenAPIまたはgRPCコントラクトが添付されなければならず — そのコントラクトが実装ではなく真実の源でなければならない
  • すべてのコンテナは所有チームを必要とする
  • トリップ状態の変更はCadenceを通らなければならない;直接のデータベース書き込みは禁止
  • 新しいデータストアにはADRとStorage Platformのサインオフが必要

Archylはこれらのルールを継続的に評価する。違反は図に、チームの週次ダイジェストに、そしてGitHub Actionを配線すればコミット時のチェックとして表示される。

Archyl機能。

  • モデルとコードのギャップに対するドリフトスコア、すべてのプッシュで再計算
  • YAMLとして著作されるコンプライアンスルール、すべてのC4要素に適用
  • Architecture Change Requests — 提案されたモデル変更のためのプルリクエストスタイルレビュー、アーキテクチャがコードと同じ厳密さに従うように
  • Architecture Insights — ドリフト+コンプライアンスシグナルからAIで浮上する異常と推奨

Uberのサイズのスタックでは、これはオプションではない。これが、専用のアーキテクチャドキュメントチームなしにモデルを正直に保つ唯一の方法だ。

APIコントラクト、イベント、マーケットプレイスの神経系

UberのMarketplaceは、高速でイベントを交換するサービスのグラフだ。トリップ状態遷移、ドライバー位置更新、サージ再計算、料金見積もり、支払い承認 — すべての変更は0から多くのダウンストリームサービスによって消費されるKafkaイベントを発行する。ほとんどの同期的なサービス間呼び出しはgRPCだ。

Archylでは:

  • すべてのコンテナは添付のAPIコントラクト(HTTP/OpenAPI、gRPC、GraphQL、AsyncAPI)を持つことができる。仕様はインラインでレンダリングされる;コンシューマーは何を呼び出しているかを正確に見る。
  • すべての非同期チャネルはブローカー(Kafka)、トピック名、スキーマ形式(Avro、Protobuf、JSON Schema)、スキーマ本体を持つEvent Channelとしてモデル化できる。プロデューサーとコンシューマーはチャネルにリンクされる。
  • 破壊的な変更はコントラクトにdiffとして表示される — そしてバージョンバンプを要求するコンプライアンスルールがある場合、変更はルールが満たされるまでブロックされる。

Uberにとって、それはC4モデルと同じ場所から検査可能になる3000のトピックと数万のコントラクトだ。「誰が私のイベントを消費しているのか?」はもうない — モデルが知っている。

Marketplace規模のDORA

オーナー付きのC4要素を持つと、それらをデリバリテレメトリに接続できる。ArchylのDORAモジュールはCI/CDとインシデントシステムからデプロイ頻度、変更のリードタイム、変更失敗率、平均回復時間を引き出し — C4要素ごと、チームごとにロールアップする。

MobilityのTrip Orchestratorについて、そのチームのデプロイケイデンスと安定性をPricingとは別に見るだろう。Marketplace全体について、プラットフォーム全体のMTTRがどうトレンドしているかを見るだろう。MTTRが急上昇したら、問題のあるコンテナにドリルダウン;デプロイ頻度が停滞したら、特定のサブツリーに帰属できる。

Archyl機能。 ArchylのDORAダッシュボードは、チームと要素の内訳とトレンドラインで4つのメトリクスをレンダリングし、インシデントを影響を与えたアーキテクチャ要素に結びつける。「我々は可観測性を持っている」が「我々はエンジニアリング健康を持っている」になる方法だ。

そしてAI層

4,000サービスのスタックはAIコーディングエージェント — Claude Code、Cursor、Windsurf、その他 — の自然な生息地だ。すべてのUberエンジニアは同じ問題を持つ:「サービスXはサービスYとどう話し、サージ乗数は実際にどこに永続化されるか?」

ArchylではモデルはMCPサーバー経由で公開される。エンジニアのラップトップ上のすべてのAIエージェントは尋ねることができる:

  • 「H3ライブラリに依存するすべてのサービスをリスト」
  • 「dispatch.MatchServiceのAPIコントラクトを見せて」
  • 「どのADRがストレージ決定をカバーしている?」
  • 「所有サービス全体でCadenceからTemporal SDK v2への移行計画を生成」

エージェントはエンジニアと同じアーキテクチャコンテキストを得る。オンボーディングは縮む。チーム横断のコードレビューは*「これは何をしているのか?」*ではなくなる。頭の中に住んでいたコンテキストは、今やクエリ可能なモデルに住む。

Archyl機能。 AIエージェントのためのMCPサーバー、archyl YAML、Structurizr DSL、LikeC4、IcePanel JSON、Backstageカタログ形式でのインポート/エクスポート — 既存のアーキテクチャデータが書き直しなしに流入するように。プロジェクトドキュメント、ユーザーフロー、アーキテクチャインサイトがサーフェスを完成させる。

このスケールの組織のための完全な機能サーフェス

Archylを評価するUber形のエンジニアリング組織なら、ここにサーフェスがあり、それが日々の生計を立てる部分にマップされている:

  • 4レベルすべてのC4モデル — システムコンテキスト、コンテナ、コンポーネント、コード — 自動レイアウト、オーバーレイ、クリックスルーナビゲーション付き。すべての図表ツールが正しく行うこと;我々はそれを正しく行いそして続ける。
  • AIアーキテクチャディスカバリ — Archylをリポジトリに向けると、C4要素を自動的に発見する。四半期ではなく1時間でゼロから最初のモデルへ。
  • Architecture-as-Code — gitにチェックインされ、解析され、検証されたarchyl.yaml。GitHub Action経由でCI/CD対応。コードと同じ厳密さ。
  • マルチフォーマットインポート — Backstageカタログ(JSON)、Structurizr DSL、LikeC4、IcePanel JSON、Archylのネイティブ YAML。
  • 完全なライフサイクル(proposed / accepted / deprecated / superseded)でC4要素にリンクされたADR。
  • 特定の要素にリンクするマークダウン、添付ファイル付きのプロジェクトドキュメント — 生きているアーキテクチャハンドブック。
  • HTTP/gRPC/GraphQL/AsyncAPIのためのAPIコントラクト、生成側コンテナに対してインラインレンダリング。
  • ブローカー、トピック、スキーマ、プロデューサー、コンシューマーを持つイベントチャネル — アーキテクチャの非同期側。
  • リリース&環境 — アーキテクチャに結びついたバージョン付きデプロイ、図に表示。
  • すべてのレベルでチームとユーザー割り当てを持つオーナーシップマップ。
  • モデルと実際のコードベースの間のドリフトスコア、すべてのプッシュで再計算。
  • モデル上のポリシーとしてのコンプライアンスルール — 著作、評価、強制。
  • 提案されたモデル変更のプルリクエストスタイルレビューのArchitecture Change Requests。
  • AIで浮上した異常、リスク、推奨のArchitecture Insights。
  • 要素ごと、チームごとにロールアップされ、トレンドラインとインシデント帰属を持つDORAメトリクス。
  • チームの所有境界にスコープされた週次のチームごとのサマリーのArchitecture Team Digest。
  • MCP統合 — チーム上のすべてのAIコーディングエージェントが同じアーキテクチャコンテキストを共有。
  • GitHub PRレビュー — Archylのレビューボットがアーキテクチャに影響するPRに、ドリフト、コンプライアンス、ADRコンテキスト付きでコメント。
  • 共有&埋め込み — 公開リンク、チーム専用リンク、内部Wikiの埋め込み可能iFrame。
  • 画像/PDFエクスポート — プレゼンテーション、正式なドキュメント、印刷スライド用のPNG、SVG、PDF。
  • 多言語 — ドキュメントとエージェントプロンプトを含む9つの言語で利用可能なすべてのArchylサーフェス。

それが完全なツールボックスだ。Uberのようなスタックなら、ほぼすべてを使うだろう。50サービスのスタックなら、成熟度に合った半分を使い — 残りに成長する。

4000サービスは必要ない

あなたはUberではない。ほとんどのエンジニアリング組織はそうではない。

しかし教訓はスケールダウンする。コンテキストをコンテナから、コンテナをコンポーネントから分離する規律、パスデペンデントな決定(我々はH3を構築した、我々はCadenceを構築した、我々はMySQLを置き換えるのではなく拡張した)を説明するADRを書く規律、すべてのボックスにオーナーシップを付ける規律 — その規律こそが50サービスのスタックを4000のように感じさせない。

C4 + ADR + オーナーシップ + ドリフト + コンプライアンス + APIコントラクト + DORA + MCP — それがArchylがすぐに使える状態で提供するものだ。Uberの例はマーケットプレイス・物流ドメインでのモデルの最大の妥当なストレステストにすぎない。

あなた自身のアーキテクチャを開く。10の製品を描く(3つあるなら3つ)。最も意外な過去の決定を持つものを選んで、そのコンテナをズームする。新参者を困惑させるであろうことを説明する3つのADRを書く。すべてのコンテナにチームをマップする。

ほとんどのエンジニアリング組織が1年で到達する場所より先にいるだろう。

あなた自身のアーキテクチャをC4でモデル化したい?Archylで始める。なぜADRとC4が一緒の方が良く機能するか、またはArchitecture Change RequestsがプルリクエストルゴルをC4モデルにもたらす方法についてもっと読む。以前のケーススタディはStripeのC4 — チャージの解剖学とNetflixのC4 — プレイの解剖学をモデル化した。