gRPC vs REST API Communication

二つの異なるソフトウェアがやり取りする状況を考えると、まるでQ&Aのように、一方が特定のデータや操作を求めるリクエストを送り、もう一方がそれを確認して必要な情報を返したり、所定の処理を行ったりします。こうした問い合わせと応答の継続的なやりとりこそがAPIの本質です。

要するに、APIはソフトウェア同士が対話するときに使うルールや手順をまとめたものです。問い合わせと応答の形式を標準化することで、異なるアプリ間でのスムーズなやり取りを実現しています。

APIのやりとりにはいろいろな形がある

APIのやりとりには統一的なパターンはなく、使い方によって形態が変わります。代表例としてはREST（Representational State Transfer）とgRPC（Google Remote Procedure Call）があります。

1. REST: インターフェース設計の一つとして、HTTPのGET、POST、PUT、DELETEなどの操作を用いてURLで示されるリソースを扱います。ステートレスな方針をとり、リクエスト内に必要な情報をすべて含めることで、クライアントとサーバーのやり取りを明確化しています。
2. gRPC: Googleが提案する柔軟なフレームワークで、Protocol Buffersというデータ形式を採用し、ユーザー認証や負荷分散、ストリーミングなどの機能を備えています。RPC（リモートプロシージャコール）の仕組みに基づき、サーバーの操作をあたかもローカルで呼び出しているように実行する設計になっています。

APIのやりとりの重要性

APIのやりとりは、拡張性に富んだ進歩的なソフトウェア設計にとって欠かせない役割を持ちます。異なる技術や環境にとらわれずにソフトウェア同士がやり取りを行えるため、柔軟で管理しやすいシステムを構築しやすくなるからです。

また、APIを通じたやりとりは分散システムの進化にも寄与します。ソフトウェアのさまざまな部分が独立して動作しながら、複数のマシンや地理的に離れた場所で連携するため、全体の効率性や信頼性、スケーラビリティを高められます。

総じて、APIのやりとりは複雑なソフトウェアを作り上げるうえで欠かせない要素です。異なるソフトウェア部品間のコミュニケーションを円滑化し、動的かつスケーラブルで分散型のアプリを構築する道筋を整えます。ソフトウェアの要件に合わせてRESTを用いるか、gRPCを採用するかはケースバイケースです。

RESTとgRPCを定義する

RESTを読み解く：Representational State Transferの枠組みを詳しく見る

インターネットを利用したアプリ開発の中で、Representational State Transfer（REST）という用語を耳にすることがあります。これは単なる言葉ではなく、アーキテクチャの設計理念を示すモデルです。HTTP操作を活用して、クライアントとサーバーが特定の状態に依存せず通信します。クライアントのリクエストによってリソースを取得・更新・移動することで、サーバーが応答する仕組みです。

RESTfulな方式では、データやエンティティ、サービスなどの再利用可能な要素を、クライアントが簡単に利用できる形で公開します。こうしたリソースはURI（Uniform Resource Identifier）で指定され、クライアントはGETやPOST、PUT、DELETEといった標準のHTTP操作を行います。

よくあるRESTの利用例は以下のようになります。

 
GET /users/123 HTTP/1.1
Host: api.example.com

この場合、クライアントはユーザーID123の情報を取得しようとサーバーへリクエストを送っていることがわかります。

gRPCを見てみる：Googleが提案するリモートプロシージャコールの概要

一方、Googleが開発したgRPCは、機能指向の通信フレームワークです。RESTがリソース指向でデータの取得や送信を中心に考えるのに対し、gRPCはあたかもサーバー上の処理をローカル関数のように呼び出せる点が特徴です。これはProtocol Buffers（protobuf）を使い、双方向ストリーミングなど高度な通信機能を提供します。

gRPCの中心を担うProtocol Buffers（Protobuf）は、.protoファイルを使ってサービスやメッセージを定義し、コンパイラでコード生成をすることで多言語対応が可能です。

.protoファイルは次のように記述できます。

 
service UserProfile {
  rpc RetrieveUser (UserRequest) returns (UserResponse);
}

message UserRequest {
  string id = 1;
}

message UserResponse {
  string name = 1;
  int32 age = 2;
}

この例ではUserProfileというサービスにRetrieveUserというRPCが定義されており、UserRequestを受け取ってUserResponseを返します。

複数のプログラミング言語との高い親和性を持つため、gRPCは幅広い開発現場で活躍します。同期・非同期の両通信に対応し、同期ではサーバーの応答を待ちますが、非同期では応答を待たずにクライアントが他の処理を進められます。

まとめると、RESTがネットワークを利用したアプリの設計思考を示すのに対し、gRPCは高性能で多機能な通信基盤を提供します。どちらもそれぞれ利点と課題を持ち、以降のセクションで詳しく解説します。

REST APIの歴史と発展

