こんにちは！クラウドインフラの世界へようこそ。SREとして日々たくさんのサーバーやコンテナと向き合っている私ですが、今回は「仮想化技術の根っこ」にある、ちょっと熱くてディープな世界を覗いてみたいと思います。
「仮想化って、1台のパソコンの中で複数のOSが動くんでしょ？」
はい、その通りです！でも、その裏側でCPUがどんな風に汗を流して調整しているのか、気になったことはありませんか？
今回は、仮想化技術の土台である「CPUの特権リング」と、そこにあるちょっとした「身分のすれ違い」、そしてそれをスマートに解決する現代の仕組みについて、身近な例えを交えながら一歩ずつ優しく紐解いていきましょう！
—
1. そもそも「特権リング」ってなに？（会社組織に例えてみよう）
CPUが持つ「特権リング（Privilege Ring）」、なんだか物々しい名前ですよね。これは、CPUが実行する命令の「お偉いさん度」を表す階級章のようなものです。
一般的に、x86アーキテクチャなどのCPUには Ring 0 から Ring 3 までの4つの階級が用意されています。
- Ring 0（最上級・社長室）:
ハードウェアを直接触る権利を持つ、OSの心臓部（カーネル）が居る場所です。「メモリを全部よこせ！」「ハードディスクに書き込め！」というワガママ（強力な命令）が許されます。
- Ring 3（一般社員・オープンスペース）:
私たちが普段使っているブラウザやメモ帳などの一般アプリ（ユーザー空間）が居る場所です。ここでは安全のために、ハードウェアを直接触るような危険な命令は禁止されています。
会社組織に例えるなら、Ring 0は「会社のすべてを動かす社長」で、Ring 3は「一般の社員」です。社員が勝手に会社の金庫を開けたら大変ですよね。だから、社員が何か特別なことをしたいときは、必ず社長（Ring 0）にお伺いを立てる仕組みになっています。これが通常のOSの姿です。
—
2. 仮想化の世界で起きる「悲劇のすれ違い」
さて、ここに「仮想マシン（VM）」という世界を作ろうとします。ホストOS（大元のOS）の上に、ゲストOS（中にいる偽物のOS）を動かすわけです。
ここで、大きな問題が発生します。
仮想化ソフト（ハイパーバイザー）は、ゲストOSに対して「どうぞ、あなたはこのPCの主役ですよ！好きにしてください！」と見せかけます。そうすると、ゲストOSのカーネルは、自分自身が当然のように Ring 0（社長室） に座る気満々で起動してきます。
しかし、現実はどうでしょう？
本当の社長（ホストOSのカーネルやハイパーバイザー）は他にいます。ゲストOSのカーネルを本当のRing 0に座らせてしまったら、そのゲストが暴走したときに、ホスト全体がクラッシュしてしまいます。
そのため、ハイパーバイザーは苦肉の策として、ゲストOSのカーネルをちょっと格下の Ring 1 や Ring 2 あたりに座らせることにしました。
ここで「乖離（かいり）」が起きます！
- ゲストOSの気持ち: 「私はRing 0にいるつもりだから、ハードウェアを直接操作する命令（特権命令）を出すぞ！」
- CPUの現実: 「おや、Ring 1にいる君からそんな命令が飛んできたぞ。規則違反だからエラー（トラップ）にして弾き返そう！」
結果として、ゲストOSが動こうとするたびにCPUが「ダメです！」と怒り出すため、動作が重くなったり、最悪の場合は動かなくなったりしていました。これが、仮想化における「特権リングの乖離」という頭の痛い問題です。
—
3. 郵便配達員に例える「トラップ・アンド・エミュレーション」の苦労
昔の仮想化（フル仮想化の初期）では、この問題を解決するために「トラップ・アンド・エミュレーション（Trap-and-Emulate）」という手法が使われていました。
これを身近な例えで言うなら、「新米のアルバイト（ゲストOS）が、社長権限が必要な書類に勝手にハンコを押そうとして、毎回受付（ハイパーバイザー）に怒られる」という状態です。
1. アルバイト（ゲストOS）がRing 1で「特権命令」を出してしまう。
2. CPUが「ピピピー！違反です！」とトラップ（割り込み）を発生させる。
3. 受付であるハイパーバイザーが飛んできて、「どれどれ、代わって処理してあげるよ」と裏でこっそり代わりに処理（エミュレーション）してあげる。
このやり取り、めちゃくちゃ手間がかかりますよね。パケットが何度も行ったり来たりするのと同じように、CPUのコンテキストスイッチが頻発し、仮想化のパフォーマンスがガタ落ちする原因になっていました。
—
4. 救世主登場！CPUのハードウェア支援機構（Intel VT-x / AMD-V）
「このままではクラウド時代のサーバー仮想化なんて夢のまた夢だ……！」
エンジニアたちのそんな悲鳴を聞きつけて、IntelやAMDといったCPUメーカーが立ち上がりました。
それが、現代のクラウド（AWSやGCPなど）を支えるCPU仮想化支援機構（Intel VT-xやAMD-V）です。
これは簡単に言うと、「仮想空間専用の新しいVIPルーム（Rootモード / Non-Rootモード）」をCPUの中に新しく作り出す仕組みです。
- Vmx Root（ホスト側モード）: ハイパーバイザーが暮らす安全な世界。
- Vmx Non-Root（ゲスト側モード）: ゲストOSが暮らす世界。
この仕組みのすごいところは、ゲストOSが「自分はNon-Root世界のRing 0にいるぞ！」と思い込める点です。
昔のように「Ring 1に落とされて怒られる」という悲劇が起きません。ゲストOSは自分が最上級階級にいるつもりで振る舞えます。そして、もし本当にハードウェアの根幹に関わる危ない操作が必要になった時だけ、CPUが自動的にハイパーバイザーへバトンを渡す（VM退出 / VM Exit）仕組みに進化しました。
これにより、無駄なエラー処理やエミュレーションの手間が激減し、パケットが高速道路を駆け抜けるかのように、仮想マシンが爆速で動くようになったのです！
—
5. 実務で触れるクラウドの裏側と設定のヒント
私たちインフラエンジニアがAWS（EC2）やGCP（Compute Engine）で仮想マシンを立ち上げる時、このCPUのハードウェア支援機能は意識せずとも裏側でフル活用されています。
例えば、KVM（Kernel-based Virtual Machine）などのLinux標準の仮想化技術をベアメタルサーバーや自前のハイパーバイザーで構築する際、BIOS/UEFIの設定でこの機能が有効になっているか確認する必要があります。
次のようなコマンドで、CPUが正しく仮想化支援機能（VT-x/AMD-V）をサポートしているか確認したことがある方も多いのではないでしょうか？
# CPUが仮想化支援（vmx または svm フラグ）をサポートしているか確認するコマンド
egrep -c '(vmx|svm)' /proc/cpuinfo
# もし「0」より大きい数字（CPUのコア数など）が返ってくれば、
# ハードウェア支援機能が有効な状態でCPUが稼働している証拠です！もしここが「0」だったりすると、KVMなどのモダンな仮想化ソフトウェアは「えっ、ハードウェア支援がないの？じゃあ昔ながらの重いやり方（ソフトウェア仮想化）で頑張るしかないね……」となり、パフォーマンスが著しく低下してしまいます。クラウドインスタンスの裏側を支える基盤選びでも、このあたりのCPUフラグの有無はパフォーマンスに直結する非常に重要なポイントです。
—
まとめ
いかがでしたでしょうか？
CPUの特権リングと仮想化の歴史は、「本当の支配者（ホスト）とうそっこの支配者（ゲスト）が、どうやったら平和に、かつ高速に共存できるか」という、先人たちの知恵とハードウェアの進化の歴史そのものです。
普段私たちが何気なく使っているクラウドの仮想サーバーも、こうしたCPUのミクロな世界での緻密な役割分担の上に成り立っていることが分かると、インフラを触るのがもっと楽しくなりますよね。
それでは、また次回のディープなインフラ解説でお会いしましょう！SREの現場からお届けしました。
コメント