AMD EPYC または Intel Xeon：ウェブホスティングに適したプラットフォームの選び方

CPU比較を行う前のホスティングプロファイル

ウェブホスティングは、画一的なCPUワークロードではありません。数千もの小規模なアカウントを扱うプラットフォームは、仮想マシン用のノードやデータベースサーバーとは異なるルールに従います。 したがって、AMD EPYCとIntel Xeonを比較する前に、クエリプロファイル、同時にアクティブなクライアント数、RAM要件、ストレージI/O、および許容される応答時間を明確にしておく必要があります。これらの要素が組み合わさって初めて、CPUの技術仕様は調達において意味のあるものとなるのです。.

シェアードホスティング 互いに独立した多数のPHP、CMS、およびメール関連のタスクを処理し、その多くは短時間の負荷ピークを伴います。コア密度が高いことは有効ですが、CPU時間、プロセス数、メモリ、I/Oに対する効果的な制限も同様に重要です。 こうした制限がなければ、単一のアカウントが限られたリソースを占有し、他の顧客の応答時間を悪化させる可能性があります。この点において、計画的なテナント分離は、合成マルチコアテストにおけるピーク値よりも重要となる場合がしばしばあります。.

マネージドCMSやオンラインショップの場合、要件はより多様です。動的なPHPリクエスト、オブジェクトキャッシュ、データベースクエリ、cronジョブ、管理アクセスなどが、時折同時に発生することがあります。要求の厳しいアプリケーションが少数である場合には、 コアあたりの性能 最大コア数よりも重要になる場合もあるが、一方、多数の独立したPHP-FPMワーカーが恒常的に稼働している場合は、並行処理の重要度が高まる。決定的なのは、Webサーバー、PHPプロセス、およびデータベースが適切に規模設定されているかどうかである。.

WooCommerceのショップを例に挙げると、この区別が明確になります。静的な商品画像は、キャッシュを備えたWebサーバーによって非常に効率的に配信できます。しかし、ショッピングカート、チェックアウト、在庫管理では、パーソナライズされたPHPの実行やデータベースへのアクセスが発生します。 クエリにインデックスが不足していたり、バッファプールが小さすぎたり、負荷がかかった際にNVMeのレイテンシが上昇したりする場合、CPUコアを増やしても待ち時間は解消されません。そのため、リクエストのレイテンシ、データベース処理時間、I/O待ち時間を個別に計測する必要があります。.

VPSやクラウドノードには、演算能力に加え、何よりも十分なRAM、ストレージ帯域幅、ネットワーク、そして透明性のあるリソース配分が必要です。CPUピンニング、予約メモリ、NUMA割り当て、ストレージQoSは、メーカーのロゴよりもゲストの体験に大きな影響を与えます。 データベース、Redis、およびストレージに密接に関連するシステムでは、さらにワーキングセット、キャッシュサイズ、書き込み負荷、NVMe SSDへの直接接続も評価の対象となります。ここでは、バランスのとれた プラットフォームのトポロジー 多くの場合、単なるウェブサーバーのスループット値よりも重要である。.

EPYC 9005とXeon 6を比較対象として位置づける

本記事では、AMD EPYC 9005とIntel Xeon 6を、明確に区別されたプラットフォーム世代として意図的に比較しています。 この比較は、これら2つの製品ファミリーをベースとしたシステムの調達、拡張、または評価を目的としています。コア構成、メモリプラットフォーム、I/O仕様、および利用可能な機能が異なる可能性があるため、他の世代や製品ラインに関する結論をこの比較から導き出すことはできません。.

また、文書化されたプロセッサ機能は、実際に 入手可能なサーバーシステム 区別する必要があります。マザーボード、ファームウェア、DIMM構成、冷却システム、電源ユニット、およびOEM認証によって、実際にどの構成が利用可能かが決まります。 したがって、具体的なSKUごとに、どのサーバーモデルが入手可能であり、計画されている構成に対して検証済みであるかを確認してください。これは、大容量のRAM、多数のNVMeドライブ、および特殊な仮想化機能の場合に特に当てはまります。.

旧世代のEPYC 700xシリーズや、それ以前のXeon Scalableモデルを、EPYC 9005やXeon 6と混同してはいけません。 同様に、他の製品ラインのデータをこれらのファミリーに当てはめることも避けるべきです。コア構成、I/O仕様、メモリプラットフォーム、および利用可能な機能は、世代によって異なる場合があります。したがって、調達比較を行う際には、常に完全なモデル名、ソケット数、および使用されるサーバーマザーボードを明記する必要があります。.

