EC2に使われている仮想化技術について噛み砕く

はじめに

　Linuxの学習のためEC2インスタンスに接続し、あちこちのディレクトリを探索していたときのことです。ふと気づいたのが「ホストOSが存在しない！？」でした。
調べてみると「ハイパーバイザーのType」が関係していることが判明し、そこから芋づる式に疑問が湧いてきたわけです。
「EC2はどのようなハイパーバイザーが使われているんだろう？」
「そもそもハイパーバイザーって具体的にはどんなんだったっけ？」
　Linuxの学習をほっぽらかし、できる限り調べ、できる限り理解し、まとめたのがこの記事となっております。

　なるべくかみ砕いて説明することを心掛けたので、同じような疑問を持った方の参考になれば幸いです。

そもそも「EC2」ってなに？

　ざっくり言うと EC2(Elastic Compute Cloud) とは 「インターネットを通して、仮想的なコンピュータを借りることができるAWSのサービス」 です。具体的なサービス提供の仕組みについては後述しますが、最初にEC2の魅力を伝えたいと思います。

個人的な魅力としては下記のとおりです。
(メリットについては色々な記事で書かれ尽くしていそうなのでざっくりと)

→ ハードウェアの購入や導入などの大規模な初期投資が不要になる(ハードウェア本体の購入費用、ハードウェアを設置するスペース...etc)

→ ハードウェアについてはAWSのデータセンターで管理してくれるので、継続的なコストも削減可能(電力、空調、防犯対策...etc)

→ 需要に合わせてリソースを増減できるため、無駄なコストを削減できる

→ 世界各地にデータセンターがあるため、海外へのサービス展開にも対応可能

　これらのメリットが、ITサービスを提供してみたい！と夢見る個人開発者から、多くの顧客を抱えるシステムを取り扱う大企業まで平等に提供されることに魅力を感じ、AWSの学習を始めておりました。
　膨大な初期費用と時間を削減し、自身が考えたものをすぐに開発・提供できる機会をAWSないしEC2は提供してくれています。

大勢の人間にどうサービスを提供しているのか？

