re:Growth ONLINE インフラ特別号で AWS Nitro について思いを馳せてみました #cmregrowth

Nitro を 語ら Nitro。

コンバンハ、千葉(幸)です。

先日行われた 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 に置き換わるのか?と考えたためです。

Nitro2

実際は Mac インスタンスはベアメタルインスタンスの一種として提供され、なおかつ専有ホストの形態で提供されます。

Nitro3

Mac mini が Mac インスタンスとして機能するために、 Nitro コントローラーが必要な機能を提供してくれます。

Nitro とは何か

Nitro とは複数のコンポーネントからなるサブシステムです。以下のようなコンポーネントから構成されます。

  • ハードウェアコンポーネント
    • Nitro カード
    • Nitro コントローラー
    • Nitro セキュリティチップ
  • ソフトウェアコンポーネント
    • Nitro ハイパーバイザー
    • Nitro Enclaves

Nitro5

アイコンは以下のページより借用しました。

スタック図のように表現すると以下のイメージです。

Nitro6

Nitro コンポーネントの働きをピックアップ

Nitro コンポーネントのうち、以下について働きの一部をご紹介します。

  • Nitro コントローラー
  • Nitro カード for EBS
  • Nitro カード for VPC

Nitro コントローラー

Nitro コントローラーは各種コンポーネントのコーディネーターとして機能します。

機能の一部として、 API エンドポイントがあります。 AWS カスタマーが発行した API リクエストは、サービスエンドポイントや AWS のコントロールプレーンを経由し、 Nitro コントローラーに到達します。

Nitro コントローラーが受領した API の種類に応じて、各種コンポーネントに対して命令が実行されます。

Nitro7

Nitro カード for EBS

Nitro カード for EBS は、NVMe コントローラーや、EBS データプレーンとの接続のブリッジとして機能します。

EC2 インスタンスと EBS ボリュームはネットワークで接続されていますので、その橋渡しとして機能するのが Nitro カード for EBS です。

Nitro8

Nitro カード for VPC

Nitro カード for VPC は、ENA コントローラーや、 VPC データプレーンとの接続のブリッジとして機能します。SecuriryGroup の適用やルーティング、帯域制限などの機能も提供します。

機能の一つであるカプセル化についてのイメージが以下です。

Nitro8-2766989

上記では EC2 インスタンス間の通信を想定しています。同一 VPC に閉じた通信であっても、EC2 インスタンスの物理ホストは地理的に離れた場所にある可能性があります。

そういったケースにおいて、 裏側では VPC データプレーンを経由して通信が行われていますが、インスタンスとデータプレーンの間に位置する Nitro カード for VPC がカプセル化/非カプセル化を行うことによって、インスタンスはそれらを意識することなく通信を行えます。

VPC にフォーカスした話については以前のイベントで取り上げていますので、以下を参照してください。

Nitro の歴史

Nitro の歴史は、以下のキーワードに集約されます。

  • ソフトウェアからハードウェアへのオフロード
  • モノリスからマイクロサービスへ

EC2 の最初期においては、基盤のほとんどの機能はソフトウェアによって実現されていました。

Nitro9

仮想化は Xen によって行われ、dom0 と呼ばれる管理用の仮想マシンがハードウェアとゲスト仮想マシン( EC2 インスタンス)の橋渡しを行っていました。

Nitro10

いくつかの機能は、順次切り出されてハードウェアにオフロードされていきます。

Nitro11

全ての機能がオフロードされ、 2017年に AWS Nitro というシステムとして発表されました。あわせて、ハイパーバイザーは Xen ベースから KVM ベースに置き換わっています。

Nitro12

一枚絵でわかりやすい awsgeek

これらのハードウェアの変遷について、わかりやすく表現してくれているサイトとして awsgeek.com があります。

Nitro13

awsgeek.com は、AWS のプリンシパル・テクニカルエバンジェリストであるジェリー・ハーグローブ氏が運営しているサイトです。

AWS サービスや re:Invent のセッションの内容など、一枚絵でわかりやすく表現してくれています。

Nitro に関する内容では、以下が参考になります。

Nitro の何が嬉しいのか

最後に、Nitro の何が嬉しいのかを以下の3点から取り上げました。

  • AWS の迅速なアップデートを支える
  • Nitro だからこそできる機能
  • セキュリティ面の向上

AWS の迅速なアップデートを支える

Nitro システムの確立により、新たなインスタンスタイプの登場や性能向上、価格低下といったことを迅速に行うことが可能となり、カスタマーはメリットを享受できます。

Nitro14

Nitro だからこそ実現できる機能

新しく追加される機能は Nitro システムが前提になっている、あるいは Nitro 以外では導入までリードタイムが発生する、といったものが多いです。

Nitro15

セキュリティ面の向上

Nitro によりセキュリティ面が強化されました。これは基盤を管理する AWS としての視点が主となりますが、引いてはカスタマー側にとってもメリットがある話です。

Nitro16

終わりに

AWS Nitro について思いを馳せました。

普段カスタマーとしてはあまり意識する必要のない領域ですが、EC2 を裏側で支える大事な機能であることを再認識できました。ふとした時に思い出していただければと思います。

re:Invent 2020 の Nitro に関するセッションについては、以下でレポートをまとめていますのであわせてご参照ください。

以上、千葉(幸)がお送りしました。