# クラウドスケール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 に増幅される。これは [[マイクロサービスコールグラフ]] や [[メタ安定障害]] の議論と接続する。 - **テール改善の手段は浪費を生む**: リクエストヘッジングはキャンセルを増やし、RPC エラー由来の浪費 CPU の大きな部分を占める。レイテンシ改善と資源効率は同じ方向に動かない。 - **本concept が実測する「RPC latency tax」は、TCP/UDP以外の標準トランスポートを持たなかったインターネットの歴史的欠落の帰結として説明しうる**: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] は、1990年代のインターネットにRPC(リクエスト/リプライ型)専用のトランスポートが標準化されなかったため、HTTPが「事実上のRPCプロトコル」として転用され、TCPの信頼性のあるバイトストリームというモデルの上にRPCを載せることで、ヘッドオブラインブロッキング・輻輳への応答の悪さ・TLSによる追加RTTという構造的なミスマッチが生じたと説明する。本concept が実測する「平均では小さいが P99 で支配的になる latency tax」は、この構造的ミスマッチが定量的にどう現れるかを示す実データと解釈できる。ただし本concept のソース(SOSP 2023)はGoogle独自のRPCフレームワーク(Stubby)を対象とし、TCP直上ではなく自社スタック上のRPCを測定している点で、両ソースが指す「RPCの実装」自体は同一ではない。(Source: [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]], [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.4) - **Googleが自前のRPCフレームワーク(Stubby)を持つに至った実務的選択は、標準化されたRPCトランスポートが長年不在だったという歴史的パターンの一事例である**: 本concept のソースはStubbyを既存のインフラとして前提に規模・構造・レイテンシを測定するが、なぜGoogleが標準プロトコルではなく独自のRPCフレームワークを構築したのかという経緯までは論じていない。[[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] が描く「1980年代から90年代にかけて数多くのRPCフレームワークが乱立した」歴史(標準の欠如ゆえにSunRPC、DCE/RPC等が個別に生まれた)は、Stubbyのような各社独自RPC基盤が生まれた背景として一貫する説明を与える。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.4, §7.5) - **本concept が実測する「サービス」への負荷分散という構造(クライアントが特定のサーバプロセスではなくサービスを呼び出し、負荷分散器がスケーラブルな数のコンテナへ振り分ける)は、教科書(本書第5章§5.3.2)がgRPCの設計を説明する際に明示する構造そのものと一致する**: 本concept のソース(SOSP 2023)はGoogleの実運用RPCが持つ広く浅いコールグラフ・強い偏りを実測データとして示すが、その背後にある「クライアント/サーバ」から「クライアント/サービス」への抽象化の変化そのものは論じていない。[[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 5 End-to-End Protocols]] §5.3.2は、gRPCの設計をSunRPC・DCE-RPCのような従来のクライアント/サーバ型RPCとの対比で説明し、「クライアントはサービスを呼び出し、負荷分散器がその呼び出しをスケーラブルな数のサーバプロセス(コンテナ)群のどれかへ振り向ける」という間接化が、クラウド時代のRPCに特有の追加の抽象層であると明示する。同章はさらに、gRPCが「Googleが自社のクラウドサービス構築に10年間使ってきたRPC機構の経験をオープンソースとして公開したもの」だと述べており、本concept が測定するGoogle内製フレームワーク(既存の横断的知見で言及するStubby)の設計思想の系譜がgRPCへ流れ込んでいることを示唆する。すなわち、本concept の実測データが示す「コールグラフの幅の広さ」「テールでの支配的なtax」は、この負荷分散を介した間接化アーキテクチャ自体が生む構造的な帰結である可能性が高い。ただし本書第5章はgRPCとStubbyの関係を「同一」とは明言しておらず、この推定はあくまで系譜の示唆にとどまる。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 5 End-to-End Protocols]] §5.3.2 gRPC, [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]]) ## 未解決の問い - RDMA/RoCE ベースの RPC では、CPU コスト・キュー遅延・テール tax はどの程度変わるか。 - Google 以外のハイパースケーラで、同じメソッド人気度分布とミリ秒スケールのレイテンシ分布が再現するか。 - ヘッジングのテール改善量とキャンセル浪費を、SLO とコストの両方で最適化する制御則は設計できるか。 - コールグラフの幅が広いサービスでは、キャッシュ/ストレージ遅延をどの階層で抑えるのが最も効果的か。 - 本concept が実測する latency tax のうち、TCPの汎用性(信頼性のあるバイトストリームというモデルをRPCに転用すること)に起因する部分と、Stubbyなど個別RPCフレームワークの実装上の選択に起因する部分はどう切り分けられるか。QUICやHomaのようなRPC専用トランスポートへ移行した場合、この latency tax はどの程度削減されるか、実測データは本wiki内にまだ無い。 ## 関連 - ソース: [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]] / [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] / [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 5 End-to-End Protocols]](gRPCの負荷分散を介した「サービス」呼び出しという間接化アーキテクチャの教科書的説明) - 概念: [[分散トレーシング]] / [[テレメトリ]] / [[サービスレベル目標]] / [[マイクロサービスコールグラフ]] / [[メタ安定障害]] / [[トランスポートプロトコル設計]] - エンティティ: [[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) - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 7 TCPの考古学]] §7.4, §7.5(RPC専用トランスポートの標準化不在という歴史的背景) - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 5: End-to-End Protocols, §5.3.2. https://book.systemsapproach.org/e2e.html(gRPCがクラウドサービス向けに追加する負荷分散の間接化アーキテクチャ)