Resistive Static Transmission（REST）APIというアイデアは、カリフォルニア大学アーバイン校の博士課程で2000年にRoy Fielding氏の研究から生まれました。既存のウェブ上の仕組みを改善するために提唱されたのが、このRESTのアーキテクチャでした。

RESTの発展

ウェブの特徴である拡張性やステートレス構造に整合する形で、Fielding氏はRESTをつくりあげました。インターネットがもつ分散性や堅牢性を活かせるように設計されている点が大きな特徴です。

RESTはウェブを構成するあらゆる要素（ドキュメント、画像、動的なサービスなど）を「リソース」としてとらえ、各リソースにURIを割り当てます。クライアントはHTTPのGET、POST、PUT、DELETEなどの操作を使って、これらのリソースにアクセス・操作します。

REST APIの進化

REST APIは時代とともに発展し、多くのウェブサービスにとって標準的な手法になりました。進化を後押しした要因として以下が挙げられます。

1. 簡潔さ: REST APIは設計がシンプルで、実装しやすいことが大きな利点です。インターネットの仕組みをそのまま利用するため、追加のツールが不要です。
2. 拡張性: ステートレスな性質により、クライアントとサーバーのやり取りに必要な情報をリクエストにすべて含めるため、大量のリクエストにも対応しやすい設計です。
3. 効率性: HTTPなど標準的なプロトコルを活用するため、キャッシュと組み合わせることでパフォーマンスが向上します。
4. 柔軟性: REST APIは特定のプラットフォームに依存しないので、さまざまな環境や言語で利用できます。そのおかげで多様なシステムと連携しやすいです。

現在のREST API

現在、REST APIはIoTからクラウドサービス、モバイル、ウェブアプリまで幅広く使われています。多種多様なシステム間のデータ交換やサービス連携の土台となっています。

ただし、大規模データや複雑なリクエストでは、RESTのJSON形式が冗長になる場合があります。HTTPを前提とすることで、一部の処理において効率的でない例もあります。このため、GraphQLやgRPCなどの新たな手法も普及しつつあります。

とはいえ、REST APIのシンプルさや拡張性は今も変わらず重要です。Fielding氏のビジョンは今日のネット社会でも広範に活躍し続けており、その応用領域と実装技術はさらに広がりをみせています。

gRPCサービスの歴史と発展

2015年、Googleはリモートプロシージャコール（RPC）のあり方に革新をもたらすgRPCを発表し、Linux Foundationの一部門であるCloud Native Computing Foundation（CNCF）の支援を受けました。

gRPC：新時代の幕開け

大規模な分散システムを運用してきたGoogleの知見をもとに生まれたgRPCは、高い汎用性と効率性を持つ技術です。マイクロサービスの多様な要求に応えられるよう、RPCの概念にHTTP/2の強みを組み合わせた設計になっています。

gRPCの普及

gRPCは最初C++、Java、Python、Goなど10の言語に対応してスタートしましたが、現在ではさらに対応言語が拡大し、NetflixやCisco、Juniper、Squareといった大手企業でも導入されています。オープンソースのコミュニティでも広く受け入れられています。

gRPCとHTTP/2の融合

gRPCが採用するHTTP/2は、複数のストリームを単一のTCP接続で扱う多重化やフロー制御、ヘッダ圧縮、サーバープッシュなどの機能を備えており、高速かつ効率的なRPCシステムにぴったりです。これにより、リクエストあたりの接続確立コストが下がり、双方向ストリーミングが実現します。

プロトコルバッファの採用

gRPCの目玉の一つがProtocol Buffers（Protobuf）との連携です。Googleが独自に開発したバイナリフォーマットで、高速かつ柔軟なシリアライズ・デシリアライズを可能にします。gRPCはProtobufを使ってクライアントとサーバー双方のコードを自動生成し、開発を効率化します。

さらなる発展

gRPCは、高パフォーマンス、多言語対応、相互運用性といった特徴を武器に発展を続けています。Googleやさまざまなコミュニティによる継続的な改良で、トレーシングやヘルスチェック、ドキュメント拡充なども進んでおり、分散システムやマイクロサービスの分野での存在感がますます高まっています。

REST APIの主要な特徴

RESTはウェブサービスを作るための建築的なアプローチです。この方法によって複数の原則が規定され、ウェブ上でのやり取りをよりシンプルかつ柔軟にする仕組みを提供します。RESTをきちんと実装したサービスは、リソースの取得や更新、共有を標準的なプロトコルを使って行います。

特徴1: ステートレス

REST APIでもっとも重要なのがステートレス性です。ステートレスとは、連続するリクエストの間にサーバー側で状態を保存しないことを指します。リクエストには必要な情報をすべて含むため、サーバーの可用性や拡張性が向上します。

特徴2: クライアントとサーバーの分離

