こんにちは！インフラの世界へようこそ。第一線のSREとして日々クラウドやKubernetesの海を泳いでいる私ですが、今回は「仮想化技術の裏側」をのぞいてみたいと思います。
クラウドを使っていると、1台の物理サーバー上で複数の仮想マシン（VM）がまるで何事もなかったかのように動いている光景を当たり前のように目にしますよね。「どうやって1台のコンピュータが何台ものコンピュータに変身しているんだろう？」と、ふと疑問に思ったことはありませんか？
今回は、その仮想化技術の中でも、少しマニアックだけど歴史を変えた超重要テクニック「準仮想化（Para-Virtualization）」と、その心臓部である「ハイパーコール（Hypercall）」について、身近な例えを交えながら優しく紐解いていきたいと思います。
難しい用語が出てきても「一歩ずつ理解していきましょう！」、大丈夫です。それでは、仮想化のディープな世界へ出発しましょう！
—
1. 仮想化の「お作法」：完全仮想化のモヤモヤ
まずは、私たちが普段当たり前のように使っている仮想化の基本形、「完全仮想化（Full Virtualization）」のお話から始めましょう。
例えば、あなたが外国のテーマパーク（仮想マシン）に遊びに行ったとします。あなたは日本語しか話せませんが、パークのスタッフ（ハードウェア）は英語しか話しません。ここで困ってしまうのが、スタッフに「あそこのアトラクションに乗せて！」とお願いするときです。
完全仮想化の世界では、ゲストOS（仮想マシンの中で動いているOS）は、自分が「仮想的な世界」にいることに気づいていません。「私はこの物理サーバーの王様だ！」と思い込んでいます。そのため、ハードウェアを直接いじろうとする危なっかしい命令を平気で出します。
しかし、ハイパーバイザー（仮想化の管理人）からすれば、「ちょっと待って！そこを勝手に触られると他の仮想マシンに迷惑がかかるよ！」と、毎回その危なっかしい命令を横取りして安全な形に翻訳し直す必要があります。
これが、CPUの特権命令をトラップしてエミュレーションするアプローチです。安全ではあるのですが、「毎回通訳を挟むので、どうしても動きがワンテンポ遅くなる」というジレンマがありました。
2. 郵便配達で例える「準仮想化」と「ハイパーコール」
ここで登場するのが、今回の主役である「準仮想化（Para-Virtualization）」です。
「Para」には「寄り添う」や「超えた」といった意味があります。準仮想化の考え方はとてもシンプルで、「ゲストOSのカーネルコードをちょっと書き換えて、最初からハイパーバイザーの存在を意識させちゃおう！」というものです。
先ほどのテーマパークの例えで言うと、ゲストOS自身に「ここは現実世界じゃなくて仮想世界だから、何かお願いするときは専用の直通電話を使ってね」と教育しておくイメージです。
ハイパーコールとは何か？
この「専用の直通電話」の正体こそが、ハイパーコール（Hypercall）です。
物理マシンの世界には、OSがCPUに直接お願いをするための「システムコール」という仕組みがありますよね。あれの仮想マシン版がハイパーコールです。
ゲストOSが「メモリを少し分けてほしいんだ」「ディスクにデータを書き込みたいんだ」と思ったとき、わざわざ回りくどい手続きを踏むのをやめ、ハイパーバイザーに対して「ねえ、これやっといて！」と直接お願いの電話（コール）をかけます。
これがハイパーコールの正体です。通訳を挟まないため、やり取りが圧倒的にスピーディーになり、パフォーマンスが劇的に向上するのです。
—
3. 実務で出会う準仮想化：KVMとVirtioのセッティング
「なるほど、概念は分かったけれど、実際のインフラ現場ではどう使われているの？」という声が聞こえてきそうですね。
現代のクラウド（AWS、GCP、Azureなど）やオンプレミスのKVM環境では、この準仮想化のアイデアが「Virtio（仮想I/Oドライバ）」という形で大活躍しています。ネットワークやディスクのI/Oを処理するとき、完全仮想化のままだと速度が出ないため、準仮想化ドライバをゲストOSに組み込んで高速化を図るのが今のデファクトスタンダードです。
ここでは、KVM環境（Libvirt）で仮想マシンを定義するXML設定ファイルのイメージを覗いてみましょう。実務でネットワークカードを準仮想化（virtio）にする設定の一例です。
<devices>
<!-- 仮想マシンのネットワークインターフェース設定 -->
<interface type='bridge'>
<source bridge='br0'/>
<!-- モデルに 'virtio' を指定することで、準仮想化ドライバを使用する -->
<model type='virtio'/>
<!-- パフォーマンス最適化のための仮想キュー設定（マルチキュー対応） -->
<driver name='vhost' queues='4'/>
</interface>
</devices>この設定が現場でどう効いてくるのか？
上記のXML設定で <model type='virtio'/> と指定すると、Linuxカーネルは標準の遅いエミュレートNICではなく、ハイパーバイザー（KVM）と直接連携する専用のドライバ（virtio_net）をロードします。
これにより、パケットの送受信時に発生するオーバーヘッドが劇的に軽減され、クラウド上の仮想サーバーでもベアメタル（物理サーバー）並みのスループットを叩き出すことができるのです。
—
4. トラブルシューティングの現場から：準仮想化の落とし穴
SREとして現場にいると、この準仮想化・ハイパーコールの仕組みが原因で思わぬハマりどころに遭遇することがあります。
例えば、少し古めのカスタムカーネルを使っている仮想マシンを最新のクラウド基盤に移行した際、ゲストOS側のカーネルが適切なハイパーコールを発行できず、CPU使用率が100%に張り付いてしまう現象（CPUスピン）に直面したことがあります。
「あれ、ネットワークもディスクもそんなに負荷がかかっていないのに、なぜCPUが死んでいるんだ…？」
そんな時は、ハイパーバイザーとゲストOSの間で交わされるハイパーコールのやり取りや、ドライバのバージョンミスマッチを疑います。
Linux環境であれば、カーネルのログ（dmesg）やvirtio関連のモジュールが正しくロードされているかを以下のようなコマンドで確認するのが第一歩です。
# ゲストOS上でVirtio関連のドライバが正常にロードされているか確認する
dmesg | grep -i virtio
# 期待される出力例（このようにドライバが認識されていればOKです！）
# [ 0.412345] virtio-pci 0000:00:03.0: vga bridge: ...
# [ 0.501234] 9pnet: 9pnet virtio transport driver registeredもしここでエラー吐いていたり、ドライバが見つからない場合は、ゲストOS側で「私は準仮想化の世界にいる」ということを正しく理解できていない（あるいは対応するモジュールが欠けている）状態なので、initramfsの再構築やカーネルのアップデートが必要になります。
—
まとめ：一歩ずつ、技術の深層へ
今回は、仮想化技術の基礎である「準仮想化」と、そのコミュニケーション手段である「ハイパーコール」について解説しました。
- 完全仮想化：ゲストOSはそのまま。ハイパーバイザーが通訳するので安全だけどちょっと遅い。
- 準仮想化：ゲストOSをちょっと改造。ハイパーコールという直通電話を使って直接お願いするので超高速！
- 現代のインフラ：KVMやクラウド上の
Virtioドライバなど、準仮想化のアイデアは至る所で私たちのインフラを支えている。
最初は難しく感じる仮想化の裏側の仕組みも、郵便配達や直通電話の例えに置き換えてみると、パケットやハイパーコールがどのように行き交っているのか、そのリアルな空気感が伝わってきたのではないでしょうか。
日々のインフラ運用やコンテナ基盤（KubernetesのNode仮想化など）の裏側を覗くとき、今回の話が少しでも皆さんの頭の片隅に残り、トラブルシューティングのヒントになればこれ幸いです。
それでは、また次回のディープな技術解説でお会いしましょう！SREの現場からは以上です。
コメント