マイクロサービス間の通信でREST APIの限界を感じていませんか。gRPCはGoogleが開発した高性能RPCフレームワークです。実際にRESTと比べて最大7倍のパフォーマンスを発揮します。そこでgRPCの仕組みを基礎から解説します。
gRPCとREST APIの違い
最大の違いはプロトコルです。RESTはHTTP/1.1を使います。しかしgRPCはHTTP/2を採用しています。またデータ形式も異なります。RESTはJSON形式ですがgRPCはバイナリ形式のProtocol Buffersです。つまりデータサイズが大幅に小さくなります。
さらに通信パターンにも違いがあります。RESTはリクエストとレスポンスの1対1通信です。一方でgRPCは双方向ストリーミングに対応しています。具体的にはサーバーからの連続送信やクライアントからの連続送信が可能です。したがってリアルタイム処理に強みがあります。
HTTP/2がgRPCを高速にする理由
HTTP/2の最大の利点は多重化です。つまり1つのTCP接続で複数のリクエストを同時に処理できます。従来のHTTP/1.1では順番待ちが発生していました。しかしHTTP/2ではその問題が解消されます。特にマイクロサービス間の小さなリクエストが多い場面で効果的です。
さらにHTTP/2は既存の接続を再利用できます。そのため接続確立のオーバーヘッドが削減されます。またサーバープッシュ機能も備えています。したがって通信効率が全体的に向上します。
Protocol Buffersの役割と仕組み
Protocol BuffersはGoogleが開発したデータ交換フォーマットです。具体的には.protoファイルでデータ構造を定義します。するとサーバーとクライアントのコードが自動生成されます。つまり開発者はビジネスロジックに集中できます。
バイナリ形式のためJSONより高速にエンコードとデコードが行われます。またペイロードサイズも大幅に削減されます。さらに複数のプログラミング言語に対応しています。特に後方互換性の管理も容易です。したがって大規模なシステムでも安定して運用できます。
gRPCの4つの通信パターン
gRPCは4種類の通信パターンをサポートします。まずUnary RPCは通常の1対1通信です。次にServer Streaming RPCはサーバーが連続的にデータを送信します。またClient Streaming RPCはクライアント側が連続送信します。そして双方向ストリーミングでは両方が同時に送受信できます。
たとえばリアルタイム通知には双方向ストリーミングが最適です。さらにフロー制御やリトライ機構も組み込まれています。しかしブラウザからの直接アクセスには向きません。そのためフロントエンドにはREST、バックエンドにはgRPCという使い分けが一般的です。このようにgRPCはマイクロサービス開発の標準技術として広がっています。