gRPCとは

RPC（リモート・プロシージャ・コール）は、リモート・コールがローカル・コールとして表示され、機能するようにするクライアント/サーバー・インタラクションのための通信モデルです。これは古い技術であり、概念的には1970年代に遡り、最初のアプリケーションはARPANETやXerox PARCなどの先駆的なコンピューティング・プロジェクトに見られました。

RPCでは、クライアントはサーバーの表現と対話します。サーバーはローカルに見えますが、実際には仲介者です。この仲介者は一般的にスタブと呼ばれ、データのマーシャリングとアンマーシャリング（つまり、データを送信に適した形式に変換し、サーバーから受信した結果を元の形式に変換すること）を処理します。これはクライアント/サーバー通信用のアーキテクチャ スタイルであるため、API 設計でよく使用されます。

RPCフレームワークには、XML-RPCやJSON-RPCをはじめ、さまざまな種類があります。これらの実装では転送プロトコルとしてHTTPを使用しますが、その形式の種類が大きく異なります。1990 年代と 2000 年代に遡るこれらの実装は、開発を簡素化し、ネットワーク通信の複雑さを抽象化し、軽量で、比較的簡単に使用でき、人間が読めるという RPC の強みを示しました。

しかし、多くの最新環境、特にマイクロサービス・アーキテクチャー、多言語環境、データ負荷の高いシステムを使用する環境では、分散アプリケーションを接続するためのより高速で高性能なフレームワークが必要です。理想的には、このフレームワークは、異なる環境とデータセンターで実行されるサービス間の、より効率的なリアルタイムのデータ転送を促進します。

gRPC はこのニーズを満たすために開発され、データのシリアル化、HTTP/2プロトコルの使用、双方向ストリーミング機能、コード生成などを通じて、低遅延と高スループットを実現します。

gRPCは、HTTP/2のリリースと同じ年、2015年に初めてリリースされました。これは、主にインターフェース定義言語（IDL）であるプロトコル・バッファー（Protobuf）を使用することにより、古いRPC実装の制限に対処します。Protobufは、構造化データをシリアル化してバイナリーにエンコードします。そのため、データがよりコンパクトになり、より高速な伝送とより高い性能が可能になります。

Protobufでは、コードを中断することなくデータ・フィールドに変更を加えることもできます。これにより、エラーが減り、リアルタイムのデータ共有と処理が可能になります。これらの主要な機能により、gRPC で構築された API は、最新の分散環境、マイクロサービス アーキテクチャ、ストリーミング アプリケーション、およびモノのインターネットシステムとデバイスの接続にとって強力な選択肢となります。

gRPC は「Google Remote Procedure Call（Googleリモート・プロシージャ・コール）」の頭文字のように見えます。しかし、grpc.ioのgRPCチームは、それが「gRPC Remote Procedure Call（gRPC リモート・プロシージャ・コール）」の略であると冗談めかして主張しています。その GitHubのノートでは、「g」がバージョンごとに異なるものを表していると指摘しています(「社交的」から「ガチョウ」、「グアダルーペ川公園保護区」まで)。いずれにせよ、GoogleはgRPCを開発し、2015年にオープンソース・プロジェクトとしてリリースしました。

gRPC は、最新の言語と主要な機能と最適化をサポートする最新のバージョンの RPC を提供します。主な機能：

• プロトコルバッファと呼ばれるインターフェース設計言語（IDL）
• データ送信にHTTP/2を使用
• 双方向ストリーミング
• コードの生成
• 4つの方法のタイプ
• TLS ベースのセキュリティとの統合
• ロギング、トレース、認証などのインターセプターのサポート

一般的にProtobufとして知られるプロトコル・バッファーは、Googleが開発したクロスプラットフォーム・データ形式で、構造化データをシリアル化するために使用されます。実際には、クライアントとサーバーの間の強力な仲介者として機能し、リクエストをバイナリコードにシリアル化して送信します。

このメカニズムは柔軟で効率的であり、プログラミング言語の非依存性、メッセージ・サイズの縮小、より高速な解析と送信を同時に実現します。Javaを使用するアプリケーションは、リクエストが2進数の共通言語に変換されるため、Pythonを使用するアプリケーションと通信できます。人間は読み取ることはできませんが、バイナリは、JSONなどのテキストベースの形式よりもコンピューターでの送信とデコードの速度が高速です。

基本的に、開発者は「.proto」という拡張子を含むテキスト・ファイルを作成します。これには、データ構造に関するすべての情報が含まれています。この情報はスキーマ・ベースのものであり、パラメーター、メソッド、および可能なアウトプット（データの構造の記述）を定義します。たとえば、「ユーザー」についてのエントリがあると、このデータには「名前」、「Eメール・アドレス」、「お気に入りのピザ・トッピング」などが含まれます。

Protobuf のドキュメントによると、これは XML に似ていますが、「より小さく、より速く、よりシンプルです。データを構造化する方法を一度定義すれば、特別に生成されたソースコードを使用して、さまざまな言語を使用して構造化データをさまざまなデータストリームで簡単に読み書きすることができます。」Protobufは仲介者として、さまざまな認証やセキュリティー対策のインストールも可能にします。

開発者は、Protocと呼ばれるコンパイラーを使用して、C#、C++、Dart、Go、Java、Kotlin、Node.js、Objective-C、PHP、Python、Rubyなど、サポートされている複数の言語でコードを生成できます。このコードは多くの機能を果たします。通常、クラスまたはモジュールが含まれ、バイナリへのシリアル化とバイナリからのデシリアル化を処理し、データ交換の複雑さを取り除きます。開発者はネットワークのパッケージ化、マーシャリング、互換性と実装のための更新について心配する必要はありません。Protobuf社がそのすべてを担います。

Protobufのスキーマベースの設計により、開発者はシステム全体を壊すことなく、既存の構造に新しいデータ・フィールドを追加できます。また、新しいデータ・フィールドを追加した後の以前のコードの調整など、API関連の面倒なタスクの更新、保守、処理に必要な労力も大幅に削減されます。ただし、.protoファイルの場合は、最初のセットアップに時間と労力がかかる場合があります。

HTTP/2は、コンピューターやサーバーが情報を交換するために使用するトランスポート・プロトコルで、バイナリー形式を使用してメッセージを送信し、TCP接続を短縮し、ヘッダー圧縮を使用します。そのすべてが、以前のプロトコル（HTTP/1.1）より高速で効率的です。また、マルチプレクシング、つまり単一の接続で複数のストリームを同時に送信する機能も可能になります。gRPCでは、チャネルと呼ばれるものを使用して、複数の接続上で複数のストリームを有効にします。メッセージはHTTP/2データ・フレームとして送信され、それぞれのデータ・フレームには複数のgRPCメッセージが含まれる場合があります。

gRPC は双方向ストリーミングを提供し、クライアントとサーバーの両方がそれぞれ独立して読み取り/書き込みストリームでメッセージを送信できます。この方法では、サーバーとクライアントが順番に応答を交換したり、サーバーがクライアントのメッセージをすべて受信するまで待機して応答したりするなど、あらゆる種類の柔軟性が可能になります。この機能は、個別のアプリケーションに応じて調整できます。

gRPCは、protocと呼ばれるコンパイラー・ツールを使用して、.protoで定義されたサービス定義とメッセージ構造に基づいて、さまざまな言語でクライアントとサーバーの両方のコードを自動的に生成します。プラグインを使用して、より多くの言語をサポートできるよう拡張できます。

Protocは、プロトコル定義で定義された言語でデータ・アクセス・クラスを生成します。これらのクラスは、[name]のようなフィールドのための単純なアクセサーと、生のバイトとの間で構造をシリアライズおよび解析するためのメソッドを提供します。¹

gRPC は、データ送信で、単項式、クライアント側ストリーミング、サーバー側ストリーミング、双方向ストリーミングという 4 つの異なる方法をサポートしています。

gRPCにはTLS（トランスポート層セキュリティー）との統合が組み込まれており、クライアントとサーバー間のデータ交換を暗号化することで、ユーザーは安全な接続を実現できます。

