DeNAがGCE E2の見掛け上のメモリ増加を解明、50%コスト削減へ

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

公開日：2026年10月4日

3行解説

ニュースの概要

DeNAは2026年10月2日、同社のインフラSREによる技術記事で、Google Compute Engine（GCE）のE2マシンタイプで発生していた原因不明のメモリ高騰について公開しました。対象は、e2-highmem-8を使う十数台のインスタンスです。topではプロセス単位の使用量が説明できず、スペックダウンの判断が難しい状態でした。調査の結果、LinuxカーネルとGCEハイパーバイザの仕組みによる「見掛け上のメモリ増加」だと分かり、監視の見直しを経てコスト削減につなげたとしています。

何が新しいのか

新しい点は、単に「メモリが増えた」のではなく、virtioメモリバルーニングによる見掛け上の増加だと切り分けたことです。topのRES合計では説明できない増加量を、/proc/vmstatのballoon_inflateとballoon_deflateの差分で確認し、約34.2GB相当と突き合わせました。さらに、Node Exporterの標準設定では見えにくいメトリクスを追加し、継続監視できる形にした点も実務上の価値があります。

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

この事例で重要なのは、E2マシンタイプではメモリバルーニングが動くという前提を、運用監視に落とし込んだ点です。見えているメモリ使用量が高くても、実際にはハイパーバイザが回収した未使用領域である可能性があります。逆に、これを知らずにサイジングすると、必要以上に大きいインスタンスを維持し続けることになりやすいです。今回のように、原因をOSレベルまで掘ると、スペックダウンの可否を感覚ではなくデータで判断しやすくなります。

日本の現場で考えると

日本企業のクラウド運用では、監視画面に出る数値だけで増強判断をしがちです。しかし、この事例のように、VM基盤の仕組みで見掛け上の使用量が増えることがあります。特に、コスト最適化を進めたいゲーム、SaaS、社内基盤では、E2のような動的リソース管理を前提にした監視設計が必要です。一方で、N4・N4A・N4Dでは同じ仕組みではないため、シリーズをまたいだ比較では前提をそろえないと誤判断につながります。

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

• E2で観測しているメモリ増加が、プロセス起因かバルーニング起因かを分けて見られるか。
• /proc/vmstatのballoon_inflate、balloon_deflate、balloon_migrateを継続採取できるか。
• スペックダウン時に、ピーク時の実メモリ需要を別期間でも確認できているか。
• 監視基盤で、標準設定では見えないメトリクスを追加して運用できるか。
• E2以外のシリーズへ移る場合、同じ前提で比較していないか。

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

記事からは、どの期間・どの条件でバルーニングが発生しやすいかまでは分かりません。また、50%のコスト削減が対象インスタンス全体に対するものか、特定範囲の削減かも本文だけでは限定できません。監視設定の具体的な変更内容も、公開範囲では途中までの説明です。

クラウド基盤では、見えているメモリ使用量がそのまま実需要とは限りません。監視の取り方やサイジングの見直しで迷う場合は、運用前提を整理したうえで検討することが重要です。

出典: DeNA Engineering