Intel Sierra Forest：並列サーバーワークロード向けのXeon-Eコア

Xeonファミリーに属するSierra Forest

Intel Sierra Forest は、Xeon 6 サーバー用プロセッサのコードネームであり、 高効率コア （E-コア）。調査対象となった製品リストには、64コアから144コアまでのモデルが含まれており、その中には6700Eシリーズのプロセッサも含まれている。インテルは、このモデルを、多数のタスクを並列処理できるクラウドやスケールアウト型アプリケーションなどを主な対象としている。

したがって、サーバー用CPUの選定において、コードネームは出発点にはなりますが、完全な仕様ではありません。同一シリーズ内のモデル間では、コア数、クロック周波数、熱設計などが異なります。どの組み合わせが適切かは、アプリケーションが同時に処理できる作業量や、各サーバーシステムの制約によって異なります。

一方、「Granite Rapids」は、パフォーマンスコア（P-Core）を搭載した別のXeon 6製品ラインを指します。これは、個々のコアの性能や特定の命令セット拡張機能が特に重要となる場合の比較対象となります。 ただし、P-CoreかE-Coreかという分類だけでは、具体的なアプリケーションにおける性能は判断できません。

Clearwater Forestは、次世代のE-CoreおよびXeon 6+として、Sierra Forestとは別物と見なすべきです。 Xeonファミリーにおける最大288個のE-Coreという数値は、Sierra Forestに対する一律の仕様ではありません。したがって、製品を比較する際は、他の世代の最大値を引き合いに出すのではなく、具体的なモデル名とその仕様を確認する必要があります。

並列処理のための多数のE-Core

Sierra Forestは、モジュラー型のマルチチップアーキテクチャを採用しています。演算用およびI/O用ダイが、プロセッサパッケージ内に共存しています。 演算ブロックは処理用のコアを提供し、I/O側を通じてプラットフォームへの接続が確立されます。アプリケーションにとって重要なのは、ブロックの数そのものではなく、その処理を利用可能なコアに分散できるかどうかという点です。

多数のコアがあれば、例えば、多数の独立したWebリクエストやバックグラウンドタスクを同時に処理することができます。その スループット これは、単位時間あたりの処理完了量、例えば1秒あたりの正常に処理されたリクエスト数を表します。この値が上昇しても、必ずしも個々のリクエストの処理速度が速くなっているとは限りません。

その点で重要なのがレイテンシです。これは、単一のリクエストや操作にかかる時間を指します。複数のサービスが同じデータベースや負荷の高いメモリを待っている場合、追加のCPUコアがさらなる処理を引き受けることはできても、それだけでは待ち時間を解消することはできません。 特に負荷のピーク時には、スループットだけでなく応答時間も考慮する必要があります。

時点では スケールアウト 作業は複数のインスタンスやサーバーに分散されます。十分な独立性が確保されており、共有リソースがボトルネックにならない限り、複数の小規模なサービスインスタンスを並行して実行することができます。一方、単一のシリアルなジョブは、未使用のコアが追加されたからといって自動的に高速化されるわけではなく、その一連のステップは互いに依存したままとなります。

プロセス境界やサーバーを越えた分散は、CPUの構成と同一視することはできません。これに関する補足記事は スウォーム・コンピューティングと分散型コラボレーション ここでは、分散システムに関する別の概念を取り上げる。Sierra Forest にとって重要なのは、具体的なソフトウェアが、既存のコアに対して並列実行可能なタスクを十分に生成できるかどうかである。

Eコア、Pコア、およびソフトウェアの互換性

Sierra ForestとXeon 6のP-Coreバージョンは、x86アーキテクチャに属しています。これにより、既存のソフトウェアの分類は基本的に容易になりますが、両方のプロセッサタイプがすべての拡張機能を同等にサポートするわけでも、同じアプリケーションで同じパフォーマンスを発揮するわけでもありません。 したがって、移行を行う際には、実行可能プログラムとその実際の要件の両方を確認する必要があります。

インテルは、Xeon 6 Eコアについて、とりわけ以下の点を挙げている。 AVX2 と VNNI. このような命令セットの拡張機能は、特定の計算をサポートすることができますが、アプリケーションがそれらを利用し、その恩恵を受けるかどうかは、そのコードやライブラリによって異なります。したがって、それらが存在するだけでは、サービスの達成可能なスループットについて何らかの結論を導き出すことはできません。