RESTではクライアントはユーザーインターフェースとデータ表示を担当し、サーバーはリソース管理や機能実行を担います。役割を明確に分けることで、クライアントやサーバーを独立して開発・拡張しやすくなります。

特徴3: キャッシュ可能

REST APIはHTTPプロトコルのキャッシュ機能を利用できます。サーバーの応答に対してキャッシュの可否を指定することで、クライアントは同じリソースを繰り返し取得しなくてもよくなります。これによりネットワーク負荷が減り、パフォーマンスが向上します。

特徴4: 階層構造

REST APIは階層化されたシステム設計を想定しています。コンポーネントが段階的に分けられているため、ある層の変更がほかの層に直接影響を与えにくく、システムを柔軟に保ちやすいです。

特徴5: 統一インターフェース

RESTは統一されたインターフェースを重視します。クライアントとサーバーが独立していても、共通のやり方でやり取りできるようにするためです。具体的には以下の考え方を含みます。

1. リソースを中心とした設計: URIで一意にリソースを識別し、GETなどの操作でデータを取得します。
2. 操作によるリソースの変更: レスポンス情報を使ってリソースを更新したり削除したりします。
3. 自己完結型メッセージ: 各リクエストやレスポンスに、どう処理すべきか明確な情報を含みます。
4. HATEOAS: サーバーから送られるリンクをたどって、クライアントが次の操作を見つけられるようにします。

特徴6: コードオンデマンド（オプション）

RESTの設計では、クライアントが必要に応じてサーバーからコード（スクリプトなど）を受け取り、機能拡張できる仕組みも用意されています。ただし、この機能は必須ではありません。

まとめると、ステートレスやクライアントとサーバーの分離、キャッシュ活用、階層化、統一インターフェースなどの特性が、REST APIを柔軟かつ拡張性の高いウェブサービス構築に最適な選択肢にしています。

gRPCサービスの主要な特徴

gRPCはGoogleが公開しているオープンソースのソフトウェアで、クライアントとサーバー間の通信を効率化する目的で設計されています。RESTなど他のプロトコルと比べて特筆すべき利点があります。

Protocol Buffersの活用

gRPCを支える基盤技術がProtocol Buffers（Protobuf）です。Googleが開発したデータ構造化の仕組みで、バイナリ形式のシリアライズにより高速にデータを取り扱えます。さらに複数言語へのコード生成が可能なので、幅広い環境で同じデータ構造を扱いやすいです。

例として、Personオブジェクトを定義するProtobufコードは以下のようになります。

 
message Person{
  string name = 1;
  int32 id = 2;
  string email = 3;
}

高いパフォーマンス

gRPCはHTTP/2の特徴を生かし、単一のTCP接続で複数のリクエストを並行して処理できます。ヘッダ圧縮やサーバープッシュなどの機能により、特に大量の通信が必要な場面で遅延を大幅に抑えます。

双方向ストリーミング

gRPCはクライアントとサーバーの双方向ストリーミングをサポートします。お互いが同時に複数のメッセージを送受信できるため、リアルタイム性が必要なアプリにとても有効です。

柔軟な拡張性

gRPCには負荷分散やトレーシング、ヘルスチェック、セキュリティ機能などを統合しやすい仕組みがあります。また、アクセス制御にトークンベースの認証を組み込むなど、多様な運用環境に対応できます。

多言語サポート

C++、Java、Python、Go、Ruby、Node.jsなど多くの言語に対応しているため、サーバーをJavaで書き、クライアントをPythonで書くといった混合環境でもスムーズに通信ができます。

このように、gRPCはデータ処理の高速化、信頼性、スケーラビリティ、多言語対応を実現するAPI開発手法として注目されています。

アーキテクチャスタイル: REST vs gRPC

APIインターフェースは、情報の受け渡しや処理の仕組みに合わせて特定のプロトコルやモデルを採用します。ここではRESTとgRPCのアーキテクチャ観点を比較し、両者の特徴と役割について整理します。

RESTの考え方

REST（Representational State Transfer）は状態に依存しないステートレス性を保ち、スケールが容易で拡張可能な通信形態を提供します。URIでリソースを識別し、HTTPメソッドを使ってやり取りを行うのが基本です。クライアントがリクエストを送り、それを元にサーバーはJSONやXMLなどの形式でデータを返します。

RESTの特徴としてはステートレスな点が挙げられます。つまり、サーバー側がクライアントの状態を記憶しないでリクエストを処理し、拡張性と信頼性を高めます。

gRPCの考え方

これに対し、gRPC（Google Remote Procedure Call）はGoogleの開発した高性能なRPCフレームワークで、サービスやメソッドを中心に通信を行います。Protocol Buffersでサービスとメッセージを定義し、HTTP/2上でデータの送受信を実施します。RESTがHTTP+JSONベースなのに対し、gRPCはHTTP/2+Protocol Buffersという組み合わせを採用します。

