# A Cloud-Scale Characterization of Remote Procedure Calls ## 論文情報 | 項目 | 内容 | |---|---| | タイトル | A Cloud-Scale Characterization of Remote Procedure Calls | | 著者 | Korakit Seemakhupt, Brent E. Stephens, Samira Khan, Sihang Liu, Hassan Wassel, Soheil Hassas Yeganeh, Alex C. Snoeren, Arvind Krishnamurthy, David E. Culler, Henry M. Levy | | 所属 | University of Virginia / Google / Google & University of Utah / University of Waterloo / UC San Diego / University of Washington | | 会議 | SOSP '23（ACM SIGOPS 29th Symposium on Operating Systems Principles）| | 開催 | 2023-10-23〜26, Koblenz, Germany | | DOI | https://doi.org/10.1145/3600006.3613156 | ## 概要（アブストラクト日本語訳） 現代のクラウドアプリケーションが分散サービス指向アーキテクチャに依存するなか、その中核をなすリモートプロシージャコール(RPC)の動作は広く研究されてきた。しかし「実際のクラウド規模」での RPC 特性に関する知識はこれまで不足していた。 本論文は、[[Google]] の内部ユーザー向け Web サービス(Google Search・Gmail・Maps・YouTube)とそれを支える大規模内部サービス([[Spanner]]・BigQuery・[[Bigtable]]・F1・GFS・Chubby)において、10,000 以上の異なる RPC メソッドを 10 億件超のトレースからサンプリングし、約 2 年間(700 日)のデータを分析した。RPC のスループット・成長率・レイテンシ・コールグラフ構造・CPU コストを包括的に計測した初の大規模フリートワイド研究である。 ## 問題設定 クラウドアプリケーションはマイクロサービス・サービス指向アーキテクチャに分解され、RPC が計算とデータのフローを制御する基本構造となっている。先行研究は RPC をマイクロ秒スケールのレイテンシ・単純な呼び出し構造と仮定し最適化を行ってきたが、ハイパースケールの実環境で RPC の動作特性を体系的に計測した研究はなかった。その結果、最適化の対象設定が誤っていたり、実際のボトルネックを見逃している可能性があった。 ## 調査方法・データ Google 内部の 3 つの計装ツールを併用した: - **Monarch** — 30 分ごとにメトリクスをサンプリングするモニタリングデータベース。700 日分のデータ(2020 年 12 月〜2022 年 11 月)。10,000+ の RPC メソッドを対象。 - **Dapper** — RPC ツリー全体(トレース)をサンプリングするサービス。1 日分で 722 億サンプルを収集。レイテンシ成分の詳細分解に使用。 - **GWP(Google-Wide Profiling)** — 日次 CPU プロファイルのサンプリング収集。RPC 処理に費やされる CPU サイクルを測定。 対象は Google の第一者商用プロダクトのみ(GCP の顧客 RPC は除外)。RPC スタックは主に [[Stubby]](gRPC と同等の機能を持つ Google 内部 RPC ライブラリ)と gRPC を使用。 ## 主要な発見事項 ### 1. RPC の成長 RPC スループット(RPS/CPU サイクル)は年率約 **30%** で増加しており、700 日間で **64%** 成長した。RPC の処理効率の向上とマイクロサービス化の進展が要因。この成長ペースは計算資源の成長を上回っている。 ### 2. レイテンシはミリ秒スケール 先行研究はマイクロ秒スケールの RPC を前提としていたが、Google の実環境では: - 90% のメソッドが中央値レイテンシ **10.7ms 以上** - 99.5% 超のメソッドが P99 レイテンシ **1ms 以上** - 最も遅い 5% のメソッドは P99 が **5 秒以上** ### 3. RPC レイテンシタックス(RLT) RPC レイテンシの成分をキュー・RPC 処理・ネットワーク転送の「タックス」と、サーバアプリケーション処理に分解すると: - **平均**: タックスは完了時間の **2.0%** のみ(うちネットワーク 1.1%・RPC 処理+ネットワークスタック 0.49%・キュー 0.43%) - **P95 テール**: タックスが支配的になり、ネットワーク起因の遅延が顕著 - タックス比の中央値が最も高い 10% のメソッドでは、RPC タックス中央値 **38%**、P90 で **96%** - P99 タックス比は 0.5%〜99.99% の広い分布(中央値 66%) ### 4. コールグラフは広く浅い - 半数のメソッドが median descendants **13 以下**、P99 descendants が 1155 以上とヘビーテール - ancestors は median で **10 以下**(P99)——深さより幅の広いグラフ構造 - Alibaba・Meta の先行調査と共通する傾向だが、テールの descendants が大きい ### 5. RPC サイズ - 小さい RPC が多数: 最小 64B(キャッシュライン 1 本)、半数のメソッドで中央値リクエスト 1530B 以下 - ヘビーテール: P99 リクエストが 196KB・レスポンスが 563KB(中央値比 2 桁増) - 大多数の RPC は Write 主体(response/request 比率の中央値 < 1) ### 6. ストレージ RPC が支配的 - 上位 8 サービスが全呼び出しの 60% を占有 - Network Disk が RPC 呼び出しの 28% を単独占有し、バイト転送でも最大 - しかし Network Disk の CPU サイクル消費は 2% 未満(ストレージは呼び出し数は多いが CPU 使用が少ない) - ML 推論・F1 などの長レイテンシ RPC は呼び出し数は少ないが CPU を大量消費 ### 7. CPU サイクルタックス - RPC 全体で CPU サイクルの **7.1%** をタックスとして消費 - 最大要因: **圧縮** 3.1%、次いでネットワーキング 1.7%、シリアライゼーション 1.2% - RPC CPU コストはヘビーテール(P99 は中央値の 1〜2 桁大きい) - RPC サイズ・レイテンシと CPU コストの間に相関なし ### 8. 負荷分散 - クラスタ間でCPU 負荷が大きく不均衡 - 同クラスタ内のマシン間では変動小(Spanner・F1・ML 推論は例外) - サーバ CPU 利用率・メモリ帯域幅・スケジューリングレイテンシがクラスタ間のレイテンシ差を説明する外因変数 ### 9. RPC エラー - 全 RPC の **1.9%** がエラーを生じる - キャンセル(45% の件数・55% の CPU 浪費): リクエストヘッジングが主因と推測 - 「エンティティ未発見」が 20% のエラー件数・21% の CPU 浪費 ## 示唆と提言 ### ソフトウェア最適化 - **スケジューリング・配置の改善**: キュー遅延が RPC タックスの 21% を占めるため、同一 RPC ツリーのクライアントとサーバをコロケーションする仕組みが有効 - **負荷分散**: システムリソース状態と RPC タイプ情報を横断したクロスレイヤー負荷分散が必要 - **メソッド固有の最適化**: 上位 10 メソッドが全呼び出しの 58% を占めるため、対象を絞った最適化が効果的 ### ハードウェア最適化 - **圧縮・暗号化・シリアライゼーションのオフロード**: CPU サイクルの主要消費源であり、NIC/アクセラレータでのオフロードが高価値 - **RPC ライブラリのアクセラレーション効果は限定的**: RPC ライブラリは CPU サイクルのわずか 1.1% のため、SmartNIC による RPC ライブラリ高速化の効果は小さい - **ストレージデータフローアクセラレーター**: Network Disk と Spanner が RPC の大半を占めるため、データ転送加速が有効 ## 強み・弱点・課題 **強み**: - 単一のハイパースケーラによる初の大規模フリートワイド RPC 計測(722 億サンプル・700 日) - 3 種類の計装ツール(Monarch・Dapper・GWP)による多角的な分析 - 先行研究の前提（マイクロ秒・単純コールグラフ）を定量的に反証 **弱点・課題**: - 単一ハイパースケーラ(Google)のデータのみで汎化可能性が不明 - TCP 上の RPC のみを対象; RDMA については将来課題 - サービス固有の最適化効果の定量化には追加研究が必要 ## 関連概念 - [[クラウドスケールRPC特性]] — 本論文が体系化したハイパースケール RPC の規模・レイテンシ構造 - [[分散トレーシング]] — [[Dapper]] を用いたトレース収集が本研究の中核計装 - [[テレメトリ]] — [[Monarch]](メトリクス)・[[Dapper]](トレース)・GWP(プロファイル)の 3 層計装 - [[Fault Localization]] — RPC エラー分析がエラー種別ごとの CPU 浪費を定量化 ## 出典 - 論文 PDF: https://homes.cs.washington.edu/~arvind/papers/google-rpc.pdf