Day 049 — gRPC/Protocol Buffers実装（続き）: デッドライン伝播とストリーミングRPCの設計判断

📚 背景知識（読んでから問題へ）

Day 048では.protoが生成するコードの役割分担と、net/rpcによるRPC呼び出しの規約（ポインタ引数・エクスポート済みメソッド）を扱いました。今日はgRPCが実務で選ばれる理由の核心であるデッドライン伝播（deadline propagation）とストリーミングRPCという2つの機能を、設計判断の軸として掘り下げます。

実際のgRPCでは、クライアントがcontext.WithTimeout(ctx, 200*time.Millisecond)のようにデッドラインを設定してRPCを呼び出すと、そのデッドラインはgrpc-timeoutというHTTP/2ヘッダーに変換され、ネットワークの向こう側のサーバーにまで伝わります。サーバー側のハンドラはctx.Done()やctx.Err()をチェックすることで、「クライアントはもう結果を待っていない」ことを知り、無駄な処理を早期に打ち切ることができます。つまりgRPCのデッドラインは、クライアント側だけの「待つのをやめる」仕組みではなく、呼び出しチェーン全体（クライアント→サーバー→サーバーが呼ぶ別サービス…）に伝播する中断信号です。

一方、標準ライブラリのnet/rpcのclient.Callはcontext.Contextを一切受け取りません。同期的に呼び出し、サーバーからの応答（またはコネクションエラー）が来るまでブロックし続けます。これはgRPCが解決している「呼び出し側が待つのをやめたい」という要求に、標準ライブラリだけでは対応できないことを意味します。

もう一つの軸がストリーミングRPCです。gRPCは4種類の呼び出し形式を持ちます。

net/rpcにはストリーミングの概念自体が存在せず、Unary RPCしか表現できません。「継続的に更新を受け取りたい」という要件に対しては、Unary RPCを一定間隔で繰り返し呼ぶポーリングで近似するしかありません。

📝 問題

1. 概念理解: gRPCのcontext.WithTimeoutによるデッドラインが「クライアント側だけで待つのをやめる」のではなく「サーバー側にも伝播する」とはどういう意味か、具体的に説明してください。また、サーバー側の処理が複数のマイクロサービス呼び出しを連鎖させている場合（A→B→C）、このデッドライン伝播がどう役立つかを1つの障害シナリオで示してください。
2. 実装: net/rpcのclient.Callはcontext.Contextを受け取れません。これにcontext.Contextによるタイムアウトを外付けするCallWithContext関数を実装してください。要件:
   • シグネチャ: func CallWithContext(ctx context.Context, client *rpc.Client, serviceMethod string, args, reply any) error
   • ctxのデッドラインが切れる前にRPCが完了した場合は、RPCの結果（error、nil含む）をそのまま返す
   • ctxのデッドラインが先に切れた場合はctx.Err()（context.DeadlineExceeded）を返す
   • サーバー側の処理時間を人為的に変えられるSlowGreeter.SayHello(req *HelloRequest, reply *HelloReply) errorを用意し、(a) デッドライン内に完了するケース、(b) デッドラインを超過するケースの両方をmain関数内で実行して結果を表示する
3. デバッグ・コードレビュー（設計上の欠陥の指摘）: 問題2で実装したCallWithContextには、「クライアントは待つのをやめられるが、サーバー側の処理は止まらない」という、本物のgRPCのデッドライン伝播とは異なる重要な限界があります。この限界が実際のシステムでどのような問題を引き起こすか、具体的な障害シナリオ（例: 高負荷時に何が起こるか）を1つ挙げて説明してください。
4. 設計・アーキテクチャ: 「サーバー上に新しいログ行が追加されるたびに、クライアントにリアルタイムで表示する」というログストリーミング機能を設計するとします。(a) net/rpcのUnary RPCを1秒間隔でポーリングする方式と、(b) gRPCのServer streaming RPCを使う方式を、レイテンシ・コネクションのオーバーヘッド・実装の複雑さの3観点で比較し、どちらを選ぶべきか、根拠とともに述べてください。

🔍 ヒント（段階的開示）