EPYC 9005シリーズには、モデルに応じて以下のプロセッサが含まれます。 Zen 5– あるいはZen-5cコア。これらの名称は、ホスティングにおける一律的な順位を示すものではありません。むしろ、具体的なSKU、コア数、クロック特性、熱設計要件、および計画されている並列処理能力の方が重要となります。 コア数の多いモデルは、適切に隔離された多数のテナントに適している一方で、異なる位置付けのモデルは、少数の計算負荷の高いアプリケーションに適している場合があります。.

インテルは、Xeon 6をP-CoreとE-Coreの2つのバリエーションに分けています。P-Coreはコアあたりの高性能を重視しており、AVX-512やAMXなどをサポートしています。 これは、使用しているソフトウェアが実際にこれらのベクトルや行列演算機能を活用している場合に重要となる可能性があります。一般的なPHPやWebサーバーのスタックでは、これによって自動的にメリットが得られるわけではありません。一方、E-Coreは、高いコア密度と並列スループットを重視しています。.

したがって、高密度で断熱性に優れた共有ワークロードやクラウドワークロードの場合、Xeon 6 E-Coreは基本的に有力な選択肢となり得ます。 また、単一コアの性能がより求められるワークロードにおいては、Xeon 6 Pコアや、適切に構成されたEPYC 9005シリーズも有力な候補となります。 これは製品の方向性を示したものであり、性能を保証するものではありません。RAMの増設、ファームウェア、およびソフトウェアの設定は結果に大きな影響を与える可能性があり、プラットフォーム構成が同一でない場合、コアタイプの比較は正確な結果をもたらさない可能性があります。.

種は要因の一つに過ぎない

CPUコアはその真価を発揮するのは、メモリとI/Oがそれに追従できる場合に限られます。DDR5チャネルは、実装数やDIMMのタイプと相まって、利用可能なメモリ帯域幅を決定します。 一方、RAMの容量は、スワップアウトなしで動作させることができるVM、データベースバッファ、またはキャッシュの数を制限します。PCIeレーンは、NVMeドライブ、ネットワークカード、および必要に応じてアクセラレータを接続します。ホスティングにおいては、この一連の要素をシステム全体として計画する必要があります。.

AMDは、EPYC 9005について、最大12チャネルのDDR5および、ソケット数やプラットフォームに応じて豊富なPCIe Gen 5接続を仕様として明記している。シングルソケットシステムでは、最大128レーンのPCIe Gen 5が記載されている。 Intel Xeon 6もシリーズによっては最大12のDDR5チャネルを提供しており、特定のシングルソケットP-Core構成では最大136のPCIeレーンを実現します。これらの数値はモデルおよびプラットフォームに関するデータであり、アプリケーションのパフォーマンスを保証するものではありません。.

複数のNVMe SSD、2枚の高速ネットワークカード、そして多数のVMを搭載したVPSノードは、実用上の違いを如実に示しています。ドライブやNICがPCIeスイッチを介して接続されている場合、それらはアップリンクを共有する可能性があります。 また、レーン割り当て、スロット、分岐、CXLのサポート、および実際に有効化されているファームウェア設定も、マザーボードによって決定されます。そのため、文書化されたCPU容量は、ブロック図および当該サーバーの検証結果と照合する必要があります。.

また、複数のNUMAノードを持つシステムでは、RAM、仮想CPU、およびI/Oデバイスがどこに割り当てられているかも極めて重要です。VMやデータベースが他のノードのメモリに頻繁にアクセスする場合、追加のレイテンシが発生する可能性があります。 したがって、現実的な負荷条件下での測定が有効です。CPU使用率だけでは、メモリのボトルネックや、ストレージやネットワーク上の待ち行列は明らかになりません。.

多数のレーンは、多くのデバイスを直接接続することを容易にしますが、データベースの低レイテンシや高いトランザクションレートを保証するものではありません。コントローラ、SSDファームウェア、RAIDやレプリケーションの設計、キューの深さ、ネットワークパスが依然として決定的な要因となります。以下の選択肢のうち AMD EPYC ホスティング また、Intel Xeonサーバーについては、コア数やクロック周波数と同様に、I/Oおよびメモリの要件についても具体的に把握しておく必要があります。.

プラットフォームとワークロードを同期する

選択の基準はメーカーではなく、負荷の分散から始まります。E-コアを搭載したXeon 6は、基本的に互いに独立し、明確に区切られた多数のタスクに適しています。一方、P-コアを搭載したXeon 6は、次のような要件に対して適しています。 コアあたりの性能 および特定のベクトル演算や行列演算。EPYC 9005もまた、さまざまなコア構成やクロックプロファイルに対応しています。したがって、これに基づいて順位をつけることはできません。重要なのは、具体的なSKU、サーバーのトポロジー、および測定されたアプリケーション負荷です。.

