【入門編】オーバーコミットメント（Overcommitment）の限界とスラッシングの発生原因 – クラウドインフラと仮想化ネットワーク実践ガイド

こんにちは！クラウドインフラの世界へようこそ。SREとして日夜システムの安定稼働と格闘している私ですが、今回はインフラ初学者の皆さんが一度はつまずく「仮想化の裏側」について、とってもエキサイティングなお話をしたいと思います。

クラウド（AWSやGCPなど）やオンプレミスの仮想化基盤を使うとき、私たちは物理的なマシンの限界を超えて、自由自在にサーバーを生み出しているような感覚になりますよね。でも、ちょっと待ってください。「実態以上のものを配る」ということは、現実世界でもどこかに無理が生じるものです。

今回は、仮想化技術の魔法を支える裏側で、一歩間違えるとシステム全体を地獄に突き落とす「オーバーコミットメント（Overcommitment）の限界とスラッシング」について、身近な例えを交えながら優しく紐解いていきましょう！

—

1. 仮想化の「お得な裏技」：オーバーコミットメントとは？

まずは、仮想化の基本からおさらいしていきましょう。
皆さんは「ハイパーバイザー」という言葉を聞いたことがありますか？ VMware ESXiやKVMなどが代表的ですが、これらは1台の頑丈な物理サーバー（ホスト）の上に、いくつもの仮想的なサーバー（ゲスト）を同居させるための「管理人さん」のような存在です。

さて、ここで管理人さん（ハイパーバイザー）は、ちょっとした「ずる賢い工夫」を考えます。これがオーバーコミットメント（過剰割当）です。

郵便局の窓口に例えてみましょう

想像してみてください。ここに、同時に4人しか対応できない小さな郵便局（物理メモリが4GBのサーバー）があります。
通常であれば、窓口は4つまで（仮想サーバーの合計メモリも4GBまで）しか作れませんよね。

しかし、局長（ハイパーバイザー）はこう考えました。
「お客さん（仮想サーバー）は全員が同時に来窓するわけじゃない。普段はみんな書類を眺めているだけだから、窓口を実際には8つ（8GB分）作っちゃおう！どうせ全員が同時に本気で窓口を使うわけないさ！」

これがオーバーコミットメントの正体です。物理的な実力（キャパシティ）を超えて、見せかけの大きなリソースをユーザーに割り当てることで、サーバーの利用効率を限界まで高めるテクニックなんですね。クラウドの世界では、コストを最適化するために日常茶飯事で行われている仕組みです。

—

2. 悪夢の始まり：「スラッシング」という名の交通渋滞

「みんなが同時に使わなければお得！」という素晴らしいアイデアですが、世の中そんなに甘くありません。

ある日、すべての仮想サーバーが「一斉に大仕事を始めなければならない瞬間」が訪れました。例えば、夜間のバッチ処理が一斉に走り出したり、セール告知でアクセスが急増したりしたときです。

8つの窓口に、それぞれ本気で用事を持ったお客さんが殺到しました。しかし、実際の窓口（物理メモリ）は4つしかありません。

席が足りない！慌ただしい「席の貸し借り」

物理メモリがパンク寸前になったとき、管理人さん（ハイパーバイザー）はどうするでしょうか？
「今使っていない仮想サーバーAの荷物をいったん机からどかして、ダンボール（ハードディスクやSSDなどのストレージ領域）にしまっておこう。そして、今急ぎの仮想サーバーBをそこに座らせよう！」

この、「メモリのデータを一時的にストレージ（スワップ領域）に退避させ、必要になったらまたメモリに戻す」という作業をスワップ（Swap）と呼びます。

スラッシング（Slashing）の発生

ここからが本当の地獄の始まりです。
あまりにもメモリが足りなすぎて、管理人さんが「ダンボールから荷物を取り出す ⇄ 不要な荷物をダンボールにしまう」という作業だけで手一杯になってしまいました。

お客さんに対応する本来の仕事（CPUの演算）をする時間が全くなくなり、ただただ部屋の中を書類の入ったダンボール箱を持って走り回るだけ状態——これがスラッシング（Slashing）です。

ネットワークやディスクの帯域はパタパタと行き来するデータの往復だけで埋め尽くされ、CPU使用率は「待ち状態（I/O Wait）」で跳ね上がるのに、サーバー全体の処理能力は急激に低下し、画面はフリーズしたように動かなくなります。これが、オーバーコミットメントの限界を超えたときに起きる悲劇なのです。

—

3. 実務で遭遇するスラッシングの兆候と、現場の対策

「じゃあ、オーバーコミットメントは悪者だから使わないほうがいいの？」というと、そうではありません。コストパフォーマンスを最大化するために、SREやインフラエンジニアは常にこの「ギリギリのライン」を攻めています。

では、現場のエンジニアは、このスラッシングの足音をどうやって察知し、どう対策しているのでしょうか？一歩ずつ実践的なアプローチを見ていきましょう。

兆候を掴むためのメトリクス監視

Linux環境やKubernetesクラスターにおいて、スラッシングが起きているときは次のような兆候が表れます。

1. メモリ使用率（Memory Usage）が常に90%以上
2. スワップイン（si） / スワップアウト（so）の数値が跳ね上がっている
3. ロードアベレージ（Load Average）が無駄に高いのに、CPUの処理が進んでいない

試しに、Linuxサーバーのコンソールで現在のメモリとスワップの状況を確認するコマンドを叩いてみましょう。

# 2秒ごとにメモリとスワップの利用状況をリアルタイムで監視するコマンド
# 'si' (swap in) と 'so' (swap out) の列が常にゼロ以外で大きく変動している場合、スラッシングの危険信号です！
vmstat 2

（※インラインコードの si や so は、スワップが発生しているかを見極める重要な手がかりになります。）

—

4. 現場で使える！オーバーコミットメントを安全に運用する設定例

スラッシングを防ぐためには、ハイパーバイザーや仮想マシン（あるいはKubernetesのノード）に対して、適切な「お守り（制限）」を設定しておくことが極めて重要です。

例えば、Linuxのカーネルパラメータである vm.swappiness を調整することで、OSがどれくらい積極的にスワップを使いたがるかをコントロールできます。

例1: Linuxカーネルのスワップ感度調整 (/etc/sysctl.conf)

デフォルトでは多くのLinuxディストリビューションで vm.swappiness = 60 などと設定されており、メモリに少し余裕があってもスワップを使おうとします。これを下げることで、無駄なスワップを抑制できます。

# /etc/sysctl.conf の末尾などに追記する設定例
# スワップの積極性を 0 から 100 の間で指定します。
# 0に近いほど、物理メモリの限界ギリギリまでスワップを使わず耐えようとします。
vm.swappiness = 10

# メモリが枯渇したときに、キャッシュ領域をどれくらい優先して解放するかを調整
vm.vfs_cache_pressure = 50

設定を反映するには、以下のコマンドを実行します。

# 設定ファイルをリロードして即時反映させる
sudo sysctl -p

例2: Kubernetes（K8s）におけるリソースのRequestsとLimitsの設定

コンテナ仮想化技術であるKubernetesでも、オーバーコミットメントは日常茶飯事です。ポッド（Pod）を安全に配置するため、私たちはマニフェストファイルに requests（最低限必要な保証リソース）と limits（これ以上使ってはいけない上限）を厳格に定義します。

apiVersion: v1
kind: Pod
metadata:
  name: robust-web-app
spec:
  containers:
  - name: web-frontend
    image: nginx:latest
    resources:
      requests:
        memory: "512Mi"  # このポッドを動かすために最低限必要なメモリ（スケジューリングの基準）
        cpu: "500m"      # 最低限必要なCPUパワー
      limits:
        memory: "1Gi"    # この上限を超えてメモリを食いつぶそうとすると、OOM Killerにより強制終了される
        cpu: "1000m"     # CPUの上限（これ以上はスロットリングされる）

Kubernetesの世界では、もしメモリの limits を超えて暴走するアプリが現れた場合、OSのスラッシングで全体が巻き添えになる前に、賢い番人（OOM Killer）がそのアプリをピンポイントで強制終了（OOMKilled）してシステム全体を守る仕組みになっています。これもスラッシングを防ぐための現代的な防衛策の一つです。

—

まとめ

いかがでしたでしょうか？
今回は、仮想化技術の裏側にある「オーバーコミットメントの限界」と、性能がガクッと落ちる「スラッシング」のメカニズムを、郵便局の窓口や日々のインフラ設定に例えて解説しました。

オーバーコミットメントは、限られた物理リソースを有効活用する素晴らしい技術である一方、過信すると危険。
全員が同時にリソースを求めると、ハイパーバイザーがデータの出し入れだけに追われるスラッシング（交通渋滞）を引き起こす。
vmstat などのツールで兆候をキャッチし、適切な swappiness の調整や、クラウド・K8sでのリソース制限（requests/limits）を行うことがSREの腕の見せ所。

インフラやネットワークの世界は、こうした「物理の限界と論理の工夫のせめぎ合い」で満ちあふれています。一歩ずつ、その挙動の理由を紐解いていけば、トラブルシューティングもきっと楽しくなりますよ。

それでは、また次回のインフラ探訪でお会いしましょう！