2026年9月11日（金）に開催された Go Conference 2026 に参加しました。OSSへの関わり方から、Goランタイムの深い話、テスト、HTTP/2の障害対応まで、普段の開発にもつながる学びが多い一日でした。特に印象に残った講演を振り返ります。

Open Source, Open World

スライド資料: https://speakerdeck.com/sanposhiho/gocon2026-open-source-open-world

要約

OSS で小さな貢献を積み重ね、Kubernetes の SIG Scheduling で設計や意思決定を担う役割へ広がっていく過程を扱った講演です。

小さなドキュメント修正から始め、Google Summer of Code をきっかけに Kubernetes コミュニティへ本格的に参加したとのことでした。継続的に貢献する中で、PR を出す側から、設計文書で議論しプロジェクトの方向性を決める側へと役割が変化していったそうです。

講演を通じて一貫していたのは、OSS はコードを書く活動である以上にコミュニティ活動でもある、というメッセージでした。技術力や実績だけではなく、メンターや仲間とのつながりが成長とキャリアを広げる。AI が実装を支援する時代だからこそ、新しいコントリビューターに経験の機会を渡し、プロジェクトを持続可能にしていくメンテナの役割が重要になる、という話が印象的でした。

感想

OSS というと技術力の高い人が参加するものというイメージを持ちがちですが、最初の一歩は小さな修正でよく、活動を続ける理由を自分なりに持つことが大切なのだと感じました。

また、個人が速く進むことよりも、コミュニティとして遠くまで進むことを選ぶという考え方に共感しました。自分が使っているツールや関心のある領域で、まずは小さな貢献から試してみたいです。

When Goroutines Are Not Enough: Runtime Locality in High-Throughput Go

スライド資料: https://speakerdeck.com/takehaya/gocon2026-when-goroutines-are-not-enough-runtime-locality-in-high-throughput-go

要約

高スループットなパケットキャプチャーツールを題材に、Go のランタイム、eBPF、NIC の RSS、CPU 配置まで含めて性能を改善した講演でした。

対象となったツールでは、NIC が受信したパケットを eBPF のリングバッファへ書き込み、Go のリーダーが読み出して PCAP に出力します。初期状態では約 0.5Mpps だったスループットを、計測と仮説検証を繰り返して約 4Mpps まで改善していました。

改善のポイントは主に三つです。まず、pprof と perf を使って syncPreempt や memmove、CPU ごとの負荷の偏りを把握しました。次に、コピーを減らし、読み取りや位置更新をバッチ化しました。最後に、IRQ・RSS キュー・eBPF リング・Go のリーダーの CPU 配置を見直しました。Go のスケジューラに任せた方がよい場面もあるため、設定を先に決め打ちするのではなく、計測に基づいて比較する姿勢が重要だと説明されていました。

ストリーム処理では、並列化と順序保証の両立も重要です。Prometheus Remote Write のように、同じ系列のデータは同じシャードへ送ることで順序を守りつつ、異なる系列は並列に処理する設計が紹介されました。

感想

「ゴルーチンを増やせば速くなる」という単純な話ではなく、実行時のコピー、割り込み、CPU 配置、Go ランタイムの挙動まで見ないと性能問題は解けないことを実感しました。

特に、ボトルネックを推測で決めず、メトリクス・pprof・perf を組み合わせて仮説を検証していく流れが参考になりました。パフォーマンスチューニングでは、まず観測できる状態をつくることが大事だと改めて感じました。

synctest時代のhttptest: Go 1.27で変わるHTTPサーバテストの裏側

スライド資料: https://speakerdeck.com/budougumi0617/go-conference2026-synctest-and-httptest

要約

testing/synctest と net/http/httptest を使った、決定的な非同期テストについての講演です。

testing/synctest は、時間に依存する非同期処理を実時間に頼らずテストするための仕組みです。テストは「バブル」と呼ばれる独立した実行環境で動き、バブル内のすべてのゴルーチンが外部から解除されないブロック状態、すなわち Durably Blocked になると、待機の完了や仮想時間の進行を判断できます。

一方で従来の httptest は実際のネットワーク I/O を使うため、サーバーの受信待ちが外部イベントで解除されうる状態として扱われます。そのため testing/synctest と組み合わせると、バブル内の処理がすべて停止したと判断できず、テストが進まない問題がありました。

Go 1.27 で追加された httptest.NewTestServer は、インメモリのネットワークを利用します。通信をチャンネルや共有バッファで表現することで testing/synctest のモデルと整合し、HTTP サーバーを含む非同期・タイムアウト処理を高速かつ決定的にテストできるようになります。

感想

時間待ちを含むテストは time.Sleep に頼ると遅く、不安定になりやすいため、仮想時間で扱える仕組みはとても魅力的です。HTTP 通信を伴う処理までその対象にできるようになったことで、リトライやタイムアウトのテストがかなり書きやすくなりそうです。

内部実装の説明を通じて、テストの使い勝手は API だけでなく、ランタイムがどのように待機状態を認識するかにも支えられているのだと理解できました。Go 1.27 を使用して、testing/synctest と httptest.NewTestServer を試してみたいです。

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

スライド資料: https://speakerdeck.com/myus4a/2-o-jitsupurodakuto-shougai-kara-manabi-naosu

要約

REALITY で実際に起きた障害を題材に、Go の HTTP/2 クライアントにおけるコネクション管理とタイムアウト設計を解説した講演でした。

課金認証基盤へのリクエストが突発的にタイムアウトし、一度発生するとほぼすべてのリクエストが失敗する状態になっていました。調査の結果、ロードバランサーなどの影響で、クライアントからは切断を検知できないハーフオープンなコネクションを再利用していることが原因だと分かりました。

HTTP/2 では一つの TCP コネクションで複数のリクエストを多重化するため、コネクションが長く使われます。Go のクライアントは、ReadIdleTimeout の間フレームを受信しなければ PING を送り、PingTimeout の間に応答がなければコネクションを不健全と判断して破棄します。

この事例では、リクエストのタイムアウトよりもヘルスチェック完了までの時間が長かったため、リトライしても不健全なコネクションを使い続けていました。ReadIdleTimeout + PingTimeout をリクエストのタイムアウト以内に収めることで、不健全なコネクションを先に破棄し、次のリトライで正常なコネクションを使えるようにして解決したとのことでした。

感想

リトライは万能ではなく、失敗の原因が接続の再利用にある場合は、同じ失敗を繰り返すだけになるという点が印象に残りました。タイムアウトは個別に設定するだけではなく、リクエスト、ヘルスチェック、リトライの時間関係を一つの設計として考える必要があります。

自分が関わるサービスでも、HTTP クライアントのタイムアウト値がなぜその値になっているのかを確認したくなりました。障害時のログから仮説を立て、HTTP/2 の実装まで読み解いて解決につなげた調査の過程も、とても参考になりました。

まとめ

今回の Go Conference では、異なるテーマの講演に共通して、仕組みを理解し、観測し、意図を持って設計することの重要性を感じました。

OSS ではコミュニティとの関わりを、性能改善では計測を、テストではランタイムの待機モデルを、ネットワーク障害ではコネクションとタイムアウトの関係を理解することが求められます。普段は便利な抽象化の上で開発できていますが、困ったときに一段下の仕組みを見に行けるよう、これからも学びを深めていきたいです。