マイクロサービスアーキテクチャ

# マイクロサービスアーキテクチャ ## 定義マイクロサービスアーキテクチャ(Microservice Architecture / MSA)は、モノリシックアプリケーションを小さなソフトウェアサービスに分解し、明確に定義された API(エンドポイント)を通じて互いに通信させる分散アプリケーションの構築・運用パラダイム。各サービスが特定のビジネスユースケースを担い、開発チームの独立性・デプロイ速度の向上・細粒度なスケーリングを実現する。大規模組織では事実上の標準となっている。([[@2023__USENIX ATC__Lifting the veil on Meta's microservice architecture]]) 基本構成要素: - **サービストポロジ**: 相互接続された多数のレプリカサービスが複数のデータセンターにまたがって実行される有向グラフ - **ロードバランサ**: データセンター入口およびサービス間の転送をルーティングするレイヤ - **可観測性フレームワーク**: メトリクス監視・ログ記録・分散トレーシング([[テレメトリ]])を担う基盤 - **スケジューラ**: ホストマシン上でサービスをコンテナとして実行するグローバルフェデレーテッドスケジューラ ## 横断的知見 - **大規模産業界実装とオープンソーステストベッドの乖離**: DeathStarBench 等のオープンソーステストベッドは単一アプリケーションを模倣するが、Metaのような大規模産業実装は多数のアプリケーションを処理する多様なサービスを持つ。過去研究で「テストベッドは産業界より静的」と指摘されたが、本論文はその乖離がトポロジの不均一性・チャーン・成長という具体的次元で発生することを定量化した。(Source: [[@2023__USENIX ATC__Lifting the veil on Meta's microservice architecture]]) - **「不適合(Ill-fitting)」エンティティの存在が研究ツールの前提を崩す**: Inference Platform のような ML プラットフォームは「ビジネスユースケースが十分なパーティション基準」というマイクロサービスの根本的前提を破る。テナントごとに Service ID を生成するため、Service ID ベースのトポロジ分析や RCA ツール(Sage の同期 RPC 前提、Tprof の非結合爆発前提)が無効化される。単一組織の設計点だけでなく不適合エンティティの多様な処理パターンをツール設計が考慮する必要がある。(Source: [[@2023__USENIX ATC__Lifting the veil on Meta's microservice architecture]]) - **トポロジの成長は「新サービス追加」が規定し「既存サービスの複製増加」ではない**: Metaの22か月データで、Regular servicesのインスタンス増加率(s=0.046%/日)は新規 Service ID 増加率(s=0.043%/日)とほぼ一致。すなわちスケールアップより機能追加が成長を牽引する。これはモデルベースのトポロジツールが定期的な再訓練と「予測が実態から乖離した時点の検知機構」を必要とすることを意味する。(Source: [[@2023__USENIX ATC__Lifting the veil on Meta's microservice architecture]]) - **「サービス」の定義の不統一が定量比較を不可能にする**: 既存の産業界研究(Luo et al., Wen et al., Zhang et al.)はサービスの定義・スケール・サンプリング方式を明示しないため定量比較が困難。この問題はインターネット計測コミュニティが開発した標準計測方法論のマイクロサービス版が必要であることを示す。(Source: [[@2023__USENIX ATC__Lifting the veil on Meta's microservice architecture]]) - **リクエストワークフローは「浅く広い」という共通構造が複数組織で確認**: Metaの Fetch プロファイル(中央値深さ4・幅472)、Alibaba(Luo et al.)、ByteDance(Wen et al.)のいずれも大規模トレースは幅方向に大きく、深さは浅い。この構造はデータシャーディング(1コレクションの取得に多数のストレージへのファンアウトが必要)という実装パターンに起因する。(Source: [[@2023__USENIX ATC__Lifting the veil on Meta's microservice architecture]]) ## 未解決の問い - 不適合エンティティ(Inference Platform・ML Scheduler 等)を自動的に識別・分類する手法は存在するか。手動の識別に依存している現状は大規模トポロジ分析のスケーラビリティを制限する。 - 「サービス」の定義を標準化し異組織間の定量比較を可能にする標準計測方法論をどう設計するか。インターネット計測コミュニティ(IMC)の方法論はどこまで参考になるか。 - 高チャーン(毎日多数のサービスが追加・廃止)に対してリアルタイムでトポロジモデルを更新するアルゴリズムは何か。モデルの staleness をオンラインで検知する方法は。 - ワークフローの「building block」(parent/child 関係)から集約ベースのパフォーマンス診断・容量計画を行う具体的な手法は実用化されているか。 - Canopy の観測性損失(深いコールパスの80%打ち切り)を補完するために、トレース外の情報(ログ・メトリクス)とどう統合するか。[[マルチモーダル障害診断]]との接続。 ## 関連 - ソース: [[@2023__USENIX ATC__Lifting the veil on Meta's microservice architecture]] - 概念: [[分散トレーシング]] / [[テレメトリ]] / [[トレースサンプリング]] / [[Fault Localization]] / [[根本原因分析]] / [[マルチモーダル障害診断]] / [[AIOps]] - エンティティ: [[Meta]] / [[Canopy]] / [[Darby Huye]] / [[Raja R. Sambasivan]] / [[Yuri Shkuro]] / [[Tufts University]] / [[DeathStarBench]] - 関連 MOC: [[SRE - MOC]] / [[AI Infra Telemetry - MOC]] ## 出典 - [[@2023__USENIX ATC__Lifting the veil on Meta's microservice architecture]](§1 Introduction、§2 Metaアーキテクチャの詳細、§3 トポロジ特性 F1-F3、§4 ワークフロー特性 F4-F6、§5 示唆と将来研究)