gRPC は、プラグ可能認証、トレース、ロギング、メトリクス、ロード・バランシング、ヘルス・チェックなどをサポートします。

gRPCには4つの異なるタイプのメソッドがあり、gRPCクライアントとgRPCサーバーによってメッセージがどのように送受信されるかを示します。その種類は次のとおりです。

単項式：クライアントが一つのリクエストを送り、サーバーが一つのレスポンスを返す単純なコール。

サーバーサイド・ストリーミング：クライアントが1つのリクエストを送信し、サーバーが複数のレスポンスを返信するコール。

クライアントサイド・ストリーミング： クライアントが複数のリクエストを送信し、サーバーが単一のレスポンスで応答するコール。サーバーは、処理と応答の前に、クライアント要求のストリーム全体が停止するのを待つことを選択できます。

双方向ストリーミング：クライアントとサーバーの両方が複数のコールを同時に送り返し、リアルタイム通信を可能にします。

gRPC とREST はどちらも、API 設計でよく使用されるアーキテクチャ スタイルです。これらには多くの類似点があります。どちらもクライアント/サーバー アーキテクチャに従っており、HTTP ベースの通信に依存しており、ステートレスであり、言語に依存しません。ただし、どのユースケースで最適になるかは異なります。

データ形式： REST APIは、JSONやXMLなどのプレーンテキスト形式を使用します。gRPCはProtobufを使用してデータをバイナリにエンコードします。

通信パターン： gRPCは、単項式、サーバー・ストリーミング、クライアント・ストリーミング、双方向ストリーミングの4つの方式をサポートしています。REST は、要求と応答の単項システムを使用します。

コード生成：gRPCには組み込みのコード生成機能がありますが、RESTにはその機能はなく、プラグインで対応する形になります。

設計パターン： gRPCはサービス指向の設計を採用しており、呼び出し可能なサーバー操作がサービスや関数として定義されます。RESTでは、設計はリソース指向であり、URLで定義されたエンドポイントを介して、HTTPメソッドを使用してサーバーのリソースにアクセスします。

ただし、gRPCはHTTP/2を使用する一方、RESTはHTTP/1.1に依存しています。

結合：gRPCのクライアントとサーバーは密結合しており、両者が同じミドルウェアのprotoファイルにアクセスできる必要があります。一方を変更すると、もう一方も変更する必要があります。RESTは疎結合です。この独立性により、片方のコンポーネントを変更してももう一方には影響しません。

gRPCは、分散環境内の複数のサービスを接続する複雑なAPIによく使用されます。gRPC は、リアルタイム ストリーミング機能と高性能を備えているため、マイクロサービス、ストリーミング、モノのインターネットのクライアントの接続など、さまざまなユースケースに適しています。

gRPC は、高性能で低遅延、大量のデータを処理できる機能、リアルタイムの双方向ストリーミング機能を備えているため、マイクロサービスの API の作成によく使用されます。

gRPC は言語に依存しないため、異なるプログラミング言語で記述されたサービス間の通信が可能になります。さらに、Protobuf定義は、マイクロサービスのデータ整合性の保護に役立つ、強力にタイプ化されたスキーマを提供します。

gRPC の双方向ストリーミング機能とは、単一のネットワーク接続上で、クライアントとサーバーの間で両方の方向にデータを同時にストリーミングできることを意味します。この機能により、gRPCはビデオ会議などの進行中のプロセスや、ユーザーが他のデータの転送中にデータセットの一部を使用したい場合に最適です。

モノのインターネット（IoT）とは、接続されたデバイスまたはクライアントのネットワークを指します。IoTデバイス—「スマート・オブジェクト」とも呼ばれる—には、スマート・サーモスタットのような単純な「スマート・ホーム」デバイス、スマートウォッチやRFIDタグ付き衣服などのウェアラブル端末、複雑な産業機械および輸送システム型などがあります。² gRPC APIは、これらのデバイス間の一貫したデータ交換を促進するためによく使用されます。

