AMD EPYC Turin：ホスティング事業者向けの最適なサーバー用CPUの選び方

AMD EPYC Turinを正しく位置づける

AMD EPYC Turinとは、 EPYC 9005シリーズ サーバー用プロセッサ。AMDは2024年10月、これを第5世代EPYCとして発表した。このファミリーには、Zen 5およびZen 5cコアを搭載したモデルが含まれている。

ホスティング事業者にとって、Turinは、均一な性能特性を持つ単一のCPUというわけではありません。 モデルラインナップは、プロセッサあたり8コアから192コアまで多岐にわたります。どのモデルが適しているかは、多数の独立した顧客リクエストが並行して実行されるか、個々のアプリケーションに短い応答時間が求められるか、あるいは仮想マシンが主に大量のメモリを消費するかによって異なります。

選択肢の中には、次の質問も含まれています。 台数: プロセッサを1基搭載したサーバーは、2ソケットプラットフォームとは異なる計算能力、メモリ接続性、および拡張性の組み合わせを提供します。すべてのモデルが両方の構成に対応しているわけではありません。データシートによると、Pで終わるプロセッサはシングルソケットシステム向けに設計されています。

したがって、事前選定は、具体的な顧客構成や、RAM、NVMeドライブ、ネットワークに対する要件から始まります。 例えば、高負荷のVPSホストでは、同時に稼働する仮想マシンに対応するための余裕が必要ですが、データベースサーバーの場合は、ストレージ要件やI/Oへの対応も考慮する必要があります。また、ソフトウェアライセンスやサーバーメーカーの許容範囲も計画に含める必要があります。

コア数が増えただけでは、既存のホストのうちどれだけを置き換えられるかは分かりません。そのためには、プロバイダーが、既存のホスティング用ハードウェアの比較可能な負荷プロファイルや測定値、および定められた冗長性を把握している必要があります。こうした基礎データがなければ、モデルの選定は可能でも、信頼性の高い統合率を算出することはできません。

コア、チプレット、クロックの仕組みを理解する

トリノでは、 チップレット設計: 演算ユニットと独立したI/Oダイは、AMD Infinity Fabricを介して接続されています。I/Oダイは、とりわけメモリや入出力デバイスへの接続を提供します。実際のサーバー設計において、これはコア数だけでなく、共有リソースへの接続性も重要であることを意味します。

Zen 5とZen 5cは、設計とコア構成が異なります。Zen 5cは同世代の中で最高のコア密度を実現していますが、それによって一般的な性能順位が決まるわけではありません。高度に並列化されたVMミックスや、レイテンシが重要なタスクが少ないアプリケーションでは、モデルによって適性が異なる場合があります。

EPYC 9965は192個のZen 5cコアと384スレッドを搭載しているのに対し、EPYC 9755は128個のZen 5コアと256スレッドを搭載している。 AMDによると、9965の最大ブースト周波数は最大3.7 GHz、9755は最大4.1 GHzとなっています。これらの数値はそれぞれの特長を示していますが、実際の負荷プロファイルに基づく比較に代わるものではありません。

指定された 最大ブースト 特に、すべてのコアに対して一定のクロック周波数が保証されているわけではありません。負荷がかかった際にどの周波数に達するかは、負荷や動作条件などによって異なります。したがって、ホスティングサービスの選定にあたっては、単体のピーク値よりも、定義されたアプリケーション構成におけるスループットや応答時間の方が、より参考になります。

スレッド数がそれぞれ2倍になるのはSMTによるものです。1つの物理コアが2つの論理スレッドを提供します。ただし、これらはコアリソースを共有しています。384スレッドは、384個の物理コアでもなければ、演算能力が自動的に2倍になるわけでもありません。 SMTやCPUリソースのオーバーブッキングが有効かどうかは、同時にアクティブな顧客負荷に基づいて検証する必要があります。

ストレージとI/Oが容量を制限する

多くのCPUコアには、適切なメモリ構成が必要です。 AMDによると、EPYC 9005はCPUあたり最大12本のDDR5メモリチャネルに対応しています。VMホストにおいては、RAMの総容量だけでなく、モジュールの配置や利用可能なメモリ帯域幅も、同時に稼働しているゲストへのリソース供給能力に影響を与えます。

データシートによると、記載されているモデルについては、最大DDR5-6400で チャンネルあたり1つのDIMM。実際に利用可能な速度は、構成やプラットフォームの認証状況によって異なります。また、データシートに記載されている「最大6 TBのDDR5」という数値は、チャンネルあたり2枚のDIMMという同データシートに記載された構成に基づくものであり、すべてのサーバーで保証されるものではありません。

必要な容量を確保するためにRAMモジュールを増やすことは有効ですが、その場合、検証対象の構成が変わってしまいます。 そのため、ベンダーは、データシートに記載されている容量と速度の最大値を個別に足し合わせるのではなく、希望するモジュールサイズと構成をサーバーメーカーの承認リストと照合する必要があります。

また、NVMeドライブやネットワークカードについては、 PCIe接続 決定的な要素です。AMDは、シングルソケットシステムでは最大128本のPCIe 5.0レーン、デュアルソケットサーバーでは最大160本と述べています。 具体的なマザーボードが実際にいくつのポートを提供するかは、プラットフォームの設計や接続の用途によって異なります。2Pでの最大値が、1Pのホストに自動的に適用されるわけではありません。

そのため、構成の際には各要素の相互関係を確認しておくことが重要です。NVMeドライブの台数が増えると追加の接続ポートが必要になる一方、高速なネットワークカードも接続する必要があります。 CXL 2.0はプラットフォーム機能の一つですが、すべてのサーバーで自動的に利用できる機能というわけではありません。選択したシステムにおいて、ハードウェア、ファームウェア、およびOSによるサポートが確認される必要があります。

トリノのホスティングプランを比較する

EPYC 9005 ファミリーには、それぞれ異なる重点が置かれています。9965 はコア密度の最大化を重視しているのに対し、9575F はより高いクロック周波数を目指しています。 選択にあたっては、CPUそのものだけでなく、具体的なモデル、ソケット数、およびアプリケーションの負荷の組み合わせが重要となります。以下の表は、AMDのデータに基づいて4つのモデルを比較したものです。

9965は、独立したタスク用に特に多くの物理コアを提供します。メモリとI/Oが追いつく限り、高度に並列化されたVMミックスにおいてこれは有益となる可能性があります。 9755はコア数は少ないものの、最大ブーストクロックが高く、L3キャッシュの総容量も大きくなっています。これらのデータだけから、ホスティングアプリケーション向けの明確な順位付けを行うことはできません。

9575Fは、個々の処理ステップで短い応答時間が求められる場合に、検討すべき選択肢の一つです。その 最大ブースト ただし、これはすべてのコアに対して永続的に保証されたクロック周波数というわけではありません。コア数が多いモデルと比較して経済的かどうかは、同時処理されるリクエストの数やライセンスモデルなどによって異なります。

9655Pでは、これが制限要因となっている P接尾辞 シングルソケットシステムへのソケットの適合性。したがって、2ソケットサーバーには、このモデルは選択肢となりません。より広範なプラットフォーム比較を行うには、具体的な構成や測定結果を盛り込む必要があります。これについては、以下の記事で解説しています。 AMD EPYCとIntel Xeonのプラットフォーム選択 さらなる指針。

ホスティング・ワークロードとボトルネックの対応付け

サーバーのCPUは、同時に実行されているサービスに適したものでなければなりません。 共有ホスティングでは多くの独立したリクエストが発生し、仮想マシンではOS全体がリソースを競合し、データベースは負荷に応じてメモリアクセスやストレージのレイテンシに敏感に反応します。以下の概要では、これらの違いをシステム設計のための確認事項に落とし込んでいます。

共有ホスティングにおいては、同時にアクティブなワーカーの数が、個々のリクエストの処理時間と同様に重要です。スループットが良好であれば、CPU使用率が高いことは許容範囲内ですが、それだけでは顧客が長時間待たされているかどうかは判断できません。そのため、定義された負荷レベルにおける応答時間の分布やエラー率も比較対象に含める必要があります。

データベースの場合、 L3キャッシュ 全体像の一部に過ぎない。 9755の総メモリ容量は512 MB、9965は384 MBです。これらのモデル値だけでは、データベースの優位性を証明するものではありません。データセットのサイズ、アクセスパターン、作業の分散、およびRAM構成によって、他の記憶階層からのデータがどの程度の頻度で必要となるかが左右されるからです。

マネージドRedisサービスは、例えばキャッシュとしてアプリケーション構成を補完します。そのため、プロバイダーはCPUリソースに加え、特に利用可能なメモリ容量や具体的なサービスの要件を考慮する必要があります。この記事は Redis 8 とホスティングプロバイダーのアップグレードに関する判断 ここでは、保存容量の制限や、こうしたサービスの運用などについて扱っています。

