# Stubby ## 概要 **Stubby** は [[Google]] が内部向けに開発した RPC(リモートプロシージャコール)ライブラリ。外部公開の gRPC と同等の機能を持ち、Google Search・Gmail・Maps・YouTube などのユーザー向けサービスと、[[Spanner]]・[[Bigtable]]・F1・GFS などの内部データ管理システムで広く使用されている。 ## 特徴 - ロケーション非依存な通信: リモートマシンへの関数呼び出しがローカル呼び出しと同様に見える - 接続管理・ネットワークプロトコル・パラメータのマーシャリング/デマーシャリング・暗号化/復号化・スレッドスケジューリングをスタック内に隠蔽 - ユーザ空間ライブラリとして実装 ## RPC フリートワイド計測での位置づけ [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]] では、Stubby を通じて Google フリート全体の RPC 特性(レイテンシ・スループット・コールグラフ・CPU コスト)を 700 日間・722 億サンプル規模で計測。10,000+ の異なる RPC メソッドが分析対象となった。 ## gRPC との関係 Stubby は Google 内部向けで、その設計知見を元に **gRPC**（外部公開版）が開発された。gRPC は現在多くのクラウドアプリケーションで標準 RPC フレームワークとして採用されている。 ## SRE Book での用語法 [[@2016__OReilly__SRE Book - Chapter 2 The Production Environment at Google, from the Viewpoint of an SRE]] では、Stubby を介した通信の呼び出し元を frontend(フロントエンド、伝統的な意味でのクライアントに相当)、呼び出し先を backend(バックエンド、伝統的な意味でのサーバに相当)と呼ぶ用語法を導入する。GSLB(Global Software Load Balancer)は外部公開サービスへのロードバランシングと同じ仕組みで RPC のロードバランシングも行い、過負荷でない適切なバックエンドタスクの BNS アドレスを解決する。データは protocol buffers(protobuf)でシリアライズされ、XML と比べてサイズが 3〜10 分の 1、処理速度が 20〜100 倍という特性を持つ。 ## lame duck の伝播(データセンター内負荷分散) [[@2016__OReilly__SRE Book - Chapter 20 Load Balancing in the Datacenter]] では、Stubby(章内では「Google's RPC implementation」)が[[レイムダック状態]]の伝播を支える仕組みとして登場する。アクティブなTCP接続を持つクライアントへは lame duck 状態への遷移が直接ブロードキャストされる一方、アクティブな接続を持たない非アクティブなクライアントに対しても、Stubby は定期的な UDP ヘルスチェックを送り続けている。この UDP ヘルスチェックにより、クライアントの接続状態にかかわらず lame duck 情報は通常 1〜2 RTT という短時間で全クライアントへ伝播する。(Source: [[@2016__OReilly__SRE Book - Chapter 20 Load Balancing in the Datacenter]]) ## 出典 - [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]] - [[@2016__OReilly__SRE Book - Chapter 2 The Production Environment at Google, from the Viewpoint of an SRE]](frontend/backend 用語法、GSLB による RPC ロードバランシング) - [[@2016__OReilly__SRE Book - Chapter 20 Load Balancing in the Datacenter]](lame duck 状態の UDP ヘルスチェックによる伝播)