こんにちは！SREとして日々クラウドの巨大なインフラと格闘している私ですが、今回はインフラやネットワークの世界に一歩踏み出したばかりのあなたに向けて、クラウドの土台を支える超重要技術、「ハイパーバイザー型仮想化（Type-1）」の世界へご案内します。
「仮想化って聞くけど、なんだか難しそう…」
「サーバーの中に別のOSが入るって、どういうこと？」
そんな疑問を、身近な例えを交えながら一つずつ解きほぐしていきますね。難しい専門用語はいったん脇に置いて、リラックスして読み進めてみてください！
—
1. 仮想化ってなぁに？ 身の回りの「空間のシェア」で考えてみよう
いきなりサーバーの話をする前に、ちょっと身近な例え話をさせてください。
あなたは今、大きなお家を建てようとしています。一部屋あたりのスペースはすごく広いのですが、そこに住むのはあなた一人だけ。これだと、リビングも寝室もキッチンも、なんだか広すぎて持て余してしまいますよね。
そこで、「家の中に壁を何枚か立てて、いくつかの『独立した部屋（ワンルーム）』に区切ってしまおう！」と考えました。
- Aさんの部屋：寝る専用
- Bさんの部屋：趣味の作業専用
- Cさんの部屋：お友達を呼ぶリビング専用
壁でしっかり区切られているので、Aさんが部屋で音楽を大音量で聞いていても、Bさんの部屋には聞こえません（お互いのプライバシーや安全が守られています）。
この「1つの大きな家（物理的なハードウェア）」を「上手に壁で区切って、あたかも何軒もの独立した家があるように見せる技術」こそが、まさに仮想化の正体です。
—
2. 登場人物を知ろう！「Type-1」と「Type-2」の違い
仮想化の仕組みには、大きく分けて2つのタイプが存在します。今回はそのうちの主役である「Type-1（タイプワン）ハイパーバイザー」に焦点を当てますが、違いを理解するために少しだけ「Type-2」にも触れておきましょう。
ホスト型（Type-2）のイメージ
普段使っているあなたのパソコン（WindowsやMac）を思い浮かべてみてください。そのパソコンの上で、VirtualBoxやVMware Workstationといった「アプリ」を起動し、その中で別のOSを動かす方法です。
これは例えるなら、「自分の部屋の中に、段ボール箱を置いて、その中でミニチュアの生活をする」ようなもの。一番下には、普段あなたが使っている母艦のOSがしっかり陣取っています。手軽で便利ですが、母艦のOSが重くなると中のミニチュア世界も動きが鈍くなります。
ベアメタル型 / ハイパーバイザー型（Type-1）のイメージ
今回主役として取り上げるType-1は、パソコンのOSという「クッション」を一切挟みません。ハードウェア（物理サーバーの鉄板そのもの）の上に、直接「仮想化専用のシステム（ハイパーバイザー）」をインストールする方式です。
これは例えるなら、「まっさらな土地に、最初から部屋を完全に分割することだけを目的とした管理ビルを建てる」ようなもの。無駄なものが一切なく、ハードウェアのパワーを100%効率よく引き出せるため、AWSやGCPといったプロのクラウドの世界では、このType-1が絶対的な標準として使われています。
—
3. Type-1ハイパーバイザーの基本アーキテクチャと動作原理
では、このType-1ハイパーバイザーが、ハードウェアの上でどのように動いているのか、その裏側の仕組みを覗いてみましょう。
支配者はハイパーバイザー、その下に住む「ゲストたち」
Type-1ハイパーバイザー（例えば VMware ESXi や KVMベースの仕組みなど）をサーバーにインストールすると、そのシステムがハードウェアの「完全な支配者」になります。
このハイパーバイザーという名の管理人が、サーバーの心臓部である以下のようなリソースを完全に掌握します。
- CPU（頭脳）
- メモリ（机の広さ）
- ストレージ（引き出しの容量）
- ネットワーク（外部との通信回線）
そして、この管理人の下に、いくつかの「仮想マシン（VM: Virtual Machine）」という名の部屋を作ります。それぞれの仮想マシンの中で動くOSのことを「ゲストOS」と呼びます。
郵便配達の仕組みに例えてみよう！
ここで、CPUやメモリのやり取りを「郵便配達」に例えて考えてみましょう。
1. ゲストOSからの手紙（リクエスト）
仮想マシンの中で動いているゲストOSが、「データを保存したい！」「計算をしたい！」というお手紙を書きます。
2. ハイパーバイザーによる仕分けと調停
その手紙は、直接ハードウェアには届きません。一度、門番であるハイパーバイザーがすべて受け取ります。ハイパーバイザーは、「あ、この手紙はA号室の分だな、こっちはB号室の分だな」と綺麗に仕分けをします。
3. ハードウェアへのお届け
仕分けが終わると、ハイパーバイザーは実際のハードウェア（CPUやメモリ）に「はい、この仕事をお願いね！」と正確に仕事を割り振ります。
このように、複数のゲストOSが勝手に暴走してハードウェアを取り合わないように、ハイパーバイザーが交通整理とリソースの配分を完璧にコントロールしているからこそ、安全にたくさんのシステムを1台のサーバー上で同居させることができるのです。
—
4. クラウド実務の世界を覗き見！設定ファイルの雰囲気を知ろう
「理屈は分かったけれど、実際の現場ではどうやって設定するの？」
そんな気になっているあなたのために、KVM（Linux標準の仮想化技術）を裏で支える仮想マシン定義ファイル（XML形式）のサンプルを少しだけ覗いてみましょう。
実務では、以下のような設定ファイル（あるいはクラウドのAPI）を通じて、仮想マシンにどれだけのCPUやメモリを割り当てるかを指定しています。
<domain type='kvm'>
<!-- 仮想マシンの名前（一意に識別するためのID） -->
<name>web-server-01</name>
<!-- 仮想マシンに割り当てるメモリの容量（ここでは2GBを指定） -->
<memory unit='KiB'>2097152</memory>
<!-- 実際にゲストOSが使用できる最大メモリ容量 -->
<currentMemory unit='KiB'>2097152</currentMemory>
<!-- 割り当てるCPUコアの数（ここでは贅沢に2コア） -->
<vcpu placement='static'>2</vcpu>
<os>
<!-- 起動の仕組みを指定（通常のPCと同じx86_64アーキテクチャ） -->
<type arch='x86_64' machine='pc-q35-7.2'>hvm</type>
<boot dev='hd'/>
</os>
<devices>
<!-- エミュレートする仮想的なハードウェア（CPU、ディスク、ネットワーク等）の定義が続く -->
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<!-- ネットワーク接続の定義：物理ネットワークと仮想世界をブリッジで繋ぐ -->
<interface type='bridge'>
<source bridge='br0'/>
<model type='virtio'/>
</interface>
</devices>
</domain>このように、コードや設定ファイルを通じて、ハードウェアの上に「仮想的なパーツ」を自由自在に組み立てていくのが、現代のクラウドインフラエンジニアの日常なんです。
—
5. おわりに：仮想化技術はインフラの魔法の箱
今回は、ハイパーバイザー型（Type-1）仮想化の基本アーキテクチャと動作原理について、身近な例えを交えて解説しました。
- Type-1ハイパーバイザーは、ハードウェアの上で直接動く「優秀な管理人」。
- OSというクッションを挟まないため、圧倒的なパフォーマンスと安定性を誇る。
- クラウドの裏側では、この技術が何台もの巨大なサーバーを効率よく分割し、私たちが使うWEBサービスを支えている。
「サーバー」と聞くと、冷たくて近寄りがたい鉄の塊のように思えるかもしれませんが、その中身を覗いてみると、すごく人間味のある（？）丁寧な交通整理と分業の仕組みで成り立っていることが分かりますよね。
インフラやネットワークの世界は、こうした「目に見えない仕組みの積み重ね」でできています。一歩ずつ、焦らずに紐解いていけば、決して難しいものではありません。
それでは、また次回の技術解説でお会いしましょう！SREチームのあなたを、いつでも応援しています！
コメント