Xeon 6 では AVX-512 Intelによると、これはP-Coreプロセッサに限定されている。 あるプログラムがこの拡張機能を必須としている場合、Sierra Forest上で変更を加えずに実行することに対する直接的な互換性の障壁となります。AVX-512をオプションとしてのみ利用している場合は、別のコードパスで動作する可能性がありますが、そのパフォーマンスについては別途評価する必要があります。

したがって、プラットフォームを切り替える前には、メインアプリケーションだけでなく、その実行環境や計算負荷の高いライブラリについても、CPU要件を確認してください。 その際、すべてのx86パッケージがどのXeonバリエーションでも同じ機能を提供するという仮定よりも、メーカーのドキュメントや実際に使用されているソフトウェアのバージョンの方が重要です。

また、互換性チェックでは、ソフトウェアが動作するかどうかしか判断できません。 所定のレイテンシ目標において、E-Core構成が十分な処理能力を発揮するかどうかは、実際のアプリケーションや適切なサーバー構成との比較によって初めて明らかになります。そのため、高度にシリアルな処理やAVX-512を多用するタスクにおいては、P-Coreシステムが重要な比較基準となりますが、必ずしも最良の選択肢とは限りません。

モデル、ストレージ、接続端子を比較する

Sierra Forest では、コア数だけを見るよりもモデル番号の方が参考になります。例えば、6710E、6756E、6766E、6780E などが候補として挙げられます。 コア数やスレッド数だけでなく、ベースクロックやターボクロック、それぞれのパフォーマンスプロファイルも比較してください。コア数が同じであっても、サーバーがどれだけの熱的余裕を確保しなければならないかは一概には言えません。

Xeon 6780Eは144コア、144スレッドを搭載しています。Intelによると、基本クロックは2.2 GHz、ターボクロックは最大3.0 GHzで、330 WのTDPは指定されたサーバープロファイルに基づくものです。 最大ターボクロックは、すべてのコアおよびあらゆる動作状況において、継続的に保証される値ではありません。6766E、6710E、および6756Eについては、製品比較で選択する前に、クロックおよびプロファイルのデータを個別に確認することをお勧めします。

したがって、これら2つの144コアモデルの違いは、冷却システムや電源の設計にも影響を及ぼします。しかし、TDP値だけでは、実際の消費電力やアプリケーションの性能を推測することはできません。 重要なのは、所定の性能制限の範囲内で、実際の負荷下において、必要な処理をこなせるのがどちらのモデルかという点です。

6780Eについて、インテルは8つを挙げている 保存チャネル、最大DDR5-6400、最大88本のPCIe 5.0レーン、および2ソケットシステムに対応。 予定されているDIMM構成において、実際にどのメモリ速度がサポートされるかは、具体的なサーバーシステムの仕様および選択したメモリモジュールの認証情報に基づいて確認する必要があります。

ホスティングと仮想マシンの容量設定

実際に十分な数のリクエストが同時に処理される場合、多くの独立したWebインスタンスは高いコア数を活用できます。しかし、計画立案においては、インストールされているインスタンスの数だけでなく、所定の応答時間目標を達成するために同時に稼働しているサービスの数が重要となります。 サーバーは、空きCPU容量を表示していても、リクエストがメモリやストレージを待機している場合、目標を達成できないことがあります。

したがって、まずはアプリケーション、キャッシュ、OSの占有分を含めたインスタンスごとのメモリ容量を見積もってください。 その後、負荷のピークや、メンテナンス、あるいはホストの障害に備えた予備容量を考慮してください。計算能力よりも先にメモリ容量が不足してしまう場合、コア数を増やしただけでは、望ましい統合を実現することはできません。

ストレージI/Oも達成可能な密度に影響を与えます。多くのインスタンスが同時にデータの読み取り、書き込み、またはログ生成を行うと、キューが発生する可能性があります。そのため、現実的な同時実行状況下では、平均スループットだけでなく、処理に時間がかかるクエリについても確認する必要があります。 たとえば、p99目標とは、対象となるクエリの少なくとも99パーセントが満たすべき応答時間を指します。

仮想マシンでは、割り当てられた ブイシーピーユー まず、仮想実行ユニットであり、物理コアが自動的に予約されるわけではありません。複数のVMが同じリソースを共有する場合、利用可能な計算時間や応答時間は、それらのVMの同時アクティビティやハイパーバイザーの設定にも左右されます。したがって、個々のサービスの要件に基づいて、予約とオーバーブッキングを計画してください。

