こんにちは！日々のインフラ運用やクラウドの裏側を覗くのが大好きなSREの皆さん、そしてこれからインフラの世界へ飛び込もうとしている皆さん、今日も元気にサーバーと向き合っていますか？
AWSやGCP、そして社内のオンプレミス環境でKubernetesや仮想マシン（VM）を触っていると、「あれ、手元の物理メモリが足りないぞ……？」という冷や汗をかく瞬間に出会うことがありますよね。クラウドの請求書を見て「メモリをオーバーサイズしすぎたかな」と頭を抱えたり、逆に「隣のVMは暇そうにしているのに、こっちのVMはメモリ不足で悲鳴を上げている」なんて不公平な事態に直面したり。
そんなとき、ハイパーバイザー（VMの管理人さん）が魔法のような裏技を使って、リソースを上手に融通してくれる仕組みがあるんです。それが今回のテーマである「メモリバルーニング（Memory Ballooning）」です！
小難しい数式や英語の仕様書は一旦置いておいて、今回は身近な例えを交えながら、このバルーニングが一体どうやって動いているのか、一緒に一歩ずつ優しく紐解いていきましょう！
—
1. そもそも「メモリのオーバーコミット」ってなに？
仮想化の世界には、「オーバーコミット（Overcommitment）」という、ちょっとドキドキする技術があります。
例えば、手元に実物の物理メモリ（RAM）が 32GB しかないホストマシンがあるとします。普通に考えたら、10GB のVMを3台作ったら、合計 30GB でもうギリギリですよね。4台目を起動しようものなら、メモリがあふれてシステムがフリーズしてしまいます。
しかし、オーバーコミットを許容すると、「どうせ全VMが同時に100%のメモリを使い切るわけじゃないよね？」という楽観的（かつ現実的な）予測のもと、手持ちの 32GB 以上のメモリを各VMに割り当ててしまうのです。
例えるなら、「全校生徒が同時に校庭に出ることはないから」という理由で、実際の生徒数よりも少し少なめの椅子しか用意していない学校のようなものです。普段はうまく回るのですが、全員が一斉に教室に戻ってきたとき（＝全VMが一斉にメモリを使い出したとき）に、大パニックが起きてしまいますよね。
このパニックを防ぎながら、限られた物理メモリを最大限に効率よく使うための「調整役」こそが、今回主役のバルーニングなんです！
—
2. 郵便配達員に例える「バルーニング」の仕組み
では、メモリバルーニングが仮想マシンの内部でどのように働いているのか、「シェアハウスの住人たちと管理人」に例えてみてみましょう。
- 物理ホスト（大家さん）： 全体のメモリ（例:
64GB）を管理している。 - 仮想マシンA・B（シェアハウスの住人）： それぞれに「最大
32GBまで使っていいよ」と部屋を割り当てられている。
ある日、仮想マシンA（住人A）はめちゃくちゃ忙しく、手元のメモリをフルに使っています。一方で、仮想マシンB（住人B）は夜更かしして朝寝坊中、メモリはほとんど使わずスヤスヤと眠っています。
ここで大家さん（ハイパーバイザー）はこう思います。
> 「おいおい、Bの部屋はほとんど空っぽなのに、Aの部屋はパンク寸前じゃないか。Bの使っていないスペースをちょっと拝借して、Aに回してあげられないかな？」
しかし、大家さんが勝手にBの部屋に土足で入り込むことはできません。仮想マシンのOSからすると「自分の部屋だ！」と思い込んでいるからです。
そこで登場するのが、ゲストOS（VMの中）でコソコソと働く「バルーンドライバ（風船ふくらまし係）」という小さなプログラムです。
1. 大家さんからの指令： ハイパーバイザーが、VM Bの中にいるバルーンドライバに「おい、風船を膨らませてくれ！」と頼みます。
2. 風船の膨張： バルーンドライバは、VM BのゲストOSに対して「ちょっとごめん、メモリの領域をくれ！」と要求し、OSから未着手のメモリをガッツリ確保して「風船（バルーン）」を大きく膨らませます。
3. メモリの返還： 風船でパンパンになったVM BのOSは、「あれ、手元で使える自由なメモリが減ったぞ……」と勘違いします。すると、OSは自発的に不要なデータを片付け、空いたメモリをハイパーバイザーに「これ、使ってないから返すね」と差し出すのです。
4. おすそ分け： ハイパーバイザーは、回収したメモリを、今まさにピンチなVM Aにスッと割り当てます。
これが、風船（Balloon）を膨らませたり縮ませたりしてメモリの容量をダイナミックに融通する「バルーニング」の正体です。物理的な増設をしていないのに、まるで生き物のようにメモリが伸縮するなんて、なんだかワクワクしませんか？
—
3. 実務で触れる！ KVM/QEMU環境でのバルーニング設定
「理屈は分かったけど、実際の現場ではどう設定するの？」という方のために、Linuxの代表的な仮想化基盤であるKVM/QEMU（Libvirt）を例に、具体的な設定を見てみましょう。
仮想マシンの定義ファイル（XML）には、以下のようにバルーンドライバ（Memballoonデバイス）が組み込まれています。
<domain type='kvm'>
<name>web-server-01</name>
<memory unit='KiB'>8388608</memory> <!-- 最大割り当てメモリ: 8GB -->
<currentMemory unit='KiB'>4194304</currentMemory> <!-- 起動時の実メモリ: 4上で動かす場合 -->
<devices>
<!-- virtio規格のバルーンドライバを有効化する設定 -->
<memballoon model='virtio'>
<stats period='10'/> <!-- 10秒ごとにメモリの利用統計をハイパーバイザーに報告する -->
</memballoon>
</devices>
</domain>💡 現場のSREが教える！チューニングのポイント
currentMemoryをmemoryよりも小さく設定しておくことで、起動時は省メモリで立ち上げ、必要に応じてバルーンを縮めて（＝メモリを追加して）スケールさせることができます。<stats period='10'/>を設定しておくと、ハイパーバイザー側からゲストOSの本当のメモリ空き状況（カレントの使用率）を正確に把握できるようになります。これがないと、ゲストOSがスワップ地獄に陥っていてもハイパーバイザー側が気づけず、手遅れになることがあるので要注意です！
—
4. 知っておくべき「バルーニングの落とし穴」とトレードオフ
万能に見えるバルーニングですが、現場のインフラエンジニアとしては「光があれば影もある」ことを知っておく必要があります。
1. ゲストOS側での「スワップ（Swap）」発生リスク
ハイパーバイザーが無理やりバルーンを膨らませてメモリを回収した際、もしゲストOS側で急にメモリが必要になったらどうなるでしょう？ OSは慌ててハードディスク（またはネットワークストレージ）の領域を一時的なメモリ代わりにする「スワップ」を起こします。
ディスクへの読み書きはメモリに比べて圧倒的に遅いため、「メモリを融通した結果、かえってシステム全体が激重になった」という本末転倒なトラブル（パフォーマンスのデグレ）が起きることがあります。
2. オーバーヘッドの存在
バルーンドライバ自身も、ホストとゲストの間で「今どれくらいメモリいる？」「これだけ回収するね」といったやり取り（ポーリング）を常に行っています。極微小ではありますが、CPUやメモリのサイクルを消費していることは覚えておきましょう。
—
まとめ：動的メモリ管理を味方につけよう！
今回は、仮想化技術の基礎である「メモリバルーニング」について、郵便配達やシェアハウスの例えを交えながら解説しました。
- バルーニングとは： ハイパーバイザーがゲストOS内のドライバ（風船）を操作し、使っていないメモリを回収して他のVMにシェアする仕組み。
- メリット： 物理的なコストを抑えながら、リソースの密度を高めて効率的なクラウド・オンプレ基盤を運用できる。
- 注意点： ゲストOS側のスワップ発生やパフォーマンス低下に目を光らせる必要がある。
インフラの世界は、一見難しそうに見える技術も、突き詰めていくと「限られた資源をどう仲良く、賢く分け合うか」という人間社会の仕組みによによく似ています。
「あ、今のサーバーの挙動、裏でバルーンが膨らんでいるのかもな」なんて想像できるようになると、日々のインフラ監視やトラブルシューティングが何倍も楽しくなりますよ！
それでは、また次回の技術解説でお会いしましょう。良きSREライフを！
コメント