記事のサマリー(TL;DR)
- 2026年9月11日、中野セントラルパークカンファレンスでGo Conference 2026が開催。参加者700人超、19セッション
- 「Invisible OOM Kill」セッションでは、GOGC/GOMEMLIMIT の誤設定でGoプロセスだけが無音で落ちる障害の原因と対策を解説
- タイムテーブル全体でAI・LLMを主題にしたセッションがゼロ。GC・ランタイム・標準ライブラリに終日集中した稀有な構成
freee・Go利用企業の運用エンジニアが押さえておくべき「Invisible OOM Kill」の実態
Go を本番運用している組織にとって、今回のカンファレンスで報告された「Invisible OOM Kill」は他人事ではありません。NginxとGoが同一コンテナで動く構成は、歴史的な経緯でそうなっているケースが国内でも少なくなく、Kubernetes 上でPodのステータスに「OOMKilled」が出ないまま5xxエラーが続発するという障害は、ログを追っても原因が掴みにくい類のものです。
特に GOGC=500(デフォルト100に対して5倍緩和)のような設定は、CPUコスト削減を目的とした最適化として一定の合理性がありますが、Goランタイム自体がコンテナのメモリ上限を認識しない点を見落とすと、GCが動く前にOOM Killerに先を越される状態になります。GOMEMLIMIT でGoにメモリ上限を明示し、GOGC=off でGCのトリガーをGOMEMLIMIT一本に絞る対策は、Go 1.19 以降であれば今すぐ適用できる内容です。kintone や Salesforce の API をバックエンドで呼び出すGoサービスなど、バースト的にメモリが増減する構成では特に有効です。
詳細
Go Conference 2026 概要
- 開催日: 2026年9月11日(木)
- 会場: 東京・中野セントラルパークカンファレンス
- 規模: 参加者700人超(オンライン含む)、セッション19本、スポンサー55社、スタッフ51人
- freeeの立場: シルバースポンサーとして協賛、ブース出展
freee でエージェント開発を担当する新卒エンジニアがGoを書き始めたのは入社後。Go Conference も今回が初参加という立場から、特に印象に残った2セッションを中心にレポートをまとめています。
セッション①「Podは生きているのにGoだけが落ちる:GOGCとGOMEMLIMITで追うInvisible OOM Killの謎」
登壇者: 株式会社エウレカ / Takeshi Watanabe 氏
形式: ドリンクセッション(昼食時間帯・15分)
障害の概要
- 数日に一度、5xxエラーが大量発生した後、何事もなかったように復旧
- panicログなし、PodステータスにOOMKilledなし、Goプロセスだけが消える
原因の構造
歴史的な経緯で NginxとGoが同一コンテナ 内で動作していた。Linuxの OOM Killer はコンテナのメモリ上限超過時に「最もメモリを消費しているプロセス」を選択して終了させる。今回のケースでは:
- 終了したのはPID 1ではないGoプロセス
- PID 1(Nginx)は生き残るのでコンテナ自体は落ちない
- どこにもOOMの記録が残らない → 「Invisible」OOM Kill
なぜメモリが増えすぎたか
Goには GOGC(ガベージコレクションのトリガー比率)という設定があり、デフォルト値は100(= live heapの2倍でGC発動)。このチームはCPU負荷軽減のために GOGC=500(= live heapの6倍)に設定。さらに重大な点として、Goランタイムはコンテナのメモリ上限を自分では認識しない。その結果、GCが発動する前にOOM Killerがプロセスを終了する状態に陥っていた。
採られた対策(3点)
| 対策 | 内容 |
|---|---|
| コンテナ分離 | NginxとGoを別コンテナに切り分ける |
| GOMEMLIMIT 設定 | GoランタイムにコンテナのメモリUpper boundを明示 |
| GOGC=off | GCトリガーをGOMEMLIMIT一本に集約し、管理を単純化 |
15分のセッションでありながら、GoのGC設計・Linuxのメモリ管理・Kubernetesコンテナ境界という3層の知識が一度に整理される内容でした。
セッション②「range over func 2年間の軌跡 — Issue #56413 はGoのエコシステムをどう変えたか」
登壇者: 國分 竜二 氏(合同会社DMM.com)
形式: 20分セッション
背景
Goにはコレクションを走査する統一的な書き方が長らく存在しなかった。
filepath.Walksync.Map.Rangeflag.Visit
これらはいずれもコレクションを反復処理するメソッドだが、呼び出し方も戻り値の形もバラバラ。この非一貫性を解消したのが Go 1.23 で正式導入された「range over func」 です。
設計の決断
セッションの核心は「なぜ interface で解決しなかったのか」という問いへの回答でした。Goチームが最終的に選んだのは、言語仕様そのものに組み込む方針。2022年のDiscussion #56413から2年間の議論を追う構成で、Issueトラッカーの議論を時系列で読み解きながら、言語設計がどう合意形成されるかを可視化した内容でした。
参加ハードルの低さ
カンファレンスの間口の広さがレポート全体で強調されています。具体的な配慮は以下の通りです。
- 難易度ラベル: 全セッションに「初心者向け / 中級者向け / 上級者向け」を付与
- ワークショップ: 6本中5本が初心者向け
- 参加費: 学生1,500円〜、一般5,000円〜、学生支援制度あり
- オンライン: 無料視聴可能。アーカイブ公開も予定
ドリンクセッション(昼食時間帯の15分枠)にエウレカのセッションが入っていたように、最も気軽な枠に実務直結の内容が配置される設計でした。
Go Context Hall:歴史の年表
会場には「Go Context Hall」と名付けられたホワイトボードが設置され、2007年の設計開始から以下の節目が年表化されていました。
- 2012年:Go 1.0リリース、「互換性の約束」
- Go 1.7:
contextパッケージ標準化 - Go 1.18:ジェネリクス導入
参加者は付箋で自分の記憶を貼り足すことができ、「GOPATHなつかしい」「Russ Coxが手動修正に疲れてgofixを投入」といったコメントが並んでいました。一人で来場しても気まずくならない、会話しなくても「参加している感」が生まれる工夫です。
TinyGoワークショップとスポンサーブース
- ワークショップは事前予約制。freeeメンバーの一人はTinyGoワークショップで実際の基板を触れた
- スポンサーブースのビンゴカードで、初めて話す企業のブースにも足を運びやすい導線を設計
- freeeブースでは「freeeがGoを使っているって知ってた?」というアンケートで来場者と対話
AIセッションゼロという特徴
タイムテーブルを最初から最後まで確認しても、AIやLLMを主題としたセッションは1本も存在しませんでした。2026年という時点で、あらゆる技術カンファレンスにAIトークが混入しがちな中、Go Conference 2026は GC・ランタイム・標準ライブラリの話で終日を埋める という方針を維持しました。流行ではなく言語の本質を深掘りできる場として機能した点が、参加者から評価されています。
クロージングで示された規模データ
| 項目 | 数値 |
|---|---|
| パートナースポンサー | 55社 |
| Gopher スポンサー | 23人 |
| スタッフ | 51人 |
| セッション数 | 19本 |
| スポンサーブース | 18 |
| 参加者(オンライン含む) | 700人超 |
当日の全セッション資料は、Koya IWAMURA 氏がZennにまとめています。アーカイブ動画の公開も予定されているため、当日参加できなかったセッションも後から確認できます。