📋 コピーfunc CallWithContext(ctx context.Context, client *rpc.Client, serviceMethod string, args, reply any) error {
	done := make(chan error, 1)
	go func() {
		done <- client.Call(serviceMethod, args, reply)
	}()

	select {
	case err := <-done:
		// TODO: 正常終了（RPCが先に終わった）
	case <-ctx.Done():
		// TODO: タイムアウト（ctxが先に終わった）
	}
}

✅ 模範解答

(1) デッドライン伝播の意味と障害シナリオ:

gRPCではクライアントが設定したcontext.WithTimeoutのデッドラインは、RPC呼び出し時にgrpc-timeoutというHTTP/2ヘッダーとしてサーバーに送信されます。サーバー側のgRPCランタイムはこのヘッダーを受け取り、ハンドラに渡すcontext.Contextにも同じデッドラインを設定します。つまり「クライアントがあと何ミリ秒で諦めるか」という情報そのものがネットワークを越えてサーバーに伝わります。

(2) CallWithContextの実装（完全なコード）:

📋 コピーpackage main

import (
	"context"
	"errors"
	"fmt"
	"log"
	"net"
	"net/rpc"
	"time"
)

// SlowGreeter は、サーバー側の処理時間をリクエストごとに変えられる
// RPCエンドポイント。デッドライン内に完了するケースと超過するケースの
// 両方を1つのサーバーでシミュレートするために使う。
type SlowGreeter struct{}

type HelloRequest struct {
	Name  string
	Delay time.Duration // サーバー側の処理時間をシミュレートする
}

type HelloReply struct {
	Message string
}

func (g *SlowGreeter) SayHello(req *HelloRequest, reply *HelloReply) error {
	time.Sleep(req.Delay)
	reply.Message = "Hello, " + req.Name + "!"
	return nil
}

// CallWithContext は net/rpc の同期 Call に context.Context によるタイムアウトを
// 外付けするラッパー。client.Call を別goroutineで実行し、その完了と ctx.Done() を
// select で競争させる。
//
// 重要な限界: ctx が先にタイムアウトした場合、この関数は呼び出し元に
// ctx.Err() を返して制御を戻すが、バックグラウンドで動いている client.Call の
// goroutineとサーバー側の処理そのものは止まらない（問題3で詳述）。
func CallWithContext(ctx context.Context, client *rpc.Client, serviceMethod string, args, reply any) error {
	done := make(chan error, 1) // バッファ1: 受信者がいなくてもgoroutineがブロックしない
	go func() {
		done <- client.Call(serviceMethod, args, reply)
	}()

	select {
	case err := <-done:
		return err
	case <-ctx.Done():
		return ctx.Err()
	}
}

func main() {
	if err := rpc.Register(new(SlowGreeter)); err != nil {
		log.Fatal(err)
	}
	listener, err := net.Listen("tcp", "127.0.0.1:0")
	if err != nil {
		log.Fatal(err)
	}
	defer listener.Close()

	go func() {
		for {
			conn, err := listener.Accept()
			if err != nil {
				return
			}
			go rpc.ServeConn(conn)
		}
	}()

	client, err := rpc.Dial("tcp", listener.Addr().String())
	if err != nil {
		log.Fatal(err)
	}
	defer client.Close()

	// ケース(a): サーバーの処理(50ms) < デッドライン(200ms) → 正常完了
	ctx1, cancel1 := context.WithTimeout(context.Background(), 200*time.Millisecond)
	defer cancel1()
	var reply1 HelloReply
	err = CallWithContext(ctx1, client, "SlowGreeter.SayHello",
		&HelloRequest{Name: "Gopher", Delay: 50 * time.Millisecond}, &reply1)
	fmt.Printf("ケース(a) 結果=%q err=%v\n", reply1.Message, err)

	// ケース(b): サーバーの処理(200ms) > デッドライン(50ms) → タイムアウト
	ctx2, cancel2 := context.WithTimeout(context.Background(), 50*time.Millisecond)
	defer cancel2()
	var reply2 HelloReply
	err = CallWithContext(ctx2, client, "SlowGreeter.SayHello",
		&HelloRequest{Name: "Gopher", Delay: 200 * time.Millisecond}, &reply2)
	fmt.Printf("ケース(b) 結果=%q err=%v is-deadline-exceeded=%v\n",
		reply2.Message, err, errors.Is(err, context.DeadlineExceeded))

	// デモ用: ケース(b)のバックグラウンドgoroutineがサーバー応答を受け取って
	// 終了するのを待つ（本番コードではこのSleepは不要。問題3の議論のための待機）
	time.Sleep(300 * time.Millisecond)
	fmt.Println("(ケース(b)のバックグラウンド処理も、300ms後には完了していたはず)")
}

実行結果（実測。go1.26で確認済み）:

📋 コピーケース(a) 結果="Hello, Gopher!" err=<nil>
ケース(b) 結果="" err=context deadline exceeded is-deadline-exceeded=true
(ケース(b)のバックグラウンド処理も、300ms後には完了していたはず)

(3) CallWithContextの設計上の限界と障害シナリオ:

CallWithContextがctx.Done()側で先にreturnしても、go func() { done <- client.Call(...) }()で起動したgoroutineは止まっていません。サーバー側のSayHelloもtime.Sleep(req.Delay)の間、律儀に処理を続け、200ms後に応答を返します。その応答は誰も受け取らない（呼び出し元はすでにctx.Err()を受け取ってreturn済み）まま、バッファ付きチャネルdoneに書き込まれて捨てられます。

これは本物のgRPCのデッドライン伝播との決定的な違いです。gRPCではクライアントのタイムアウトがサーバー側のctxにも伝わり、サーバーのハンドラが自分でctx.Err()をチェックして処理を中断できます。一方このCallWithContextは「クライアントが待つのをやめる」だけで、「サーバーに処理をやめさせる」ことは一切していません。

(4) ポーリング方式 vs Server streaming RPC方式の比較:

選ぶべき方式: このケース（ログのリアルタイム表示）では(b) Server streaming RPCを選ぶべきです。理由は、要件が明示的に「新しいログ行が追加されるたびに」というイベント駆動での即時性を求めており、ポーリング間隔を短くすればレイテンシは改善できますが、その分無駄なリクエスト数が増えてサーバー負荷が上がるという直接的なトレードオフがあります。Server streaming RPCはこのトレードオフ自体を発生させず、「データがあるときだけ送る」という理想的な特性を持つため、実装の複雑さという追加コストを払う価値があります。逆に、更新頻度が低く（例: 1日1回のバッチ結果通知）多少のレイテンシが許容される場合は、実装の単純さを優先してポーリングで十分という判断もあり得ます。

🪜 Step-by-Step 解説

💡 設計思想・なぜこう書くのか

🌐 他言語との比較

🏆 実務での使いどころ

• マイクロサービスのタイムアウト設計: サービスAがサービスBを呼ぶ際、Aが設定するタイムアウトはBが内部で使うタイムアウトより長くしてはいけません（Bのタイムアウトの方が先に発生するよう、余裕を持って短く設定する「タイムアウトの入れ子」設計）。デッドライン伝播が使えるgRPCではこれをコード側で強制しやすくなります。
• 古いAPIへのcontext対応の後付け: 今日のCallWithContextのようなパターンは、レガシーな同期APIやサードパーティライブラリにcontext.Contextベースのキャンセルを外付けする際の定石です。ただし「本当にキャンセルできているか」を必ず検証する必要があります。
• 観測性との組み合わせ: 本番システムでは、CallWithContextのようなラッパーでタイムアウトが発生した回数をメトリクスとして記録し、「クライアントは諦めたがサーバー側処理は続いている」という状態がどれだけ発生しているかを監視することが、問題3で述べたリソース圧迫を早期発見する手段になります。

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: CallWithContextをさらに改良し、ctxがタイムアウトした際にサーバー側のTCPコネクション自体をclient.Close()で切断してしまう設計を試してみましょう。ただしこれは同じコネクションを共有する他の未完了呼び出しも巻き込んで失敗させるという新たな設計トレードオフを生むため、その影響も考察してみてください。
• 次回予告: ミドルウェア設計パターン — http.Handlerのチェーン設計を扱います

🎯 自己評価

自分の回答

気づき・メモ