gRPCの仕組み ― HTTP/2とProtocol Buffersで実現する高速通信

gRPCはGoogleが開発したRPC（Remote Procedure Call）フレームワークだよ。普通のREST APIがHTTPリクエストを送って「このURLのデータください」ってやるのに対して、gRPCは「この関数を実行して」って直接呼び出す感覚で通信できるんだ。しかも通信にHTTP/2を使うから、めちゃくちゃ速いんだよ。

HTTP/2には3つの大きな特徴があるよ。まず「多重化（マルチプレキシング）」で、1つの接続で複数のリクエストを同時に送れる。次に「ヘッダー圧縮」で、毎回同じようなヘッダーを送る無駄がなくなる。そして「バイナリフレーミング」で、テキストじゃなくバイナリでデータをやり取りするから処理が速いんだ。REST APIのHTTP/1.1だと1リクエストごとに順番待ちが発生するけど、gRPCはそれがないんだよ。

そう、gRPCの心臓部だね。Protocol Buffers（protobuf）は、データの形式と通信の定義を .proto ファイルに書くIDL（インターフェース定義言語）だよ。たとえば「ユーザー情報にはname（文字列）とage（数値）がある」「GetUserという関数はUserIdを受け取ってUserを返す」みたいに定義する。この .proto ファイルからGo、Python、Java、TypeScriptなど各言語のコードを自動生成できるんだ。

その通り！REST APIだとJSONの形式はドキュメントに書いてあるだけで、実際に送られてくるデータが正しいかはランタイムまで分からない。でもgRPCなら .proto ファイルが「契約書」になって、コンパイル時に型チェックされるから安全なんだ。しかもprotobufはバイナリシリアライゼーションだから、JSONより圧倒的にデータサイズが小さくて高速だよ。

いい質問だね。まず1つ目が「Unary（単項）」で、1リクエスト・1レスポンスの普通のやり取り。2つ目が「Server Streaming」で、クライアントが1回リクエストするとサーバーがデータを連続で返してくる。株価のリアルタイム配信みたいなイメージだね。3つ目が「Client Streaming」で、クライアントがデータを連続送信してサーバーがまとめて1回応答する。ファイルアップロードに便利だよ。4つ目が「Bidirectional Streaming」で、双方向に同時にデータを流せる。チャットアプリみたいな用途にぴったりだね。

似てるけどもっと洗練されてるよ。WebSocketは生のバイトストリームだから、データ形式やエラー処理を全部自分で実装しないといけない。gRPCの双方向ストリーミングはprotobufで型付けされてるし、フロー制御やエラーハンドリングもフレームワークが面倒を見てくれる。あと、gRPCには「Channel（チャネル）」と「Stub（スタブ）」っていう概念があって、Channelがサーバーへの接続を管理し、Stubがその上で関数呼び出しを行うんだ。接続の再利用やロードバランシングもChannelが自動でやってくれるよ。

できるよ。gRPCでは「Interceptor（インターセプター）」がその役割を果たすんだ。認証トークンの付与、ログ出力、メトリクス収集、リトライ処理なんかをInterceptorとして実装すれば、すべてのRPC呼び出しに自動で適用できる。REST APIのミドルウェアと同じ発想だけど、gRPCだとクライアント側にもサーバー側にもInterceptorを置けるのが特徴だね。

いや、使い分けが大事だよ。gRPCはマイクロサービス間の内部通信には最強だけど、弱点もある。まずブラウザから直接呼べない。HTTP/2のフレーミングをブラウザのJavaScriptから制御できないからね。gRPC-Webっていうプロキシを挟む方法はあるけど、Unaryとサーバーストリーミングしかサポートしてない。あと、curlやブラウザで手軽にテストできないし、人間が読めないバイナリ通信だからデバッグしにくい面もある。

そういうこと。でもgRPCにはまだ面白い機能があるよ。「Reflection API」を使うと、サーバーが自分の持ってるサービス定義を動的に教えてくれるから、.protoファイルがなくてもgrpcurlみたいなツールで叩ける。あとgRPCには標準の「Health Checking Protocol」があって、Kubernetesのヘルスチェックと統合しやすいんだ。マイクロサービスを本番運用するときにこれが地味に効いてくるよ。

ざっくり言うと、マイクロサービス間の高速通信、ストリーミングが必要な場面、多言語環境での型安全な連携にはgRPC。ブラウザから直接叩くパブリックAPI、サードパーティ向けのオープンAPI、シンプルなCRUD操作にはREST。最近はgRPCで内部通信しつつ、外部向けにはAPIゲートウェイでRESTに変換する「gRPC Gateway」パターンも人気だよ。両方の良いとこ取りができるんだ。

まさにそれが現代のベストプラクティスの一つだね。ちなみにgRPCの「g」はGoogleの「g」だけど、バージョンごとに違う意味が付けられてて、1.0は「gRPC」、1.1は「good」、1.2は「green」って遊び心があるんだ。技術的に優れてるだけじゃなくて、エコシステムも充実してるから、大規模分散システムを作るなら一度は触っておきたいフレームワークだよ。