6780Eを搭載した2ソケットサーバーの場合は、さらに以下の NUMAトポロジー 確認事項：メモリへのアクセスは、メモリがどのソケットに接続されているか、およびVMがどこで実行されているかによって異なる場合があります。 ハイパーバイザー上のメモリ構成と配置を確認し、負荷がかかった状態でのローカルアクセスとリモートアクセスを比較してください。Intelの2ソケット対応は、選択したCPUに対する具体的なサーバーおよびハイパーバイザーの承認に代わるものではありません。

負荷プロファイルを実用的に比較する

測定計画は、具体的な決定から始まります。すなわち、既存のサーバーやP-Coreシステムと比較して、新しい構成では、同じサービス品質を維持しつつ、いくつのキュー・ワーカーまたはネットワークリクエストを処理できるか、ということです。 その際、両方の候補について、同じアプリケーション、データ量、および定義された同時実行数を設定してください。以下の手順は、当社独自の方法論的な推奨事項であり、Intelによる文書化されたテスト手順でも、実施されたテストの説明でもありません。

ワーカーについては、追加のコアを実際に稼働させられるよう、テストには十分な数の独立したタスクを含める必要があります。時間ごとの完了タスク数と完了までの時間を記録するとともに、データベース、ストレージ、または外部インターフェースが処理を制限していないかを確認してください。 単一のシリアルジョブだけでは、並列処理を前提としたプラットフォームを評価する唯一の根拠としては不適切です。

ネットワークサービスを独自に比較するため、パケットサイズ、暗号化、ネットワークカード、ドライバについても記録しておいてください。アプリケーションでアクセラレータを使用する場合は、具体的なCPUおよびサーバー構成での利用可能性、ならびに導入済みのソフトウェアによるサポート状況を確認してください。 その後、仕様書上の情報から推測するのではなく、同じ負荷条件下で実際に比較を行い、アクセラレータの使用がメリットをもたらすかどうかを確認してください。

あらかじめ～を置いておいてください p95またはp99のレイテンシ目標値 負荷を一定に保ち、理解しやすい段階ごとに負荷を上げていきます。その際、スループットとエラー率、およびレイテンシを測定してください。1秒あたりのリクエスト数が増えても、合意された応答時間目標を超過したり、エラーが増加したりする場合は、同等の成果とは言えません。予想される負荷のピーク時についても、同様の分析を繰り返してください。

の電気出力を測定する システム全体 アイドル時、部分負荷時、およびピーク負荷時。ハードウェア構成、ファームウェア、パフォーマンスプロファイル、ソフトウェアバージョン、および測定時間を記録し、差異が誤ってCPUのみに起因するものとして解釈されないようにする。 完了した作業量とそれに必要なエネルギーから、サービス品質が同じである限り、エネルギー単位あたりの作業量を比較することができます。

エネルギー需要とコストの把握

指定された TDP これはプロセッサの設計値であり、サーバー全体の測定値ではありません。Xeon 6780E について、インテルは指定されたサーバープロファイルにおいて TDP を 330 ワットと公表しています。これだけでは、特定の負荷における実際の消費電力や電気代を直接読み取ることはできません。

信頼性の高い比較を行うには、ストレージ、ドライブ、ネットワークカードを含むシステム全体の消費電力が重要となります。消費電力は負荷に応じて変化します。そのため、代表的な期間にわたって測定を行い、アイドル状態だけでなく、通常の負荷状態や高負荷状態も記録してください。単一のピーク値だけでは、動作状況を不完全な形でしか表せません。

仝 エネルギー単位あたりの仕事 例えば、これは「正常に完了したリクエスト数」を「測定されたエネルギー消費量」で割った値として表すことができます。その際、同じ要件を満たす作業のみを比較するようにしてください。エラー率や応答時間が合意された目標値を超えている場合、スループットが高くてもほとんど意味がありません。また、データ量や負荷の推移も比較可能なものでなければなりません。

採算性を確保するには、この比率だけでは不十分です。電力や冷却コストに加え、ラックスペース、ハードウェアの調達、保守、ソフトウェアライセンスの費用も合わせて計算する必要があります。特にコア数に依存するライセンスモデルの場合、コア数が多いとコスト計算が大きく変わってくる可能性があります。重要なのは、想定されるライセンス規則ではなく、具体的な契約条件です。

