そのリトライ、死んだコネクションを使い回していませんか ── GoのHTTPクライアントとHTTP/2を実プロダクト障害から学び直す

Go Conference 2026の登壇で使ったスライドです。
https://gocon.jp/2026/timetable/1264230/

Transcript

1. そのリトライ、 死んだコネクションを使い回していませんか ── GoのHTTPクライアントとHTTP/2を 実プロダクト障害から学び直す 2026年09⽉11⽇(⾦) Go Conference 2026 松⽥ 祐佐 / REALITY株式会社
2. ⾃⼰紹介 松⽥ 祐佐 (まつだ ゆうさ) REALITY株式会社 バックエンドエンジニア • 2020年グリー株式会社(現グリーホールディングス株式会社)新卒⼊社 • 2022年からグリーグループのREALITY株式会社で VTuberの配信プラットフォームアプリ「REALITY」の開発に従事 REALITY上でのアバターです！ 2
3. アジェンダ • REALITYが遭遇したあるネットワーク上の障害 • 効果がなかった対策、そしてたてられた仮説 • 障害解決のための知識：HTTP/2の基礎 • 障害解決のための知識：net/httpのコネクション管理 • 学んだ知識を元に導出したアプローチとその結果 • まとめ 3
4. アジェンダ • REALITYが遭遇したあるネットワーク上の障害 • 効果がなかった対策、そしてたてられた仮説 • 障害解決のための知識：HTTP/2の基礎 • 障害解決のための知識：net/httpのコネクション管理 • 学んだ知識を元に導出したアプローチとその結果 • まとめ 4
5. あるネットワーク上の障害 背景 • • REALITYでは、親会社であるグリーグループで広く使われている課⾦‧認証基盤を利⽤ この課⾦‧認証基盤のAPIサーバに対して、REALITYのサーバからHTTP/2でAPIリクエストを 投げる形で利⽤ 起きた障害 • • ある⽇突然、課⾦認証基盤へのAPIリクエストが、context.Contextを⽤いてREALITY側で設定した タイムアウトにより⼤量に失敗する現象が発⽣ エラーメッセージは「context deadline exceeded」 5
6. 前提: システムのアーキテクチャ REALITY 課⾦‧認証基盤 k8s Pod Pod Pod API サーバ HTTP/2 ロード バランサ API サーバ API サーバ 6
7. 前提: システムのアーキテクチャ REALITY 課⾦‧認証基盤 k8s Pod API サーバ HTTP/2 ロード バランサ Pod API サーバ API サーバ Pod ここ起因で障害が起きた！ 7
8. 障害の特徴 今回の障害の特徴 ① 定常的ではなく、急にバースト的に発⽣して、しばらくすると⾃然回復する ② ⼀度発⽣したらほぼ全てのAPIリクエストについてタイムアウトする ③ 課⾦‧認証基盤側のロードバランサにそもそもリクエストが到達していない 早期に解決したいが、なかなか原因も対策もつかめず、 毎⽇補填対応をしながら調査を並⾏して進めるという期間が続きました... 8
9. 問題が起きていたコード var client = createHTTPClient() // デフォルトからカスタマイズした http.Client // コインを付与する処理 func issueCoin(coinAmount uint) error { ctx, cancel := context.WithTimeout(ctx, 10 * time.Second) ... req, err := http.NewRequestWithContext( ctx, "POST", "/api/v1/coin/issue", bytes.NewReader(data) ) ... res, err := client.Do(req) // コインを付与する APIを叩く if err != nil { return err } } 9
10. 問題が起きていたコード var client = createHTTPClient() // デフォルトからカスタマイズした http.Client // コインを付与する処理 func issueCoin(coinAmount uint) error { ctx, cancel := context.WithTimeout(ctx, 10 * time.Second) ... req, err := http.NewRequestWithContext( ctx, "POST", "/api/v1/coin/issue", bytes.NewReader(data) ) ... res, err := client.Do(req) // コインを付与する APIを叩く if err != nil { return err } } 10
11. 問題が起きていたコード var client = createHTTPClient() // デフォルトからカスタマイズした http.Client // コインを付与する処理 func issueCoin(coinAmount uint) error { ctx, cancel := context.WithTimeout(ctx, 10 * time.Second) ... req, err := http.NewRequestWithContext( ctx, "POST", "/api/v1/coin/issue", bytes.NewReader(data) ) ... res, err := client.Do(req) // コインを付与する APIを叩く if err != nil { return err } } 11
12. 問題が起きていたコード var client = createHTTPClient() // デフォルトからカスタマイズした http.Client // コインを付与する処理 func issueCoin(coinAmount uint) error { ctx, cancel := context.WithTimeout(ctx, 10 * time.Second) ... req, err := http.NewRequestWithContext( ctx, "POST", "/api/v1/coin/issue", bytes.NewReader(data) ) ... res, err := client.Do(req) // コインを付与する APIを叩く if err != nil { return err } } 12
13. 問題が起きていたコード func createHTTPClient() *http.Client { transport := http.DefaultTransport.(*http.Transport).Clone() … (DialContextだったり IdleConnTimeoutだったりその他パラメータも調整 ) transport.HTTP2 = &http.HTTP2Config{ SendPingTimeout: 10 * time.Second, PingTimeout: 10 * time.Second, } return &http.Client{ Transport: transport, } } var client = createHTTPClient() 13
14. 問題が起きていたコード func createHTTPClient() *http.Client { transport := http.DefaultTransport.(*http.Transport).Clone() … (DialContextだったり IdleConnTimeoutだったりその他パラメータも調整 ) transport.HTTP2 = &http.HTTP2Config{ SendPingTimeout: 10 * time.Second, PingTimeout: 10 * time.Second, } return &http.Client{ Transport: transport, } } AIに推奨されたパラメータに推奨値をそのまま⼊れていた var client = createHTTPClient() 14
15. アジェンダ • REALITYが遭遇したあるネットワーク上の障害 • 効果がなかった対策、そしてたてられた仮説 • 障害解決のための知識：HTTP/2の基礎 • 障害解決のための知識：net/httpのコネクション管理 • 学んだ知識を元に導出したアプローチとその結果 • まとめ 15
16. 対策：⼀時的なネットワーク起因の問題のようなので、リトライする • 最初に思ったこと：⼀時的なネットワーク起因の問題なのでは？ ◦ ◦ 障害時も課⾦‧認証基盤側のシステムに問題が起きていないことは確認をとれていた APIリクエストがタイムアウトする状態は⼀定時間経過すると⾃然回復する • そもそも ◦ 問題が起きていた箇所ではAPIリクエストを⼀度しか呼び出さないコードになっていた 仮説 ⼀時的なネットワーク起因の問題のように⾒えるので、リトライするように直せばOKなのでは？ 16
17. 対策：リトライを⼊れた擬似コード var client = createHTTPClient() // デフォルトからカスタマイズした http.Client // コインを付与する処理 func issueCoin(coinAmount uint) error { for i := range 2 { ctx, cancel := context.WithTimeout(ctx, 10 * time.Second) ... res, err := client.Do(req) // コインを付与する APIを叩く if err != nil { ... continue } } return errors.New("リトライしても失敗 ") } 17
18. 対策：リトライを⼊れた擬似コード var client = createHTTPClient() // デフォルトからカスタマイズした http.Client // コインを付与する処理 func issueCoin(coinAmount uint) error { for i := range 2 { ctx, cancel := context.WithTimeout(ctx, 10 * time.Second) ... res, err := client.Do(req) // コインを付与する APIを叩く if err != nil { ... continue } } return errors.New("リトライしても失敗 ") } 18
19. 対策：結果 解決しなかった！ リトライしても成功せず、1回⽬と同じ 「context deadline exceeded」が発⽣ 19
20. Podのログを観察してみると... • とりあえずで対策した案がうまくいかないのでPodのログを眺めてみる • 以下のような現象が確認された • ⼀度課⾦‧認証基盤へのAPIアクセスが「context deadline exceeded」で タイムアウトするようになると、そのpodからのAPIアクセスはリトライし てもほぼ成功しない状態が続く • ただAPIリクエストの中に「http2: client connection lost」というエラー が出ると、そこからはAPIリクエストが成功するようになる 20
21. Podのログを観察してみると... • コネクションが切断されたログ「http2: client connection lost」がでたら、 再度うまくいくようになった • つまりコネクションが新規に接続され直したらうまくいくようになった 仮説 今のリトライ処理はネットワーク的に不調なコネクションを使いまわしているから うまくいかないのではないか？ 21
22. 解決につながりそうな仮説 • 仮説：今のリトライ処理はネットワーク的に不調なコネクションを使いまわしている のではないか？ • ということは 使⽤しているコネクションがネットワーク不良の時、 「http2: client connection lost」が出る(つまり切断する)ようにしてから、 APIリクエストを送ればうまくいくのではないか HTTP/2とnet/httpのコネクションの死活管理の仕組みについて学んでいこう 22
23. アジェンダ • REALITYが遭遇したあるネットワーク上の障害 • 効果がなかった対策、そしてたてられた仮説 • 障害解決のための知識：HTTP/2の基礎 • 障害解決のための知識：net/httpのコネクション管理 • 学んだ知識を元に導出したアプローチとその結果 • まとめ 23
24. HTTP/2の基礎：フレーム • HTTP/1ではリクエストやレスポンスは基本的に⼀塊のデータとしてやりとりされる ◦ • transfer-encoding: chunkedなどの部分的な例外は存在 HTTP/2ではリクエストやレスポンスは「フレーム」という単位で細切れにされてやりとりされる HTTP/1 HTTP/2 24
25. HTTP/2の基礎：ストリーム • HTTP/1では1本のTCPコネクションには同時に⼀つのリクエスト‧レスポンスのやりとりしかできない • HTTP/2では1本のTCPコネクション上で同時に複数のリクエスト‧レスポンスのやりとりをできる ◦ リクエスト/レスポンスのペアをストリームという単位で識別し、各ストリームごとのフレームを 混ぜて送っている HTTP/1 ＊ HTTP/1に関して「パイプライン」もあるがここでは省略 HTTP/2 25
26. HTTP/2の基礎：コネクションの特性 • まとめるとHTTP/2では ◦ フレームという単位でデータを細切れにしてやり取りしている ◦ リクエスト‧レスポンスのやり取りを1本のTCPコネクション上で 複数同時に扱うことができる • したがってHTTP/2のコネクションの特性として ◦ 1本のTCPコネクションの利⽤される期間が⻑い ◦ 1本のTCPコネクションが同時に複数のリクエスト‧レスポンスの処理で 利⽤される 26
27. HTTP/2のコネクション特性は今回の障害と合致している 今回の障害の特徴(再掲) ① 定常的ではなく、急にバースト的に発⽣して、しばらくすると⾃然回復する ② ⼀度発⽣したらほぼ全てのAPIリクエストについてタイムアウトする ③ 課⾦‧認証基盤側のロードバランサにそもそもリクエストが到達していない 説明がつく！ HTTP/2は1本のコネクションを⻑期間同時に並⾏で使うし、 TCPコネクションを新規に張り直す機会が少ない → 1度コネクション不良になるとそれを使ったAPIリクエストが全て失敗するし、バースト的に⾒える 27
28. アジェンダ • REALITYが遭遇したあるネットワーク上の障害 • 効果がなかった対策、そしてたてられた仮説 • 障害解決のための知識：HTTP/2の基礎 • 障害解決のための知識：net/httpのコネクション管理 • 学んだ知識を元に導出したアプローチとその結果 • まとめ 28
29. HTTP/2におけるnet/httpのclient.Do概観 コネクションプール map[string][]*ClientConn 送信⽤ goroutine A client.Do A “example.com:443” コネクション1 送信⽤ goroutine B Aのフレーム Bのフレーム Aのフレーム Aのフレーム リクエスト Bのフレーム レスポンス ⋮ client.Do B 受信ループ⽤ goroutine The Go gopher was designed by Renée French. Gopher illustrations by Egon Elbre (CC0). ⋮ 29
30. HTTP/2におけるnet/httpのclient.Do概観 コネクションプール map[string][]*ClientConn 送信⽤ goroutine A client.Do A “example.com:443” コネクション1 送信⽤ goroutine B Aのフレーム Bのフレーム Aのフレーム リクエスト Bのフレーム レスポンス ⋮ http2: client connection lost client.Do B のキーマン 受信ループ⽤ goroutine The Go gopher was designed by Renée French. Gopher illustrations by Egon Elbre (CC0). Aのフレーム ⋮ 30
31. 「http2: client connection lost」が出るタイミングはいつか • net/httpはHTTP/2コネクションごとに対応する受信ループ⽤のgoroutineをもち、レ スポンスや制御⽤のフレームを読み続けている • 受信ループごとにヘルスチェック処理を特定のタイミングで実⾏しており、ヘルス チェックに失敗すると対応するコネクションが死んだと判定される このとき処理中だったリクエストは「http2: client connection lost」で失敗する コネクションはプールから切断‧破棄され、次のリクエストは新しいコネクションを確⽴する 31
32. なぜこのヘルスチェック処理が必要なのか • TCPの切断は必ずしも相⼿に通知されるとは限らない ◦ 経路上の障害、ロードバランサの退役など • 上記のような場合、⽚⽅だけが「切れた」と認識している状態が発⽣する →「half-open connections」 ◦ ◦ 送信側: ローカルのバッファに書き込めてしまい、エラーにならない 受信: 何も届かないだけなのでレスポンスに時間がかかっているだけの場合と区別がつかない • したがってhalf-open connectionsの場合には能動的に検知をしなければ、気づきよ うがない このヘルスチェック処理はhttp.DefaultClientでは動かないような設定になっている 32
33. net/httpが⽤意する能動的なコネクション死活管理の仕組み • ヘルスチェック処理は以下のようなステップで⾏われる ◦ 受信ループのgoroutineで⼀定時間フレームを読み込んでいない場合にヘルスチェック処理を発⽕ ◦ 受信ループが対応しているコネクション上でPingフレームという制御⽤のフレームを送る ◦ Pingフレームに対し、⼀定時間以内に ▪ ACKが返された場合はコネクションを「Healthy」とする ▪ ACKが返されなかった場合はコネクションを「Unhealthy」とする ◦ 「Unhealthy」となったコネクションはコネクションプールから除外され、そのコネクション上のス トリームを使っていた処理は「http2: client connection lost」エラーで中断される 33
34. net/httpのヘルスチェック処理 送信⽤ goroutine A client.Do A コネクション1 Aのフレーム Aのフレーム The Go gopher was designed by Renée French. Gopher illustrations by Egon Elbre (CC0). Aのフレーム リクエスト レスポンス 受信ループ⽤ goroutine 34
35. net/httpのヘルスチェック処理 受信ループのgoroutineで⼀定時間フレームを読み込んでいない場合にヘルスチェック処理を発⽕ 送信⽤ goroutine A コネクション1 Aのフレーム client.Do A リクエスト レスポンス 最近フレーム読み込んでないな... The Go gopher was designed by Renée French. Gopher illustrations by Egon Elbre (CC0). 受信ループ⽤ goroutine 35
36. net/httpのヘルスチェック処理 受信ループのgoroutineで⼀定時間フレームを読み込んでいない場合にヘルスチェック処理を発⽕ 送信⽤ goroutine A コネクション1 Aのフレーム client.Do A リクエスト レスポンス ヘルスチェック⽤ goroutine 起動 The Go gopher was designed by Renée French. Gopher illustrations by Egon Elbre (CC0). 念の為ヘルスチェックするか！ 受信ループ⽤ goroutine 36
37. net/httpのヘルスチェック処理 受信ループが対応しているコネクション上でPingフレームという制御⽤のフレームを送る 送信⽤ goroutine A client.Do A コネクション1 Pingフレーム Aのフレーム リクエスト レスポンス ヘルスチェック⽤ goroutine The Go gopher was designed by Renée French. Gopher illustrations by Egon Elbre (CC0). 受信ループ⽤ goroutine 37
38. net/httpのヘルスチェック処理 ⼀定時間内にACKが返された場合はコネクションを「Healthy」とする 送信⽤ goroutine A コネクション1 client.Do A Pingフレーム Ping ACK Aのフレーム リクエスト レスポンス ヘルスチェック⽤ goroutine 通知 ⼀定時間内にPing ACK 返ってきました！ The Go gopher was designed by Renée French. Gopher illustrations by Egon Elbre (CC0). よし！コネクション⼤丈夫だな！ 受信ループ⽤ goroutine 38
39. net/httpのヘルスチェック処理 ⼀定時間内にACKが返されなかった場合はコネクションを「Unhealthy」とする 送信⽤ goroutine A コネクション1 client.Do A Pingフレーム Aのフレーム リクエスト レスポンス ヘルスチェック⽤ goroutine 通知 ⼀定時間内にPing ACK 返ってきませんでした... The Go gopher was designed by Renée French. Gopher illustrations by Egon Elbre (CC0). え、このコネクションダメだ... 受信ループ⽤ goroutine 39
40. net/httpのヘルスチェック処理 「Unhealthy」となったコネクションはコネクションプールから除外され、 そのコネクション上のストリームを使っていた処理は「http2: client connection lost」エラーで中断される client.Do A http2: client connection lost 除外だ！ このコネクション使っているやつに連絡！ The Go gopher was designed by Renée French. Gopher illustrations by Egon Elbre (CC0). 受信ループ⽤ goroutine 40
41. net/httpが⽤意する能動的なコネクション死活管理の仕組み(再掲) • ヘルスチェック処理は以下のようなステップで⾏われる ◦ 受信ループのgoroutineで⼀定時間フレームを読み込んでいない場合にヘルスチェック処理を発⽕ ◦ 受信ループが対応しているコネクション上でPingフレームという制御⽤のフレームを送る ◦ Pingフレームに対し、⼀定時間以内に ▪ ACKが返された場合はコネクションを「Healthy」とする ▪ ACKが返されなかった場合はコネクションを「Unhealthy」とする ◦ 「Unhealthy」となったコネクションはコネクションプールから除外され、そのコネクション上のス トリームを使っていた処理は「http2: client connection lost」エラーで中断される 41
42. net/httpが⽤意する能動的なコネクション死活管理の仕組み(再掲) • ヘルスチェック処理は以下のようなステップで⾏われる ◦ 受信ループのgoroutineで⼀定時間フレームを読み込んでいない場合にヘルスチェック処理を発⽕ ◦ 受信ループが対応しているコネクション上でPingフレームという制御⽤のフレームを送る http.HTTP2Config.SendPingTimeout ◦ Pingフレームに対し、⼀定時間以内に ▪ ACKが返された場合はコネクションを「Healthy」とする ▪ ACKが返されなかった場合はコネクションを「Unhealthy」とする ◦ 「Unhealthy」となったコネクションはコネクションプールから除外され、そのコネクション上のス トリームを使っていた処理は「http2: client connection lost」エラーで中断される http.HTTP2Config.PingTimeout 42
43. SendPingTimeoutとPingTimeoutを使えばやりたいことができそう 元々の仮説 使⽤しているコネクションがネットワーク不良であるならば、「http2 client connection lost」を出 るようにしてから、APIリクエストを投げればうまくいくのではないか 導出したアプローチ • • • リクエストを投げてから終わるまでの間に、ヘルスチェックが終了することを保証すれば良い そうすると⼀回⽬のリクエストのタイムアウト前までに 「http2: client connection lost」エラーが出る(コネクションが死んでいる場合) その状態でリトライしたら、新しいコネクションを使ってくれるのでうまくいくようになるは ず！ 43
44. SendPingTimeoutとPingTimeoutを使ったリトライの図 ⽬指すべきリトライの姿 44
45. SendPingTimeoutとPingTimeoutを使ったリトライの図 ⽬指すべきリトライの姿 SendPingTimeout + PingTimeout < Contextのタイムアウト となるようにすればよい！！ 45
46. アジェンダ • REALITYが遭遇したあるネットワーク上の障害 • 効果がなかった対策、そしてたてられた仮説 • 障害解決のための知識：HTTP/2の基礎 • 障害解決のための知識：net/httpのコネクション管理 • 学んだ知識を元に導出したアプローチとその結果 • まとめ 46
47. 最終的なコード：SendPingTimeoutとPingTimeoutの設定値 func createHTTPClient() *http.Client { transport := http.DefaultTransport.(*http.Transport).Clone() … (DialContextだったり IdleConnTimeoutだったりその他パラメータも調整 ) transport.HTTP2 = &http.HTTP2Config{ SendPingTimeout: 5 * time.Second, PingTimeout: 3 * time.Second, } return &http.Client{ SendPingTimeout: 10秒から5秒に PingTimeout: 10秒から3秒に Transport: transport, } } var client = createHTTPClient() 47
48. 最終的なコード：API呼び出し部分 var client = createHTTPClient() // デフォルトからカスタマイズした http.Client // コインを付与する処理 func issueCoin(coinAmount uint) error { for i := range 2 { ctx, cancel := context.WithTimeout(ctx, 10 * time.Second) ... res, err := client.Do(req) // コインを付与する APIを叩く if err != nil { ... continue } } return errors.New("リトライしても失敗 ") SendPingTimeout(5s) + PingTimeout(3s) <Contextのタイムアウト(10s) が成⽴ マージン⽤に2s確保されている } 48
49. 結果 • うまくいった！ ◦ ◦ ⼀回⽬のリクエストで失敗する際にエラーが「context deadline exceeded」から「http2: client connection lost」に変わった ⼆回⽬のリクエスト(リトライ)が成功するように！ • 今回の障害に起因する補填作業の件数が0になった！ • ここまできてようやく最初の設定でうまくいかない理由もわかった 49
50. 問題が起きていたコード(再掲) func createHTTPClient() *http.Client { transport := http.DefaultTransport.(*http.Transport).Clone() … (DialContextだったり IdleConnTimeoutだったりその他パラメータも調整 ) transport.HTTP2 = &http.HTTP2Config{ SendPingTimeout: 10 * time.Second, PingTimeout: 10 * time.Second, } return &http.Client{ Transport: transport, } } var client = createHTTPClient() 50
51. 問題が起きていたコード(再掲) func createHTTPClient() *http.Client { transport := http.DefaultTransport.(*http.Transport).Clone() … (DialContextだったり IdleConnTimeoutだったりその他パラメータも調整 ) transport.HTTP2 = &http.HTTP2Config{ SendPingTimeout: 10 * time.Second, PingTimeout: 10 * time.Second, } return &http.Client{ Transport: transport, } } SendPingTimeoutが PingTimeoutがともに10秒 つまりContextのタイムアウト時間より⼤ var client = createHTTPClient() 51
52. アジェンダ • REALITYが遭遇したあるネットワーク上の障害 • 効果がなかった対応策、そしてたてられた仮説 • 障害解決のための知識：HTTP/2の基礎 • 障害解決のための知識：net/httpのコネクション管理 • 学んだ知識を元に導出したアプローチとその結果 • まとめ 52
53. まとめ • HTTP/2は仕組み上、コネクション1本あたりの⽣死が与える影響が⼤きいので、HTTP/1のときよりさら に慎重な死活管理が求められる • コネクション不良を検知できない状態でリトライをしても死んだコネクションが使われ続けるリスクが ある • HTTPクライアントの各種パラメータは適当な値ではなく、意思をもって根拠のある値を設定することが ⼤事 ◦ そのためにはネットワークの基礎であったりnet/httpの実装を深掘りするのがなんだかんだ近道 今一度自分たちの HTTPClientのコードにどのようなパラメータ設定が されているか確認していただき、改めてそのパラメータにしている理由などに想 いを馳せるきっかけになれば幸いです。 53
54. ご清聴ありがとうございました 54
55. Appendix • https://github.com/egonelbre/gophers 55