複数のリクエストを同時に処理したり、双方向でストリーミングしたりする機能に比重が置かれている点が大きな特徴です。

主な相違点

RESTとgRPCを比較すると、次のような違いがあります。

1. リソース指向かメソッド指向か: RESTはURIで特定のオブジェクトを指して操作するのに対し、gRPCはサーバーのメソッドを遠隔呼び出しする形です。
2. 状態管理: RESTはステートレス運用が基本ですが、gRPCは長いセッションに対応しやすく、ストリームの利点を活かせます。
3. 通信プロトコル: RESTはHTTP/1.1が中心ですが、gRPCはHTTP/2により多重化や圧縮を生かした高速通信が可能です。
4. データ形式: RESTは人間が読みやすいJSONを主に使いますが、gRPCはバイナリ形式のProtocol Buffersを使い、高速かつ軽量です。
5. サービス定義: gRPCは.protoファイルで明確にサービスとメッセージを定義するため、より強力に型を保障できます。

総じて、RESTとgRPCは設計思想と使う技術が異なります。サービスが求めるリアルタイム性やデータの複雑さ、スケーラビリティ要件などを踏まえて、どちらを選ぶかを検討する必要があります。

RESTにおけるリソースメソッド

REST（Representational State Transfer）では、システムを複数のリソースとして分割し、HTTPプロトコルを使って操作します。リソースとは、データ要素または機能の集まりを指し、URIを介してアクセスします。

RESTでのリソース操作

RESTではHTTPのメソッド（GET、POST、PUT、PATCH、DELETEなど）を用いてリソースを操作するのが基本です。

1. GET: リソースの読み取り
2. POST: 新しいリソースの作成
3. PUT: 既存リソースの全体更新
4. PATCH: 既存リソースの部分更新
5. DELETE: リソースの削除

これらのメソッドは、以下のような特徴を持ちます。

冪等性と安全性

冪等性とは、同じ操作を何回繰り返しても結果が変わらない性質を指します（GET、PUT、DELETEなど）。安全性とは、リソースを変化させない操作のことを言い、GETは安全な操作とみなされます。

RESTful APIでのメソッド実践

RESTful APIを設計する際は、CRUD（Create、Read、Update、Delete）の各操作にHTTPメソッドを対応させるのが一般的です。リソースをURIで管理し、適切なメソッドを呼び出すことでAPI設計をわかりやすく保てます。

例としてブログのAPIを考えると、/articlesをリソースとし、GET /articlesで記事一覧を取得し、POST /articlesで新規記事を投稿、GET /articles/{id}で特定記事の取得、PUT /articles/{id}で記事更新、DELETE /articles/{id}で記事削除、といった形です。

こうしたリソースメソッドを理解すると、REST APIを設計しやすくなり、クライアントも使い方を直感的に把握できます。

gRPCにおけるRPCの理解

Google発のgRPCフレームワークでは、APIインターフェースにおけるコアな仕組みとしてRPC（リモートプロシージャコール）を活用します。ここではRPCとは何か、gRPCとどう結びつくのかを簡単に見てみます。

RPCとは

RPCは、ネットワークの向こう側にあるサービスを、あたかも手元で呼び出しているかのように扱う仕組みです。クライアントがサーバーに対して関数呼び出しを行うイメージで、サーバーはその呼び出しを受けて処理し、結果を返します。

RPCとgRPCの関係

gRPC（Google Remote Procedure Calls）は、このRPCの考え方をさらに発展させてHTTP/2上で動作させ、Protocol Buffersを用いた高効率なデータ通信を実現しています。gRPCは以下の4つのRPCスタイルを提供します。

1. Unary RPC: クライアントが1回リクエストを送信し、サーバーから1回レスポンスを受け取る最も基本的なパターン
2. Server streaming RPC: クライアントが1回リクエストを送信し、サーバーが複数のレスポンスをストリーミングで送り返す方法
3. Client streaming RPC: クライアントが複数のリクエストをストリーミングで送り、最後にサーバーが1回レスポンスを返す方法
4. Bidirectional streaming RPC: クライアントとサーバーが双方に複数のメッセージをストリーミングでやり取りする方法

 
# Unary RPCの例

def GetFeature(self, request, context):
    feature = self.GetFeature(request)
    if feature is None:
        return route_guide_pb2.Feature(name="Locationに該当なし", location=request)
    return feature

上記のPythonコード例は、gRPCサーバー内でUnary RPCを行うシンプルなイメージです。クライアントが単一のリクエストを送り、サーバーは単一のレスポンスを返す形を示しています。

RPCにおけるProtobufの役割

gRPCでは、サービスインターフェースとメッセージ形式をProtocol Buffersで定義します。以下のように.protoファイルに書くと、gRPCがクライアントやサーバー用のコードを自動生成してくれます。

 
service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

