こんばんは。今日は、最近よく耳にして気になっていたgRPCという技術について調べてみたので、分かったことをここにまとめました。
それではまいります。
Contents
gRPCとは
- Googleが作ったRemote Procedure Calls（後述）の新しいオープンソースフレームワーク
- 2015年2月に発表され、初版は2016年8月に公開
- 公式サイトやドキュメントはこちら
- 後述のRPCと同様、クライアントの中のRPCスタブがサーバと要求のやりとりをする
- 特徴は以下。
- 通信ではHTTP/2を利用するため、従来のRPCよりも高速
- データのエンコーディングに、Protoco Bufferという、これまたGoogleが開発した技術を利用している（シンプルさとパフォーマンスを追求するために構造化データをシリアライズして扱う）
- Go、C++、Java、Python、C#、Ruby、Node、PHPなど多くの言語でサポートされているので、異なる言語のアプリケーション間でも利用できる
トレンドは、2020年頃に一度謎の落ち着きを見せていますが、右肩上がりであることには変わらなさそうです。
参考文献：
https://ja.wikipedia.org/wiki/GRPC
https://docs.microsoft.com/ja-jp/dotnet/architecture/cloud-native/grpc#what-is-grpc
そもそもRPCってなんだ
- あるコンピュータから、ネットワーク上の別のコンピュータ上で動作するプログラムと通信を行うための規約（プロトコル）
- 1970年代に登場したソフトウェアアーキテクチャ
- クライアント・サーバのシステムや分散システムなどで用いられている
- クライアントは、サーバ側のコードを直接実行するわけではなく、ローカルスタブプロシージャを呼び出す（下図１）
- スタブが要求をサーバに投げる（いろいろ説明をはぶいた）
- サーバではサーバスタブが要求を受け取り、そしてサーバ側のコードを実行する
参考：
https://docs.microsoft.com/ja-jp/windows/win32/rpc/how-rpc-works
REST APIと何が違う？
システムのコンポーネント間通信といえば、REST APIによる呼び出しも思いつきますが、gRPC/RPCとREST APIは根本的に何が違うのでしょうか？また、どちらを採用すべきなのでしょうか。
こちらが分かりやすかったです。
https://www.integrate.io/jp/blog/grpc-vs-rest-how-does-grpc-compare-with-traditional-rest-apis-ja/
RESTと比較したgRPCの違い（引用）
- JSONの代わりにProtobufを使用
- HTTP 1.1ではなく、HTTP 2で構築
- Swaggerのようなサードパーティツールを使用する代わりに、生来のコード生成
- 7～10倍の速さのメッセージ送信
- RESTより遅い実装
特に通信速度の差は非常に魅力的ですね。これは上でも取り上げた、HTTP/2による通信と、Protocol Bufferの利用によるものと考えられるそうです。一方で、実装はRESTと比べると時間がかかる（記事では、REST実装に10分かかる処理が、gRPCだと45分かかる、という例が紹介されています）点はデメリットといえそうです。
RESTよりもgRPCを使うべきシナリオは、以下のようにまとめられています。
- マイクロサービスのコンポーネント間通信（通信速度が非常に重要となるため）
- 多言語システム（gRPCは豊富な言語サポートがあるため）
- リアルタイムのストリーミング（今回触れていないですがgRPCを使うと双方向ストリーミングができるため）
- 低電力低帯域ネットワーク（RESTが用いるJSONと比べても、Protocol Bufferメッセージはより軽量で、高速な通信ができるため）
JSONとProtocol Bufferのパフォーマンス比較は以下の記事にもわかりやすくまとまっていたので、リンクを貼っておきます。
以上、gRPCについて調べたことのまとめでした。時間があれば今度実装もしてみたい。
参考になった！という方いらっしゃいましたら、下のいいねボタンをポチっていただけると励みになります。
おしまい
コメントを残す