gRPC から RESTful API へ: gRPC サービスを Rest of the World に公開する

※この投稿は米国時間 2024 年 8 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

最新のマイクロサービス アーキテクチャを設計するにあたっては、パフォーマンスが鍵となることは明らかです。高頻度取引や準リアルタイム システム以外でも、サービス間通信に数ミリ秒ほどの余分なラグが生じるだけで、全体的なユーザー エクスペリエンスに大きく影響します。こうした環境では高性能通信プロトコルとして gRPC が登場し、低レイテンシ、高効率のシリアル化、厳密に型指定されたメッセージのために広く採用されています。

一方で、システム境界を越えたサービス間通信のほとんどが、依然として HTTP API に大きく依存していることを認識する必要があります。これは、API が主に API 作成者と API 利用者という形で分離されたエンティティ間の契約として機能しており、これを gRPC に変更すると多くの摩擦が生じるためです。さらに、すべてのデベロッパーが gRPC サービスを利用できるほど十分な装備や経験を備えているわけではありません。そのため、API プロバイダは、gRPC サービスのみを提供する方向に自らを制限してしまうと、潜在的なユーザー層を逃してしまう可能性があります。

このブログ投稿では、高性能な gRPC サービスと、広く採用されている RESTful HTTP API のエコシステムとの間のギャップを簡単に埋める方法についてご紹介します。既存の gRPC サービスと一緒にデプロイできる自動生成 gRPC ゲートウェイを活用してプロトコル変換を処理し、HTTP インターフェースを提供するソリューションをご提案します。さらに、クリーンな RESTful API ファサードを安全なセルフサービス方式で提供するためのエンタープライズ API 管理プラットフォームとして Apigee をご紹介します。

gRPC から HTTP へのゲートウェイ

架空の e コマースサイトを運営する会社が、その運営の過程で、コンポーネントの一部が独自の価値を提供していることに気づいたとします。その会社は、自社の戦略的な API エコノミーの取り組みにそれらを組み込むことができると考えています。この例は、さまざまなプログラミング言語で記述されたさまざまなサブコンポーネントで構成されているサンプルのマイクロサービス アーキテクチャに基づいています。API プラットフォームへのオンボーディングを検討したい最初のサービスは、通貨サービスです。このサービスには、サポート対象の通貨を一覧表示し、ある通貨から別の通貨への両替を実行できる 2 つの gRPC メソッドが用意されています。

冒頭で述べたように、gRPC サービスは、内部サービス間通信、いわゆる「East-West」サービス間通信によく使用されます。gRPC は優れたパフォーマンス特性を備えていますが、現状、多数の API が HTTP を主要な通信プロトコルとして使用しています。こうした API を gRPC に移行するには、特にすべてのデベロッパーが gRPC フレームワークに精通しているわけではないことを考慮すると、多大なリソースの投資が必要になります。

この課題を克服するために、従来の JSON HTTP ベースの API をサービスに提供するアダプタレイヤを提供したいと私たちは考えています。プロトコル変換を自ら手動で記述する代わりに、オープンソースの gRPC ゲートウェイ プロジェクトを使用して、ユースケース向けのアダプタを自動で生成することにしました。ゲートウェイは、.proto ファイルに基づいてサービスとメッセージを指定しています。これは、サービス プロデューサーと利用者との間に位置する唯一の信頼できる情報源、つまり契約として機能します。ゲートウェイの生成を簡素化するために、便利なラッパーを作成しました。このラッパーに .proto ファイルを直接指定するだけでゲートウェイを生成できます。

上記のコマンドは、提供された .proto ファイルを解析し、受信した HTTP REST リクエストを gRPC に変換して、指定されたエンドポイントに送信するための go モジュールを生成するものです。最後に、ゲートウェイを go モジュールでラップし、独立してデプロイできるようにします。

最終的なアーキテクチャでは、コンテナ イメージを構築し、Cloud Run などのターゲット ランタイムにデプロイします。ゲートウェイがどのように動作するかを確認するために、ゲートウェイをローカルで実行することもできます。

