【実務・中級編】 Intel EPT（Extended Page Tables）およびAMD NPT（Nested Page Tables） – クラウドインフラと仮想化ネットワーク実践ガイド

クラウドの底力を支える「裏の立役者」：Intel EPT & AMD NPTが変えた仮想化メモリ管理の現実

こんにちは。クラウドインフラの底上げとKubernetesのしびれるようなネットワークトラブルに日々立ち向かっているシニアSREの私です。

夜中にPagerDutyが鳴り響き、「Web APIのレイテンシが急激に悪化している」「データベースの95パータイル値が跳ね上がっている」というアラートを眺めながら、CloudWatchやGCPのモニタリング画面を睨みつける――インフラエンジニアであれば、誰もが一度は経験する胃の痛む瞬間でしょう。

こうしたパフォーマンス劣化の原因を深掘りしていくと、データベースのクエリでも、アプリケーションのコネクションリークでもなく、「ハイパーバイザーの仮想化オーバヘッド」という根深い壁に突き当たることがあります。特に、CPUやネットワークがどれだけ高速になっても、避けて通れないのがメモリ管理のボトルネックです。

今回は、現代のクラウドインフラ、そしてコンテナを支えるKVMやVMware ESXiなどの基盤技術において、絶対に避けて通れないIntel EPT（Extended Page Tables）とAMD NPT（Nested Page Tables）について、パケットの…いや、メモリバスの息づかいが聞こえるほどリアルに、そして実務で直面するトラブルシューティングの視点も交えて解説していきます。

—

1. なぜ仮想化のメモリ管理はこれほどまでに泥臭いのか？

まずは、私たちが普段当たり前のように使っているクラウドインスタンスの裏側で、メモリがどのように扱われているかを整理しましょう。

物理サーバーの上で仮想マシン（VM）を動かすとき、OSは自分がベアメタル（物理機）上で動いていると勘違いしたままメモリを割り当てようとします。しかし、実際にはその下にはハイパーバイザーがいます。

伝統的なソフトウェアによるアドレス変換（Shadow Page Table）の悲劇

初期の仮想化技術では、このアドレス変換をソフトウェアで必死にこなしていました。
1. ゲストOSの仮想アドレス（GVA） $\rightarrow$ ゲストOSの物理アドレス（GPA）
2. ゲストOSの物理アドレス（GPA） $\rightarrow$ ホストOSの物理アドレス（HPA）

この2段階の変換を、ハイパーバイザーが「影（Shadow）」のページテーブルを作ってソフトウェア的に同期させていたのです。これが Shadow Page Table（SPT） です。

結果はどうなったか？ゲストOSがアプリケーションのメモリ領域にアクセスするたびに、ページフォールトが発生し、ハイパーバイザーへのコンテキストスイッチが起き、CPUのサイクルがドブに捨てられるような状態になりました。データベースのベンチマークを取ると、CPU使用率は100%なのにスループットが全然出ない――そんな地獄のようなパフォーマンス低下が日常茶飯事だったのです。

—

2. ハードウェアによる救世主：Intel EPT と AMD NPT のメカニズム

この「メモリ変換の二度手間」をハードウェアの力で力業かつエレガントに解決したのが、Intelの EPT（Extended Page Tables） であり、AMDの NPT（Nested Page Tables）（※AMDではRVI: Rapid Virtualization Indexingとも呼ばれます）です。

MMUレベルでの「2次元テーブルウォーク」

EPT/NPTが何をやっているかというと、CPUのメモリ管理ユニット（MMU）自体に、2段階のアドレス変換をハードウェアレベルで処理する回路を組み込みました。

従来はゲストOSのページテーブルを舐めるだけで精一杯だったMMUが、ハードウェア支援を受けることで、

ゲストOSのページテーブルを引く
その結果得られたGPAを、さらにハイパーバイザー側のEPT（物理メモリ上のツリー構造）を使ってHPAに変換する

この一連の「テーブルウォーク」を、CPUがキャッシュ（TLB: Translation Lookaside Buffer）を駆使しながら、ほぼノーペナルティ（実際には数倍のオーバーヘッドはありますが、ソフトウェア処理に比べれば桁違いに高速）で実行します。

[ゲストOSの仮想アドレス (GVA)]
          ↓ (ゲストのページテーブル)
[ゲストOSの物理アドレス (GPA)]
          ↓ (Intel EPT / AMD NPT によるハードウェア変換)
[ホストOSの物理アドレス (HPA)]

この仕組みのおかげで、現代のクラウドインスタンスは、物理マシンとほぼ遜色ないメモリパフォーマンスを発揮できるのです。

—

3. 実務で知るべきパラメーターと、クラウド選定における「落とし穴」

SREやクラウドアーキテクトとして実務に携わる際、このEPT/NPTを意識しなければならないシーンはどこでしょうか？

それはズバリ、「ハイパーバイザーのチューニング」と「コンテナ・仮想化基盤のパフォーマンスデバッグ」です。

1. 巨大ページ（Huge Pages / Transparent Huge Pages: THP）との組み合わせ

EPT/NPTが有効であっても、メモリのページサイズが標準の4KBのままだと、巨大なメモリ空間を持つモダンなWeb APIサーバーやインメモリDB（Redisなど）では、TLBミスが頻発します。

ここで重要になるのが、2MBや1GBといったHuge Pagesです。EPTが有効な環境でHuge Pagesを組み合わせると、ページテーブルの階層が浅くなるため、ハードウェアによるアドレス変換の効率が爆発的に向上します。

以下は、Linuxホスト（KVM基盤など）でTransparent Huge Pagesの状態を確認・設定するための一般的な設定ファイル（sysfs）の操作例です。

# 現在のTHP（Transparent Huge Pages）の設定を確認する
cat /sys/kernel/mm/transparent_hugepage/enabled

# 出力例: [always] madvise never
# 「always」になっている場合、カーネルが勝手に巨大ページ化を試みるため、
# データベースサーバーなどではメモリ断片化によるレイテンシスパイクの原因になることがある。

# 実務での推奨設定：明示的にアプリケーション側（madvise）に制御を委ねるか、
# 必要に応じて「never」にしてK8sのkubelet側やHugePages機能で明示的に管理する。
echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

# デフラグの挙動を調整し、メモリ割り込みによるレイテンシ悪化を防ぐ
echo defer+madvise | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

2. クラウドプロバイダー（AWS / GCP）における見えない違い

私たちがAWSのEC2（Nitroシステム）やGCPのCompute Engineを使うとき、ハードウェア仮想化支援（EPT/NPT）は当然のようにデフォルトで有効化されています。

しかし、オンプレミスでOpenStackやKVM、あるいはProxmoxなどを用いて独自のプライベートクラウドを構築する際、CPUの機能フラグが正しくパススルーされていないケースに遭遇することがあります。

例えば、KVMのXML定義（libvirt）において、CPUモデルが正しく設定されていないと、EPTが十分に活かされない、あるいはネストされた仮想化（Nested Virtualization：KVMの上にさらにDocker/K8sや別VMを建てる構成）でパフォーマンスが著しく劣化します。

以下は、KVMのゲストXML設定でCPUの拡張機能を確実に有効化する設定の抜粋です。

<!-- libvirtのドメイン設定ファイル (XML) の抜粋 -->
<domain type='kvm'>
  <name>production-api-worker-01</name>
  <!-- host-passthroughを使用することで、物理CPUのEPT/NPTを含む全ての拡張命令をゲストに直結させる -->
  <cpu mode='host-passthrough' check='none'>
    <topology sockets='1' dies='1' cores='8' threads='2'/>
    <!-- ハードウェア支援機能を確実にパススルーするための設定 -->
    <feature policy='require' name='vmx'/> <!-- Intelの場合 (AMDの場合はsvm) -->
  </cpu>
</domain>

—

4. パフォーマンス劣化時のトラブルシューティング手法

「APIサーバーのレスポンスが、なぜか断続的に100msほど遅延する」
このようなトラブルシューティングの現場で、メモリ仮想化層（EPT/NPT）がボトルネックになっていないかを切り分ける手順を伝授します。

ステップ1: perfコマンドを用いたTLBミスの計測

Linuxのパフォーマンス解析の王様である perf を使って、ハードウェアレベルのイベントを観測します。

[SREの現場メモ]
本番環境でいきなり重いperfコマンドを叩くのはタブーです。
影響範囲を限定し、ステージング環境やカナリア環境で検証するか、影響の少ないカウンターを指定してください。

# EPTミスの発生状況やTLBミスを簡易的にプロファイリングする
sudo perf stat -e cache-misses,tlb:dtlb-miss-walk,tlb:itlb-miss-walk -p <対象のPID> -- sleep 10

もしここで dtlb-miss-walk（データTLBのウォークミス）の数値が異常に高騰している場合、メモリのアクセスパターンがTLBのキャッシュサイズを超えているか、あるいはハイパーバイザー側のページテーブルの階層（EPTのウォーク）でオーバーヘッドが発生している疑いがあります。

ステップ2: ホスト側のCPUステータスとKVMの統計情報の確認

KVMハイパーバイザー上で動いている場合、ゲストがどれくらいハイパーバイザーの支援（EPTの処理など）に依存しているか、あるいはその切り替えコスト（VM退出/侵入）が発生しているかを virsh で確認できます。

# 特定の仮想マシンの統計情報をリアルタイムで覗き見する
virsh domstats <ドメイン名> --cpu-total

ここで、CPUの「exit」に関連するカウンターが異常値を示している場合、ゲストOSが频繁に特権命令やメモリの特殊な操作を行い、ハイパーバイザー側でのハンドリングが発生しているサインです。

—

5. まとめ：目に見えないレイヤーを知る者が、真のインフラを制す

今回は、Intel EPTとAMD NPTという、普段のアプリケーションコードを書いているだけでは絶対に目に見えない「ハードウェアの底力」について解説しました。

モダンなクラウドやコンテナ技術は非常に抽象化されており、私たちがインフラの泥臭いディテールを意識しなくても動くようになっています。しかし、ひとたび大規模なトラフィックや、ミリ秒単位のレイテンシがシビアに求められるWeb API、あるいは高負荷なデータベース運用に直面したとき、「CPUやメモリがハードウェアレベルでどのようにデータをやり取りしているか」という物理的なイメージを持っているかどうかが、エンジニアとしての生死を分ける決定的な差となります。

次にクラウドのインスタンスタイプを選ぶとき、あるいはK8s基盤のカーネルパラメータをチューニングするとき、この記事で解説した「メモリ2重変換のストーリー」を思い出していただければ幸いです。

それでは、今夜も安定したデプロイと平穏なオンコールを祈って！