[SAP] Azure VM の SAPS 値 – 正しい参照先と混乱が生じやすい原因とは ?

  • Article

執筆者: Juergen Thomas (MSFT)

このポストは、2018 年 11 月 4 日に投稿された SAPS ratings on Azure VMs – where to look and where you can get confused の翻訳です。

 

SAP ソフトウェアを Azure に移行する場合、まずどのタイプの Azure VM を使用するかを決める必要があります。その際の主な基準の 1 つが、SAP ワークロードのスループット要件です。SAP では数十年前からスループットを示す値として「SAPS (SAP Application Performance Standard)」を使用しています。サーバーや Azure VM の SAPS を測定するには、サーバー メーカーやクラウド サービス プロバイダーが SAP SD Standard Application ベンチマークを実行する必要があります。100 SAPS は、1 時間に 2,000 件の受注項目を完全に処理できる能力として定義されています (https://www.sap.com/about/benchmark/measuring.html、英語)。

SAP NetWeaver および SAP HANA 向けの Azure VM として認定を受ける際、対象 VM のスループットとして、マイクロソフトは SAPS 値を提供します。SAP 側でさらにそのデータが使用され、SAP ノート #1928533 に Azure の SAPS 値が記載されます。この SAP ノートは公式の情報で、SAP NetWeaver 認定 VM の SAPS を確認できるようになっています。そこには SAP NetWeaver ワークロードを実行する性能が認められた各 Azure VM の vCPU 数、メモリ、SAPS が記載されています。

では、混乱しやすい箇所というのは、どこにあるのでしょうか?

まず混乱が生じる原因は、Azure のようなハイパースケール クラウドについて、SAP が公式の SAP SD Standard Application ベンチマークをドキュメント化する際の手法にあります。Azure VM に関する SAP SD ベンチマークの一覧はこちらのリンク (英語) からご確認いただけます (なお、マイクロソフトは Azure VM の認定に関してベンチマークを公開することが義務付けられているわけではありません。結果として、認定 Azure VM によってはベンチマークがこのページで公開されているないこともあります。)。ベンチマークの 1 つをクリックすると、次のようにデータが表示されます。

image

混乱はここから始まります。このデータのどこにも、テスト対象の VM で定義されている vCPU 数とメモリは記載されていません。代わりに、VM が実行されているホストのテクニカル データが記されています。CPU とコアの数についても、このデータにはホストの実際の構成が反映されていません。ここに示されているのは、Intel ハイパースレッディングがホストで構成されている場合の理論容量です。上の図の場合、M128s VM の vCPU 数やメモリ容量は、公式の SAP ベンチマーク Web ページでは突き止めることができません。情報を得るには、Azure の価格ページか SAP ノート #1928533 をチェックする必要があります。つまり、公式の SAP ベンチマーク Web ページに表示されているデータは、SAP のサイジング目的で特定の Azure VM の SAPS を調べる場合、混乱の原因となるのです。VM の SAPS 値は表示されていますが (SAP ノート #1928533 でも確認可能)、一緒に記されているのは、SAPS の要件に応じて Azure VM インフラストラクチャに必要となるホストのテクニカル データです。

次に混乱が生じるのは、異なるタイプの VM を比較して、vCPU あたりの SAPS 値を計算するときです。注意していただきたいのは、ここでの「vCPU」または「CPU スレッド」という言い方は、Windows タスク マネージャーなどに表示される単一ユニットを指しています。VM に対して「コア」という言葉を使用していないのは、ベア メタル サーバーに対しての固定的な意味合いが強いからです。Intel のベア メタル環境では、ハイパースレッディングが無効なサーバーの場合、1 コアは 1 CPU スレッドに相当します。また、ハイパースレッディングが有効なサーバーの場合、1 コアは 2 CPU スレッドに相当します。

Azure VM の 1 vCPU がスループットとして引き出せる SAPS を計算する際、異なる Azure VM を比較すると少し驚く結果になることがあります。DS14 v2 を例に見てみましょう。SAP ノート #1928533 の記載に基づくと次のようになります。

  • 16 vCPU、112 GiB メモリ、24180 SAPS
  • vCPU あたりのスループット: 24180 / 16 = 1511 SAPS

同じ数の vCPU を持つ DS16 v3 (ただしメモリは 64 GiB) の場合、次のように SAPS 値が低くなります。

  • CPU スレッドあたりのスループット: 17420 SAPS / 16 = 1088 SAPS

DS16 v3 は最新の VM であり、パフォーマンスまたは vCPU あたりのスループットは通常常に向上しているものと想定されるため、ある意味驚きの結果です。期待外れの結果となった理由は、Intel ハイパースレッディングの有効なホストで実行される VM をマイクロソフトが導入したからです。このホスト サーバーでは、物理プロセッサ コア 1 つは、CPU スレッド 2 つに相当します。つまり、Azure VM の 1 vCPU は、ホスト サーバー上のハイパースレッド コアの CPU スレッド 2 つのうちの 1 つにマッピングされるのです。ベア メタル サーバーのハイパースレッディングでは、スループット全体が向上します。ただし、ホストの CPU スレッド数が 2 倍になるからといって、スループットも 2 倍になるわけではありません。標準的な SAP ワークロードにおけるハイパースレッディングによるスループット向上は、30 ～ 40% 程度です。したがって、ハイパースレッディングによる 2 CPU スレッドを持つホストの 1 コアでは、ハイパースレッディングが無効な同じプロセッサ コアの 130 ～ 140% のスループットを達成できることになります。つまり、ハイパースレッド コアの 1 CPU スレッドあたりのスループットは、1 CPU スレッドを持つ非ハイパースレッド コア 1 つの 65 ～ 70% 程度となります。

これは、先ほど DS14 v2 と DS16 v3 を比較した場合の 1 vCPU あたりの SAPS の差と一致します。

現在のところ、NetWeaver や SAP HANA の認定を取得した以下の Azure VM ファミリが、Intel ハイパースレッディングが有効なホスト ハードウェアで実行されています。

  • D(S)v3
  • E(S)v3
  • M シリーズ

先に述べたように、SAP ベンチマーク Web ページの詳細データには、ハイパースレッディングが有効であるかどうかは一切示されていません。単にホストの理論容量が記載されているだけです。特定の VM ファミリが実行されている Azure ホストでハイパースレッディングが有効であるかどうかは、Azure の価格ページで公開しています。下のスクリーンショットのように説明がされています。

clip_image004[4]

重要:

VM は性能に一定の制限があることにご注意ください。一般的には、同じファミリ内のサイズの小さい VM ほど、ストレージとネットワークの性能は低くなります。M128s、M128ms、ES64 v3 といった大きいサイズの VM の場合、ホストで実行されているのはその VM のみであるため、ホストが利用できるネットワークとストレージの性能すべてをその VM で独占できます。サイズの小さい VM の場合、ネットワークとストレージの性能は複数の VM で分け合います。特に、SAP HANA だけでなく SAP NetWeaver では、負荷の高いワークロードを実行する VM が、同じホスト上の他の VM と共有している CPU、メモリ、ネットワーク、ストレージの性能を占有しないようにすることがきわめて重要です。VM のサイジングにあたっては、ネットワークやストレージの性能を考慮する必要があります。各 VM のネットワークとストレージのスループットに関する詳細は、以下でご確認いただけます。

今回の内容で、vCPU あたりの SAPS の計算や評価に対する見方は明確になったでしょうか? また、ここでは、SAP ベンチマーク Web ページがサイジングの参照先としてふさわしくない理由もお伝えしました。サイジングの際には、SAP ノート #1928533 を参考にしてください。