# Lifting the veil on Meta's microservice architecture: Analyses of topology and request workflows ## アブストラクト（日本語訳） マイクロサービスアーキテクチャは多くの組織において分散アプリケーション構築の主流パラダイムであり、モノリシックアプリケーションと比べてビルド・管理・運用の方法を多面的に変える。新たな課題を生み出すと同時に、既存の前提を変更することも迫る。しかし今日、大規模マイクロサービスアーキテクチャの特性は組織外からは不透明で、研究機会を著しく損なっている。本論文は Metaのマイクロサービスアーキテクチャを特徴づけることで大規模マイクロサービスへの理解を深める。これまで未報告(もしくは過少報告)だったが、マイクロサービストポロジやリクエストワークフロートレースを使うツールを開発・研究するうえで重要な側面に焦点を当てる。トポロジは極めて不均一で絶え間なく変化しており、マイクロサービスアーキテクチャに綺麗に収まらないソフトウェアエンティティを含む。リクエストワークフローは高度に動的だが、サービス名とエンドポイント名で局所的な性質を予測できる。マイクロサービス計測における障害要因を定量化し、ツールと将来の研究への示唆で締めくくる。 ## 論文情報 | 項目 | 内容 | |---|---| | 会場 | USENIX Annual Technical Conference (ATC) 2023 | | 開催 | 2023年7月10〜12日、ボストン(米国) | | 著者 | Darby Huye (Tufts University / Meta)、Yuri Shkuro (Meta)、Raja R. Sambasivan (Tufts University) | | データ公開 | https://github.com/facebookresearch/distributed_traces | ## 概要 Metaのマイクロサービスアーキテクチャを、サービスレベルトポロジからリクエストワークフローのトレースへとトップダウンに分析した実証研究。22か月分のサービス履歴ログ(17 MB)と、2022年12月21日の1日分の分散トレース(Canopy、4.6 TB)を使い、研究ツール開発に向けた定量的知見を提供する。 ## 問題設定 - 産業界のマイクロサービスアーキテクチャの定量的特性が外部に公開されていないため、研究ツールが非現実的な前提を置く問題がある - 既存のオープンソーステストベッド(DeathStarBench等)は産業界の実際の規模・複雑度を反映していない - 先行研究(Luo et al. / Wen et al.)は単一の設計点の部分的な観測に留まる ## 分析手法・データセット | データセット | 説明 | 保持期間 | 利用期間 | |---|---|---|---| | Service History | サービス展開・廃止・サービス間通信 | 22か月 | 全期間 | | Service Endpoints | サービスが公開するエンドポイント | 30日 | 1日 | | Traces | Canopyが収集した分散トレース | 30日 | 1日(4.6 TB) | 分析には Ads / Fetch / RaaS の3プロファイルに対応する 650万トレース(全 Canopy トレースの0.5%)を使用。 ## 主要な知見 ### F1: 不適合ソフトウェアエンティティの存在 Metaのトポロジには3種類のエンティティが存在する。(1)単一のビジネスユースケースに特化したサービス、(2)多数のビジネスケースを処理しながら単一サービスとして展開されるもの、(3)マイクロサービスアーキテクチャの「ビジネスユースケースで分割すれば十分」という前提に合わない「不適合(Ill-fitting)エンティティ」。代表例は Inference Platform(ML モデルをテナントごとに Service ID で展開するプラットフォーム)と ML Scheduler(単一サービスとして出現し27万件超のインスタンスを保有)。 ### F2: 現在のトポロジ規模 - アクティブサービス数: 18,500(不適合サービス除外後7,400) - サービスインスタンス数: 12百万超(除外後11.2百万) - 通信エッジ数: 393,622 - サービスの中央値ファンイン/ファンアウト: 4(不適合除外後3/6) - エンドポイント数分布はべき乗則(α=2.23、R²=0.99)に従うが、通信トポロジ・インスタンス数はべき乗則に従わない ### F3: トポロジの成長とチャーン - 22か月でインスタンス数が約2倍に増加(傾きs=0.046%/日、Regular servicesのみ) - 成長は既存サービスの複製増加でなく新サービス追加によって規定される - 22か月で18万件の新 Service ID が展開され、89.7%はある時点で廃止された - Regular servicesのうち7.7%が1週間未満で廃止、40%は22か月を通じて稼働 ### F4: リクエストワークフローの一般特性 トレースサイズはプロファイルの高レベル機能によって異なるが、大半は小規模。トレースは浅く広い構造を持つ。 | プロファイル | 中央値トレースサイズ | 中央値コール深さ | 中央値コール幅 | |---|---|---|---| | Ads | 2 service blocks | 1 | 1 | | Fetch | 498 | 4 | 472 | | RaaS | 4 | 2 | 3 | ### F5: リクエストワークフローの予測可能性 - ルート Ingress ID はトレース特性を予測しない - 親 Ingress ID は子サービス集合(children set)を50%超の実行で予測できる(variable relaysの71.9〜81.6%でドミナントな children set が存在) - 親 Ingress ID は RPC コール数や並行性の予測力を持たない - 親 Ingress ID + children set の組み合わせで並行性の標準偏差が減少する(Ads・Fetch で中央値が 0.13/0.09 → 0.04/0.02) ### F6: 観測性の損失 - トレースコールパスの大部分が Inferred サービス(レートリミット・計装欠如による早期打ち切り)で終端する - 深いコールパスほど打ち切り率が不均等に高い(RaaS では深さ3に到達するパスの80%が打ち切り) - 打ち切りのほとんどは復元不可能(既知データベース呼び出し分のみ推定可能) ## Canopyトレーシング基盤の特徴 Meta の Canopy はイベントベースとスパンベースの両方の特徴を持つ独自の分散トレーシング基盤。 - **実効トレースモデル**: 各スパン(サービスブロック)に Thrift RPC の Service ID・エンドポイント名を自動記録 - **ストリーミングモデル**: セッションウィンドウ方式でトレースを非同期構築(固定ギャップ閾値で区切る) - **サービスごとのサンプリングプロファイル**: ランダムヘッドベース or 適応的サンプリングをサービス単位で設定可能 - **推定サービスブロック(Inferred blocks)**: 早期打ち切りを受けたサービスをトレース構築時に推定補完 ## 考察 トポロジの絶え間ない変化(F3)はモデル学習ツールへの定期再訓練の必要性を示唆する。リクエストワークフローの高い多様性(F5)は、ルートエンドポイント単体での集約が不十分であることを意味し、parent/child 関係の基本構成単位(building block)から集約する設計が有望。観測性の損失(F6)は既存ツールが想定する完全なトレース可視性が現実には成立しないことを示す。 また本研究は「サービス」の定義を各組織が独自に決めるため定量比較が困難という方法論的課題を明示し、インターネット計測研究のようなマイクロサービス固有の標準計測方法論の必要性を提起する。 ## 強み・弱点・課題 **強み** - 22か月・12百万インスタンス・650万トレースという大規模実データを公開 - 定量的特性(べき乗則の成否、チャーン率、並行性分布)を詳細に測定 - ツールへの示唆と将来研究の方向性を体系的に整理 **弱点・課題** - 単一組織(Meta)のデータであり汎化の限界がある - 他組織のアーキテクチャとの定量比較はメソドロジの不統一により不可能 - 不適合エンティティの除外が結果に大きく影響するが、自動的な識別手段がない - 観測性の損失(F6)により、ワークフローの完全な姿を把握できていない可能性がある