第4章 gRPC:フードの下で
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
前の章で学んだように、gRPC アプリケーションはネ ットワーク上で RPC を使用して通信する。gRPC アプリケーションの開発者は、RPC がどのように実装され、どのようなメッセージ・エンコーディング・テクニックが使用され、RPC がネットワーク上でどのように動作するかといった基本的な詳細について心配する必要はない。サービス定義を使って、サーバ側、クライアント側、どちらでも好きな言語のコードを生成すればよい。低レベルの通信の詳細はすべて生成されたコードに実装され、高水準の抽象化を得ることができる。しかし、複雑なgRPCベースのシステムを構築し、本番で動作させる場合、gRPCがどのように動作するかを知っておくことが重要である。
この章では、gRPC の通信フローがどのように実装されているのか、どのようなエンコーディングテクニックが使用されているのか、gRPC が基礎となるネットワーク通信テクニックをどのように使用しているのか、などを探っていく。クライアントが指定された RPC を呼び出すメッセージフローを説明し、それがどのようにネットワークを経由する gRPC 呼び出しにマーシャリングされるか、ネットワーク通信プロトコルがどのように使用されるか、サーバでどのようにアンマーシャリングされるか、対応するサービス、リモート関数がどのように呼び出されるか、などについて説明する。
また、gRPCのエンコーディング・テクニックとしてプロトコル・バッファを、通信プロトコルとしてHTTP/2をどのように使用しているかについても見ていく。最後に、gRPCの実装アーキテクチャと、その周りに構築された言語サポートスタックに飛び込む。ここで議論する低レベルの詳細は、ほとんどのgRPCアプリケーションではあまり役に立たないかもしれないが、低レベルの通信の詳細をよく理解しておくことは、複雑なgRPCアプリケーションを設計している場合や、既存のアプリケーションをデバッグしようとしている場合に非常に役に立つ。
RPCフロー
RPCシステムでは、サーバはリモートで呼び出すことのできる関数セットを実装している。クライアントアプリケーションは、サーバアプリケーションのリモート関数を呼び出すスタブ関数を直接呼び出すことができるように、サーバから提供される同じ関数の抽象化を提供するスタブを生成することができる。
ネットワーク上でリモートプロシージャコールがどのように動作するかを理解するた めに、第2章で説明したProductInfo サービスを見てみよう。ProductInfo サービスの一部として実装した関数の1つに、getProduct がある。この関数では、クライアントが製品IDを提供することで、製品の詳細を取得することができる。図4-1は、クライアントがリモート関数を呼び出す際の動作を示している。
図4-1. ネットワーク上でのリモートプロシージャコールの仕組み
図4-1に示すように、クライアントが生成されたスタブでgetProduct 関数を呼び出すときの主なステップは以下の通りである:
クライアント・プロセスは、生成されたスタブの ...