LDR; gRPC は REST API のアンチパターンです。しかし、一部の組織にとっては、その苦労は価値があるかもしれません (ああ、Kubernetes を使用している場合は、たとえ知らなかったとしても、すでに gRPC を使用しています)。
Kubernetes (クバネティス):コンテナの運用管理と自動化を行うために設計されたオープンソースソフトウェアです。
2005 年にサンフランシスコで開かれた小さな技術者ミーティングで、2 人の人物 (1 人は Google、もう 1 人は Yahoo) との会話の中で、両社がそれぞれ Web 初のパブリック API をリリースしようとしていることを知りました。Google は Google Maps API をリリースしようとしており、Yahoo は最近買収した Flickr 写真共有サイト用の API をリリースしようとしていました。API エコノミーがビッグバンから生まれたと言えるなら、これは私がこれまで経験した中で、そしておそらくこれからも経験するであろうビッグバンに最も近い出来事だったでしょう。
数か月以内に、私はシリコンバレーで API エコノミー初の大規模な集会を急遽開催しました。それは Mashup Camp というイベントで、その後数年間で世界中で Mashup Camp がさらに開催されました。これらのイベントから明らかになったことが 1 つあるとすれば、それは Google がパブリック API プロバイダー (および自社専用のプライベート API プロバイダー) となることの模範となるだろうということでした。確かに、2006 年の初めまでに多くの企業が API を急いでリリースしていましたが、トレンド セッターとなったのは明らかに Google でした。
その後、他の主要な API プロバイダーが登場しましたが、Google は API プロバイダーの中でも独自の地位を確立するほどの規模で、今でも高く評価されています。2016 年 (インターネットの歴史からすると永遠の年月です) に、私はGoogle の Tim Burks によるプレゼンテーションに参加しました。その中で彼は、Google は毎秒 100 億回以上の API 呼び出しを処理していると述べました。そう、毎秒です!
それは 5 年前のことです。この記事を準備するにあたって、私は Twitter で Burks 氏に最新の数字があるかどうか尋ねました。彼は、新しい数字がより多くのゼロを含むことは知っていたものの、まったく知らなかった同僚や元 Google 社員にツイートしました。実際、当初の 100 億という推定値は低すぎるという意見が一致しており、その根拠として、当時の Google 製品マネージャー Mugur Marculescu 氏が 1 秒あたり「数百億」の API 呼び出しを記述した、2015 年の Google の公式gRPC導入を挙げています。
Google は必要に迫られて gRPC を発明しました。創業当時から、同社はパフォーマンスにこだわり続けています。私が長年 Google I/O (年次開発者会議) で参加した数多くのセッションで、ユーザーが何かをクリックまたはタップした瞬間から、画面に完全な応答が反映されるまでの間の 1 ピコ秒にも Google が執着していることがはっきりとわかりました。この執着は、Chrome の構築方法から、提供している開発者ツール (WebAssembly など)、そしてご想像のとおり、API 主導のインフラストラクチャの仕組みまで、Google のあらゆる活動に表れています。Google の思い通りにできるとしたら、あらゆるユーザー エクスペリエンスは、ユーザーの手のひらに量子コンピューターがあり、ネットワークが関与していないかのように機能するでしょう (少なくとも現時点ではどちらも真実ではありませんが)。
Google と Yahoo は Web API で API エコノミーの誕生に貢献したかもしれませんが、パフォーマンスにこだわる Google は、規模が大きくなると (繰り返しますが、1 秒あたり数百億回の API 呼び出し)、Web の基盤となるプロトコル (HTTP) と XML や JSON などのペイロード形式に依存してその量のトランザクションを簡単にサポートするのは、コストがかかりすぎて時間がかかりすぎることにすぐに気付きました。貴重なマシン時間 (つまりお金) が、各 API 呼び出しのクライアント側とサーバー側でのデータのシリアル化と逆シリアル化に浪費されるだけでなく、そのプロセスでは貴重な数秒が無駄になっていました。Google にとって、時間は文字通りお金なのです。
ここで登場するのが、Google による API の RPC (リモート プロシージャ コール) アーキテクチャ スタイルの再発明である gRPC です。このアーキテクチャ スタイルは、スケール メリットと速度のメリットを優先して、REST の称賛されている利点の一部を犠牲にしていますが、すべてを犠牲にしているわけではありません。フェラーリが走るように、gRPC は REST を馬車のように見えます。非常に高速であるため、最速のものだけが求められる状況に適しています (例: Kubernetes のコンテナ ランタイム インターフェース。Kubernetes 管理者が実際に直接触れる実装はほとんどない、またはまったくない)。
gRPC が Google のネットワーク上で毎秒行われる膨大な数の API 呼び出しの基盤となったことで、同社は計り知れないほどのマシン サイクルを節約し、それに応じてコストを削減しています。規模が大きければ、大きなコスト、つまり株主にとって大きな価値となるようなコストです。
他の API アーキテクチャ パターンと比較して、大規模環境でのコストの低さは、gRPC の唯一の有益な価値提案ではありません。OpenAPI などの独立した記述仕様を使用して API が帯域外で記述される REST と比較すると、 gRPCは、gRPC 仕様に帯域内 API 記述の規定が含まれているという点で GraphQL に似ています。つまり、記述が組み込まれています。API の機械可読な記述を作成するためにまったく別の一連のテクノロジーを採用する必要がないという利便性に加えて、このアプローチの主なダウンストリームの利点の 1 つは、10 を超える言語で gRPC API のクライアント ライブラリ (SDK) を自動的に生成する Google 構築のツールを利用できることです。残念ながら、REST と比較すると、REST や GraphQL のように gRPC API をプロビジョニングまたは使用するためのツールは他にはそれほど普及していません。gRPC に真剣に取り組むには、組織は苦労を覚悟する必要があります。しかし、ある程度の規模になると（その数はわかりませんが）、計算上は有利に働く可能性があります。
gRPC には他にも魅力的な属性があります。REST などの一般的な API アーキテクチャ パターンのほとんどにはイベント駆動型ストリーミング オプションが含まれていません (このためには別のテクノロジを使用する必要があります)。一方、gRPC にはイベント駆動型ストリーミングの規定が含まれているだけでなく、サーバーからクライアント、クライアントからサーバー、またはその両方の方向のストリーミングが可能なタイプです。
Google は、Google らしく、この発明を自分だけのものにしませんでした。gRPC 仕様は誰でも無料で使用でき、Google は独自の gRPC ツールの一部をオープンソースとして提供しています。
これほど多くの利点があるため、すべての組織が自問すべき疑問が浮かび上がります。「gRPC が API エコノミーのトレンドをリードする Google にとって非常に優れているのであれば、私たちにとっても十分なのでしょうか?」
残念ながら、ProgrammableWeb ではこの質問に答えることはできません。しかし、私たちができることは、この質問に答えるために必要な情報を提供することです。gRPC の使用に関する最も包括的な入門書と実践ガイドです。このシリーズでは、歴史、テクノロジー、仕組み、長所、短所について説明し、実践的なチュートリアルも提供して、gRPC を実際に体験していただけるようにしています。
デビッド・ベルリンドProgrammableWeb
編集長
gRPC は、インターネット上のある場所にあるプログラムが、インターネット上の別の場所にある別のプログラムの別の関数にデータを渡すことを可能にする API フレームワークです。この記事では、分散コンピューティングの分野で gRPC がどのように登場したかを説明し、...
この記事では、gRPC について詳しく見ていきます。まず、仕様と実装の観点から gRPC アーキテクチャの基本について説明します。次に、gRPC API を作成するために必要な基本的な概念と実践について詳しく見ていきます。
この記事の目的は、gRPC API のコード作成に伴う多くの日常的な作業を実行するツールである protoc を起動して実行し、さまざまなプログラミング言語で gRPC コードを自動生成する方法を説明することです。JavaScript、C#、GoLang でのコードの自動生成について説明します...
gRPC はエンタープライズ レベルの分散コンピューティングに多大な力をもたらしますが、実装が簡単なテクノロジではありません。幸いなことに、これを実現するために必要なフレームワークを提供するプロジェクトがあります。この記事では、gRPC の Node.js 実装の詳細な調査に焦点を当てます。
この記事では、Kubernetes の Container Runtime Interface (CRI) テクノロジーで gRPC がどのように使用されているかを見ていきます。まず、フロントエンドで gRPC があまり見られないのはなぜでしょうか。これはこれまで何度も尋ねられてきた質問であり、答える価値のある質問です。
このシリーズでは、gRPC 仕様とは何か、そしてそれがどのように機能するかについての基本を紹介しました。今回は、ソース コントロール管理サービス GitLab がサーバー側アーキテクチャを Gitaly プロジェクトにリファクタリングしたときに、gRPC をどのように採用したかを実際に見ていきます。
この記事では、Messaging as a Service プラットフォーム Ably.io が gRPC を使用してサービスのストリーミング機能を最適化する方法について説明します。Ably.io の技術スタックの概要を簡単に説明し、次に gRPC を使用してサービス内の通信を最適化する方法について説明します...
gRPC は、API を提供および使用するための REST および GraphQL に代わるアーキテクチャ パターンです。JSON や XML などのデータ形式標準に依存することが多い他のアーキテクチャと比較して、Web スケールで実行することを目的とした API を作成する方法として、多くの企業で人気が高まっています。