上記では SayHello というRPCメソッドが HelloRequest を受け取り HelloReply を返す仕様になっています。

まとめ

RPCとgRPCの結びつきを理解すると、gRPCの柔軟かつ強力な通信手法を使いこなしやすくなります。RPCのさまざまな形態とProtocol Buffersによる定義の明確化により、大規模で複雑なシステムやマイクロサービスを構築する際にgRPCは大きな強みを発揮します。

データ形式: JSON vs Protocol Buffers

APIによる通信では、扱うデータ形式の選定がパフォーマンスや可用性に直結します。RESTとgRPCで主に使われる形式として、JSON（JavaScript Object Notation）とProtocol Buffers（Google開発）があります。それぞれの特性や利点、使用場面を比べてみます。

JSONの特徴

JSONはテキストベースで、人が読みやすい形に整形できる軽量なデータ形式です。キーと値のペアと配列によってデータを表現します。JavaScript由来ですが、言語非依存のため多くのプログラミング言語で取り扱いやすくなっています。

JSONの例として以下のようなデータ構造があります。

 
{
  "person": "Deborah Smith",
  "age": 26,
  "location": "San Francisco"
}

Protocol Buffers（Protobuf）

Protocol Buffers（Protobuf）は、Googleで開発されたバイナリ形式のシリアライズ手法です。データ構造を.protoファイルで明示的に定義し、それをコンパイルして各言語に対応したコードを生成します。JSONよりもコンパクトかつ高速なシリアライズ・デシリアライズが特徴です。

以下はProtobufのシンプルな例です。

 
message Individual {
  required string person = 1;
  required int32 age = 2;
  optional string location = 3;
}

JSONとProtocol Buffersの主な違い

1. 可読性

JSONはテキスト形式で人にもわかりやすいですが、Protobufはバイナリ形式なので人が直接読むのは難しいです。

2. パフォーマンスとデータサイズ

Protobufはバイナリ形式なので、JSONよりも圧倒的にデータサイズが小さく、高速です。大規模システムや高トラフィックな環境では有利といえます。

3. スキーマ互換性

Protobufは.protoファイルでスキーマを定義し、後からフィールドを追加しても旧バージョンが破壊されません。一方、JSONはスキーマレスなので柔軟ですが、スキーマの進化管理は開発側の運用次第です。

4. 多言語サポート

JSONとProtobufはいずれも幅広い言語で利用できます。しかしProtobufは専用コンパイラでコードを生成するため、型安全性が高く、高速に動作します。

まとめ

シンプルさや人へのわかりやすさを重視するならJSONが適しており、大規模データや性能が重要な場合はProtobufが有利です。APIの要件やデータ量に応じて選択するとよいでしょう。

パフォーマンス比較: REST vs gRPC

API通信においては、応答速度や同時接続数、CPUリソース使用率などのパフォーマンス要因が不可欠です。ここではRESTとgRPCを比較して、それぞれの特徴をざっと確認します。

パフォーマンスにかかわる要素

APIのパフォーマンスを左右する指標としては以下が代表的です。

• リクエスト-レスポンスタイム: リクエストを送信してからレスポンスを受け取るまでの時間
• 同時リクエスト処理数: 一定時間内にどれだけのリクエストを捌けるか
• CPUリソース消費: 通信処理にどれだけのCPUが使われるか

RESTのパフォーマンス

RESTはHTTP/1.1を使い、データ形式としてJSONを選ぶことが多いです。テキストベースなので可読性が高い反面、情報量が増えるとオーバーヘッドが大きくなります。

リクエスト-レスポンスタイム

RESTの場合、しばしばリクエストごとに接続を張り直し、JSONのパースも負荷になるため、応答時間が長くなりがちです。

同時リクエスト処理数

HTTP接続のオーバーヘッドとJSONのシリアライズ・デシリアライズで、同時処理数が多い状況になるとリソース消費が増えやすいです。

CPUリソース消費

文字列解析が絡むため、データ量が多いとCPU負荷も高くなります。

gRPCのパフォーマンス

gRPCはHTTP/2とバイナリ形式のProtocol Buffersを使うため、高速かつ軽量です。

リクエスト-レスポンスタイム

HTTP/2の多重化によって、単一のTCP接続で複数リクエストを同時に処理でき、レスポンスタイムを短縮できます。Protobufも処理が高速です。

同時リクエスト処理数

HTTP/2により大量の並行リクエストをコンパクトに処理できるため、スループットが上がります。

CPUリソース消費

バイナリ形式でデータサイズが小さいので、シリアライズ・デシリアライズのCPU負荷が低く効率的です。

比較一覧

性能面で見ると、RESTは実装や学習コストが比較的低く人気があるものの、高負荷環境ではオーバーヘッドが大きくなる点に注意が必要です。一方、gRPCは高速・軽量という利点があるため、大量データや高スループットを要求されるシステムに向いています。

