はじめに
以前から、Firestoreのリアルタイム同期にgRPCが使われていることや、（仕事でよく使う）Google CloudでgRPCの知識を求められる機会が多く、知的好奇心と必要性の両輪でgRPCへの学びの機運が高まっていたため学んだことを備忘録的に残しておきます。
gRPC入門
概要
gRPCはGoogle発、Remote Procedure Call（RPC）のフレームワークです。
マイクロサービス間通信に利用していたGoogle社内の技術「Stubby」を汎用化して作られました。
Googleにおけるアプリケーション開発では、スケーラブルなマイクロサービス型のアーキテクチャーが基本となっており、サービス間の通信処理を担うコンポーネントとして、Stubbyと呼ばれる独自のRPCライブラリーが利用されてきました。gRPCは、このライブラリーをオープンソースとして再実装したもので、さまざまなプログラミング言語で使用することができます。
何だか難しい言い回しが続きますが、前述の通りgRPCは通信を行うためのフレームワークです。
「Protocol Buffers」と呼ばれる定義ファイルをもとにサーバやクライアントの実装コードを自動生成でき、その自動生成したコードを介して通信を行うことができます1。
コードを自動生成できるため、他言語間で通信を行うのも容易く、アプリケーションの実装と技術的な実装が疎結合になります。
通信の足回り（プロトコル）には、従来より利用されてきたHTTP/1.xをより効率化したHTTP/2を用いています。
全体感を把握するための図解としては下記の図が非常に分かりやすいです。
Protocol Buffersによってクライアントとサーバのコードを生成し、HTTP/2を用いて通信を行います。
主な利用用途はもちろんマイクロサービスだとは思いますが、他にもGoogle Cloud Client Librariesの裏側で用いられていたり、モバイルアプリに組み込んで使うことも挙げることができます。
The main usage scenarios:
- Low latency, highly scalable, distributed systems.
- Developing mobile clients which are communicating to a cloud server.
- Designing a new protocol that needs to be accurate, efficient and language independent.
- Layered design to enable extension eg. authentication, load balancing, logging and monitoring etc.
本番環境をgRPCに移行していくユースケースを知りたい方は、下記の動画およびスライドが非常に分かりやすくオススメです。
Remote Procedure Call（RPC, 遠隔手続き呼び出し）
gRPCはRPCフレームワークです。RPCとは一体何なのでしょうか？
平たく言ってしまえば、RPCとは「異なる場所にある関数（手続き）を呼び出すためのしくみ」です。
Protocol Buffers（protoファイル）上で通信に用いる関数等を定義しコンパイルすると、各プログラミング言語向けのソースコードが自動生成されます。
自動生成されたソースコード内のメソッドをクライアントで利用すると、メソッドの裏側ではサーバへの通信が行われますがクライアントはそのことを意識する必要はありません（透過的）。
この仕組みは「関数を呼び出し戻り値を受け取る」関数呼び出しと相似の関係になっています。
RPCでは通信が透過的に取り扱われ、（遠隔にある）サーバ上の関数を呼び出すようにして通信を行うことができます。
ref. RPCの具現化であるgRPC
gRPCとREST APIの差分
REST APIもOpenAPI Specification（Swagger）を用いればソースコードの自動生成が行えますし、gRPCと類似な部分を感じる方も多いかと思います。
ざっくりカテゴライズすると、gRPCもREST APIも、アプリケーションレイヤのひとつ上の層に位置する「クライアントとサーバ間の通信ルール」ですので、利用シーンの位置付けは被る部分も多いかと思います。
なぜポストREST APIが求められるのか？ REST APIがカバーできない2つの要因とその対策
その上で、思想としてREST APIはリソース指向2ですがgRPCは読んで字の如くRPCである点や、前者が主にデータ表現にJSONを用いるのに対して、後者はProtocol Buffersによるバイナリデータを取り扱う点、そもそもREST APIがHTTP/1.1以前の思想であるためgRPCのようにストリーミングを取り扱わない点、といった違いがあるかなと思います。
マイクロサービスの呼び出しには、REST APIもよく利用されますが、REST APIが既存のHTTP(S)プロトコルをそのまま利用しているのに対して、gRPCでは、HTTP/2プロトコルをベースとして、マイクロサービスの連携に必要なさまざまな機能が実装されています。具体的には、アプリケーションレイヤーでのフロー制御、多段階にわたるサービス呼び出しの連携、ロードバランスとフェイルオーバー、双方向のストリーミング通信などがあります。
gRPC vs REST
gRPCProtocol Buffers - smaller,faster.
HTTP/2(lower latency).
Bidirectional & Async.
Stream Support.
API oriented (no constraints-free design).
Code Generation through Protocol Buffers in any language-1st class citizen.
RPC based gRPC does the plumbing for us.REST
JSON- text based, slower, bigger
HTTP1.1 (higher latency)
Client -> Server requets only
Request/Response support only
CRUD oriented(Create-Retrieve-Update-Delete/POST GET PUT DELETE)
Code generation through OpenAPI/Swagger(add-on)-2nd class citizen
HTTP verns based- we have to write the plumbing or use a 3rd party library
- gRPCチュートリアル - 他のプロトコルとの比較
- スターティングgRPC_読書メモ - gRPCとRESTの違い
- Why is gRPC better/worse than REST?
- gRPCと従来のREST APIの比較
gRPCの二大要素技術
gRPCは通信プロトコルとしてHTTP/2を利用し、データのシリアライズにProtocol Buffersを利用しています。
gRPC は transport の機能は完全に HTTP/2 に任せて、より上位のレイヤーの関心ごとに注力できる様になっています。
By default, gRPC uses Protocol Buffers
ここからはgRPCの二大要素技術であるHTTP/2とProtocol Buffersについてざっくりとまとめていきます。
HTTP/2
HTTP/2登場前に広く利用されていた（今も広く利用されている）HTTP/1.1に関して、Webが大規模化するとともに様々な問題が表出してきました。
一例を挙げると、ネットワーク通信の利用やプロトコルの仕組みが非効率であるために生じるレイテンシーの問題等です。
HTTP/1.1の問題点のおさらい
- HTTP Head of line Blocking
- ネットワーク通信の利用が非効率
- 曖昧でテキスト処理が煩雑
そんな状況を打破するべく、HTTP/1.1登場の16年後、パフォーマンス向上を目指してリリースされたのがHTTP/2です。
HTTP/2はgRPCのStubbyに続きGoogleが起源でして、Google発のプロトコルSPDYをもとに標準化されました。
世界はさらにGoogleに依存または支配されていくことを示唆するような亜種の批判もあります。このプロトコルはここ30年間に開発されたプロトコルと同様の手法でIETFによって開発されました。しかしながら我々はSPDYにおけるGoogleのすばらしい仕事を認めています。それは新しいプロトコルがデプロイできるということを証明しただけでなく、それによりどのような効果が得られるのかを示す数値も提供しました。
HTTP/1.1との互換性を保つことを優先しつつパフォーマンスを向上させるため、ひとつのTCPコネクション上で複数の仮想的なコネクション（ストリーム）を確立したり、通信はバイナリベースで行う等の大きな仕様変更を導入しました。
・ストリーム（1.1のパイプラインに近いもの）を使ってバイナリデータを多重に送受信する仕組みに変更
・ストリーム内での優先順位設定や、サーバーサイドからデータ通信を行うサーバーサイドプッシュを実装
・ヘッダーが圧縮されるようになった
バイナリベースって何？
HTTP/1.xはテキストベース、HTTP/2はバイナリベースのプロトコルだと言われています。
HTTP/1.xであれHTTP/2であれ、通信を行うためにはまずTCPコネクションを張ります。
TCP上では任意のメッセージを送り合うことができますが、ルールがないとクライアントもサーバもお互いメッセージを解釈できないので、HTTPという仕様を定め、メッセージの形式を決めています。
HTTP/1.xだと、メッセージをテキストで表現し、改行位置等に意味を持たせています。
「Status-Lineは一行目」「:の後に空白を許可」「改行で区切る」等のテキストの記述方法に関するルールを定めることで、メッセージをパースし情報を取り出すことができるわけです。
実際にHTTPサーバを自作すると分かるかと思いますが、HTTP1.xに準拠したサーバは、受け取ったテキストをルールに従いパースしてヘッダ等の情報を取り出していきます。
Goならわかるシステムプログラミング 第6回 - GoでたたくTCPソケット（前編)
一方で、HTTP/2はメッセージをテキストではなくバイナリでやりとりする仕様になっており、バイナリの並び順自体にルールを定めていることから「バイナリベース」のプロトコルと呼ばれます。
バイナリベースはテキストに比べて効率的な表現ができるため、小さな容量で多くの情報をやりとりできるメリット等を持ちます。
バイナリプロトコルは、小さな容量で転送でき、より効率的に解析できます。そして最も重要なのは HTTP/1.x のようなテキストプロトコルと比較して、間違いを少なくできることです。なぜなら、テキストプロトコルは、空白の処理や大文字と小文字の区別、改行コード、空白のリンクといったものに対応する多くのアフォーダンスを持っているからです。
gRPCの双方向通信とHTTP/2の関係性
gRPCはWebSocketのような双方向通信（Bidirectional streaming RPC）を行うことができます。
双方向通信をどのように実現しているのかと言えば、そもそもgRPCの通信プロトコルであるHTTP/2が持つ「ストリーム」は双方向であるとRFCに記載されており、その性質をそのまま流用しているようです。
そんな双方向なストリームを複数個制御することで、gRPCは双方向なデータ送受信を行っています。
Yes, bidirectional streaming is native to HTTP/2. You can read RFC-7540 for the details of how the protocol works, but basically it allows you to create several streams on a single TCP connection, and each stream can send data in either direction independently of each other.
How does grpc achieve "bidirectional streaming rpc" like a websocket?
Client- and server-side stream processing is application specific. Since the two streams are independent, the client and server can read and write messages in any order.
Core concepts, architecture and lifecycle - Bidirectional streaming RPC
HTTP/2にて触れた「ステートフルなストリーム」と「多重化されたストリームを複数個制御すること」により、双方向なデータ送受信を行うことができる。
HTTP/2のサーバプッシュに対する誤解
HTTP/2には「サーバプッシュ」と呼ばれる仕様があります。
「プッシュ」と聞くとWebSocket等の代替のようにも聞こえますが、現状は限定的な機能にとどまっています。
現状のサーバプッシュは「キャッシュプッシュ」であり、主にブラウザのキャッシュにコンテンツを先回りでお届けするような用途で用いられています。
gRPCにおいてもサーバプッシュの機能は使われていません。
”キャッシュプッシュ”とも呼ばれている機能です。
ブラウザがページをリクエストすると、サーバーは応答でHTMLを送信し、JavaScript、画像、CSSの送信を開始する前に、ブラウザがHTMLを解析し、すべての埋め込みアセットに対してリクエストを発行するのを待つ必要があります。
サーバープッシュを使用すると、サーバーは、クライアントが必要と考える応答をキャッシュに「プッシュ」することで、このラウンドトリップの遅延を回避できる可能性があります。
HTTP/2 push is called push, but it has nothing to do with notifications pushed from the server. It is just a more or less a sensible way of reducing application load time by saving round-trips.
Using a single HTTP/2 connection for bidirectional (and symmetric) communication
As good as HTTP/2 features are, it’s not exactly what we were looking for. It turns out Pushes are only processed by the browser and do not bubble up to your client code.
All server push streams are initiated via PUSH_PROMISE frames
Protocol Buffers
gRPCが利用するHTTP/2はバイナリベースのプロトコルですので、データをバイナリで表現する必要があります。
gRPCはProtocol Buffersを用いてデータをバイナリに変換（シリアライズ）しています。
改めて「Protocol Buffersとは何ぞや」ですが、データの通信および永続化のためのシリアライズフォーマットです。
protoファイル（foo.proto）に関数やメッセージを定義しコンパイルすると、各プログラミング言語向けのソースコードを生成してくれます。
生成したソースコードを使って、データのシリアライズ / デシリアライズを行うことができる上に、シリアライズしたデータをやりとりする関数を利用することもできます。
Protocol Buffers は端的にいえば、言語+コンパイラ+ライブラリの3つの要素から構成される serialization mechanism です。Protocol Buffers は独自の Inteface Definition Language（IDL）を持っており、その言語を利用して構造化データを message 型として記述すると、コンパイラ（protoc）が各プログラミング言語向けの実装を生成してくれます。その自動生成されたコードを Protocol Buffers ライブラリとともに利用することで、効率的な binary format への serialize/deserialize が行えます。
Protocol Buffersの初出が2008年7月、gPRCは2016年8月です。
出自からそもそもProtocol BuffersはgRPCと独立した技術なので、gRPC以外と併用することができます。
諸々の考慮は必要かもしれませんが、例えばRedisのようなインメモリキャッシュにデータを保存する際にProtocol Buffersを使うといったことも可能です（How to store protobuffer object in redis cache?）。
Google社内では各ストレージにデータを保存する形式としてProtocol Buffersを採用している事例も多いようです。
Google の内部の RPC は Protocol Buffers 形式でやり取りをされ、ストレージにも Prrotocol Buffers 形式でデータが保存され、データ解析パイプラインや mobile client との通信も Protocol Buffers 形式で行われている
gRPC-Web
WebにおけるJavaSctiptがHTTP/2のストリームを取り扱うAPIを持っていないこと等もあり（？）、ブラウザは直接gRPCを取り扱うことができません。
In general HTTP/2 should be transparent in its use to web pages and web applications and so there is no need to implement low level HTTP/2 streams and connection details.
HTTP/2 supports bidirectional stream but you don't have access to this stream from JavaScript
What is the meaning of - HTTP2 doesn't provide API used by the clients, while websockets do?
それでもWeb（ブラウザ）でgRPCを取り扱いたいニーズはあり、生み出されたのがgRPC-Webです。
簡単に言ってしまえばブラウザからのHTTP通信をgRPCに変換するプロキシを準備してブラウザとgRPCサーバを繋げる仕組みがgRPC-Webです。
対応プロキシはEnvoyやNGINX等です。
プロキシへのリクエスト形式は規定されているので、Protocol BuffersによってgRPC-Web向けの実装を自動生成することで仕様に準拠したリクエストを行うことができます。
gRPC-WEBを使ったWEBアプリ開発/Development web-app with gRPC-WEB
Bidirectional streaming RPCをサポートしていない等、通常のgRPCとは異なる部分もあります。
まとめと今後の予定
gRPCに入門しました。
gRPCの裏側を知っていく内にHTTP3やQUIC等にも興味が出てきたので、今後キャッチアップしていこうと思います。
-
あくまでデフォルトではProtocol Buffersを用いるだけであり、他の技術を利用することもできます。「By default, gRPC uses Protocol Buffers」What is gRPC? - Overview ↩
-
リソースに対する操作をHTTPメソッドで記述する考え方 ↩