双方向ストリーミングのサポートとマイクロサービス対応の機能（および CNCF プロジェクトとしてのステータス）により、gRPC はクラウドネイティブAPI でますます使用されるようになっています。

gRPCは、さまざまなプログラミング言語でクライアント・ライブラリを生成するために使用されます。これらのライブラリは、.protoファイルで提供されるサービス定義に基づいて生成されます。サービスが定義されると、gRPCは選択されたプログラミング言語でクライアントコードを自動的に生成します。

この機能により開発者の作業が簡素化され、低レベルの通信コードではなくアプリケーション・ロジックに集中できるようになります。

gRPCは、高性能要件でAPIを構築する組織や開発者に多くのメリットをもたらします。そのメリットは以下のとおりです。

より高速かつ効率的な伝送： gRPCの性能に寄与する要因がいくつかあります。1つは、Protobufシリアル化によりメッセージ・サイズが小さくなり、小さなパッケージをより迅速に送信できることです。また、バイナリは、JSONやXMLなどの平文形式よりも効率的に解析されます。

さらに、gRPCはHTTP/1.1よりも高速で効率的なHTTP/2を使用し、レイテンシーと帯域幅の使用量をさらに削減します。

移植性の向上：gRPCはプロトコルバッファ（言語やプラットフォームに依存しないシリアル化メカニズム）を使用してデータ構造とRPCインターフェイスを記述するため、さまざまなプラットフォーム間でさまざまな言語で記述されたサービス間の通信が可能になります。

ランタイム・エラーの削減：Protobufは強力な型付けを可能にします。つまり、明示的に定義されたデータ構造を強制するということです。強力な型付けにより、一貫性と早期のエラー検出が促進され、実行時にエラーが発生する可能性が減ります。

柔軟なカスタマイズ： ミドルウェアの組み込みサポートにより、セキュリティーや認証対策、分析ツールなどの主要な機能のカスタマイズや追加が可能になります。

gRPCには多くの利点がありますが、課題がないわけではありません。たとえば、使いやすさが最優先事項となるシンプルなデータ・ソースを備えた公開APIなど、場合によっては、gRPCによって生じる複雑さは不必要な場合があります。gRPCの課題には次のようなものがあります。

複雑さ： gRPCが必要とするようにメッセージ構造とサービスの定義を.protoファイルで行う場合、XMLやJSONなどのテキストベースの形式を扱うよりも困難な場合があります。

使いやすさ： gRPC、プロトコル・バッファ、HTTP/2は、RESTの扱いに慣れた開発者にとっては急な学習曲線となる可能性があります。

デバッグ： バイナリ形式は人間が読み取れるものではないため、gRPCアプリケーションの検査、デバッグ、ログ記録が困難な場合があります。バイナリを変換できるツールはありますが、XMLやJSONと比較して追加の手順が必要です。

最新性とサポート： gRPCは、RESTなどの他の一般的なアーキテクチャーほど古くはなく、それほど大規模なコミュニティーやプラグインやドキュメンテーションのサポートは多くありません。新しいフレームワークとして、gRPCで利用できるツール（セキュリティー・スキャナー・ツールなど）は、より確立されたスタイルと比べて少なくなります。

ブラウザー非対応：WebブラウザーはgRPCプロトコルをネイティブにサポートしていないため、ブラウザー・ベースのアプリケーションから直接gRPCサービスを呼び出すことはできません。この問題を回避する方法の1つとして、gRPC-Webのようなプロキシーを利用する手段があります。gRPC-Webは、ブラウザーのHTTPとgRPCプロトコルとの間の変換レイヤーとして機能します。

Webアプリケーションは、gRPC-Web JavaScriptクライアント・ライブラリーを使用してgRPC呼び出しを開始し、ブラウザー互換に適応したgRPCリクエストを送信します。リクエストはプロキシ・サーバーに送信され、プロキシ・サーバーはそのリクエストを標準gRPCリクエストに変換して、gRPCバックエンド・サーバーに転送します。gRPCサーバーはリクエストを処理し、プロキシ・サーバーに応答を送り返します。プロキシは、その応答を再度gRPC-Web形式に変換してから、クライアントに送り返します。