ここで設定された GRPC_SERVER_ENDPOINT 環境変数は、ゲートウェイがトラフィックを送信する先の gRPC エンドポイントを指しています。この場合、gRPC 通貨サービスはすでにポート 9090 でローカルに実行されています。ゲートウェイが起動したら、通常の JSON HTTP リクエストをゲートウェイのエンドポイントに送信できます。

ご覧のとおり、gRPC 通貨サービスが、より広範な API エコシステムで簡単に使用できる JSON HTTP API として提供されるようになっています。ただし、この新しい API がこの会社の確立された API 戦略とどのように整合しているかを考えると、まだ改善の余地があります。

• この API は、広く利用されている RESTful API 設計原則には従っておらず、依然として元の .proto 仕様の構造を多分に反映しています。

• この API は、認証、一元的なロギングとモニタリング、エラー処理、収益化などの API 管理機能をサポートしていません。

• 開発者は、新しい API を見つけ、自分自身を API 利用者としてオンボードできるセルフサービス オプションにアクセスできません。

API 管理で参入障壁を下げる

API 管理レイヤを Apigee API Proxy ファサードの形で活用することで、上記の機能の一部を実現し、ひいては API の採用を促進できます。Apigee は gRPC サービスをパススルー モードでネイティブに公開できますが、ここでは以前に変換されたプロトコルで操作し、次のようなさまざまな便利なポリシーと構成を適用できます。

• 適切な RESTful ファサードを提供でき、gRPC の基盤となるメッセージ形式を抽象化できるメソッド、パス、ペイロードの変換

• API プログラムの運用パフォーマンスと成功を測定するための指標と、豊富な分析データの収集

• 他のシステムを保護し、クライアントにクォータを課すための一貫した API セキュリティ、エラー処理、トラフィック管理制御

gRPC ゲートウェイ上に構築するには、まず API プロキシが gRPC ゲートウェイに安全にアクセスできるようにする必要があります。この API プロキシは、Cloud IAM を使用して認証を適用可能な Cloud Run にデプロイできます。このセキュリティ メカニズムでは、API プロキシは Google Cloud 認証自体を使用するか、API クライアントから受信した認証情報を転送するように構成する必要があります。

API プロキシを使用してルートを管理する Apigee の柔軟で包括的なアプローチにより、RESTful パスを API 利用者に公開し、実行時に gRPC ゲートウェイが期待するパスに書き換えることができます。

Apigee API プロキシを介して通貨サービスをプロキシすると、API 指標と分析データが自動的に収集され、API の健全性と成功に関する豊富な分析情報が得られます。また、追加のトラフィック管理、セキュリティ、メディエーション、さらにはコード拡張ポリシーを適用して、API プロキシを構築することもできます。

この API を新しいユーザーに紹介して宣伝するためにご活用いただけるのが、Apigee のデベロッパー ポータルです。API プロダクトを公開し、デベロッパーが API を発見、探索、テストできるようにすることで、新たな機会が生まれます。これをさらに進めるには、必要に応じて API プロダクトを収益化し、使用量ベースの価格設定やサブスクリプション プランなどのさまざまな戦略で追加の収益源を得られるようにします。

まとめと次のステップ

ここでは、gRPC サービスを HTTP API として簡単に新しいユーザーに公開し、Apigee のような包括的な API 管理プラットフォームの利点も活用する方法を示しました。gRPC のパフォーマンスと REST API の使い慣れたツールを組み合わせることで、サービスとデータの新しい可能性が解き放たれ、より幅広いデベロッパーとアプリケーションにリーチできます。このハイブリッド アプローチを採用することで、API エコシステムを構築するときに gRPC と REST のギャップを埋めることができ、両方の長所を活用できます。

関心のある方は、Apigee DevRel サンプルの手順を実行して、これをテストすることができます。

-アプリケーション モダナイゼーション担当 EMEA ソリューション リード Daniel Strebel

-Apigee、EMEA テクニカル ソリューション コンサルタント Omid Tahouri