セキュリティ面：gRPC vs REST

APIを考える上でセキュリティは欠かせません。gRPCとRESTそれぞれで採用されるセキュリティ面の仕組みや方法を比較してみます。

RESTのセキュリティ

RESTful APIではHTTP/HTTPSの仕組みをそのまま利用するため、SSL/TLSが主な防御手段になります。

1. SSL/TLS: SSLの後継にあたるTLSは公開鍵暗号や共通鍵暗号を組み合わせ、データを暗号化して通信を守ります。
2. トークン認証: RESTでは通常、クライアントがユーザー名やパスワードなどの情報で認証を行い、認証サーバーから受け取ったトークンをHTTPヘッダーに載せてリソースにアクセスします。
3. OAuth: OAuthは認可のためのオープン標準プロトコルで、ユーザーの認証情報を渡さずに他のサービスにアクセスを与える仕組みを提供します。

以下はトークンを使ったREST APIの例です。

 
import requests

url = "https://api.samplenetworking.com/info"
headers = {"Authorization": "Bearer YOUR_ONE-TIME_PASSKEY"}

response = requests.get(url, headers=headers)

gRPCのセキュリティ

gRPCでもベースにSSL/TLSを使用し、トークン認証などRESTと同様の手法を採れますが、さらに拡張的な仕組みが備わっています。

1. SSL/TLS: REST同様、gRPCでも通信を暗号化するためにSSL/TLSを使用します。
2. トークン認証: gRPCでは各RPC呼び出しにトークンを含める方法で認証可能です。
3. Googleのトークン認証: Googleオープンソースらしく、OAuth2による認証にも対応します。

下記はトークンを使ったgRPCの認証の例です。

 
from grpc import insecure_channel
from grpc.credentials import access_token_call_credentials

channel = insecure_channel('localhost:50051')
cred = access_token_call_credentials('YOUR_ONE-TIME_PASSKEY')
secure_conn = channel.intercept_metadata([('authorization', 'Bearer ' + 'YOUR_ONE-TIME_PASSKEY')])

stub = YOUR_SERVICE.Stub(secure_conn)

RESTとgRPCのセキュリティの比較

基本的に、RESTもgRPCも同等のセキュリティ機能を利用可能です。ただし、利用するプラットフォームやブラウザとの相性、企業の方針によってお問い合わせや選択が分かれるケースがあります。

スケーラビリティの比較

API通信基盤を選ぶ際、将来的にどれだけ拡大できるかは大事な要素です。RESTとgRPCのスケーラビリティを比べてみましょう。

RESTのスケーラビリティ

RESTはステートレスかつHTTPに準拠しているので、水平方向にサーバーを増やすスケールアウトがしやすいです。キャッシュ機構とも相性がよく、大量アクセス時でもサーバー負荷を分散できます。欠点としては、大量のデータをやり取りする際にJSONが冗長になりがちな点です。

gRPCのスケーラビリティ

gRPCはHTTP/2の多重化などにより接続のオーバーヘッドが少ないため、高負荷でも効率よくさばけます。Protocol Buffersの効率的なシリアライズによって大量データにも対応しやすいです。ただし、持続的な接続を多用すると、リソース管理が複雑になる懸念もあります。

主な比較

RESTはステートレス性やキャッシュを標準機能として扱いやすく、gRPCはHTTP/2やバイナリ形式で高い処理効率を誇ります。アプリの種類やデータ規模、運用要件によって選択するとよいでしょう。

部分的な障害の扱い: RESTとgRPC

分散システムでは、一部のリクエストやノードに障害があっても残りの機能を維持する設計が重要です。RESTとgRPCでは、こうした「部分的な障害」の扱いが異なるので、比較してみます。

RESTにおける部分的な障害

RESTの場合、HTTPステータスコードで結果を表現します。例えば、200は成功、404はリソースなしを示唆します。206というステータスを返して「一部の内容しか取得できませんでした」と伝えるなど、HTTPの枠組みに合わせてエラーメッセージを返却します。

レスポンスボディには追加情報を含めることも可能です。たとえば、エラーの詳細や検証エラーなどをJSON形式で返すことで、クライアント側は問題箇所を把握しやすくなります。

 
HTTP/1.1 206 Partial Content
Content-Range: bytes 0-499/1234

{
  "error": "ネットワークの制限で一部しか取得できません"
}

gRPCにおける部分的な障害

gRPCでは基本的にステータスコードやエラーディスクリプタを使って結果を伝えます。NOT_FOUNDやUNAVAILABLEなど、RESTのステータスコードより詳細な分類が存在します。Unary RPCならエラーを一度返すだけですが、ストリーミングRPCでは途中でエラーが返されるケースもあります。

最終的なレスポンスとは別に、メッセージ単位での返信も行えるので、部分的な障害をきめ細かく伝達する設計が可能です。

RESTとgRPCの違い

