re:Invent 2025: EC2インスタンスのパフォーマンス最適化とプロセッサ特性の理解
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Everything you've wanted to know about performance on EC2 instances (CMP405)
この動画では、AWS EC2インスタンスのパフォーマンス最適化について、Seth FoxとArthur Petitpierreが解説しています。インスタンスファミリーの命名規則（C、M、Rシリーズの違いやvCPU対RAMの比率）、第6世代以降は同世代内でC、M、Rインスタンスに同じプロセッサが搭載されていること、Intel、AMD、Gravitonの各プロセッサの特性の違いが説明されます。hyperthreadingの有無がパフォーマンスに与える影響をOpenSSLベンチマークで実演し、Gravitonは物理コアごとに1 vCPU、Intelは2スレッドという設計の違いを示します。また、AMD C7AのCCX構造やNUMAトポロジーによるメモリアクセスの不均一性、24XLから48XLへの移行時にレイテンシが悪化する事例など、ハードウェアレベルの理解が重要であることを具体例とともに解説しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
インタラクティブセッションの開始とEC2インスタンスポートフォリオのデコーダーリング
みなさん、ようこそ。みんな聞こえていますか？素晴らしい。これは code talk なので、暗い部屋に隠れてスライドを見ているだけではないということを、みんなに理解してもらいたいんです。これはインタラクティブなセッションです。まず、いくつかの質問をしていきますし、スライドもいくつか用意していますが、質問をしてくれればくれるほど、より多くのことが得られます。そのために工夫があります。ステッカーを用意しているので、質問をしたらステッカーをもらえます。今日はそういう流れでいきます。
まず、会話をセットアップするために、少し準備をしていきます。当然、パフォーマンスについて話していきます。でも、その後は、本当にみなさんから質問をしてもらいたいんです。今日の趣旨はそこです。console talk になる方が多いと思いますが、code talk にもなるでしょう。その前に、今日この部屋にいる人たちがどんな人たちなのか、ちょっと把握したいんです。手を挙げてください。自分のアプリケーションのパフォーマンスメトリクスを見たことがあって、なぜそれが本当はもっと速く動くべきなのに、そのくらい速く動いていないのか、よくわからないと思ったことはありますか？何人か手を挙げていますね。手を挙げなかった人たちに言いたいのは、あなたたちは本当に運がいいか、それとも楽観的なのか、どちらかだということです。でも今日、それを確認していきます。
もう一度手を挙げてください。パフォーマンスを最適化しようとして、問題に対してもっと大きなコンピュータを投入したことがある人。もしかしたら、より大きなインスタンス、より多くのコア、より多くのメモリ。たくさんの手が挙がっていますね。ありがとうございます。だからこそ株価が高いんです。最後の質問です。NUMA nodes、cache lines、CPU affinity といった用語を聞いたことがある人、でも正直なところ、それがアプリケーションのパフォーマンスにどのような影響を与えるのか、よくわかっていない人は何人いますか？何人か手が挙がっていますね。手を挙げた人たちの反応を見ると、みなさんは本当に正しい場所に来たと思います。
業界には根強い神話があります。それは、モダンなコンパイラとクラウドインフラストラクチャが、ハードウェアを本当に理解する必要性を抽象化してしまったというものです。きれいなコードを書いて、クラウドにデプロイして、魔法が起こるということです。でも、ここが重要なんです。これが今日探索していくことなんですが、コードが動くことと、コードが飛ぶように動くことの違いは、しばしば、これらの抽象化の下にあるハードウェアを理解することに帰着します。同じサーバーが 2 台あって、同じコードを実行していて、同じワークロードを処理しているのに、一方が一貫して 40 パーセント良いパフォーマンスを発揮しているという状況を想像してください。目に見えるエラーもなく、ツールに明らかなボトルネックもありません。何が起こっているのでしょうか？答えは、スレッドがどの CPU コアに着地したのか、またはデータ構造がキャッシュラインとどのように整列しているのかと同じくらい単純かもしれません。
可能なことの限界を押し広げているとき、すべてのミリ秒のレイテンシが重要なとき、インフラストラクチャの予算から最後の一滴のパフォーマンスを絞り出そうとしているとき、そのときこそ、これらの低レベルの詳細を理解することが、興味深い雑学から重要な知識へと変わります。今日は、カーテンを引き戻して、メモリトポロジーを探索し、なぜ RAM が単なる 1 つの大きなプールではないのかを説明します。hyperthreading の技術を調べて、なぜ時々より少ないコアを使用することでより良いパフォーマンスが得られるのかを見ていきます。実際にパフォーマンスを測定する方法について話します。きれいな画像以上のものを提供する方法です。最も重要なことに、これらの最適化がいつ重要で、いつ重要でないのかについて、情報に基づいた決定を下す方法を学びます。
私の名前は Seth Fox です。Arthur Petitpierre と一緒にお送りしています。さっそく始めましょう。EC2 インスタンスのポートフォリオの読み方についてお話ししたいと思います。長年にわたって、私たちは多くのインスタンスと多くのインスタンスファミリーを持っていますが、デコーダーリングというものがあります。これはあなたが手に入れるステッカーです。 こんな感じになります。これを皆さんに説明して、何を見ているのかを理解してもらいましょう。 私たちの主力製品である C、M、R の 3 つをハイライトしました。これらはコンピュート最適化、汎用、メモリ最適化インスタンスです。これは正確には何を意味するのでしょうか？基本的には vCPU と RAM の比率です。上にその比率が表示されていますが、そのスタックを上に進むにつれて、vCPU と RAM の比率は 2 倍になります。
このデコーダーはインスタンスファミリー全体で機能します。c8gn.2xlarge を見てみましょう。これは何を意味するのでしょうか？C が見えるので、これはコンピュートベースのインスタンスです。8 世代目なので、コンピュートベースインスタンスの系統の中でどこに位置するかが分かります。その後、このインスタンスにはいくつかのオプションがあります：G と N です。G はこれが Graviton インスタンスであることを示しているので、Graviton プロセッサが搭載されています。N はこのインスタンスがネットワークに何らかの違いがあること、つまり特殊なネットワークを持っていることを示しています。次に数字に入ります。2xlarge は vCPU の数を示します。すべてが 2 倍になります。medium で 1 から始まり、large で 2、xlarge で 4、2xlarge で 8 になります。つまり、8 個の vCPU があり、その比率のおかげで 16 ギガバイトの RAM があることが分かります。
これを分解すると、8 世代目のコンピュートベースインスタンスで、8 個の vCPU、16 ギガバイトの RAM、そして最大 50 ギガビットの特殊なネットワークを備えています。
1 つのコンピュートベースインスタンスを見ると、これはインスタンスポートフォリオ全体をカバーしており、インスタンスの選択を行う際にさまざまな部分を分解するために使用できます。次のものに進む前に最後にコメントを 1 つ：上の左側の表で、C、M、または R インスタンスがメモリの量が異なることについて言及しました。非常に頻繁に遭遇する神話があります。それは 5 世代目にさかのぼるもので、C シリーズのプロセッサが他のものより速いかもしれないというものです。それが本当だった最後の時は Intel 5 世代目の AWS インスタンスの場合です。6 世代目から、C、M、R インスタンスに同じプロセッサを搭載しています。M6I を使用している場合、C6I に同じプロセッサがあり、R6I にも同じプロセッサがあります。
これにより、パフォーマンスを分析する人としてのあなたの生活がはるかに簡単になります。また、Spot のようなものを使用していて、多様化したい場合にも非常に簡単です。それでも同じプロセッサです。できるだけ、次の世代でもそれが本当のことになるようにしていきます。つまり、7 世代目全体で確実に当てはまります。Graviton 側では、7 世代目の Graviton ベースインスタンスは Graviton 3 であり、これは C7G、M7G、R7G で同じものです。AMD 側でも同じです：AMD 7G の同じ Genoa ベースプロセッサです。8 世代目でもそれを行いました。9 世代目でもそれを行います。15 世代目で同じになるとは約束できませんが、できる限りそうするようにします。
プロセッサブランド間のパフォーマンスプロファイルと周波数の真実
I instances でも同じように広げていて、例えば C、M、R と同じプロセッサを使っています。AMD、Intel、Graviton があって、Intel と AMD の中でも複数のファミリーと複数の系統があります。CPU ブランドが異なっていても、パフォーマンスは同じですか？いいえ、そんなに単純ではありません。同じブランドのプロセッサ内では、プロセッサは全く同じで、同じ世代内でのパフォーマンスプロファイルも同じです。C8I、M8I、R8I であれば、それは同じプロセッサで同じパフォーマンスプロファイルです。Intel から AMD に移動すると、全く異なります。AMD から Graviton に移動すると、これも全く異なります。
他のすべてと比較してどれが優れているかは言えません。ガイダンスは提供できます。一般的には Graviton プロセッサの方がコスト効率が良いと言えますが、場合によっては AMD プロセッサの方が高価ですが、より高速です。Intel との他の組み合わせもあります。それらは異なるものに最適化されており、異なる動作をするため、その質問に対する簡単な答えはありません。Graviton ベースのインスタンスでは、同じメモリドメイン内に多くのコアがある場合がありますが、AMD は 8 コアのクラスタを使った全く異なるタイプの最適化を行っています。メモリにアクセスするときに異なるパフォーマンスプロファイルを持つことになり、それはアプリケーションに影響を与えます。
ベンダー内では、サーバーチップは異なる SKU を持ち、異なる TDP とクロック速度を持っていますが、これらの使いやすい VM は単一の SKU として均一な基盤ハードウェアを持っているため、バリエーションはないと言っていますね。低いコア数は通常、より高いブースト周波数を持つ傾向がありますが、これらのインスタンスタイプで低いコア数にしても、基盤ハードウェアが均一であるため、高いコア数と比較してシングルスレッドアプリケーションでより高いパフォーマンスが得られることはありません。いつものように、簡単な答えではありませんが、
VM は大きなサーバーのスライスです。EC2 インスタンスで実行すると、大きなサーバーのスライスが得られます。内部的には、これらの大きなサーバーを droplets と呼んでいます。クラウドは droplets でできているからです。その大きな droplet は、ファミリー内の最大サイズと同じ数のコアを持つことになります。CAG 48 XL の例を取ると、それは 2 ソケットサーバーで、各々 96 コアを持つ 2 つの Graviton 4 プロセッサを持っています。CAG large を取ると、それは 2 vCPU インスタンスで、これは 2 ソケット、192 コアサーバーの 1 つのスライスです。
ある意味では、小さな VM を選択したからといって、より高い周波数が得られるわけではありません。なぜなら、それらはより大きなものからのスライスとして取られるからです。これらのより大きなものは、1 世代内で、特定のベンダーに対して、全く同じ基盤プロセッサを持っています。これらの droplets はインフラストラクチャ全体で均一です。ただし、本当に非常に高い周波数を気にする場合は、R7IZ のような特別なインスタンスタイプがあります。通常は Z で後置されており、これらは高周波数、通常 4 ギガヘルツ以上に設計されています。M5ZN を持っていたことがあり、これはそのようなインスタンスの 1 つで、Z1D もあります。これらは EDA のようなものに設計されたインスタンスの傾向があり、最も高いシングルスレッドパフォーマンスを得ることが非常に有益です。
汎用からFlexまで：インスタンスタイプの分類と選択ガイド
プロセッサーのタイプファミリーについて話していますが、基本的に我々が汎用と呼ぶものは3つの異なるタイプを含んでいます。T series はバースト可能なインスタンスで、AWS における flex タイプのインスタンスの唯一のタイプであり、オーバーコミットされています。つまり、これらのインスタンスでは、より多くの VM を実行し、実際の物理コアよりも多くの vCPU を販売しています。これはコスト面で優れており、パフォーマンス要件が限定的なアプリケーションに適していますが、パフォーマンスを本当に気にする場合には、おそらく良い選択肢ではありません。
他の汎用インスタンスはオーバーコミットされていません。オーバーコミットされていないというのは、例えば 2 vCPU ベースのインスタンスを取得するたびに、そのインスタンス用に 2 つの vCPU を確保しているということです。正しい方法で行っており、つまりそれらの割り当ては静的です。VM は浮遊していません。2 つのコアが割り当てられると、その 2 つのコアに留まるため、キャッシュがウォームになると、それはあなたのために温かいままになります。NUMA ノードの境界を越えて何かを割り当てることはありませんので、AMD インスタンスで 4 コアが 1 つの CCX にあり、4 コアが別の CCX にあるという状況になることはありません。常に境界内です。7 世代 AMD で 16 コアの VM がある場合、それは 2 つの CCX にまたがります。
Compute optimized インスタンスは、名前が compute optimized と言っているからといって、プロセッサーがより高速であるという意味ではありません。これは単に、最も気にすることがコンピュート能力を持つことであり、大量のメモリを持つことについてはあまり気にしない場合、それが必要なものであるということを意味しており、vCPU あたり 2 ギガバイトのメモリを備えています。Memory optimized も、メモリがより高速であるという意味ではありません。これは単に、より多くのメモリを取得するということです。R インスタンスタイプでは、コアあたり 8 ギガバイトのメモリを取得します。それはそれ以上になる可能性があります。X インスタンスは 16 ギガバイト、Z インスタンスは 8 ギガバイトのメモリを備えています。Accelerated compute は、GPU、FPGA、および我々が導入した様々な他のタイプのアクセラレーターを取得できる場所です。
Storage optimized は、EBS のような仮想ディスクではなく、サーバー内に物理的に配置されたローカルディスクを取得することを意味しています。HPC optimized インスタンスは、同じハードウェアで構成されていますが、HPC アプリケーション用の特別なリングフェンシングメカニズムを備えた非常に特殊なインスタンスタイプです。Flex インスタンスは、M と R インスタンスの一部が flex バージョンとして存在する別のオプションで、通常のクラスと全く同じハードウェアを備えていますが、オーバーコミットされており、ロードバランスされているため、ほとんどの場合 100% のパフォーマンスを取得できますが、基盤となるハードウェアのパフォーマンスの 80% まで低下する可能性があります。
Flex インスタンスは、パフォーマンス面で非常に重要でない場合に非常に便利であり、より安価です。ただし、パフォーマンス面で完全な再現性を望む場合は、おそらくあなたにとって適切ではありません。T series よりも優れている点は、CPU サイクルをクレジットして、それを消費して、クレジットが不足する段階に達し、その後無制限モードを持つというメカニズムがないということです。より安定した利用パターンなので、より予測可能です。Staging は flex インスタンスを使用するのに最適な場所であり、特に主に機能テストを行っており、最大スループットが必要ない場合です。
M シリーズインスタンスから得られる最大スループットを本当に評価したいのであれば、M Flex は選ばないでください。100% 得られることもあれば、80% しか得られないこともあります。ただし、主に機能テストを行うステージング環境であれば、それは何も変わりません。最大値の 80% しか得られなくても十分だと分かっているのであれば、それも素晴らしい選択肢です。ほとんどの場合、80% 以上は得られます。通常のインスタンスと同じインターフェースで動作します。名前を付けるときに「dash Flex」を付けるだけで、最大サイズは Flex では利用できません。
パフォーマンスの可視性に関しては、はい、スロットルされていて 100% の全力が出ていない場合は見えます。ただし、正直に言うと、本当に重要でないことをしているのでなければ、もう T クラスは使わないでください。代わりに Flex インスタンスを使ってください。はるかに良い選択肢です。Flex インスタンスの場合、ワークロードが 80～100% のどの範囲にあるのかを知りたければ、私たちを信頼してください。下限があります。舞台裏で何が起こっているかというと、透過的なマイグレーションでそれらのインスタンスをロードバランシングしています。突然、非常にホットなドロップレットに入って 60% まで低下するようなことがないようにするための、かなり効率的なメカニズムがあります。私たちは透過的にものを移行させます。
プロセッサ世代の進化：Sky LakeからGranite Rapidsまで
透過的なマイグレーションは、AWS が話すのを躊躇してきたものです。私たちはかなり長い間、主に信頼性の目的でこれを行ってきました。今は EC2 FAQ に載っていますが、FAQ に載る前からずっと行っていました。顧客に対して公開しているわけではなく、インスタンスのマイグレーションをスケジュールすることはできませんが、舞台裏で大いに使用しており、非常に信頼性の高いメカニズムです。考え方としては、インスタンスは完全に仮想的な構成要素です。それはどこかに存在するのではなく、クラウドに存在します。 では、これらの異なるインスタンスタイプの実際のプロセッサについて少し話しましょう。ここでは主に C、M、R に焦点を当てます。これらはおそらくあなたが使用しているもののうち 90% です。異なるベンダーのコード名に詳しい方々のために、私たちはよく「5 世代目、6 世代目、その他」の背後にあるものは何かという質問を受けます。パフォーマンス比較をするときに、最新のものを使うことをお勧めしますが、それはおそらく正しいことだと思います。異なるプロセッサタイプとの比較をする場合、世代ギャップがあります。
例えば、Graviton Gen 6 は Intel または AMD の Gen 5 に相当します。これはすべてに当てはまります。Gen 6 は Graviton Gen 7 に相当します。Gen 7 Intel と AMD は Graviton Gen 8 に相当します。その他については、Gen 9 Graviton はまだ存在しませんが、いずれかの時点で来るでしょう。Intel と AMD の Gen 5 では、Sky Lake と Cascade Lake がありました。これは、うまくいけば二度とやらないような奇妙なことでした。Sky Lake で導入し、その後 Cascade Lake で静かなリフレッシュを行いました。ほぼ同じパフォーマンスプロファイルでしたが、場合によっては Cascade Lake の方が少し高速でした。これは顧客にとって少し奇妙でした。顧客が不満を言い、私たちが耳を傾けたので、もう一度はやっていません。
AMD Gen 5 は Rome でした。Graviton 側では Gen 6 が Graviton 2 でした。私からの推奨としては、Spot を通じて使用している場合を除き、もうこれらを使用しないことです。これらのインスタンスの価格性能比はもはや見合いません。より最新のものに切り替えれば、より良いパフォーマンスが得られます。Gen 6 の Intel と AMD は Gen 5 と全く同じ価格で設定されており、より高速です。非常に高速というわけではありませんが、高速です。容量が利用できない場合を除き、Intel や AMD で Gen 5 を使用したり、Graviton 側で Graviton 2 を使用したりする理由は全くありません。
Gen 6 でさえ、最近リリースしたものと比べると、古くなり始めています。Gen 7 よりは安いですが、価格性能比という観点では、Gen 7 または Gen 8 を使用する方が良いでしょう。Intel 側では Ice Lake です。AMD 側では Milan です。Graviton 側では Gen 7 が Graviton 3 です。より最近では、Intel の Gen 7 は Sapphire Rapids です。AMD の Gen 7 は Genoa で、素晴らしいプロセッサです。Graviton では Graviton 4 です。そして、数ヶ月前にリリースした最新のものとしては、Intel 側に Granite Rapids があり、AMD 側に Turin があります。Graviton については、推測するのは簡単で、それもやってくるでしょう。
ここ数年見てきたいくつかのトレンドとしては、ソケットあたりのコア数が増加しています。これは全体的に当てはまります。Intel でも見てきましたし、AMD でも見てきましたし、Graviton でも見てきました。これは止まりません。様々なインスタンスタイプの次世代でも当てはまるでしょう。vCPU あたりのドルも増加しています。製造技術、メモリ技術、そのすべてがより高価になっています。ですから vCPU ベースでの価格は上がっています。
とはいえ、パフォーマンスあたりのドルは減少しています。なぜなら、パフォーマンスが向上しているからです。vCPU ベースでは高くなっていますが、アプリケーションが実際にプロセッサのパフォーマンスから恩恵を受けるなら、より良い価値提案が得られます。単位作業あたりの消費電力も減少しています。消費電力の観点からもう少し負荷を軽くしたい、そしてより良い地球市民になりたいのであれば、最新世代のインスタンスを使用した方が良いです。その点ではもう少し良いです。組織内で持続可能性の目標を持っている人はいますか？Graviton があり、最新プロセッサを活用することで、そのような多くのことに役立つでしょう。
もう一つ見てきたトレンドで、今後どのように進化するかは見てみましょう、というのは、私たちのプロセッサの一部が同時マルチスレッド処理を使用しているということです。これは物理コアあたり 2 つ以上の実行スレッドを使用する能力です。
私たちの中には、そうではない人もいます。そしてそれはパフォーマンスと、パフォーマンスの測定方法に影響を与えます。プレゼンテーションの後半でもう少し詳しく見ていきます。
質疑応答：Spotマーケット、価格設定、インスタンス構成の柔軟性
では、いくつかのポイントについてですが、ああ、そうですね、一旦ここで止めます。質問がありますか？どんな質問ですか？次はどこに行けるでしょうか？皆さん今日は静かですね。初デートですから。皆さん疲れているのではなく、興奮しているはずです。では前の方に進みましょう。
では、ここでの仮想化についていくつかのポイントです。これまで議論してきたすべてのファミリーが spot instances で利用可能なのか、そして Sapphire Rapids という名前はどこから来ているのか？ということですね。それらはすべて最初から spot として利用可能です。spot をリリースするとき、spot マーケットが有効になりますが、問題は技術的に spot として利用可能かどうかというより、むしろ健全な spot マーケットのための容量が十分であるかどうかです。リリースしたときに、それらのものの中には非常に成功したものがあり、顧客が大量に新しい世代に移行しているかもしれません。その場合、spot のための容量はほとんどないかもしれません。健全な spot マーケットを得るまでには、通常は数週間、より現実的には数ヶ月かかります。
ただし、一般的には、新しい世代の非常に早期採用者は spot 顧客であり、Capacity Commitment Discounts を使用する能力を持っている、または非常に早期採用者です。Capacity Commitment Discounts を使用した割り当てメカニズムを使用して、Generation X から始まるすべてのものが欲しいと言う場合、リリース当日に on-demand 顧客がそれらのインスタンスを使用し始める前に、あなたがそれを使用しています。価格は低く、パフォーマンスは素晴らしいです。その後、on-demand 顧客が切り替え始め、その後 spot マーケットは数週間消えてしまいます。それまでに十分な容量を起動して、健全な spot マーケットを持ち始めるまでです。
では、2 番目の質問についてですが、Intel からのコード名についてです。ほとんどのコード名は Washington 州の川と湖から来ていると思います。確かにそれは昔は本当でした。今日はどうかわかりません。なぜなら、Fire Rapids が Washington のどこかにあるかどうか覚えていないからです。私は 6 ヶ月前まで Seattle にいましたが、Sapphire Rapids を見たことがありません。私たちのプロセッサ名はもう少し単純です：Graviton 1、2、3、4。追跡するのは非常に簡単で、どこから来たのかわかります。他に質問がありますか？
では、さっき言ったことへの返答をちょっと。なぜ Graviton 2 が第5世代なのかというと、EC2ベースのインスタンスの最初の世代をリリースした時点では Graviton がなかったんです。最初の Graviton ベースのインスタンスが A1 と呼ばれた理由を聞かないでください。それは私たちの最初の ARM プロセッサだったし、その時点では次のものを A2 と呼ぶつもりだったのかもしれませんが、結局そうはなりませんでした。A1 があって、それはポーティング用の車両だったんです。そして次の世代では C と M と R があって、C6G と M6G と R6G になったわけです。正直なところ、EC2 のプロダクト管理チーム内でインスタンスに名前を付ける責任を持つ人になりたくはありませんね。どうやって名前を付けようとしても、どこかの時点で失敗しますから。
もう一つの質問は、世代が上がると vCPU あたりの価格は上がるけど、パフォーマンスあたりの価格は下がるって言ったじゃないですか。新しい世代に移行して本当にお金が節約できるかどうかをどう判断するんですか？例えば8コアのワークロードを使ってる場合、価格を下げるために4コアに落とさなきゃいけないですよね？それは状況によります。アプリケーションが本当に単一のインスタンスで動いてるなら、そうですね、それは問題になります。パフォーマンスが上がるというトリックがあります。通常は複数のパラメータがあるからです。CPU のパフォーマンスだけじゃなくて、OK、実は必要なメモリの量があるんです。
ネットワークが本当にボトルネックじゃなければ、潜在的には M でコア数を半分にすることができるし、それがあなたのアプリケーションにとって最適なポイントかもしれません。ほとんどの場合、サーバーのプール、つまり特定のワークロードを処理している Web サーバーのプールがあって、顧客から来るリクエスト数が一定で、変動しています。
例えば平均的には 100 個のサービスを使ってるとしましょう。今、より高速なものが1つあれば、平均的には 80 個を使うようになるかもしれません。インスタンスあたりではより高くなりますが、使う数は少なくなります。重要なのは、必ずしもマシンの CPU 負荷を心配することではなく、API リクエスト毎秒は何か、そのインスタンスのビジネス測定値は何か、インスタンスのスループットは何かを心配することです。それが増加して、テストしてそれが上がれば、その価格パフォーマンスメトリクスを得ているんです。
単一のサーバーがあって、それを分散させる方法がないなら、あなたの言う通り、より良いパフォーマンスが得られますが、より多く支払うことになります。Spot マーケットとその健全性についての質問があります。古いサーバーラックを取り外し始めるのはどの時点ですか？私は多くのバイオインフォマティクスワークロードを実行しています。ボックスとメモリが必要ですが、速度については本当に気にしません。M4 まで遡るすべてのものを実行しています。非推奨化の時点があるんですか、これを使うのをやめてください、ラックを取り外し始めるつもりです、みたいな？
M4で実行している場合、おそらくもうM4ハードウェア上では実行されていません。今はXeon Nitroで実行されており、私たちは以前の世代の仮想化システムをエミュレートして、あなたがまだM4で実行されていると信じさせています。そしてそれは機能します。特定のハードウェアでソフトウェアを検証する必要がある企業にいる場合でも、同じように機能しますが、私たちの側ではおそらくもうM4ではありません。私たちはできるだけ、それらのインスタンスが必要な顧客のためにインスタンスをリタイアしないようにしています。
ですから、まだM2を起動できるアカウントがありますが、それはもう本当のM2ではありません。価格性能の観点からすると、そんな古いものは実行しないでください。それは全く意味がありません。他の理由もありますが、そうでなければ、私たちはインスタンスをリタイアすることはないと思います。まあ、私たちはしましたが、古いGPUインスタンスのような特定のインスタンスの場合、エミュレートできず、ハードウェアをもう維持できなくなった場合です。その場合、私たちはそれらのインスタンスをリタイアしました。一般的には、できるだけ長い間それらを利用可能にするために最善を尽くしています。
1つ質問があります。最新のインスタンスタイプの価格がより低くなると言及されていましたよね？ただし、私が観察した1つのことは、Reserved Instancesを使用する場合、古い世代の方がはるかに安いということです。あなたが言及したことは、DRIsの価格設定モデルを変更したRDSでは非常に当てはまると思います。EC2ではそれを見たことがないと思います。EC2インスタンスでの私の経験では、それも可能であり、私たちも顧客をRIsからSavings Plansへシフトさせようとしています。
私が価格設定に関して言及したことは、オンデマンドに特に適用されていました。これらの長期的なコミットメントに価格を付ける方法は、少し異なる場合があります。2番目の質問は、すべてのインスタンスタイプは1つのCPUのようなもので、メモリとCPUは厳密に制限されていますよね？AWSがメモリを選択できるように変更する計画はありますか？GPUは例えば2、メモリは4または8、GCPがやるのと同じ方法です。私が知る限りではありません。ありがとうございます。ただし、私たちはより多くの多様性も提供しています。
その問題を処理する方法は2つあります。非常に少ない数を持つか、それをカスタマイズ可能にするか、または多くの異なる組み合わせを提供するかです。私たちは非常に広い範囲の可能な組み合わせをカバーしていると信じています。本当に不足しているものがあれば、アカウントチームに知らせてください。PFRsと呼ばれるメカニズムがあり、そこで不足しているかもしれないことが私たちのチームに信号を送ります。私たちのチームは不足している機能を特定する可能性があり、需要が十分に大きいと感じた場合、それを実装するかもしれません。
彼らは choose-your-own instance configuration のアプローチから離れていくかもしれないというのが私の理解です。確認することはできませんが、そうなる可能性があります。確かに、それは保守するのが課題です。しかし、950 個の instance type が 100 単位の増分で利用可能なので、既存のポートフォリオの中で皆さんのニーズに合うものを見つけることができます。結局のところ、どこで複雑性を公開するかという選択に帰着します。そのレベルの柔軟性を公開することにした場合、物理ハードウェア上で instance をどのように分割するかという複雑性が増すことになります。物理ハードウェアは固定されているからです。つまり、複雑性をどこに置くかという問題なのです。これまでのところ、私たちは複雑性をある程度皆さん側に置くことを選択してきました。固定サイズを多数提供し、皆さんがその中から選択するというアプローチです。
Nitro仮想化スタックとベアメタルインスタンスのパフォーマンス特性
最大 socket 数に関する最初のご質問についてですが、Intel ベースの X class instance では 4 個の socket があります。U class instance は非常に特殊で、オンデマンドでは取得できず、主に SAP を対象としていますが、最大 8 個の socket を取得できます。hyperthreading に関するもう一つのご質問については、それについて具体的に説明し、どのように識別するかをお見せします。
vCPU を増やさず、前の世代から新しい世代に移行しても、パフォーマンスは向上します。これは、すべてのベンダーが CPU の設計方法を改善しているからです。それを行う方法はたくさんあります。世代から世代へと、通常はより大きなキャッシュがあります。L1 は最新世代ではほぼ固定されていますが、L2 は増加し、L3 は大幅に増加しています。最新世代の Intel と AMD には大規模な L3 キャッシュがあり、これはメモリアクセスを扱う際に大いに役立ち、通常はワークロードを高速化します。
改善できるもう一つの領域は、branch predictor の動作方法を変更することです。多くのアプリケーションは、CPU がコードの次の分岐セットをどのように予測するかに非常に敏感です。メモリネットワークも改善され、より拡張性が高くなりました。メモリレイテンシはほぼ同じレベルに留まっていますが、メモリ帯域幅は大幅に増加しています。G5 Intel では、正しく覚えていれば、4 つのメモリチャネルがありました。最新世代は 8 つのメモリチャネルを持っています。最新世代の AMD ベースの instance は 12 個のメモリチャネルを持っています。プロセッサのこれらの異なる領域を改善することで、それらをより良く、より高速にします。
アプリケーションにパフォーマンスの問題がある場合、単に CPU をより多く投入することが常に役立つとは限りません。アプリケーションに CPU をより多く与えることが、常にそれを高速化するわけではありません。より多くの vCPU の恩恵を受けるには、ある程度の並列性を持つアプリケーションが必要です。複数の CPU を使用できる場合、それは潜在的にそれを高速化しますが、ある程度のレベルまでです。アプリケーションの 100 パーセントを並列化できることはほぼありません。そのため、アプリケーションの一部はまだ順序実行のままであり、それを無限に加速することはできません。
プロセッサがどのように改善されてきたかについて、もう一つ言い忘れたことがあります。それは、プロセッサが並列で実行できる命令の数も改善されているということです。多くの人はプロセッサについて、毎サイクル1つのことを実行するというメンタルモデルを持っていますが、実は最新のCPUは複数の命令を並列で実行できます。
メモリのロードとストア、加算、乗算を実行でき、プロセッサの中には1サイクルで最大6つの命令を実行できるものもあります。アプリケーションの中には、特定のプロセッサから1サイクルあたり数個の命令しか抽出できないように構築・最適化されているものがあります。それらを大幅に最適化しない限り、実はCPUを十分に活用していないことになります。ですから、あなたの質問に対する直接的な答えはなく、より詳細な分析と低レベルの最適化が必要になります。
私たちのインスタンスのほとんどは現在、最新世代の仮想化スタックを使用しています。第4世代から第5世代に移行した際に、仮想化の方法を変更しました。Xenからnitroに移行したのです。これはパフォーマンスに大きな影響を与えています。なぜなら、仮想化プリミティブの多くを専用ハードウェアにオフロードしたからです。仮想化システムのノイズが低下しました。2つの仮想化システムを同じプロセッサの上に公開したことがないため、実際の比較はできませんでしたが、Nitro仮想化スタックに移行した際には大きなゲインがありました。
また、前のシステムで発生していたノイジーネイバー効果も軽減されました。Nitroではメモリ帯域幅レベルを除いて、ほぼノイジーネイバーの問題がありません。Nitroはまた、ベアメタルインスタンスを可能にしました。仮想化プリミティブをすべてインスタンスの外に移動させたため、ネットワークアクセス、EBS、そのすべてがオフロードされ、ハイパーバイザーレベルでセキュリティの観点から実際に行う必要があることは何もありません。ハイパーバイザーを削除して、CPUを完全にコントロールできるメタルオプションとしてインスタンスを提供することができます。
欠点は、フルインスタンスとしてのみ提供されるため、小さなチャンクでは提供されないということです。ただし、プロセッサを完全にコントロールする必要がある場合は、メタルインスタンスで可能です。パフォーマンスの観点からは、通常のワークロードではメタルインスタンスがより高速になることは期待しないでください。ネットワークとNitro IPアドバイザーによって導入されるパフォーマンスペナルティのレベルは非常に限定的です。ネットワークレベルで非常に強い要件を持つ人々にとっては、少しの影響があります。例えば、高頻度取引を行っている人々は違いを感じるでしょう。
ただし、通常の人が通常のウェブアプリケーションとデータベースをやっている場合、自分で仮想化システムを実行する必要があるなど他の理由がない限り、ベアメタルに行く意味は全くありません。そういった場合は、パフォーマンス要件というより機能要件になってきます。 先ほどハイパースレッディングについての質問がありましたね。これがそれについて話すスライドですか？ちなみにこのスライドのタイトルは間違っています。ハイパースレッディングについて質問がありましたし、誰が聞いたのか忘れてしまいましたが、この機能は結構変わってきています。
ハイパースレッディングの実演：IntelとGravitonのSMT比較とRSA暗号処理
Graviton を導入する前は、すべてのインスタンスでハイパースレッディングが有効になっていました。つまり、物理コアごとに 2 つのスレッドが物理コアにマップされていました。Graviton から始まって、私たちはシングルスレッドのインスタンスを導入しました。つまり、各 vCPU が物理コアにマップされています。AMD GENOA から、AMD もハイパースレッディングなしになりました。これはパフォーマンス側に多くの影響を与えます。それについて簡単なデモをお見せできます。 私がやろうとしているのは C7I、つまり第 7 世代の Intel ベースのインスタンスに接続することです。/proc/cpuinfo で何があるかを見ると、 これは C7I large なので、2 つの vCPU を公開しています。
これらの vCPU は実は同じ物理コアのスレッドです。OpenSSL speed テストを実行してみます。 次に、Graviton ベースのインスタンスでまったく同じことをやります。 こちらも同じサイズなので、やはり large インスタンスですが、今回は 2 つの vCPU があり、それぞれの vCPU が物理コアです。
そこから一定レベルのパフォーマンスが得られます。 1 秒あたりの署名数という観点で見ると、大体 39,000 です。次に 2 番目のテストをやります。同じことをやりますが、今回は 2 つの実行スレッドで行います。OpenSSL は自分がやっていることを並列化する能力があるので、実は今 2 つのプロセスを使ってやっており、そこから何が得られるか見てみましょう。
1 秒あたりの署名数で見ると、42,000 でやや高いパフォーマンスが得られていますが、持っていたものを 2 倍にはなっていません。1 つの vCPU が 1 つの物理コアにマップされている Graviton 側で、まったく同じことをやると、 まず観察できることは、1 秒あたりの署名数という観点では、単一の実行スレッドでやや遅かったということです。2 つの実行スレッドでやると、 ほぼ 2 倍になっています。完全ではありませんが、ほぼです。
このテストを使って Graviton 4 が Intel より優れていると言いたいわけではないんです。ここで示したいのは、SMT があるかないかがパフォーマンスに影響を与えるということなんです。低い負荷レベルでアプリケーションをテストすると、2つの異なる設計が見えてきます。Intel は大きくて強力なコアを持っていて、低い利用率のレベルでは非常に優れたレイテンシーを提供する可能性があります。Graviton 側では、より小さいコアを持っていますが、数が多いので、1つの vCPU を1つの物理コアにマッピングすることができます。低い負荷レベルでは、私たちはそこまで高速ではないかもしれません。しかし、スケーリングはより高くなります。つまり、これらは2つの異なる設計であり、2つの異なるパフォーマンスプロファイルにつながるということです。
どちらを使うべきかと言っているわけではなく、それが重点ではないんです。他にもたくさんのメトリクスがありますし、Intel プロセッサーの方が高速な場合もあれば、Graviton プロセッサーの方が高速な場合もあります。ただ、これらのインスタンスのパフォーマンスを評価する際には、このことを念頭に置いておいてください。AMD プロセッサーについても同じことが言えます。AMD プロセッサーは少し異なります。AMD は非常に高いコア数のプロセッサーを持っていたので、generation 7 から non-SMT として公開することにしました。vCPU あたりのコストは高くなりますが、十分に並列化されていて、十分に負荷をかけて実行すれば、得られるパフォーマンスは非常に優れたものになります。
このデモにおいて、それが重要なポイントだと思います。これは並列化されていたんですよね？つまり、アプリケーションが並列化できなければ、これを活用することはできないんです。先ほどの Arthur のポイントに戻ると、アプリケーションがより大きな、より大きなコアを持つことの利点を活用できるかどうかが重要な区別であれば、それは重要です。 はい、ですから、例えば hyperthreading に関するこの情報、そしておそらく CPU 命令やその他のことについても、確認すれば、ここにいる他の皆さんにも役に立つと思います。私の質問は、hyperthreading に関するこの情報、そしておそらく CPU 命令やその他のことについても、ええ、おそらくインターネットで見つけることができます。おそらく AWS からのブログポストがあるでしょう。それは API で公開されていますか？それは API で公開されていませんが、プロセッサーが教えてくれます。しかし、その場合、インスタンスを起動して確認する必要があります。はい、API が公開していないものがたくさんあります。
API は、どのインスタンスでも得られる L1、L2、L3 キャッシュの量を公開していません。API は NUMA トポロジーを公開していません。API はメモリレイテンシーや理論的なメモリ帯域幅を提供していません。API が提供していないプロセッサーの特性がたくさんあります。
各プロセッサーには、命令セットのオプションがあります。Intel プロセッサーの一部の世代には、57ビットの仮想アドレス空間を公開する機能がありますが、すべてではありません。それは EC2 API には含まれていません。EC2 インスタンスを起動すれば、オペレーティングシステムがその特定の機能を検出できたかどうかを確認できます。しかし、プロセッサーには、API で現実的に公開できるものよりもはるかに多くのものがあります。
例えば、EKS クラスタがかなりたくさんあるような場合、ひとつの使用例として考えられます。自分たちのカタログを作成して、自分たちが気にかけている命令セットを正確に把握するための作業をすることができます。それらの命令セットをラベルとして公開するノードプールを作成すれば、特定のワークロードを特定のプロセッサセットにスケジュールすることができます。これはプロセッサファミリーごとに無期限にやるようなものではありません。覚えておいてください、C8M8 や R8 であれば、それらの中には同じプロセッサが入っています。そこまで複雑ではないのですが、910 の場合は作業が必要になります。リフレッシュするときは、絶対に必要です。これは新しいものを立ち上げるたびに当てはまります。常に進める前にテストしてください。
ご質問の趣旨は理解しています。どの深さまで対応したいかという問題があります。これまでのところ、周波数と CPU タイプの公開に限定することを選択してきました。インスタンスを起動すれば、オペレーティングシステムに公開されているため、すべての情報を取得できますが、API として利用可能にはしていません。それをドキュメンテーションの一部にするかどうかについて、社内で議論があります。それがひとつの方法になる可能性があります。実際のところ、私たちのチームはそのドキュメンテーションを自分たちで持っています。有用だと思っているからです。ですから、はい、それを公開することはできます。
あなたのデモンストレーションで、OpenSSL のベンチマークを行い、第 7 世代と第 8 世代の Graviton を比較していました。それは意図的なものでした。第 7 世代の Graviton を試してみたら、おそらく大幅に負けていたと思います。2 vCPU については、そうではありません。1 vCPU はさらに遅くなりますが、2 vCPU については、いいえ、それでも Graviton 3 で勝つでしょう。
昔、ロードバランサーを Graviton に移行しようとしたことがあります。しかし、それは別の問題でした。どの命令セットについて話すつもりなのか、私は知っています。SSL ロードバランサーで見たことがあるかもしれない問題は、Graviton 2 の問題でした。Graviton 2 では、予想していなかった結果をもたらすような間違いを犯してしまいました。RSA が Graviton 2 では Intel ベースのインスタンスと比べてそこまで遅くなるとは予想していませんでした。
その理由は、RSA が 64 ビット整数乗算を大量に使用するためです。Graviton 2 コアには単一の 64 ビット整数乗算器がありました。SSL または TLS 接続を実行するとき、セッション確立時に、Graviton 2 は Intel ベースのインスタンスと比べてはるかに遅かったのです。SSL セッションの AES 部分は、Graviton 2 では Intel ベースのインスタンスと比べてはるかに高速でした。長い接続があれば、何も見えず、Graviton は素晴らしいパフォーマンスを発揮していました。短い接続、例えば IoT デバイスの束のためのゲートウェイ、または観測可能性システムのためのゲートウェイで、メトリクスを送信するたびに SSL 接続を再確立するような場合、Graviton 2 はひどいものでした。
Graviton 3 ではこの問題を、コアに乗算ユニットを 1 つ追加することで解決しました。これにより Graviton 3 は大幅に高速化しました。また、これを部分的に解決しました。
Graviton 2 ではこの問題を部分的に軽減するために、Graviton 2 向けに RSA を最適化しました。AWS の暗号ライブラリである AWSLC 内では、Graviton 2 上で非常に高速な RSA 実装を持っています。ですからこの問題はもう存在しなくなり、Graviton 4 は暗号処理で素晴らしいパフォーマンスを発揮しています。このギャップは埋まりましたが、Graviton 2 の初期段階では確実に存在していました。
メモリトポロジーの不均一性：CCXとマルチソケット構成の落とし穴
メモリトポロジーについて 5 分ほど話す時間があります。地球は平らではありませんし、これは AWS のいくつかのインスタンスで非常に顕著に見られます。C7A プロセッサのメモリトポロジーは、CCX、つまり Compute Core Complex と呼ばれる 8 つのコアのグループで構成されています。これら 8 つのコアは L3 キャッシュのスライスとメモリダイへの接続を共有しています。
その世代の AMD ベースのインスタンスで実行すると、アプリケーションはフラットなトポロジーを見ることはありません。最初のブロック上で実行されるアプリケーションスレッドがあり、メモリ内の何かにアクセスする場合、メモリのその部分はキャッシュ内でウォームな状態に保たれます。次の CCX から同じメモリ部分にアクセスしようとすると、その情報はキャッシュに入っていません。
2 XL インスタンス（単一スライスになります）から 4 XL インスタンスに移行した顧客のケースを見たことがあります。今では 2 つのスライスにまたがっており、2 つのメモリドメイン間にまたがっているため、アプリケーションが遅くなるのを目撃しています。一方のドメインからメモリにアクセスしようとしていて、そこのデータが他方のドメインからのウォームアップで既に存在していた場合、キャッシュミスが発生し、まずキャッシュを補充する必要があり、それは彼らが期待していたほど高速ではありませんでした。
24 XL インスタンスでは、このような不均一性があります。48 XL では、2 番目のソケットがあるため、別のレベルの不均一性が生じます。そして、最初のソケット上のコアと、これら 2 つのソケットに関連付けられたメモリの間の距離がさらに大きくなります。AWS にデプロイするときは、これに注意してください。私たちのインスタンスの最大サイズは、通常 2 つのソケットです。
例えば、24 から 48 へと同じ世代のインスタンスで移行する場合、必ずしも高速化されないケースがあります。より多くのコアとより多くのメモリが得られますが、アプリケーションがメモリがもはやフラットで均一ではないという事実を考慮していない場合、予期しない問題が発生する可能性があります。数週間前に、データベースを 24 XL から 48 XL に移行した顧客がいたのですが、メモリが 2 つのソケットに分散されたため、データベースの P50 レイテンシが 2 倍になってしまいました。
より多くのメモリとより多くの vCPU を持っていたのに、データベースは平均的に遅くなってしまいました。リクエストによっては同じ速度のものもありました。全体的なスループットは高くなりましたが、レイテンシは確実に高くなりました。これは Kubernetes でも問題になる可能性があります。以前、誰かがそれについて話していたからです。コンテナが異なるドメイン、異なるソケットにランディングした場合、それらの間の接続性は予想より遅くなります。
Kubernetes には NUMA 対応になるという新しい機能が登場しており、それは確認する価値があります。これは非常に重要になる可能性があります。これらは、大きな違いを生み始める低レベルの違いの一部です。私の推奨事項は、正確に何をしているかを知らない限り、Kubernetes クラスター上の 2 ソケットサイズを避けることです。正確に何をしているのであれば、それを実行してください。しかし、そうでなければ単一ソケットのままにしてください。
セッション終了とまとめ
API では公開していませんが、複数のソケットがあっても、マルチソケットホスト上にランディングしているが小さなオンデマンドインスタンスを持っている場合、単一の複雑なサイズに保つというアドバイスはそれほど強く適用されません。2 つの CCX 間のレイテンシとメモリ帯域幅の違いは、2 つのソケット間の違いと比べてはるかに低いです。皆さん、ありがとうございました。時間が終わってしまいました。アンケートに記入してください。質問をしなかったのにステッカーが欲しい方は、私のところに来てください。喜んで配ります。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion