gRPCは、あらゆる環境で実行できる、最新のオープンソースの高性能リモートプロシージャコール(RPC)フレームワークです。データセンター内およびデータセンター間のサービスを、ロードバランシング、トレーシング、ヘルスチェック、認証のプラグ可能なサポートにより効率的に接続できます。また、分散コンピューティングのラストマイルで、デバイス、モバイルアプリケーション、ブラウザをバックエンドサービスに接続するのにも適用できます。
主な使用シナリオ
- マイクロサービススタイルのアーキテクチャで多言語サービスを効率的に接続
- モバイルデバイス、ブラウザクライアントをバックエンドサービスに接続
- 効率的なクライアントライブラリの生成
gRPCを素晴らしいものにするコア機能
- 11言語の慣用的なクライアントライブラリ
- ネットワーク上で非常に効率的で、シンプルなサービス定義フレームワーク
- http/2ベースのトランスポートによる双方向ストリーミング
- プラグ可能な認証、トレーシング、ロードバランシング、ヘルスチェック
誰がgRPCを使用していて、なぜ使用しているのか?
多くの企業が既に環境内の複数のサービスを接続するためにgRPCを使用しています。ユースケースは、オンプレミスまたはクラウド環境で、さまざまな言語で少数のサービスから数百のサービスを接続するまで多岐にわたります。以下は、初期導入企業からの詳細と引用です。
以下、ユーザーの声をご覧ください。

Squareでは、カスタムRPCソリューションのすべての使用をgRPCに置き換えるために、Googleと協力してきました。複数のプラットフォームのオープンなサポート、プロトコルの実証済みのパフォーマンス、ネットワークに合わせてカスタマイズおよび適応できることから、gRPCに移行することを決定しました。Squareの開発者は、ストリーミングAPIを作成できるようになること、そして将来的にはモバイルクライアントやサードパーティAPIとの統合のためにgRPCをネットワークのエッジにプッシュできるようになることを楽しみにしています。

gRPCの初期使用では、独自のエコシステム内に容易に拡張することができました。さらに、プルリクエストやプロジェクトを管理するGoogleチームとのやり取りを通じて、gRPCを直接改善することに大きな成功を収めました。gRPCを採用した結果、開発者の生産性が向上し、非JVM言語での開発が可能になると期待しています。

自社開発のRPCシステムからgRPCへの切り替えはシームレスでした。ストリームごとのフロー制御をすぐに活用して、小規模なRPCと同じ接続で、大規模なRPCのスケジューリングを改善することができました。

gRPCがHTTP/2トランスポート上に構築されているという事実は、リクエストヘッダーにネイティブの双方向ストリーミング機能と柔軟なカスタムメタデータをもたらします。最初のポイントは、大規模なペイロード交換とネットワークテレメトリのシナリオにとって重要であり、後者は、さまざまなネットワーク要素認証メカニズムを含むがこれらに限定されない機能を拡張および追加することを可能にします。さらに、gRPC/proto3がもたらす幅広い言語バインディングサポートにより、社内および社外の消費者の両方に柔軟で迅速な開発環境を提供できます。最後に、設定、運用状態の取得、ネットワークテレメトリのためのネットワーク通信プロトコルは多数ありますが、gRPCは、クライアント/サーバーの相互作用を容易にするための、統一された柔軟なプロトコルとトランスポートを提供します。
gRPCの背景
gRPCは、Googleによって最初に作成されました。Googleは、**Stubby**と呼ばれる単一の汎用RPCインフラストラクチャを使用して、データセンター内およびデータセンター間で実行されている多数のマイクロサービスを10年以上接続してきました。2015年3月、GoogleはStubbyの次期バージョンを構築し、オープンソース化することを決定しました。その結果がgRPCであり、現在ではGoogle以外の多くの組織で、マイクロサービスからコンピューティングの「ラストマイル」(モバイル、Web、モノのインターネット)までのユースケースを強化するために使用されています。
gRPCを作成した理由の詳細については、gRPCブログのgRPCの動機と設計原則をご覧ください。