この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンバンハ、千葉（幸）です。
先日行われた re:Growth 2020 Online インフラ特別号〜AWS re:Invent 振り返り勉強会〜 において、「改めて Nitro に思いを馳せる」というテーマで発表を行いました。
資料の共有と、概要のご紹介をします。
資料
きっかけは Mac インスタンス
私が今回のテーマを AWS Nitro システムに設定したきっかけは、2020/12/1 のキーノートで行われた Mac インスタンスの発表です。
以下の記事を参考にすると、Mac インスタンスは Mac mini と Nitroコントローラの組み合わせによって実現されたと説明されています。
Mac インスタンスはベアメタル（チック）かつ専有ホスト
Mac mini が使用されると聞いた時、私はすぐに腹落ちができませんでした。
当初の私の雑な理解では、「 EC2 インスタンスは物理ホスト上のハイパーバイザーによって稼働する仮想マシン」と認識しており、ここでの物理ホストがそのまま Mac mini に置き換わるのか？と考えたためです。
実際は Mac インスタンスはベアメタルインスタンスの一種として提供され、なおかつ専有ホストの形態で提供されます。
Mac mini が Mac インスタンスとして機能するために、 Nitro コントローラーが必要な機能を提供してくれます。
Nitro とは何か
Nitro とは複数のコンポーネントからなるサブシステムです。以下のようなコンポーネントから構成されます。
- ハードウェアコンポーネント
- Nitro カード
- Nitro コントローラー
- Nitro セキュリティチップ
- ソフトウェアコンポーネント
- Nitro ハイパーバイザー
- Nitro Enclaves
アイコンは以下のページより借用しました。
スタック図のように表現すると以下のイメージです。
Nitro コンポーネントの働きをピックアップ
Nitro コンポーネントのうち、以下について働きの一部をご紹介します。
- Nitro コントローラー
- Nitro カード for EBS
- Nitro カード for VPC
Nitro コントローラー
Nitro コントローラーは各種コンポーネントのコーディネーターとして機能します。
機能の一部として、 API エンドポイントがあります。 AWS カスタマーが発行した API リクエストは、サービスエンドポイントや AWS のコントロールプレーンを経由し、 Nitro コントローラーに到達します。
Nitro コントローラーが受領した API の種類に応じて、各種コンポーネントに対して命令が実行されます。
Nitro カード for EBS
Nitro カード for EBS は、NVMe コントローラーや、EBS データプレーンとの接続のブリッジとして機能します。
EC2 インスタンスと EBS ボリュームはネットワークで接続されていますので、その橋渡しとして機能するのが Nitro カード for EBS です。
Nitro カード for VPC
Nitro カード for VPC は、ENA コントローラーや、 VPC データプレーンとの接続のブリッジとして機能します。SecuriryGroup の適用やルーティング、帯域制限などの機能も提供します。
機能の一つであるカプセル化についてのイメージが以下です。
上記では EC2 インスタンス間の通信を想定しています。同一 VPC に閉じた通信であっても、EC2 インスタンスの物理ホストは地理的に離れた場所にある可能性があります。
そういったケースにおいて、 裏側では VPC データプレーンを経由して通信が行われていますが、インスタンスとデータプレーンの間に位置する Nitro カード for VPC がカプセル化/非カプセル化を行うことによって、インスタンスはそれらを意識することなく通信を行えます。
VPC にフォーカスした話については以前のイベントで取り上げていますので、以下を参照してください。
Nitro の歴史
Nitro の歴史は、以下のキーワードに集約されます。
- ソフトウェアからハードウェアへのオフロード
- モノリスからマイクロサービスへ
EC2 の最初期においては、基盤のほとんどの機能はソフトウェアによって実現されていました。
仮想化は Xen によって行われ、dom0 と呼ばれる管理用の仮想マシンがハードウェアとゲスト仮想マシン（ EC2 インスタンス）の橋渡しを行っていました。
いくつかの機能は、順次切り出されてハードウェアにオフロードされていきます。
全ての機能がオフロードされ、 2017年に AWS Nitro というシステムとして発表されました。あわせて、ハイパーバイザーは Xen ベースから KVM ベースに置き換わっています。
一枚絵でわかりやすい awsgeek
これらのハードウェアの変遷について、わかりやすく表現してくれているサイトとして awsgeek.com があります。
awsgeek.com は、AWS のプリンシパル・テクニカルエバンジェリストであるジェリー・ハーグローブ氏が運営しているサイトです。
AWS サービスや re:Invent のセッションの内容など、一枚絵でわかりやすく表現してくれています。
Nitro に関する内容では、以下が参考になります。
- Jerry Hargrove - The Evolution of the EC2 Host
- Jerry Hargrove - Powering Next Gen EC2 Instances Deep Dive into the Nitro System
- Jerry Hargrove - Evolution of the EC2 Host
- Jerry Hargrove - Evolution of the EC2 Host
Nitro の何が嬉しいのか
最後に、Nitro の何が嬉しいのかを以下の3点から取り上げました。
- AWS の迅速なアップデートを支える
- Nitro だからこそできる機能
- セキュリティ面の向上
AWS の迅速なアップデートを支える
Nitro システムの確立により、新たなインスタンスタイプの登場や性能向上、価格低下といったことを迅速に行うことが可能となり、カスタマーはメリットを享受できます。
Nitro だからこそ実現できる機能
新しく追加される機能は Nitro システムが前提になっている、あるいは Nitro 以外では導入までリードタイムが発生する、といったものが多いです。
セキュリティ面の向上
Nitro によりセキュリティ面が強化されました。これは基盤を管理する AWS としての視点が主となりますが、引いてはカスタマー側にとってもメリットがある話です。
終わりに
AWS Nitro について思いを馳せました。
普段カスタマーとしてはあまり意識する必要のない領域ですが、EC2 を裏側で支える大事な機能であることを再認識できました。ふとした時に思い出していただければと思います。
re:Invent 2020 の Nitro に関するセッションについては、以下でレポートをまとめていますのであわせてご参照ください。
以上、千葉（幸）がお送りしました。
68