モデルを公平に比較するためには、VMの構成、RAMの搭載量、ストレージ、および負荷レベルを可能な限り同等の条件に保つ必要があります。 そうしないと、応答時間やスループットの差異をCPUの選定に適切に結びつけることができません。また、個々のクエリ処理速度の向上と総スループットの向上は別個の目標であり、料金プランの策定においてそれぞれ異なる重み付けがされる可能性があります。

VM容量の計画例

計算上の例を挙げると、その規模が明らかになります。EPYC 9965を搭載したホストには、192個の物理コアと384のスレッドがあります。 そこに、それぞれ4つのvCPUを持つ48台のVMを設定すると、48 × 4 = 192のvCPUが割り当てられます。これは割り当ての計算であり、VMが達成可能なパフォーマンスの測定値ではありません。

A ブイシーピーユー これは、必ずしも排他的に予約された物理コアを意味するわけではありません。 ハイパーバイザーは、利用可能な論理プロセッサ上に仮想プロセッサをスケジューリングします。実際の実行は、どのVMが同時に動作しているか、およびそれらにどのリソースが割り当てられているかによって異なります。また、プロセッサの384スレッドも、384個の独立した物理コアに相当するわけではありません。

については オーバーブッキング まず、予想される同時負荷と、各料金プランが提供する性能を明確にしておく必要があります。割り当てられたvCPUの数が多いほど、負荷のピークが重なることが稀な場合には機能しますが、多くのゲストが同時に計算を行う場合、待ち時間が生じるリスクが高まります。 スレッド数だけを見るのではなく、実際の顧客構成に基づいてこの想定を検証してください。

次に、メモリ要件を別途計算します。VMに割り当てる予定のRAMを合計し、さらにハイパーバイザーの要件や運用上の予備分も考慮に入れます。CPUの計算だけでは、ホストが十分なRAMを提供しているかどうか、あるいは複数のゲストが同時に稼働している際に必要なメモリ帯域幅が確保されているかどうかは判断できません。

ストレージやネットワークについても同様です。多数の仮想マシンが同時にNVMeドライブにアクセスしたり、データを転送したりすることがありますが、その際には、総スループットだけでなく、I/Oレイテンシや負荷のピークも重要な要素となります。そのため、実際に使用するドライブやネットワークカードの接続構成と性能も計画に組み込んでおく必要があります。

最後に、メンテナンスや障害に備えて予備の容量が必要です。あるホストが障害を起こした後、残りのホストが追加のVMを受け入れる場合、通常の稼働状況で必要なリソースをすべて使い切っている状態ではいけません。 48台のVMを例に挙げたこのケースでは、安全な利用上限も統合率も定めていません。これらはいずれも、具体的な環境に基づいて検討する必要があります。

プラットフォームと仮想化の準備

プラットフォームの計画は、具体的なCPUモデルと、ソケットが1つ必要か2つ必要かを検討することから始めます。コア数、RAM、I/Oの要件は、希望するホストシステム全体として整合性が取れている必要があります。 EPYC 9655PのようなPモデルは、1ソケット向けに設計されているため、2ソケット構成には使用できません。

その後、以下の項目を確認してください。 メーカーの承認 CPU、マザーボード、BIOSについて。TurinはSP5ソケットを採用していますが、既存のSP5サーバーが、それだけの理由で9005シリーズの全モデルに対応するわけではありません。また、電源や冷却システムも、選択したCPUおよび使用する筐体に対応している必要があります。

RAMモジュールは、容量、チャネル構成、およびサーバーメーカーの仕様に基づいて計画してください。これに加え、必要なNVMeドライブやネットワークカードも考慮する必要があります。重要なのはその数だけでなく、具体的なシステムにおいてどのスロットやドライブベイが接続されているかという点でもあります。 これにより、注文前に、希望する構成が当該プラットフォームで実現可能かどうかを事前に確認することができます。

機密性の高い顧客のVMについては、 SEV-SNP VMメモリの保護に整合性メカニズムを追加する。TDISPを介したTrusted I/Oも、デバイスアクセスにおけるもう一つの構成要素となり得る。しかし、これが実用的なソリューションとなるかどうかは、ファームウェア、ハイパーバイザー、ゲストOS、および必要に応じてデバイスの組み合わせ次第である。