共有ホスティングにおいて、高いコア密度は、CPU時間、プロセス数、メモリ、I/Oに関する制限が隣接するアカウントを実際に保護する場合にのみ有用です。したがって、E-Coreモデルは、高度に並列化されたテナント環境に適している可能性があります。 適切なコア構成を持つEPYC 9005モデルも同様に適している可能性があります。一方、負荷の高い単一のECサイトやCMSインスタンスの場合、利用可能なコア数の多さよりも、ワーカーごとの応答時間やデータベースのパフォーマンスの方が重要です。.

VPSノードおよびストレージ関連サービスでは、さらに以下の検証が必要となります。 I/Oトポロジー. EPYC 9005は、プラットフォームに応じて豊富なDDR5およびPCIe 5.0リソースを備えています。Xeon 6もまた、シリーズやモデルに応じてメモリチャネルやPCIeレーンを提供しています。 これらの情報は事前選定の参考にはなりますが、特定のNVMeレイテンシやデータベーススループットを保証するものではありません。マザーボード、搭載構成、ファームウェア、ソフトウェアの選択も、決定の重要な要素となります。.

ホスティング向けのCPUベンチマークを適切に計画する

検索キーワード CPUベンチマーク ホスティング 不適切な単純化を招く恐れがある：CPUの測定結果は、ホスティングサービスを説明するものではない。 SPECは結果を完全なシステムとしての成果とみなしており、重要な構成詳細の開示を求めています。したがって、プラットフォーム間の比較を行うには、両方の対象システムについて、ソケット数、メモリ構成、ストレージ、ネットワーク、およびソフトウェアが同等の状態でテストを行う必要があります。.

PHP-FPM の場合、リクエストのスループットが高いだけでは不十分です。プラットフォームは、短時間の合成負荷下では多くのレスポンスを返せる一方で、並行して実行される cron ジョブや低速なデータベースクエリによって、高い p99 値を記録してしまうことがあります。 そのため、動的なページとキャッシュされたページについて、キュー、エラー率、応答時間を個別に計測する必要があります。バージョン管理されたデプロイを行うことで、テスト済みのアプリケーションと設定を明確に記録することができます。. ホスティングにおけるGitワークフロー

データベースの場合、レコードサイズとキャッシュの状態を文書化しておく必要があります。これは、RAM内に完全に収まるテストと、I/O負荷の高い運用では、異なる限界値が示されるためです。 VPSの密度が高い場合、ゲスト環境での経験も重要となる。どのスケジューリング指標が有意義かは、ハイパーバイザーとゲストOSによって異なるため、CPUレディ時間は普遍的に適用可能な測定指標として扱ってはならない。負荷テストを繰り返し実施し、測定方法および偏差を明確に記録しておくこと。.

構成とトポロジーの確認

比較を行う前に、まず現状を把握しておく必要があります。そうすることで、一見CPUの違いのように見えるものが、実際にはNUMAの割り当ての違い、メモリの差異、あるいはWebサーバーの設定変更に起因している可能性を排除できます。 以下のコマンドは情報を読み取ったり設定を確認したりするものであり、CPUのピンニングやサービス設定を変更することはありません。各システムで必要な権限を持って実行し、出力結果は安全に保管してください。.

と一緒に lscpu CPUモデル、論理CPU、ソケット、コア、および検出されたNUMAノードを記録します。. numactl --hardware このツールがインストールされている場合、NUMAノードごとの利用可能なCPUとメモリが追加表示されます。どちらの出力も、認識されたハードウェアトポロジーを示しており、ホスティング負荷下での実際の使用状況を示すものではありません。.

lscpu
numactl --hardware
nginx -T
php-fpm -tt

呼びかけ nginx -T 有効な NGINX の設定を出力するため、内部ホスト名、ファイルパス、または証明書への参照が含まれている可能性があります。出力を転送する前に、こうした情報を確認し、必要に応じて修正してください。. php-fpm -tt これは設定チェックの一例です。バイナリ名やオプションは、ディストリビューションやPHPのバージョンによって異なります。本番環境の設定を変更する前に、まずローカルで利用可能なバージョンを確認してください。.

VPSの実例が、その目的を明らかにしています。VMのvCPUがNUMAノードのコアに固定されているにもかかわらず、そのVMに割り当てられたRAMの大部分が別のノードにある場合、メモリアクセスに余分なレイテンシが生じる可能性があります。したがって、以下を文書化してください。 CPUピン止め およびRAMの割り当てを統一する。その後に初めて、別のCPUプラットフォームが必要か、あるいはまずはより一貫性のあるゲストトポロジーが必要かを判断できる。.

仮想化を安全かつ計画的に運用する

VPSやクラウドサービスにおいて、体感されるパフォーマンスはプロセッサ名だけで決まるわけではありません。. CPUピン止め 必要に応じてvCPUを指定された物理コアに割り当てることで、実行時間の変動を抑制できます。ただし、これはキャパシティに関する判断となります。排他的に予約されたコアは、他の顧客への柔軟な割り当てには利用できません。 したがって、計算能力が保証された料金プランの場合、この予備分は稼働率計画に組み込む必要があります。.

同様に重要なのは、 NUMAアフィニティ マルチソケットまたは高コア数のシステムにおいて。VMは、可能な限り同じNUMAノード内のプロセッサコアとメモリを利用すべきです。他のノードのメモリに頻繁にアクセスする場合、追加のアクセス経路によってレイテンシが増加する可能性があります。 したがって、大規模なVMを計画する際は、単にすべてのコア数とメモリ総量の合計を見るのではなく、まずはローカルRAMの容量とコアの割り当てを考慮するようにしてください。.

RAMの予約により、約束されたメモリ容量が単なる楽観的なオーバーブッキングに起因することを防ぎます。さらに、 ストレージQoS VMごとのIOPS、スループット、またはキューを設定し、バックアップ、データベースのインポート、あるいは設定ミスのあるゲストが、共有NVMeプールをブロックしないようにする。 CPU、RAM、ストレージごとにオーバーブッキングの制限を個別に設定してください。適切なCPUクォータを設定しても、ストレージがピーク負荷時にすでに高い待ち時間を発生させている場合、ノードの耐負荷性は低下します。.

機密性の高い仮想マシンについては、両プラットフォームとも、通常の仮想化を超える機能を提供しています。AMDはEPYC 9005において、SEV、SEV-ES、およびSEV-SNPについて文書化しています。SEV-SNPは、特定のページテーブル攻撃やメモリマッピング攻撃に対する保護メカニズムを補完するものです。 Intelは、TDXを、ゲストOSおよびVMアプリケーションを、クラウドホスト、ハイパーバイザー、およびプラットフォーム上の他のVMから隔離する技術として説明しています。.

こうした機能があるからといって、AMD EPYC サーバーや Intel Xeon サーバーのセキュリティが自動的に向上するわけではありません。Intel TDX については、対応プロセッサ、適切な DIMM の構成、および具体的な OEM または ODM プラットフォームを確認する必要があります。 文書化されたDIMMの仕様は、プラットフォームの実装によって異なる場合があります。さらに、これらの機能を利用するには、ファームウェア、ハイパーバイザー、カーネル、ゲストOS、および運用プロセスの連携が適切に調整されている必要があります。 また、鍵のライフサイクル、認証、復元、および監視についても確認してください。これらのプロセスがなければ、有効化されたハードウェア機能だけでは、顧客のセキュリティ要件を完全に満たすことはできません。.

比較および運用におけるエラーの原因

信頼性の高い比較を行うには、まずシステム規模を同じにすることが不可欠です。調達対象がプラットフォームクラスに関わる場合、2ソケットのサーバーを1ソケットのシステムと比較してはなりません。 テストごとに、CPUモデル、ソケット数、アクティブなコア数、RAM容量、およびDIMMの構成を記録してください。そうして初めて、結果がアーキテクチャ、追加ハードウェア、あるいは異なる構成のいずれに起因するかが明らかになります。.

また、メモリやI/Oの構成が異なると、結論が歪められてしまいます。DDR5のチャネル割り当て、NVMeの世代、RAID構成、ネットワークカード、あるいはBIOSの電源プロファイルが異なると、スループットやレイテンシに大きな影響が生じます。 AMDはEPYC 9005について、具体的なI/O構成はプラットフォームやマザーボードに依存するため、文書化されたインターフェース容量はアプリケーションにおける性能を保証するものではないと指摘しています。.

PCIeレーン数が多いと、複数のNVMeドライブや高速ネットワークカードを直接接続しやすくなります。しかし、それだけではデータベースのレイテンシを低くできるとは限りません。ストレージ内のキュー、コントローラーのファームウェア、レプリケーション、データベースパラメータ、そしてRAM内のワークセットが依然として重要な要素となります。 ストレージに近いアーキテクチャについては、本記事で補足しています。 IoTプラットフォーム向けウェブホスティング ネットワーク遅延、セグメンテーション、およびストレージパスに関する観点。.