(画像引用：https://aws.amazon.com/jp/aws-ten-reasons/)

　世界に数百万人以上のユーザーが存在する中、AWSは継続的にサービスを提供しています。具体的なEC2の利用ユーザー数を知ることはできませんが、2006年から現在まで存在する本サービスには、多くの顧客が存在していると考えられます。

　では、どのようにして多くの顧客へ継続的なサービスを提供しているのでしょうか。AWSは膨大な数のサーバーを保有していますが、それでも世界中の需要に応えるには仮想化技術により、物理リソースを効率的に共有する必要があります。

　仮想化とは、上記図表のように、「ハイパーバイザー」と呼ばれる仮想化ソフトウェアを用いて、1台の物理ハードウェアのリソース（CPU、メモリ、ストレージ、ネットワーク...etc）を分割し、複数の独立した仮想マシンとして動作させる技術です。各マシンはあたかも独立した物理サーバーのように動作し、それぞれ異なるOSやアプリケーションを実行できます。

　EC2の利用ユーザーは、仮想化を用いて生成された仮想マシンをインターネットを通して借り、仮想マシン(インスタンス)に自身が選択したOSとソフトウェアを導入して各々のサービスを提供できます。

　ゲストOS(仮想マシンにインストールするOS)についても上記図表のように幅広い選択肢が与えられ、幅広いユースケースへの対応が可能になっています。

前述したとおり、EC2は個人開発者から大規模なシステムを扱う企業まで幅広く対応しています。具体的には、仮想マシンに割り振られるCPU/メモリ/ストレージ/ネットワーク(場合によってはGPU)を用途に合った組み合わせで用意しています。

用途に合わせたインスタンスタイプの説明をしようと思いましたが、AWS公式サイトのほうが詳しく、見やすく書かれているためこちらをご参照ください。
https://aws.amazon.com/jp/ec2/instance-types/

ハイパーバイザーをもう少し詳しく

「ハイパーバイザーを用いて仮想化を実施し、多くの顧客へ仮想マシンを提供できます。」と記載はしましたが、あまりハイパーバイザーに関してイメージが湧かない方もいると思います。
　前述しましたが、「ハイパーバイザー」は仮想化ソフトウェアのことであり、1台の物理ハードウェアのリソース（CPU、メモリ、ストレージ、ネットワーク...etc）を分割し、複数の独立した仮想マシンとして動作させます。

リソースの仮想化と分割

　物理的なCPU、メモリ、ストレージ、ネットワークなどのリソースを論理的に分割し、各仮想マシンへ割り当てます。ストレージを多めに割り振ることでデータベースサーバーに、CPUを多く割り振ることで高度な計算に用いる、ネットワークを多く割り振ることでリアルタイム通信を可能にするなど、仮想マシンに割り振るリソースを柔軟に指定し、様々なユースケースに対応させることができます。

仮想マシン間の分離

それぞれの仮想マシンは独立して稼働しているため、一方の仮想マシンに異常が発生しても他の仮想マシンには影響せず、それぞれの仮想マシンは相互に干渉できない作りとなっております。

ハイパーバイザーのType-1、Type-2について

　ハイパーバイザーには 「Type-1」 と 「Type-2」 の2種類が存在します。この2つの違いは「ホストOS」が存在するか否かです。

Type-1ハイパーバイザー
　物理ハードウェア上に直接インストールされるこのハイパーバイザーは、「ベアメタル(型)ハイパーバイザー」と呼ばれます。Type-1ハイパーバイザーはハードウェアと直接交渉し、仮想マシンにリソースを割り当てます。ハードウェアとリソースの交渉を直接実施するため、仮想マシンへのリソース割り当てを柔軟に対応することができます。

Type-2ハイパーバイザー
　一方、Type2のハイパーバイザーはホストOSがすでにインストールされているハードウェアに仮想化ソフトウェアがインストールされます。ハイパーバイザーはハードウェアではなくホストOSと交渉してリソースを割り振ります。ホストOS上に仮想化ソフトウェア以外のソフトウェアも稼働している場合、リソースの割り振りが柔軟におこなえないこともあります。なので大規模なワークロードや、重要なワークロード時にType-2ハイパーバイザーで生成された仮想マシンを利用することは推奨されません。ただ、Type-2ハイパーバイザーの導入は容易なため、開発環境やテストなどの用途では活躍します。

EC2での仮想マシンはどっち？
　EC2ではType-1ハイパーバイザーを用いて仮想マシンの生成・管理をおこなっているため、ホストOSは存在しません。

ハイパーバイザー「Xen」「Nitro」について

　EC2でサポートされているハイパーバイザー(仮想化ソフトウェア)には 「Xen(ゼン)」 と 「Nitro(ナイトロ)」 がサポートされており、利用されているハードウェアやハイパーバイザーによって、提供されるインスタンスタイプが分かれてきます。

Xen (ゼン)

　Xenには、登場人物としてハイパーバイザーの他に 「Domain-0(Dom0)」 と 「Domain-U(DomU)」 が存在します。
　DomUはユーザーが実際に使用するインスタンスです。ハードウェアとのリソースのやり取りは、ハイパーバイザーとDom0を通しておこなわれます。具体的には下記図表のイメージです。

　ユーザーが利用している仮想マシンからもしも、「ストレージを用いてファイルの保存を実行したい！」と要求を受けた場合、最初にハイパーバイザーへ依頼を出します。ただし、ハイパーバイザーは物理ハードウェアのリソースへアクセスできないため、権限を持っているインスタンスDom0へ依頼を転送し、Dom0がハードウェアとやり取りをし、完了結果を逆の順番で伝達します。

　Xenは2006年のころからEC2でサポートされ、現在でもXenで動くインスタンスタイプが存在しています。

(画像参照)

ただし、Xenには複数の課題が存在していました。

主な課題としては大きく分けてこの2つになると思います。

・ハードウェアとやり取りをするDom0も仮想マシンとしてリソースを消費してしまうため、Dom0分のリソースを顧客に提供できない

・ネットワークやストレージの処理をソフトウェアに任せているため、遅延が発生してしまう

　先ほどの事例では仮想マシンがハイパーバイザーを経由して、どのようにハードウェアとやり取りしているかを簡単に説明するために一つの仮想マシンで図式化しましたが、実際仮想マシンは下記のようになる想定です。(ちょっと盛りましたが)

　Dom0もインスタンスとしてリソースを消費し、ストレージやネットワークのI/O処理をソフトウェアで実施してしまうため、多くの顧客にパフォーマンスの高い仮想マシンを提供するとなると、このXenの特徴は課題となっていました。

これらの課題を解決したのが、これから紹介する 「Nitro System」 です。

Nitro System (ナイトロ システム)

　Nitro SystemはAWSが独自開発した仮想化技術です。ネットワーク処理やストレージ処理、管理機能を 「Nitro Card」 と呼ばれる専用ハードウェアに分散させることで、Xenを使用していた時に抱えていた課題を根本的に解決しました。

解決策に向けたアクションは大きく2つあります
・ハイパーバイザーの役割をメモリとcpuの仮想化/割り当てに絞り、軽量化を図る
・ストレージやネットワークのI/O処理を独自開発したハードウェアへ分散させる

　もしもユーザーが使用している仮想マシンで「ストレージを用いてファイルを保存したい！」となった場合、仮想マシン内のNVMeドライバがSR-IOV経由でNitro Card for EBSへ、ハイパーバイザーを経由せずに直接アクセスします。
　Nitro Card for EBSは受信したデータをハードウェアで暗号化し、ネットワーク経由でEBSストレージサービスへ送信します。保存が完了すると、Nitro Card for EBSからSR-IOV経由で仮想マシンへ直接完了通知を返却し、処理を終了します。

※SR-IOV: 仮想マシンが物理デバイスに直接アクセスできる技術
※NVMeドライバ: 高速ストレージと通信するためのソフトウェア

　このように、ハイパーバイザーを経由せず、I/O処理を独自のハードウェアへ分散させることで、このNitro Systemを利用したインスタンスはベアメタルとほぼ同等の性能を実現させることができました。

「ベアメタル」とは、仮想化をせず物理ハードウェアにOSを直接インストールしている状態です

実際の性能比較

　AWSが実施したHPC(High Performance Computing)ワークロードのベンチマークでは、Nitro Systemを用いたインスタンスとベアメタルで各用途での比較が行われましたが、どの用途でもベアメタルとの性能差に大差が無いことを示しております。
(参考：https://aws.amazon.com/jp/blogs/hpc/bare-metal-performance-with-the-aws-nitro-system/)

ワークロード	用途	ベアメタル vs Nitro性能差
OpenFOAM	流体力学シミュレーション	0.5%
GROMACS	分子動力学	0.5%
WRF	気象予測	0.6%
HPL	行列演算	0.8%

すべてのケースで性能差は1%以内。これは576コア（16インスタンス）での大規模計算においても同様のパフォーマンスを示しています。
つまり、Nitro Systemは仮想化が持つ課題をほぼ完全に排除し、ベアメタルと同等の性能を実現しています。

このNitro Systemを用いたインスタンスタイプは2017年から登場し、幅広い用途に応じたタイプをAWSは提供しています。

(画像参照)

おわりに

　今回、Linuxの学習ついでに始めたEC2でのハンズオンから、「ホストOSが見つからない！なぜ？」や「ハイパーバイザーって聞いたことあるけど何だ？Type1?2?」という疑問を持って調査を始めました。
その過程で見えてきたのは、XenからNitro Systemへの進化により、仮想化技術が抱えていた「性能劣化」という根本的な課題がほぼ解決されたという企業努力の結果でした。
　
　結局この記事を執筆している間、Linuxの学習は進んでいなかったのですが、よりAWSが好きになった時間なのでよかったです。

下に参考になった文献をまとめているので、よろしければご確認ください。
ここまで読んでいただき、ありがとうございました。

参考文献

AWS:Amazon EC2 をささえる技術

AWS：Bare metal performance with the AWS Nitro System

AWS：The components of the Nitro System

AWS:AWS Nitro System

AWS：Amazon EC2 instance types

AWS：AWS の クラウドが選ばれる 10 の理由

AWS：Amazon EC2 インスタンスタイプ

AWS：タイプ 1 とタイプ 2 のハイパーバイザーはどのように異なりますか?