• RESTはHTTPステータスコードに基づき、必要に応じてJSONで詳細を書くスタイル。
• gRPCはより細分化されたステータスコードと、ストリーミング途中での障害通知が可能。
• RESTはステートレスな分、再試行などはクライアント側で実装する必要があるが、gRPCは組み込みのリトライメカニズムを利用しやすい。

つまり、障害対応や再試行ロジックをどう組み込むかによって、RESTかgRPCのどちらが使いやすいかが変わってきます。

REST APIの主な利用シーン

RESTはシンプルでわかりやすい仕組みのため、さまざまなアプリケーションに取り入れられています。以下は代表的な事例です。

ウェブアプリ

ウェブブラウザとサーバー間での通信には、REST APIがよく使われます。たとえばユーザー認証や投稿データの送受信など、HTTPを介した操作が中心となるアプリに向いています。

モバイルアプリ

モバイル端末からサーバーにデータを要求・送信するときもRESTがよく選ばれます。銀行のモバイルアプリやSNSなど、JSON形式でのやりとりがわかりやすい利点があります。

マイクロサービス

小さなサービス同士がHTTPベースで通信する場合、RESTが標準的な選択です。各サービスを独立開発・デプロイできるメリットがあります。

IoTデバイス

センサー情報などを簡易的にサーバーへ送る場合にも、RESTが導入しやすいです。温度センサーなどがAPIを介してデータを送信・受信する仕組みを構築できます。

CMSやSNS

WordPressやDrupalなどのCMSはREST APIを備えており、コンテンツやユーザー管理などを外部サービスと連携できます。TwitterやFacebookなどのSNSでもREST APIを提供しており、投稿の取得や分析がしやすいです。

このようにRESTは、構造がシンプルで広範囲に受け入れられているため、多岐にわたる場面で利用されます。

gRPCサービスの主な利用シーン

Googleが提案したgRPCは、高速・効率的なRPC通信を扱う技術です。特に以下の状況で効果を発揮します。

マイクロサービス間通信

gRPCはHTTP/2を使って、複数サービス間の通信オーバーヘッドを減らすのに向いています。RESTと比べてメッセージがコンパクトで、かつストリーミングを活用できるため、大規模サービスでの内部通信に適しています。

Pythonで実装する場合のgRPCサーバー例は以下のようになります。

 
import grpc, calculator, time
from concurrent import futures
import calculator_pb2
import calculator_pb2_grpc

class CalculatorService(calculator_pb2_grpc.CalculatorServicer):
    def SquareRoot(self, request, context):
        response = calculator_pb2.Number()
        response.value = calculator.calc_sqrt(request.value)
        return response

server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
calculator_pb2_grpc.add_CalculatorServicer_to_server(CalculatorService(), server)
server.add_insecure_port('[::]:50051')
server.start()

try:
    while True:
        time.sleep(86400)
except KeyboardInterrupt:
    server.stop(0)

リアルタイム通信

チャットやライブ配信など、即時に送受信したい場面ではgRPCの双方向ストリーミングが役立ちます。RESTのようにリクエスト-レスポンスの繰り返しをする必要がなく、常時つながったまま情報をやり取りできます。

分散システム

サーバーが複数のノードやデータセンターに分散して動作するようなケースでも、gRPCは多重化で接続負荷を下げ、Protocol Buffersによる効率的なデータフォーマットで通信を最適化します。

モバイルアプリ

帯域に制限があるモバイル環境で、通信をできるだけ軽くしたい場合にもgRPCが有用です。メッセージがコンパクトで双方向ストリーミングにも対応しているため、リアルタイム通知などに向いています。

つまりgRPCは高効率・多言語対応が鍵となるシーンで威力を発揮します。サービス内部やリアルタイム用途、モバイルなど多岐にわたる場面での利用が進んでいます。

RESTの実例

REST APIがどのように利用されているか、代表的な事例をいくつか見てみます。

事例1: Twitter API

TwitterはSNSの大手として知られていますが、RESTベースのAPIを提供しており、ユーザーのツイートやプロフィールなどにアクセスしたり、投稿を自動化したりできます。リソース指向の設計で、エラーなどはHTTPステータスコードとJSON形式のレスポンスで返されています。

事例2: Amazon S3

AmazonのクラウドストレージサービスS3もRESTを利用します。HTTPメソッド（GET、PUT、DELETEなど）を使ってオブジェクトをアップロード・ダウンロードでき、分かりやすいURIで管理します。たとえば撮影した画像をPUTでアップロードして、GETでダウンロードするといった操作が可能になります。

事例3: Google Maps

地図情報を扱うGoogle Maps APIもREST的な設計で、URLパラメータを通じて座標を指定し、JSONやXML形式で緯度経度や経路情報を取得します。例えば、不動産サイトで物件を地図表示する際に活用されています。

