re:Invent 2024: AWSエンジニアが解説 Nitro Systemの進化と性能向上
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Dive deep into the AWS Nitro System (CMP301)
この動画では、AWSのSenior Principal EngineerのAli Saidiが、AWS Nitro Systemの詳細について解説しています。2013年から始まったNitro Systemの開発により、従来のHypervisor機能を専用チップに移行し、ネットワーキング、ストレージ、セキュリティ機能を大幅に改善してきた経緯を説明しています。特に、Nitro Cardによるネットワーク帯域幅の1Gbpsから200Gbpsへの向上や、EBSの帯域幅の2Gbpsから100Gbpsへの進化など、具体的な性能向上の成果が示されています。また、Nitro Security ChipによるRoot of Trustの実現や、オペレーターアクセスの排除による強固なセキュリティ体制の構築についても詳しく解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Nitro Systemの概要と独自チップ開発の理由
AWS Nitro Systemの詳細についてご説明させていただきます。私はAWSのSenior Principal EngineerのAli Saidiです。本日は、Nitroについて、なぜ私たちがこのような方法を選択したのか、そしてそれによってどのようなメリットが得られるのかについてお話しします。これまでAWSでは、コアコンピューティングや機械学習など、複数の分野でシリコンチップの開発を行ってきました。 シリコン開発への最初の投資はNitro Systemで、従来のHypervisorの機能を専用チップに移行しました。 これは2013年に、後にAWSが買収することになるAnnapurna Labsというスタートアップとの協業から始まりました。
この講演の大部分はNitro Systemについてですが、その前に、私たちがシリコン開発に投資している他の分野についても少しお話ししたいと思います。まず一つ目は、AWS Gravitonです。これは、クラウドの幅広いワークロードに対して、AWSで最高のコストパフォーマンスを実現するホストCPUです。現在、Epic Games、Stripe、Pinterest、Datadog、さらにはSAPなどのお客様がGravitonでワークロードを実行しています。これらのお客様の中には、コンピューティングの大部分をGravitonで実行している企業もあります。 カスタムシリコンへの3番目の投資は、機械学習の推論とトレーニングワークロードで最高のコストパフォーマンスを実現するために一から開発されたAWS InferentiaとAWS Trainiumです。Databricksなどのお客様がこれらを活用しています。
では、なぜ私たちは独自のチップを開発するのでしょうか？答えは単純です。お客様に直接的な価値をもたらす場合に、独自のチップを開発します。 独自のチップを開発することで、私たちのユースケースに特化させることができます。AWSにおける特化とは、AWS環境の運用と私たちの特定のニーズに焦点を当てて設計をカスタマイズすることを意味します。「当然、どんなシリコンチップでも特定の市場向けにカスタマイズされているのではないか」とお考えかもしれません。通常、チップを開発する際は、その開発コストを償却するために、できるだけ多くの市場に適用できるようにしたいものです。しかし、そうすると様々な機能を詰め込む必要が出てきます。私たちの場合は、自社のユースケースにのみ焦点を当てることで、パフォーマンスと電力効率を最適化しています。
2つ目のメリットはスピードです。コンセプトの立案から、データセンターへの導入、そしてお客様への提供まで、開発プロセス全体を所有することで、より迅速な実行が可能になります。これにより、より早くテクノロジーをお客様にお届けすることができます。このプロセスを所有することで、コンセプトから導入までの時間を短縮できるのです。 3つ目は革新です。独自のチップを開発することで、より多くのイノベーションを実現し、より多くの価値を創造することができます。シリコン、マザーボード、サーバー、ファームウェア、Hypervisor、ラック、インフラストラクチャーを開発するチームが全て同じ屋根の下にいることで、従来のサイロを超えて最適なソリューションを構築し、個々のコンポーネントだけを見ていては不可能だった最適化を実現することができます。
そして最後は、セキュリティです。Nitroは、ハードウェアのRoot of Trust、サーバー上のファームウェアの検証、認証済みで監査可能なAPIを通じたホストとの限定的な相互作用により、サーバーのセキュリティを強化する手段を提供します。 Nitroは、クラウドにおける仮想化を最も基本的なレベルで根本的に見直したものです。 Nitro Systemには、ネットワーキング、ストレージ、セキュリティ機能を提供するNitro Cardsとホストプロセッサーが含まれています。その上でNitro Hypervisorを実行し、さらにその上でお客様のVMとアプリケーションが動作します。本日は、この分離がどのようにしてより優れたセキュリティを提供し、新機能の開発を可能にしてきたかについてお話しします。
Nitro Systemの進化：ネットワーキングとストレージの革新
その前に、私たちがどのようにしてここまで辿り着いたのかについてお話しさせていただきます。すべては、シンプルな疑問から始まりました：EC2の開発に約10年を費やしてきた経験を活かすとしたら、既存のシステムをどのように変えられるだろうか、という疑問です。 この問いに対して、多くの提案がありました。スループットの向上、ハイパーバイザーの簡素化、レイテンシーとジッターの削減、ベアメタル並みのパフォーマンスといった性能面での提案がありました。そしてセキュリティ面では、透過的な暗号化、ハードウェアのRoot of Trust、オペレーターアクセスの排除、監査可能な限定的なAPIセットといった機能が提案されました。Nitroは、これらすべてを実現する機会を私たちに与えてくれました。
これにより、AWSで開発しているチップや、それらで動作するファームウェアを含む、ハードウェアとソフトウェアの組み合わせによる包括的な改善を実現する機会が得られました。2017年にAC5インスタンスでNitroを導入して以来、5世代のチップを開発してきました。この journey は実際には2013年のC3インスタンスから始まり、Enhanced Networkingを導入し、従来ハイパーバイザーベースだった機能を専用チップに移行し始めました。これにより、より高性能なネットワーキング、低レイテンシー、そしてホストのCPU使用率の改善を実現しました。
時間の経過とともに、私たちは新しいNitro Cardを使って、ネットワーキング以外のストレージなどのI/O操作も処理できるように拡張してきました。大幅な機能削減が可能なハイパーバイザーを構築し、2017年以降にローンチしたすべてのEC2インスタンスでNitro Systemを使用しています。 Nitro以前のシステムでは、カスタマーインスタンスはXenハイパーバイザー上で動作していました。Xenは効果的でしたが、メモリ管理、CPUスケジューリング、デバイスシミュレーション、リミッター、Security Group の適用など、多くの機能を処理していました。さらに、特権を持つdom0には完全なLinuxユーザースペースが含まれており、これらの機能すべてがホストのCPUリソースを消費していました。
私たちは、まずネットワーキングから始めて、これらの機能を専用デバイスにオフロードし始めました。 異なる目的に応じたNitro Cardファミリーを開発しました - ネットワーキングを処理するもの、ストレージを管理するもの、そして両方の機能を実行するものです。 VPC用のNitro Cardは、片側にPCIeライクなコネクタがあり、インスタンスに接続されたENIデバイスを提供する仮想機能を備え、もう片側にネットワークアダプターがあります。これにより、ENIのアタッチメント、Security Group、Flow Logs、ルーティング、DNS、DHCPなど、以前はハイパーバイザーで実行されていたVPCデータプレーンの機能をオフロードしました。
新しいバージョンのNitro Cardは、VPCで暗号化を有効にした際に、パフォーマンスに影響を与えることなく、256ビットAESによる透過的なネットワークトラフィックの暗号化をサポートしています。 Elastic Network Adapter（ENA）は印象的な進化を遂げ、最初は10ギガビットのネットワーキングから始まり、25ギガビット、100ギガビット、そして現在は200ギガビットまで進化しました。これは同じデバイスモデルとドライバーを維持したままです。互換性を保ちながら、パフォーマンスが1桁向上したというのは、実に驚くべき成果です。
VPCネットワーキングにおけるNitroカードのもう一つの重要な進歩は、Elastic Fabric Adapter (EFA)でした。EFAは、低レイテンシーと高帯域幅を同時に必要とするHPCや機械学習ワークロード向けに特別に設計されています。これを実現するために、AWSが開発したScalable Reliable Datagram (SRD)というテクノロジーを実装し、複数のネットワークパスにトラフィックを分散させることで、輻輳を軽減しホットスポットを回避しています。
従来のネットワークプロトコルは、通常ネットワーク内の単一のパスを使用するため、輻輳への反応が遅く、障害への対応はさらに遅くなります。しかし、Closネットワークでは、ポイント間に複数のパスが存在します。Nitroカードに搭載されたSRDを使用することで、輻輳を検知してそれを回避し、より多くの帯域幅を同時に利用できます。これはインターネットスケールの時間ではなく、データセンタースケールの時間で動作します。
Nitroカードに搭載されたこのSRDは、多数のパスを同時に使用するための基盤を提供し、すべてのパスに帯域幅を分散させ、輻輳を素早く検知し、輻輳のないパスにトラフィックを移動し、リンクに問題のあるパスを回避することで、テールレイテンシーを削減し帯域幅を増加させます。これらの分散アプリケーションでは、計算、ネットワーキング、そしてすべてのネットワークメッセージが交換された後に再び計算を開始するという、バルク同期型であることが多いため、テールレイテンシーが特に重要です。このようなシステムでは、中央値や平均レイテンシーよりも、P100レイテンシー、つまりテールレイテンシーの方が重要になります。
SRDがどのように機能したか見てみましょう。グラフのX軸にコア数、Y軸にスケーリングを示しています。理想的には赤い線、つまり完璧なスケーリングになるはずです。EFAがない場合、それは紫の線になります。スケーリングは始まり、約400コアまで到達しますが、その後平坦化し、さらにマイナスに転じてしまいます。EFAを使用すると、より長時間、ほぼ線形にスケールすることができます。EFAの第1バージョンは最大100ギガビットのネットワーキングをサポートし、第2バージョンは最大200ギガビットのネットワーキングと30%低いレイテンシーを実現しています。
Nitro Systemがもたらすセキュリティと性能の向上
SRDを使用している別の領域は、一般的なネットワーキングです。しかし、その前にTCPがネットワークにどのように反応するか説明させてください。TCPはパケットの順序通りの配信を期待します。従来、フローはネットワークの単一のパスにハッシュされ、そのパスを通って順序通りに到着します。時には、大きなフローが別のフローと同じパスにハッシュされることがあり、オーバープロビジョニングされたネットワークでも輻輳が発生します。 ここで黄色で示されているように、スイッチが負荷に対応できずパケットをドロップしてしまうことがあります。これによりTCPはバックオフし、トラフィックは流れ続けているにもかかわらず帯域幅が減少してしまいます。
赤で示されているような状況では、リンクに問題が発生することがあります。 TCPの輻輳制御は、ある程度のパケットロスには対応できますが、リンクが完全に失われた場合、TCPは全く上手く対応できません。接続タイムアウトを待ち、新しい接続を再確立してから、その後の処理を続けなければなりません。ネットワーク内に複数のパスがあれば、それらを全て使えばいいと思うかもしれません。しかし、TCPには順序通りの配信という前提があります。もし複数のパスでトラフィックを送信すると、パケットが順不同で到着し、輻輳制御アルゴリズムはネットワークに問題があると判断して帯域幅を減少させてしまいます。
ENA Expressでは、これらの処理をNitro Cardにオフロードしています。TCPは順序が乱れたセグメントをうまく処理できませんが、私たちはTCPを取り、そしてNitro CardがSRDを使用してネットワーク全体にトラフィックを分散させます。ネットワークは受信側でパケットを順序通りに再構築し、アプリケーションに提供します。これにより、アプリケーションを一切変更することなく、SRDと複数パスの利点を活用することができます。
特にファイルシステム、インメモリデータベース、メディアエンコーディングのようなワークロードでは、そのメリットは非常に大きくなります。シングルフローの帯域幅が5ギガビットから25ギガビットへと5倍に増加し、高負荷時のレイテンシーベンチマークでは最大85%の改善が確認されています。設定も簡単で、APIやコンソールのトグルを通じてENA DeviceでENA Expressを設定するだけです。同じAvailability Zone内では、TCPとUDPに対して透過的に動作し、大幅なパフォーマンス向上が得られます。
ネットワーキングにおけるパフォーマンスの向上は目覚ましいものでした。EC2が始まった当初、1ギガビットのネットワークが一般的で、それは約10年間ほとんど変わりませんでした。今日では、10ギガビットから25ギガビット、50、100、200ギガビットへと大きく進化し、現在では複数のテラビット対応のインスタンスも提供しています。この数年間でのネットワーク帯域幅とパフォーマンスの向上は、本当に驚くべきものでした。
Nitro Systemが適用されたのはストレージの分野でした。
次にNitro Systemを適用したのはストレージの分野です。先ほど申し上げたように、Nitro CardはNVMeデバイスのセットを提供します。NVMeは標準化されたドライバーを持つ優れた標準プロトコルで、Nitro CardはNVMeインターフェースを一方で公開し、もう一方でEBSデータプレーンに変換します。ネットワーキングと同様に、EBSボリュームの暗号化を有効にすると、Nitro Card上で性能の低下なく透過的に処理されるため、暗号化の有無を選択する際のトレードオフを考える必要がありません。また、ネットワーキングで触れたように、ここでもSRDを使用しています。ストレージリクエストを行うと、ストレージサーバーへの複数の経路でリクエストを送信することで、ストレージワークロードのテールレイテンシーを改善しています。
ネットワーキングと同様に、パフォーマンスの大幅な向上が見られます。10年前を振り返ると、EBSの帯域幅は2Gbpsでした。現在では、最大100Gbpsの帯域幅と40万IOPSを提供しています。EBSは素晴らしいソリューションで、ほとんどのお客様にとって最適な選択肢です。より優れた耐久性とスナップショット機能が得られますが、一部のワークロードではローカルストレージが必要です。そこでNitro Systemでさらなる投資を行った分野の一つがこれです。
この仕組みについて説明する前に、フラッシュメモリとSSDの動作について少し背景説明をさせていただく必要があります。SSDには2つの重要なコンポーネントがあります。1つ目はNANDで、ここにビットが格納されます。しかしNANDには特殊な性質があり、1バイトや1ビットを変更したい場合でも、単純に変更することはできません。NANDに書き込むためには、ブロック全体を消去する必要があり、ブロックは通常メガバイト単位です。これに対処するために、Flash Translation Layer（FTL）と呼ばれるものがあります。これは論理アドレスと物理アドレスのマッピング、ガベージコレクション、そしてフラッシュには寿命があり書き込み回数に制限があるため、消耗を均一にするウェアレベリングを管理します。
考えてみると、これはデータベースのWrite Loggingとよく似ています。データを書き込んで、後でガベージを掃除するわけです。データベースと同様に、すべてのSSDベンダーは独自のFTL実装を持っており、同じNVMe APIを外部に提供していても、それぞれが少しずつ異なる動作をします。平均的なケースでは、どれも良好な性能を発揮しますが、私たちの経験では、時々予期せぬ奇妙な動作をすることがあります。例えば、最悪のタイミングでガベージコレクションが開始され、突然リクエストが停滞してしまうことがあります。このような動作により、一貫したパフォーマンスを実現することや、データベースのような一貫したレイテンシーを必要とするワークロードを実行することが難しくなります。
では、必要なパフォーマンスをどのように実現できるのでしょうか？私たちはFTLをNitro Cardに統合しました。これにより、最大60%のレイテンシー削減、信頼性の向上、そしてEphemeralキーによる暗号化を実現しています。つい昨日、第3世代のSSDを搭載したI4gインスタンスを発表しました。これは2年前のI4gインスタンスと比較して、最大65%高いリアルタイムストレージパフォーマンスと50%低いレイテンシーの変動性を実現しています。
これにより、私たちはHypervisorとホストCPUから離れ、専用ハードウェアであるネットワーキングとストレージの機能に移行しました。XenにおけるPrivileged DomainであるDom0は、現在では大幅にオフロードされ、その機能のほとんどがNitro Systemによって処理されているのがお分かりいただけると思います。このようなI/Oのオフロードを行った後、Hypervisorが実際に必要とする機能を見直すことができました。これにより、先ほど説明した機能の多くを取り除いた軽量なHypervisorが実現しました。メモリとCPUの割り当てを行い、あとは邪魔にならないようにするだけです。SSH、systemd、ネットワークスタックなども存在しません。非常にコンパクトであり、コンパクトであることは素晴らしいことです。リソースの使用が少なく、何も要求しない限り、邪魔になることもありません。
Nitro Systemの高度なセキュリティ機能と独立評価
これにより、ベアメタルに近いパフォーマンスを実現しています。同じサイズのベアメタルインスタンスと仮想化インスタンスを比較しても、通常はパフォーマンスの違いを感じることはできません。実質的にベアメタルと同等なのです。さらに、私たちはサーバーにNitro Security Chipを追加しました。マザーボードにはファンの速度や温度を測定するコンポーネントがありますが、これらすべてを更新できるようにしたいと考えています。これらのコンポーネントは監視され、最新のファームウェアバージョンで動作していることを確認する必要があります。
Nitro Security Chipにより、マザーボード上のフラッシュデバイスの内容を測定し、期待値と一致していることを確認し、アウトオブバンドで更新することが可能になりました。これにより、管理とセキュリティ監視をNitro Cards に移行し、Nitro Hypervisorの使用に切り替えることができます。
パフォーマンスとセキュリティについて説明してきましたが、Nitro Systemのもう1つの重要な側面をご紹介したいと思います。それはモジュラー設計です。異なるサーバーに搭載できる様々なカードがあり、異なる構成を構築することができます。振り返ってみると、1つのインスタンスから70のインスタンスに到達するまでに11年かかりました。しかし、Nitro Systemの導入後、7年で70から現在の約850まで増加しました。これは、インスタンス数の大幅な増加を表しており、Nitro System以前では実現できなかった、様々なストレージ構成、ネットワーク構成、アクセラレータに関する柔軟性をお客様に提供しています。
ネットワーキングとストレージについて説明してきましたが、セキュリティについてもう少し詳しく見ていきましょう。AWSのセキュリティは共有責任モデルに基づいています。AWSはクラウドのセキュリティ に責任を持ちます。つまり、ホストソフトウェアと仮想化レイヤーからサービスを運用する施設の物理的セキュリティまで、すべてのコンポーネントの運用、管理、制御を行います。一方、お客様はクラウド内のセキュリティに責任を持ちます。これには、Security Groupsの設定、OSの最新状態の維持、VPCの設定など、必要なセキュリティ構成の実施が含まれます。
ここ数年、コンピューティングに対する関心が高まっていますが、同時に混乱も生じています。私たちはこれを、お客様のコードとデータを保護するという観点から捉えています。最初によく受ける質問は、誰から保護するのかということです - 通常は、他のお客様やクラウドプロバイダーからコードとデータを保護します。これを第一の次元と呼んでおり、Nitroは外部からのアクセスからお客様のコードとデータを保護するメカニズムを構築しています。これはNitroのデザインにおける基本的な決定事項となっています。
これらの保護機能を振り返ってみましょう。Nitroは、CPUで実行されているお客様のコードと、主にNitro Cardsで実行されている私たちのコードとの間に物理的な分離を提供します。システムが起動すると、Nitro Security Chipを搭載したNitro Cardsがサーバーのファームウェアの内容を測定して検証します。その後にのみ、サーバーのストレージのロックを解除し、お客様のインスタンスを実行します。システムのダウンタイムなしに、すべてのソフトウェアをライブアップデートすることができます。このソフトウェアは、世界中に分散したチームによって開発され、複数者によるコードレビューとテストを受け、自動化されたビルドパイプラインによって暗号署名され、デプロイメントポリシーとスケジュールを定義するデプロイメントシステムによってデプロイされ、デプロイメント中はモニタリングされ、異常が検出された場合はロールバックがトリガーされます。
最も重要なのは、ハイパーバイザーへのリモートアクセスが存在しないことです - SSHサーバーはありません。暗号化され、認証され、承認され、ログに記録されるAPIのみが存在し、これらのAPIにはお客様のコンテンツにアクセスする方法は一切含まれていません。第二の次元は、お客様のワークロードをより信頼度の高いコンポーネントと低いコンポーネントに分割することです。この分離により、オペレーターのアクセスを制限し、アプリケーションのバグによるデータ露出から保護することができます。よくある例として、プライベート署名キーをEnclaveの中に置くことで、アプリケーションにバグがあってもそれらのキーにアクセスできないようにすることが挙げられます。
通常のNitroインスタンスのすべての保護機能がある場合、Enclaveは何を提供するのでしょうか？これは、親が一部のCPUとメモリを提供する別のインスタンスです。Nitro Hypervisorが新しいVMを作成し、そのVMには永続的なストレージがありません。SSHでアクセスすることもできません。非常に制約が厳しく、親への小さな経路のみを持っています。親はその中で実行されているプロセスにアクセスできません。しかし、そのEnclaveの証明レポートを取得でき、Enclave内にはプライベートキーがあり、証明レポートにはパブリックキーがあります。
これを使用してEnclaveに送信するデータを暗号化でき、親インスタンスはそれにアクセスできません。これにより、署名キーやPIIなどの最も機密性の高いデータをそのEnclave内で安全に保護することができます。
最近、Nitroインスタンスにいくつかの機能を追加しました。その1つがUEFI Secure Bootです。 UEFIは、インスタンスを不変的な方法で起動することを可能にします。お客様はオンプレミスでSecure Bootを使用してきており、AWSでも同様の機能を使用できないかとの要望がありました。Secure Bootでは、ブートローダーとOSの計測を行い、それらの測定値をUEFI変数と比較し、合格した場合にのみシステムが起動します。これにより、再起動後も持続する可能性のある脅威に対する多層防御が提供されます。というのも、UEFI変数に登録された鍵で署名されたソフトウェアのみが起動可能となるためです。
また、Trusted Platform Module（TPM）のサポートも追加しました。インスタンスに対して標準的なTPM 2.0インターフェースを提供しています。インスタンスの起動時に、測定値がTPMに記録されます。これらの測定値にはプラットフォームの識別情報が含まれており、暗号化データの生成に使用できます。このデータは、LUKSやBitLocker、あるいはお客様が作成したカスタムアプリケーションのロック解除に利用できます。
ここまでNitro Systemのセキュリティについて簡単にお話ししましたが、この topic については詳細なホワイトペーパーを用意しています。私たちは、オペレーターによるお客様データへのアクセスを制限する独自のアーキテクチャを実現しており、このホワイトペーパーでその詳細を説明しています。さらに、NCC Groupが最近Nitro Systemの独立したアーキテクチャレビューを実施し、クラウドサービスプロバイダーの従業員が基盤となるホストにログインしたり、インスタンスストレージやEBSボリュームに保存されたお客様のコンテンツにアクセスしたりする仕組みが存在しないことを確認しています。
Nitro Systemの全体像とEC2インスタンスの実装
これらすべてを統合して、エンドツーエンドの全体像を見てみましょう。ここではGraviton4サーバーを例に説明します。このサーバーでは、多数のVMを稼働させることも、1～2台のベアメタルインスタンスをホストすることも可能です。ホストは独立したライフサイクルを持ち、すべてNitro Cardの1つによって管理されています。多くの人はホストCPUをサーバーの中心と考えがちですが、私たちのシステムではその考えを完全に覆しています。Nitro Cardがシステムの中心なのです。これらは、すべてのファームウェアを測定し、期待通りのものが実行されていることを確認してから、ホストCPUの起動を制御します。
Graviton 2は、EC2で初めてDRAMの暗号化を実装したインスタンスでした。Graviton4のリリースに伴い、この暗号化を他のインターフェースにも拡張しました。Graviton4 CPUとNitro Card間のインターフェース、そしてコヒーレントな複数のGraviton4ソケット間の通信も、新たに暗号化されるようになりました。
これらすべてをまとめると、左側にEC2のコントロールプレーンがあります。 Start InstancesやRun Instancesを呼び出すと、このコントロールプレーンと通信することになります。ここには、リクエストの認証、リクエストサイズやAvailability Zone、Placement Groupに合った容量プールの特定、そして最終的にインスタンスをホストするサーバーを特定する、複数のサービスが存在します。右側には、Nitro CardsとNitro Controllersがあります。この例では、1,092GBのRAMと96コアのVMを持つc8g.24xlargeインスタンスを実行しています。
コントロールプレーンに対してインスタンスの作成を要求すると、まずコントロールプレーンがNitro Controllerにメッセージを送り、このインスタンス用のリソースの割り当てを依頼します。そして、Nitro Hypervisorにメッセージが送られ、96コアと1,092GBのRAMを持つインスタンスのシェルを作成するよう要求します。これでリソースが予約されました。次に、コントロールプレーンはNitro Cardsに対して、そのインスタンスに基本的なデバイスを接続するよう要求します。これには、ストレージやネットワーキング、ENAデバイス、EBSボリュームなどが含まれ、それらが接続されます。これでデバイスはインスタンスに直接接続されました。Nitro Hypervisorは介在せず、Nitro Cardsと直接通信します。次に、コントロールプレーンが起動を指示し、インスタンスが起動します。ファームウェアがEBSボリュームを見つけてオペレーティングシステムを起動し、インスタンスが実行を開始して、初期化プロセスが完了します。
インスタンスが実行されると、Metalインスタンスの場合でも非常によく似た構成になります。実際、ここでもほぼ同じです。コントロールプレーンとNitro Cardsがあり、唯一の違いはNitro Hypervisorが存在しないことです。これは、VPCネットワーキングとEBSのすべての機能がNitro Cardsに組み込まれているためです。ベアメタルか仮想インスタンスかに関わらず、同じインスタンス、同じIOデバイスを持ち、同じように見え、同じように感じ、同じモニタリング機能を利用できます。
そして、この同じメカニズムを使ってMacインスタンスを作成することもできます。iOS、iPad、Mac向けのソフトウェアのビルドや署名のためにMacを使用したい開発者が多くいます。私たちは、EC2で実現できる同じような柔軟性と設定可能性を提供したいと考えました。そこで、Nitro Controllersを使用し、ThunderboltからPCIeへのブリッジを設置し、ThunderboltケーブルでMac miniに接続しました。これにより、他のインスタンスと同じように見え、同じように感じ、なおかつEC2の利点を活かしながらVPCで実行できるインスタンスが実現しました。
ご清聴ありがとうございました。このセッションではマイクを使った質疑応答ができないため、ホールで質問をお受けしたいと思います。ご参加いただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion