# クラウドスケールRPC特性 ## 定義 クラウドスケールRPC特性は、ハイパースケール環境で RPC が示す規模・構造・レイテンシ・CPU コスト・エラー率の横断的な性質をまとめる概念である。旧「RPC規模特性」と旧「RPCレイテンシ特性」は、同じ Google SOSP 2023 論文の同一概念面を分けていたため、本ページに統合した。([[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]]) Google の実運用 RPC は、スループット年率約 30% 増、上位 100 メソッドが全呼び出しの 91% を占める強い偏り、広く浅いコールグラフ、ミリ秒スケールの中央値レイテンシ、テールで支配的になる RPC latency tax を同時に持つ。 ## 横断的知見 - **規模とレイテンシは分けて最適化できない**: 件数ではストレージ RPC が支配的だが、CPU 時間では遅いメソッドが支配的である。呼び出し頻度だけで最適化対象を選ぶと CPU 節約を外し、CPU 時間だけを見るとユーザー影響の大きいテールを外す。 - **実運用RPCはマイクロ秒ではなくミリ秒の世界で動く**: Google 実環境では多くのメソッドの中央値が 10ms 以上で、マイクロ秒級 RPC 最適化の前提とずれる。Dapper などの分散トレースでキュー・アプリ処理・ネットワーク転送を分解しないと、ボトルネックを誤る。 - **平均では小さい tax がテールでは支配的になる**: 平均 RPC latency tax は小さいが、P99 ではタックス比が大きくなる。サービスレベル目標では平均改善よりテール分解が重要になる。 - **コールグラフは深さより幅が問題になる**: descendants はヘビーテールで、単一のストレージ/キャッシュ遅延が広い fan-out に増幅される。これは [[マイクロサービスコールグラフ]] や [[Metastable Failure]] の議論と接続する。 - **テール改善の手段は浪費を生む**: リクエストヘッジングはキャンセルを増やし、RPC エラー由来の浪費 CPU の大きな部分を占める。レイテンシ改善と資源効率は同じ方向に動かない。 ## 未解決の問い - RDMA/RoCE ベースの RPC では、CPU コスト・キュー遅延・テール tax はどの程度変わるか。 - Google 以外のハイパースケーラで、同じメソッド人気度分布とミリ秒スケールのレイテンシ分布が再現するか。 - ヘッジングのテール改善量とキャンセル浪費を、SLO とコストの両方で最適化する制御則は設計できるか。 - コールグラフの幅が広いサービスでは、キャッシュ/ストレージ遅延をどの階層で抑えるのが最も効果的か。 ## 関連 - ソース: [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]] - 概念: [[分散トレーシング]] / [[テレメトリ]] / [[サービスレベル目標]] / [[マイクロサービスコールグラフ]] / [[Metastable Failure]] - エンティティ: [[Google]] / [[Stubby]] / [[Dapper]] / [[Monarch]] ## 出典 - [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]](RPC throughput growth, method popularity, call graph structure, RPC completion time decomposition, latency tax, error/cancellation analysis)