RPC(遠隔手続き呼び出し)
RPC
リモートのサーバー上の処理を、まるでローカルの関数を呼ぶように実行する方式。『振る舞い(操作)』を公開する。性能重視の内部通信でよく使われる。Protobuf/Thrift/gRPCなど。
RPCの発想: リモートを『ローカルのように』呼ぶ
RPC(Remote Procedure Call)の狙いは、ネットワーク越しの処理を、あたかも手元の関数のように呼べるようにすること。
# 見た目はただの関数呼び出しだが…
user = get_user(123)
# 実は裏でリモートサーバーと通信している!
図を描画中...
**stub(スタブ)**が通信の面倒(引数を送れる形に変換=marshal、受け取って戻す=unmarshal)を肩代わりするので、開発者はローカル関数のように書けます。
『振る舞い』を公開する
RPCは『どんな操作(振る舞い)ができるか』を公開します。getUser、createOrder、cancelReservation のように、動詞=操作が前面に出ます。これがRESTとの思想の違いです(RESTは『データ(リソース)』を公開する)。
なぜ内部通信向きか
性能が出るから。Protobufなどはデータをコンパクトなバイナリにして高速にやり取りします。マイクロサービス同士の内部通信のように、速さが大事で相手も自分たちが管理している場面に向きます。
つまずきポイント(短所)
- 密結合: クライアントがサーバーの実装に強く依存する。サーバーの変更がクライアントに波及しやすい。
- 操作ごとに新API: 新しい操作を足すたびに新しいRPCメソッドが要る。
- 既存技術を活かしにくい: HTTPの汎用キャッシュ(Squid等)やブラウザの仕組みに乗りにくい。
- デバッグが難しい: ローカル関数に見えるので、ネットワーク起因の問題が見えづらい。
これらの理由から、外部公開APIには不向き。外部にはRESTを使うのが定石です。
📊 図解
RPC のやりとり(シーケンス図)
stub が marshal / unmarshal を肩代わりするので、開発者はローカル関数のように書けます。
図を描画中...