タグ: #gRPC

← すべての記事

• gRPCのデバッグと観測：grpcurl、リフレクション、channelz、そしてメトリクスの罠

  gRPCはバイナリであるため、curlで中身を見ることはできません。その代わりに、サーバーが自らスキーマを通知するリフレクション（grpcurlがこれを使用）、標準のヘルスサービス、チャネル・サブチャネル・ソケットの統計情報を取得できるchannelz、そしてメトリクスが窓の役割を果たします。小さなクラスターの指標から2つの罠が見つかりました。kube-apiserver 1.34のetcdクライアント指標であるgrpcclientms

  2026-10-16 · 18 分で読めます #gRPC#grpcurl#서버 리플렉션#channelz#Prometheus

• grpc-go コードマップ: ClientConn から http2Client まで、Serve からハンドラーまで

  grpc-go のクライアントは5層構造になっています。チャネル（ClientConn）がリゾルバのラップとバランサーのラップを内包し、バランサーがサブチャネル（addrConn）を作成し、呼び出しごとにピッカーが READY なサブチャネルを1つ選んでその HTTP/2 トランスポート（http2Client）にストリームを開きます。サーバーは Serve → 接続ごとに http2Server → ストリームごとに handleSt

  2026-10-16 · 16 分で読めます #gRPC#grpc-go#코드 읽기#오픈소스#Go

• 小さなクラスターで実際に動く gRPC: etcd、CRI、Hubble、OTLP

  8ノードの小さなクラスターで 4 つの gRPC 通信を読み取り専用で計測しました。kube-apiserver は同じノードの etcd に対して TCP 接続を 247 個も開いていましたが、これは Kubernetes がリソース（CRD を含む）ごとに etcd クライアントを個別に作成するためであり、ソースコードのコメントに既知の問題として記載されています。kubelet は containerd にランタイムとイメージの 2

  2026-10-16 · 19 分で読めます #gRPC#etcd#CRI#containerd#Hubble

• KubernetesにおけるgRPC：1つのPodに偏る理由とヘルスチェック

  Kubernetes Serviceのデフォルトの負荷分散は、コネクション確立時に1回だけバックエンドを選択します。gRPCは1つのコネクションを長く使い、その上で呼び出しを集中させるため、Podを増やしても既存コネクションの呼び出しは最初に選んだPodにしか行きません。解決策は3つあります。ヘッドレスサービスとクライアント側のroundrobin、呼び出し単位で分散するL7プロキシ（Envoy・Cilium・メッシュ）、そしてプロキシ

  2026-10-16 · 19 分で読めます #gRPC#쿠버네티스#부하 분산#헤드리스 서비스#xDS

• ストリーミング、deadline、リトライ、keepalive：呼び出しが長引く、または失敗したとき

  gRPCのメソッドは、リクエストとレスポンスがそれぞれ1つかストリームかによって4つに分類されます。ストリームはHTTP/2のフロー制御ウィンドウによって保護され、制限時間はdeadlineとして残り時間とともに次のサーバーに伝えられ、キャンセルはRSTSTREAMとして伝播します。ライブラリによるリトライは、サーバーがレスポンスヘッダーを送る前（Trailers-Only）にのみ、最大5回、0.8〜1.2倍のジッターを混ぜて行われます

  2026-10-16 · 20 分で読めます #gRPC#스트리밍#deadline#재시도#keepalive

• HTTP/2上のgRPC：擬似ヘッダー、5バイトのプレフィックス、トレーラーのステータスコード

  gRPCの呼び出し1つはHTTP/2のストリーム1つです。リクエストはPOSTと:path /パッケージ.サービス/メソッド、content-type: application/grpc、te: trailersで始まり、メッセージごとに圧縮フラグ1バイトと長さ4バイトが先頭に付加されます。結果はHTTPステータス（常に200）ではなく、レスポンス末尾のトレーラーのgrpc-statusで決まります。grpc-goにおいてこの擬似ヘッダ

  2026-10-16 · 20 分で読めます #gRPC#HTTP/2#트레일러#상태 코드#grpc-timeout

• protobuf ワイヤ形式: 21バイトを1区切りずつ

  protobufメッセージは「タグ（フィールド番号とワイヤタイプ）＋値」の並びです。整数は7ビットずつ区切って使うvarint、文字列とまとまりは長さを先頭につけ、デフォルト値はそもそも送信しません。卓球のラリー1件を標準ライブラリのみで手動エンコーディングしてみたところ21バイトで、同じ内容のJSONは72バイト（インデント付きは111バイト）でした。int32で-1を送信すると10バイト、sint32で送信すると1バイトです。フィー

  2026-10-16 · 12 分で読めます #gRPC#protobuf#varint#직렬화#하위 호환

• gRPCが解決する課題と全体像：契約書、コード生成、チャネル、HTTP/2

  gRPCは「遠くの関数を自分の関数のように呼び出す」という問題を4つの要素に分けて解決します。それは、契約書(.proto)、その契約書から生成された言語別のコード(スタブ)、接続とロードバランスを担当するチャネル、そしてその下層にあるHTTP/2です。この記事では、4つの要素がそれぞれ何を担っているのか、なぜJSON over HTTP/1.1ではなくこのように分けたのか、その代償は何かを整理します。小さなクラスター(8ノード)のメト

  2026-10-16 · 13 分で読めます #gRPC#protobuf#HTTP/2#RPC#쿠버네티스