これらの例から、RESTはSNSやクラウドストレージ、地図サービスなど幅広い領域で使われていることがわかります。

gRPCの実例

gRPCはその高いパフォーマンス、双方向ストリーミング、多言語対応などを活かし、多くの企業で導入が進んでいます。

Netflixの例

世界的な動画配信プラットフォームであるNetflixは、多数のマイクロサービスを内部で連携させるため、gRPCを導入しています。メッセージのコンパクトさと高速性により、サービス間通信の遅延を大幅に削減しています。

Squareの例

決済サービスを提供するSquareでは、支払い処理や在庫管理など多種多様な機能間でgRPCを利用しています。型安全かつストリーミングが得意な点がメリットとなり、リアルタイム性の要求に応えています。

CoreOSの例

CoreOSが提供する分散キー・バリューストア「etcd」は、クラスタ間通信にgRPCを使っています。HTTP/2による効率良い接続とProtobufの高速処理により、大規模な分散システムでも安定した動作を実現しています。

Ciscoの例

ネットワーク機器大手のCiscoは、IOS XEソフトウェアで活用しています。大規模ネットワーク環境でも負荷分散や接続管理がしやすい特長が評価されています。

こうした事例から、gRPCの優れたパフォーマンスと拡張性が、マイクロサービスから設備管理まで幅広い用途で活かされていることが分かります。

REST vs gRPCの長所と短所

API通信の代表格として、RESTとgRPCにはそれぞれメリット・デメリットがあります。プロジェクト要件やチームの得意分野を踏まえて選ぶのが肝要です。

RESTのメリット・デメリット

メリット

1. 理解しやすい: HTTPをベースにしており、リソース指向なため直感的です。
2. 拡張性の高さ: ステートレスでサーバー側で状態を持たないため、水平スケールしやすいです。
3. HTTPキャッシュが利用可能: GETリクエストの結果をキャッシュし、パフォーマンス向上が図れます。
4. 普及度が高い: ドキュメントやライブラリ、コミュニティが充実しています。

デメリット

1. データの過不足: 取得したい情報が多すぎたり少なすぎたりする場合があり、通信効率を損ねることがあります。
2. オーバーヘッド: JSONのテキスト処理や複数リクエストのやり取りで遅延が大きくなるケースがあります。
3. 多数の往復: 複雑な操作をする際に、複数のリクエストを行う必要が生じやすいです。

gRPCのメリット・デメリット

メリット

1. 高性能: Protocol BuffersとHTTP/2を組み合わせることで転送と解析が高速です。
2. 単一接続で多重通信: HTTP/2の特性により、同時アクセスが多い環境でも効率的です。
3. 双方向ストリーミング: リアルタイム通信が必要な場面で大きなアドバンテージになります。
4. 多言語対応: マルチ言語プロジェクトでも型安全なRPCを実装できます。

デメリット

1. 学習コスト: Protocol BuffersやHTTP/2などRESTよりも習熟が必要です。
2. ブラウザ対応の制限: HTTP/2に非対応の環境には直接接続できません。
3. バイナリ形式の難しさ: JSONに比べて可読性が低く、デバッグしにくいです。

要するに、RESTは広く普及していて実装が簡単な反面、速度や効率面で制限があることも。gRPCは高い性能と多機能性を誇りますが、導入にあたって学習や環境対応などのハードルがあります。

RESTかgRPCかを選ぶときの指針

API通信を設計する際に、RESTとgRPCのどちらを選ぶべきかは、プロジェクト要件と運用環境の両面から検討するとよいです。

プロジェクト要件を整理する

まずはデータ量や通信の形態を整理します。

• データ形式: 結果の可読性が大事ならJSONのREST、性能重視ならProtobufのgRPCが合うケースが多いです。
• やり取りのタイプ: 片方向で十分ならRESTでも良いですが、双方向ストリーミングが必要ならgRPCに軍配が上がります。
• 対応言語: gRPCはさまざまな言語に対応している一方、ブラウザ環境との連携はRESTがしやすいです。

運用環境を考慮する

さらに、アプリを実行する場や利用者の環境も重要です。

• 接続環境: 帯域幅が限られ、高遅延の環境だとgRPCの方が効率的です。
• ブラウザ対応: 通常のウェブブラウザから直接アクセスするならRESTがシンプルです。
• ファイアウォールなどネットワーク制約: HTTP/2の通らない環境ではgRPCが使いにくい場合があります。

メリット・デメリットを比較

最終判断

最終的には、プロジェクトの性格や制約に合わせて決定します。ウェブ中心やシンプルなAPIならRESTで十分ですが、大規模なデータ処理や双方向通信が必要ならgRPCが最適です。場合によっては両方を使い分けるハイブリッド構成も考えられます。

要件と運用環境を見極め、メリットとデメリットを総合的に把握すれば、RESTとgRPCいずれのアプローチも効果的に活用できます。