> [!abstract] 概要(arXiv abstract の日本語訳) > クラウドサービスは近年、モノリシックアプリケーションから数百の疎結合マイクロサービスのグラフへと、大きな転換を始めている。マイクロサービスは現行クラウドシステムの多くの前提を根本から変え、QoS と利用効率を最適化する際の機会と課題の双方を提示する。 > > 本稿ではマイクロサービスがクラウドシステムスタックに与える影響を探究する。まず DeathStarBench を提示する——マイクロサービスで構築された新規の open-source ベンチマークスイートで、大規模なエンドツーエンドサービスを代表しモジュラかつ拡張可能である。DeathStarBench はソーシャルネットワーク、メディアサービス、電子商取引サイト、銀行システム、UAV 群の調整制御のための IoT アプリケーションを含む。次に DeathStarBench を用いて、マイクロサービスのアーキテクチャ特性、ネットワークおよびオペレーティングシステムへの影響、クラスタ管理における課題、アプリケーション設計とプログラミングフレームワーク上の trade-off を研究する。最後に数百ユーザを含む実展開で tail at scale 効果を探究し、マイクロサービスが性能予測可能性に与える圧力の増大を強調する。 ## 論文情報 - タイトル: An Open-Source Benchmark Suite for Cloud and IoT Microservices - 著者: Yu Gan ほか 24 名(全員 Cornell University、PI: [[Christina Delimitrou]]) - 媒体: [[ASPLOS]] 2019(24th International Conference on Architectural Support for Programming Languages and Operating Systems) - DOI: 10.1145/3297858.3304013、arXiv:1905.11055v1 [cs.DC] - リポジトリ: [[DeathStarBench]] ## 概要 本稿は、現代クラウドサービスがモノリシックからマイクロサービスへ移行する潮流に対応する初期のオープンソースベンチマークスイート [[DeathStarBench]] を提案する。Social Network・Movie Reviewing/Streaming・E-commerce・Banking・Swarm Coordination(cloud版とedge版)の 6 つのエンドツーエンドサービスを構築し、各サービスが 25-41 のユニークなマイクロサービスを含む。これを用いてハードウェア・OS・ネットワーク・クラスタ管理・プログラミングフレームワーク・tail-at-scale の各層でマイクロサービスがもたらす設計示唆を実証的に分析する。 ## 問題設定 従来のクラウドベンチマーク([[Cloudsuite]]・[[TailBench]]・µSuite ほか)は単層ないし 2-3 層のサービスに限定され、現代の数十マイクロサービスからなるエンドツーエンドサービスを表現できない。一方マイクロサービスの台頭は AWS・Twitter・Netflix・Apple・eBay 等で広く確認され、性能予測可能性・cluster 管理・hardware 設計に新たな要求を課す。本稿は、open-source・large-scale・end-to-end・多言語実装のベンチマークスイートを構築し、マイクロサービスの全層的な影響を測定可能にする。 ## 提案手法 ### DeathStarBench の 5(+1)サービス すべて Docker container 上で動作: | サービス | LoC(新規) | プロトコル | unique microservices | 主要言語 | |---|---|---|---|---| | Social Network | 15,198 | Apache Thrift RPC | 36 | C 34%, C++ 23%, Java 18% | | Media (Movie Reviewing) | 12,155 | Thrift RPC | 38 | C 30%, C++ 21%, Java 20% | | E-commerce | 16,194 | REST + RPC | 41 | Java 21%, C++ 16%, C 15% | | Banking | 13,876 | Thrift RPC | 34 | C 29%, Javascript 25% | | Swarm Cloud (UAV) | 11,283 | REST + RPC | 25 | C 36%, Java 19% | | Swarm Edge (UAV) | 13,876 | REST | 21 | C 29%, Javascript 25% | メモリ層は memcached・MongoDB・MySQL を併用、NGINX を load balancer/HLS streaming、front-end は node.js を多用、検索は Xapian、開発元は [[Sockshop]] 由来のコンポーネントを部分的に活用。 ### 設計原則 - **Representativeness**: NGINX、memcached、MongoDB、RabbitMQ、MySQL、Apache HTTP、ardrone-autonomy、Sockshop など実運用 open-source コンポーネントを部品とする - **End-to-end operation**: クライアントから backend までの完全な実装 - **Heterogeneity**: C/C++、Java、Javascript、node.js、Python、HTML、Ruby、Go、Scala の混在 - **Modularity**: Conway の法則に従い 1 microservice = 1 関心 - **Reconfigurability**: RPC/HTTP API による microservice 入替が容易 ### 自作 distributed tracing system Thrift timing interface を介して各 RPC 入出時に timestamp を付与し、Zipkin Collector に倣った Trace Collector が Cassandra に格納。ネットワーク処理時間と application 処理時間を分離して測定。**overhead は end-to-end latency の 0.1% 未満**。 ## 実験設定 - 20 台 2-socket 40-core Intel Xeon(E2699-v4/E5-2660 v3、128-256GB)+ 10GbE ToR スイッチ - Cavium ThunderX(2-socket、48 in-order cores/socket、1.8GHz、16MB shared LLC)と比較 - RAPL で周波数スケーリング、Intel vTune で cycle breakdown - Swarm では Parrot AR2.0 24 機 + 20 台 2-socket 40-core サーバ - 比較: 同等機能の monolith 版(全機能を Java 1 binary、backend は memcached/MongoDB)を作って同一指標で測定 ## 実験結果 ### アーキテクチャ層(Section 4) - **Cycle breakdown**: 全サービスで cycle の大半がフロントエンドストール(fetch 起因)。retired instructions は Social Network で平均 21% に留まり、現行サーバはマイクロサービス向けに provisioned されていない - **i-cache pressure**: NGINX/memcached/MongoDB/monolith は依然高 MPKI。残るマイクロサービスは monolith より低い(コードフットプリントが小さいため)。Social Network の L1i miss の大半は kernel・Thrift で発生 - **Brawny vs wimpy cores**: Cavium ThunderX は低負荷で QoS を満たすが Xeon より早く saturate。Social Network・Media が最も低周波数耐性が低く、Swarm は network-bound のため最も耐性が高い ### OS/Network 層(Section 5) - Social Network ではネットワーク処理が全実行時間の 36.3% を占める(monolithic NGINX: 5.3%、memcached: 19.8%、MongoDB: 13.6%) - 多くのマイクロサービスで kernel 時間が user 時間と並ぶ - RPC 処理を Xilinx Virtex7 FPGA に offload すると 10-60× の速度向上を確認 ### Cluster Management 層(Section 6) - Dependency 1 件のミスマネジメントで Social Network の tail latency が 10.4× 悪化、回復には長時間 - 既存 autoscaler(performance/utilization 最適化)は QoS 違反の検出・解消に不十分 ### Tail-at-Scale(Section 8) - 数百ユーザの実展開で測定。マイクロサービスでは 1 microservice の不調や 1 サーバの遅さがエンドツーエンド latency を桁違いに悪化させる - Monolith では同条件で悪化幅が小さい ## 新規性 - **規模**: 既存ベンチマーク([[Cloudsuite]]・[[TailBench]]・µSuite)は 1-3 層のため捉えられない、cascading QoS 違反やネットワーク輻輳のような **at-scale 効果** を実証可能にする - **包括性**: ハードウェア → OS/ネット → cluster 管理 → プログラミング → tail-at-scale の **全層** を同一スイートで分析した最初の研究 - **オープンソース**: 学術・産業の研究者が共通基盤として使えるよう公開 ## 強み / 弱点・課題 ### 強み - 6 つの異なるドメイン(SNS・メディア・EC・金融・IoT 群)を 1 つの suite で網羅する規模感 - monolith 版を別途実装することで実証的比較を可能にした - 0.1% overhead の自前 distributed tracing で全体を計測可能にした - 当時数百ユーザ規模の deployment を Cornell で運用しており、tail-at-scale を本物の workload で観測している ### 弱点・課題 - 個々のサービスは Cornell の学生実装が中心で、商用サービスのコード品質・データ量・利用パターンを完全には反映しない - 自前 trace system は今となっては [[OpenTelemetry]]・[[Jaeger]] 等の標準化された tracing に置換すべき - Conway の法則ベースの分割が必ずしも最適な service boundary とは限らない - 後続研究([[Train-Ticket]] 等)に比べると **fault injection** の枠組みは含まれず、SRE/AIOps の評価には不向き