製品を採用する前に、ゲストのセットアップ、認証、管理の方法、および提供されるVM機能にどのような制限が適用されるかについても確認しておく必要があります。 CPU機能だけでは、スタック全体の互換性が保証されるわけでも、あらゆる攻撃から保護されるわけでもありません。したがって、実際にサポートされている構成を文書化し、アップデート時にはその構成を最新の状態に保つようにしてください。

稼働状況を測定し、ボトルネックを特定する

既存のホスティング用ハードウェアと比較するには、追跡可能な 負荷プロファイル：おおよそ同じVM構成、同程度のデータ量、および定義済みのクエリの種類。RAMの搭載容量、ストレージ、ネットワーク、およびソフトウェアの設定を記録しておいてください。そうして初めて、後で差異がCPUに起因するものか、それともシステム上の他の変更に起因するものかを区別できるようになります。

単一のピーク値だけでなく、複数の負荷レベルを調査してください。 その際、スループット、応答時間の分布、エラー率を測定してください。多くのリクエストの処理が遅くなったり失敗したりする状況では、スループットが高くてもホスティングサービスとしての価値は低くなります。各サービスにおいて、どの程度の応答時間とエラー率が許容範囲であるかを事前に明確にしておきましょう。

RAMの使用率やメモリの動作状況、およびストレージやネットワークのレイテンシや使用率を並行して監視してください。CPUにまだ余裕があるにもかかわらず応答時間が長くなっている場合、プラットフォームの別の部分がボトルネックとなっている可能性があります。逆に、CPUの使用率が高いという事実だけでは、顧客のユーザー体験が悪化しているとは限りません。

VMの応答時間に異常が見られる場合は、想定されている同時実行性と CPUのオーバーブッキング. その後、実際のRAM搭載状況、ファームウェアおよびハイパーバイザーの設定を、計画された構成と比較してください。原因を同時に変更されたワークロードと混同しないよう、可能な限り個々の要因をピンポイントで変更し、同じ負荷レベルを再度実行してください。

また、日常運用には、セキュリティ情報、ファームウェアのメンテナンス、アクセス制御、および検証可能なバックアップが含まれます。AMDはEPYCプロセッサについても、セキュリティ脆弱性に関する情報や対策情報を公開しています。運用担当者は、サーバーメーカーによる適切な更新をスケジュールに組み込む必要があります。 メンテナンス後は、保護機能や提供されているゲスト構成が想定どおりに利用可能かどうかを再度確認してください。

調達と経済性が決め手となる

調達に関する決定は、既存のプラットフォームが引き続き要件を満たしているかどうかという問いから始まります。容量と予備能力が十分であれば、その運用を継続することが合理的である可能性があります。 一方、Turinへのアップグレードを行うには、具体的なCPUモデル、ファームウェア、およびその他のコンポーネントがサーバーメーカーによって承認されている必要があります。共通のソケットであるSP5であるという事実だけでは、その証明としては不十分です。

比較する 1P-Host 2P構成において、コア数、RAM、およびポートの総需要に基づいて。 2つのソケットが必要となるのは、単に目標とするVM数が多いからという理由だけではありません。逆に、選択したサーバーで必要なメモリとI/Oの組み合わせを収容できない場合、1ソケットプラットフォームは選択肢から外れる可能性があります。

同時に実行される独立したタスクが多い場合、コア密度は重要な選定基準となり得ます。一方、レイテンシに敏感なアプリケーションでは、自社のアプリケーション構成において、より高いクロック周波数を持つモデルも検討する価値があります。 併せて、具体的なライセンスモデルも検討してください。コア単位、ソケット単位、あるいはVM単位のコストによって、プラットフォームの経済的な優先順位が変わる可能性があります。

仝 TDP これは、サーバー全体の消費電力を測定したものではありません。AMDはEPYC 9755および9965について、それぞれ500ワットのTDPを公表していますが、これだけでは、特定の負荷下での消費電力や年間のエネルギーコストは算出できません。 RAM、ストレージ、ネットワーク、冷却システムも、システム全体の評価には含まれる必要があります。

エネルギーおよびコストの比較を行う際は、代表的な負荷レベルにおけるシステム全体を評価し、必要な予備容量も考慮に入れてください。 購入費用、ソフトウェアライセンス料、および計画された利用期間にわたる運用コストを比較検討する必要があります。比較可能な既存データがなければ、具体的な節約額や信頼性の高い統合率を約束することはできません。