HTTP/2上のgRPCワイヤ形式と呼び出し条件

gRPCはリモートプロシージャコールのフレームワークで、通常のネイティブgRPCはHTTP/2ストリーム上で呼び出しを運びます。リクエストはPOSTとサービス・メソッドのパスを使い、content-typeはapplication/grpcで始まります。各メッセージには圧縮フラグ1バイトと長さを示す4バイトのbig-endianフィールドがあります。gRPCメッセージ境界とHTTP/2 DATAフレーム境界は一致するとは限りません。HTTPレスポンスが200でもRPC成功とは限らず、通常は末尾のgrpc-statusで結果を判断します。即時エラーにはtrailers-only応答もあります。中継機器がトレーラーとHTTP/2の意味を保つか確認してください。

専門家の視点：チャネルは単一接続や無制限の容量ではない

GoogleのエンジニアJean de KlerkはgRPCの技術記事で、チャネルを論理的な接続先として説明し、resolverとload balancerが複数のHTTP/2接続を管理する仕組みを解説しています。これは接続利用や復旧についての実装者の説明であり、全言語のランタイムが同じ接続プールを持つ保証ではありません。接続ごとの同時ストリーム数は相手側の設定で制限されることがあります。開始済みの長時間ストリームを途中から別バックエンドへ移すことも通常できません。必要ならアプリケーション側でキャンセル、再接続、再開位置を設計します。

スキーマと転送を分けて考える

Protocol Buffersはよく使われるIDLおよびメッセージ形式ですが、gRPCで唯一使えるペイロード形式ではありません。圧縮方式はgrpc-encodingで示され、圧縮フラグが立ったメッセージに適用されます。形式や生成スタブだけで、JSONに対する一定の容量削減率や速度向上が保証されるわけではありません。スキーマ、データ形状、言語ランタイム、圧縮、ネットワークごとに計測します。生成コードは一部の契約不一致を検出できますが、独立して更新されるサービス間の互換性は別途管理が必要です。

deadline・再試行・ブラウザーでの制約

仕様文書ではgrpc-timeoutがない場合、サーバーは無限のタイムアウトを想定すべきとされています。本番クライアントは通常、呼び出し元の処理時間に合うdeadlineを設定します。明示的に定義しない限りRPCは冪等と見なされず、プロトコルに重複排除機能もありません。結果不明の障害後に再試行すると処理が重複する可能性があるため、冪等キーと再試行対象のエラーをアプリケーションで決めます。gRPC-WebはネイティブgRPCと機能範囲が異なるため、必要なストリーミング方向とプロキシ対応を確認します。実経路でトレーラー、フロー制御、ストリーム上限、キャンセル、再試行を試験してください。

参考資料