メモリの「空き」は幻か？——バルーニング技術で仮想化基盤のオーバーコミットを極める
クラウドエンジニアの皆さん、こんにちは。
皆さんはAWSやGCPでインスタンスを立ち上げる際、メモリ容量を気にせず「とりあえず多めに」確保していませんか？あるいは、オンプレミスのハイパーバイザー上で「物理メモリは128GBしかないのに、合計200GB分のVMを動かしたい」という無茶振りに頭を抱えたことはないでしょうか。
今日は、そんなインフラの「見えない綱渡り」を支える技術、メモリバルーニング（Memory Ballooning）の深淵に迫ります。教科書的な定義を超えて、現場でなぜこの仕組みが重要なのか、そしてトラブル時にどう立ち回るべきかを、叩き上げの視点から解説します。
—
1. なぜ「バルーニング」が必要なのか：オーバーコミットの甘い罠
ハイパーバイザー（KVMやESXiなど）において、物理メモリを各ゲストOSに静的に割り当てるのは「贅沢」です。多くのWeb APIサーバーは、起動直後はメモリを食いますが、アイドル時には大半がキャッシュとして眠っています。
ここで登場するのがオーバーコミットです。「実際に使っていないメモリは、他の誰かに貸し出せばいい」という考え方ですね。しかし、ホストが無理やりメモリを奪うと、ゲストOSは突然のメモリ不足に見舞われ、OOM Killer（Out of Memory Killer）が暴走してプロセスを殺し始めます。
そこで、ゲストOSのカーネルと「対話」し、平和的にメモリを回収するための仕組みがバルーニングです。
通信フロー（メモリ回収のシーケンス）
1. ホスト側の判断: ハイパーバイザーが「物理メモリが逼迫している」と判断。
2. バルーン膨張指示: ハイパーバイザーがゲストOS内のvirtio-balloonドライバに対し、「メモリをよこせ」と信号を送る。
3. ゲストOSの苦渋の決断: ゲストカーネルは、バルーンドライバを通じて未使用メモリを確保し、それをホストに差し出す（この時、ゲスト内ではメモリが減ったように見える）。
4. 再割り当て: ホストは回収したメモリを別のVMへ割り当てる。
—
2. 実践：KVM/QEMU環境でのバルーニング設定
実務において、KVM上でこの挙動を制御するには、ドメイン設定ファイル（XML）の調整が不可欠です。
<!-- /etc/libvirt/qemu/web-api-server.xml -->
<devices>
<!-- バルーンドライバの定義 -->
<memballoon model='virtio'>
<!-- 統計情報の収集間隔（秒）。トラブルシューティング時に必須 -->
<stats period='5'/>
</memballoon>
</devices>ここで重要なのが <stats period='5'/> です。これを入れておかないと、ホストから「今どれくらいメモリ余ってる？」と問い合わせても、正確な統計値が返ってこないことがあります。障害調査の際、「virsh dommemstat が何も返さない！」と焦らないための定石です。
—
3. デバッグと運用：現場で役立つコマンド
運用中、VMのパフォーマンスが急に落ちた場合、バルーニングが原因で「メモリが絞り取られていないか」を確認する必要があります。
ホスト側からメモリ状態を確認する
virshコマンドを使って、ゲストのメモリ状況をリアルタイムに覗き見ましょう。
# ゲスト内のメモリ使用状況を統計データとして取得
virsh dommemstat web-api-server
# 出力例：
# actual: 4194304 (現在の割り当て量 KB)
# rss: 3200000 (ホストから見えている実使用量)もし actual が target より極端に小さければ、バルーニングによってメモリが回収されすぎており、それが原因でゲスト内のアプリケーションがスワップアウトを起こしている可能性が高いです。
—
4. API開発者が知るべき「メモリの境界線」
Web APIを開発する際、コンテナ（Kubernetes）環境であっても、ノードレベルではこのバルーニングの影響を受けます。特に、cgroups の制限値とバルーンによる回収が競合すると、Podの OOMKilled が頻発します。
PythonやNode.jsでメモリ制限を意識したコードを書く際、psutil等で取得するメモリ使用量と、OSが報告する空きメモリの間には常に乖離があることを忘れないでください。
import psutil
# ゲストOS内で「実質的に使えるメモリ」を確認するロジック
def check_memory_pressure():
mem = psutil.virtual_memory()
# 物理的な空きメモリだけでなく、キャッシュやバッファも考慮した閾値監視
if mem.available < 500 * 1024 * 1024: # 500MBを切ったら警告
print("警告: 物理メモリ逼迫の兆候。バルーニングによる回収の影響か？")
return True
return False—
5. シニアからの教訓：バルーニングを「信じるな」
最後に、一つだけ現場の知見を。
バルーニングは便利な機能ですが、「データベースサーバー」のようなメモリ消費が激しいアプリケーションには極力適用しないでください。 データベースはメモリをキャッシュとして使い切りたがるため、ホストがバルーンでメモリを回収しようとすると、激しいページフォールトが発生し、I/O待ちによるパフォーマンス劣化を引き起こします。
- Web API/Appサーバー: バルーニング有効（オーバーコミットを活用してコスト削減）
- DB/Redis/キャッシュサーバー: メモリを固定（Pinning/Reservation）
インフラの構成管理は、技術の「仕組み」を理解した上で、その技術を「どこに適用しないか」を決める作業です。皆さんの環境が、今日も安定して稼働することを願っています。
それでは、また次回の深掘り記事でお会いしましょう。
コメント