ABEMA広告配信サーバーのOOM原因とgo-cacheのTTL不具合を追う

編集: グリットアーツ編集部

公開日：2026年9月27日

3行解説

ニュースの概要

CyberAgent Developers Blogは2026年9月16日、ABEMAの広告配信システムで起きたメモリ増加障害の調査結果を公開しました。対象は、広告キャンペーンの配信目標を2分ごとに計算し、インメモリキャッシュへ書き込むバックエンドです。本番ではメモリ使用量が右肩上がりに増え、8GiBの上限に達してOOMKillが繰り返されました。調査の結果、原因はpatrickmn/go-cacheをラップした社内共通ライブラリの実装にあり、TTL付きキャッシュのはずなのにメモリが解放されない状態になっていました。

何が新しいのか

この事例の新しさは、キャッシュとしては正常に見えるのに、裏側ではメモリだけが増え続ける点です。記事では、goroutine数は横ばいなのにheap_objectsだけが0.65Mから15.4Mまで増えたこと、v2.1.50では安定していたのにv2.1.51で増加が始まったこと、そして変更点が「2分粒度の集計区間追加」だけだったことが示されています。つまり、機能追加そのものよりも、キーの増え方とTTL削除の仕組みが噛み合わなかったことが本質でした。

さらに、TTLの削除はGet時の論理判定だけではなく、janitorという巡回処理が物理削除を担うことも明らかになりました。ここでruntime.SetFinalizerと値コピーの組み合わせが重なり、期限切れでもメモリが回収されない構造になっていました。単なる「キャッシュが増えた」ではなく、削除の責務がどこにあるかを見誤ると、Goでもリークが起きることを示した点が重要です。

グリットアーツ編集部の分析

このニュースで注目すべきなのは、障害がユーザー向けの画面やAPIエラーではなく、裏方の計算プロセスで起きていたことです。広告配信のような長時間稼働システムでは、デプロイでPodが入れ替わるとメモリが一度リセットされるため、リークが見えにくくなります。今回も、デプロイ間隔が空いて初めて8GiBの上限に達しました。つまり、監視で見るべきなのは稼働率だけでなく、heap_objectsのような増え方の指標だと分かります。

また、2分ごとの定期処理に2分粒度のキーを追加したことで、上書きではなく新規エントリが増えた点は、日本の現場でも起こりやすい落とし穴です。バッチ間隔、TTL、cleanupIntervalがずれると、キャッシュは「あるのに消えない」状態になり得ます。Goでインメモリキャッシュを使う場合、TTL設定だけで安心せず、物理削除の仕組みまで確認する必要があります。

日本の現場で考えると

この事例は、広告配信だけでなく、在庫計算、予約制御、配信目標の集計、監視集約など、長時間動く単一プロセスにそのまま当てはまります。特に日本の本番環境では、夜間デプロイや定期リリースが多いと、メモリが都度リセットされて異常に気づきにくいことがあります。再起動で一時的に復旧しても、根本原因が残っていれば運用負荷だけが増えます。

向いているのは、キャッシュの寿命と削除条件を明確に管理できる構成です。一方で、TTLを付けたから自動的にメモリが減ると考える用途は慎重に見るべきです。特に、キーの粒度が処理間隔と一致する場合は、エントリ数が想定以上に増える可能性があります。サーバー室やクラウド基盤では、メモリ上限に達する前に検知できる監視設計が重要です。

導入・検討時に確認したいこと

• TTL切れのエントリが、論理削除だけでなく物理削除される条件は何か。
• janitorやcleanupIntervalの設定が、実際の更新間隔と合っているか。
• goroutine数だけでなく、heap_objectsやキャッシュ件数を監視できるか。
• キーの粒度が定期処理の間隔と一致したとき、エントリが増え続けないか。
• デプロイ時にメモリがリセットされることで、リーク検知が遅れないか。

現時点で分かっていないこと

記事から確認できるのは、ABEMAの広告配信サーバーで起きた原因と調査過程までです。社内共通ライブラリの具体名、修正後の長期安定性、他システムへの影響範囲は明示されていません。また、同種の実装がどの程度社内に広がっているかも不明です。

Goのインメモリキャッシュは、TTLを付ければ安心とは限りません。長時間稼働する基盤の監視や保守設計を見直す際は、メモリの増え方と削除の仕組みを切り分けて確認することが重要です。

出典: CyberAgent Developers Blog