単発のブーストクロックも、ホスティングのベンチマークとはなりません。AMDは、最大ブーストを「通常のサーバー環境下で単一のコアが到達し得る周波数」と定義していますが、並列の持続負荷下では、熱的およびエネルギー的な条件が異なります。 したがって、単一のクロック値からノード全体の性能を推測するのではなく、代表的な同時アクセス状況下での応答時間のパーセンタイル値やスループットを測定すべきです。.

結局のところ、TDPはサーバーの実際の消費電力を測定するものではありません。コストの試算を行うには、選択したRAM、ストレージ、ネットワーク負荷、および電力プロファイルを含むシステム全体の測定値が必要です。その 比較可能性 公開結果には、システムの完全な仕様の記載も求められます。SPECは、結果を個々のプロセッサのものではなく、システム全体の結果として明確に扱っています。.

測定可能な要件に基づいて調達を決定する

まず、負荷プロファイルを記録します。クライアントの数と規模、典型的な同時接続数と最大同時接続数、PHPおよびアプリケーションの割合、データベースクエリ、キャッシュヒット率、インスタンスごとのRAM容量、ならびにI/Oおよびネットワークのピーク値などです。これにより、抽象的なランキングではなく、要件カタログが作成されます。 これによって初めて、高いコア密度、個々のワーカーの短い応答時間、あるいは特に大規模なストレージ接続のどれが決定的な要因となるかが明らかになります。.

次に、既存のプラットフォームを拡張するか、中古または在庫のシステムを評価するか、あるいは完全に新しいサーバー構成を調達するかを決定します。EPYC 9005およびXeon 6については、具体的なサーバーモデルについて、入手可能性、OEM承認、ファームウェアのメンテナンス、および交換部品の計画を確認する必要があります。 CPUファミリーの名称だけでは、希望するRAM、ストレージ、ネットワーク機器の供給状況や互換性の検証が保証されるわけではありません。.

その後、ソケット構成やサーバープラットフォームを含む具体的なSKUを比較してください。AMD EPYC 9005については、コアバリエーション、モデル、および計画されているDDR5およびPCIeの拡張性を確認する必要があります。 このファミリーにはZen 5およびZen 5cモデルが含まれていますが、それらの特性を一律に同一視してはなりません。Intel Xeon 6については、特にP-CoreとE-Coreのバリエーションを区別する必要があります。これは、コアあたりの性能とコア密度において、それぞれ異なる目標を追求しているためです。.

完全な部品表として構成を確認してください：検証済みのDIMM構成、NUMAノードごとのローカルRAM、NVMeドライブの数と接続方法、NIC、PCIeスイッチ、および冷却システムと電源ユニット。1 EPYC-9005 ホスティングノード 具体的に利用可能な構成が、要求されるコア数、メモリチャネル数、およびI/Oの組み合わせを提供している場合、それは当然のことです。これは、選択されたSKUおよびサーバープラットフォームの適合性を確認するものであり、Intel Xeonに対する一般的な性能上の優位性を示すものではありません。.

E-Coreを搭載したIntel Xeon 6サーバーは、規模が適切に制限された独立したワークロードが多い場合、妥当な選択肢となり得ます。P-Coreモデルは、個々のアプリケーションがコアあたりの高い性能を必要とする場合や、適切なベクトルおよび行列演算機能が重要となる場合に、より適しています。 インテルはXeon 6のP-CoreについてAVX-512およびAMXを挙げていますが、これらの機能が役立つかどうかは、使用するソフトウェアとその具体的な実装方法によって異なります。.

注文前に、自社のイメージ、設定、および実環境に近いデータ量を用いて、再現性のあるテストを実施してください。 1秒あたりのリクエスト数に加え、エラー率、応答時間のパーセンタイル、データベースの待ち時間、ストレージのレイテンシ、および並行バックアップや障害発生時の挙動についても記録してください。後の意思決定の根拠が明確になるよう、ハードウェアおよびソフトウェアに関する完全な情報が必要です。.

A 試験運用 これは、計画されているクライアント密度、新しいハイパーバイザー機能、慣れないNVMe設計、あるいはエネルギーコストがコスト計算に大きな影響を与える場合に有効です。その際は、明確なリソース制限を設けた、限定的かつ代表的な顧客グループまたはテストグループで運用を行ってください。 観測されたピーク負荷、容量の余裕、運用プロセスを把握して初めて、推計、調達、および展開について技術的な根拠を示すことができる。.