また、統合には移行に伴う負担も生じます。アプリケーションの検証、データの移行、運用手順の調整が必要となるからです。こうした一時的なコストや、発生しうるダウンタイムのリスクを、ランニングコストと比較検討してください。既存のサーバーの稼働を継続することは、その利用可能な容量と運用コストが計画期間を通じて十分である限り、依然として有力な選択肢となります。

動作状況、ファームウェア、およびボトルネックの確認

もし テールレイテンシ, まず発生時刻と影響を受けたリクエストチェーンを確認してください。同時に、エラー率、キューの長さ、または並列リクエスト数が増加していないかを確認してください。p99レイテンシが高いということは、最も処理に時間がかかるリクエストが所定の時間枠を超過する可能性があることを意味します。平均値だけでは、この問題が明らかにならない場合があります。

次に、CPU使用率と処理の分散状況を調査してください。全体的な使用率が低い場合でも、個々のスレッドでボトルネックが発生している可能性は排除できません。一方、多くのコアが稼働している場合は、独立したタスクが十分に存在しているか、あるいは同期処理や待機時間が追加のスループットを制限していないかを確認してください。

2ソケットシステムの場合、 保管場所 トラブルシューティングについて：プロセスや仮想マシンとそのメモリのNUMA割り当てを確認してください。Xeon 6780Eは2ソケットシステムに対応していますが、アプリケーションにとって具体的な配置が適切かどうかは、サーバーやハイパーバイザーの設定にも依存します。

原因が特定できない場合は、メモリおよびストレージのI/O、ネットワークパス、外部サービスを追跡してください。データベースの応答遅延やネットワーク接続の混雑は、サーバーのCPUが常にフル稼働しているわけではないにもかかわらず、クエリの実行時間を延長させる可能性があります。 コア数の多さを早合点して原因と決めつけるのではなく、測定値を遅延しているクエリの発生時刻と照らし合わせて分析してください。

導入および展開の前に、サーバーメーカーのCPU対応リスト、ソケット、必要なBIOSバージョン、およびハイパーバイザーによるサポートを確認してください。 Intelは、6700EシリーズにはLGA4710-2を、6900PにはLGA7529-1を採用していますが、これだけではXeonシリーズ間の包括的な互換性を推測することはできません。

さらに、使用しているプロセッサシリーズの仕様更新情報も参照してください。具体的なステッピングおよびファームウェアのバージョンに対して、関連するエラッタや説明を確認し、必要に応じて文書化された回避策を適用してください。これにより、システム全体の承認に、既知の技術的制約が追加されます。

適切なサーバープラットフォームの選択

選択は、データシート上の最大値ではなく、用途から始めるべきです。インテルは、Xeon 6シリーズのEコアを高コア密度とタスク並列処理によるスループットを重視したものと位置づけ、一方、Pコアはコアあたりの高性能を重視したものと位置づけています。しかし、どのプラットフォームがあなたのレイテンシ目標や処理能力の要件を満たすかは、まだ決まっていません。

この表を、以下のための出発点として活用してください。 同等のサービス品質における比較、パフォーマンスのランキングとしてではなく。以下の選定方法は当社独自の推奨事項であり、Intelによる公式なテスト手順ではありません。既存のプラットフォーム、適切なSierra Forest構成、および必要に応じてP-Coreシステムを、応答時間、エラー率、データ量に関する同じ要件で比較してください。 それぞれの構成を記録し、システム全体の有効な処理能力を算出してください。

また ARMベースのサーバー は、比較対象として考えられる選択肢の一つです。ただし、その場合は、オペレーティングシステム、アプリケーション、および必要なソフトウェアパッケージがアーキテクチャに適合している必要があります。さらに、移植や運用において変更が必要になる場合もあります。アーキテクチャの名称だけでは、一般的な効率上の利点は保証されず、同じ負荷条件下で検証する必要があります。

最終的には、必要な容量に十分な余裕を持たせ、適切な運用条件を備え、かつ総コストが最も低いプラットフォームを選択してください。その際、移行作業やライセンス費用も考慮に入れ、必要に応じてリスクや設置スペースも評価してください。 コア数の多さは選択基準の一つですが、アプリケーションのテストやコスト計算に代わるものではありません。