SAP の 2 層構成から 3 層構成への移行時に見られるパフォーマンスの低下

執筆者: Juergen Thomas (MSFT)

このポストは、2016 年 11 月 21 日に投稿された Moving from SAP 2-Tier to 3-Tier configuration and performance seems worse の翻訳です。

 

先日、SAP ERP システムを仮想化環境で 2 層構成から 3 層構成に移行するお客様のケースに携わる機会がありました。このお客様は、システムを仮想化した際に、SAP の 2 層構成を維持するだけの十分な大きさの仮想マシンを新しいホスト ハードウェアで用意できなかったため、3 層構成に移行しました。ASCS とダイアログ インスタンスのみを 1 台の VM に移行し、DBMS サーバーは、同じプライベート クラウドでホストされる別の VM に配置しました。移行後に新しい構成をテストすると、機能に関しては問題ありませんでしたが、パフォーマンスに関してバッチ処理で実行速度に関する数値が悪化していました。2 層構成での同じバッチ ジョブ実行と比較し、数パーセントどころではない差がありました。そこで、いくつかの観点から調査を行いました。まず、DBMS の設定が変更されていないかを確認しましたが、そのようなことはありませんでした。メモリは少し増えましたが、他のパラメーターは変更されていません。ASCS とプライマリ アプリケーション サーバーも同じように構成されています。構成に違いはありませんでした。テストは 1 つのバッチ ジョブのみで行ったので、ネットワーク スケーラビリティに関連する問題も排除できました。

次に、SAP の個々のレコードの統計 (トランザクション STAD) を調査しました。特に実行が遅かったデータベースに対するバッチ ジョブにおいて、データベースに対するSELECT操作でかなりの時間がかかっていました。SQL Server DBMS からデータを抽出するときの実行時間が累積して長時間になっているようでした。しかし一方で、DBMS VM の実行が遅くなる理由は見つかりませんでした。ようやく問題を突き止められたのは、テストの実行時にシステムに対して実行していたあるバッチ ジョブについて議論しているときでした。問題は、2 層構成から 3 層構成に移行したことで増えたネットワークの遅延に関係していました。そこで、この問題に関するデータを集めて、詳しく調査することにしました。以下に、興味深い事実をお見せしたいと思います。

SAP NetWeaver 内のツールでくまなく調査する

SAP NetWeaver に組み込まれている機能を使用することで、DBMS システムにおける各クエリの応答時間と、その相手側のアプリケーション インスタンスにおける応答時間を測定できます。少なくとも、SQL Server についてはこれが可能です。この測定機能は、具体的には以下の 2 つです。

• DBA コックピット – SQL ステートメント
• ST05 – パフォーマンス トレース

SQL Server に DBA コックピットを使用する場合、データは以下の場所にあります。

この DBA コックピットのデータは SQL Server インスタンスから直接取得されます。正確には、sys.dm_exec_query_stats という DMV から取得されます。この DMV には、クエリの実行ごとに測定された多くのデータが保管されています。ただし、SQL Server インスタンス内についてのデータです。つまり、時間のカウントが始まるのは、クエリが SQL Server インスタンスに到達した時点です。時間のカウントが終了するのは、クエリの結果がアプリケーションで使用する SQL Server クライアント (ODBC、JDBC、など) で取得できる状態になった時点です。経過時間は純粋に SQL Server 内で記録、測定されるため、通常ネットワークの遅延は考慮されません。

一方、SAP ST05 パフォーマンス トレースは次のようになります。

これは、クエリがアプリケーション サーバー インスタンスから送信された時点から、結果が戻ってくる時点までを、クエリ実行時間として測定します。この場合、SAP アプリケーション インスタンスと DBMS サーバーの間のネットワーク通信にかかる時間もすべて測定値に含まれます。つまり、これは SAP アプリケーション インスタンスにとっての応答時間であり、今回のバッチ ジョブの場合、この応答時間がバッチ ジョブの実行時間に大きく影響している可能性があります。特に DBMS システムとのやり取りに大量の時間が費やされているバッチ ジョブについては、このように推測できます。

詳細な測定

より詳細な測定と構成による影響を検証するため、ほぼ 100% の時間を DBMS とのやり取りに費やすジョブを作成して少し極端なケースをテストしました。測定の際は次のような手順を踏みました。

• SQL Server のプロシージャ キャッシュを T-SQL コマンド DBCC FREEPROCCACHE を使用して削除しました。このコマンドは、SQL Server DMV sys.dm_exec_query_stats のデータも削除することに注意してください。
• 次に、対象のジョブの実行をトレースするために、適切なフィルターを設定して ST05 を開始しました。

• 対象のジョブを実行したところ、実行時間はわずか 10 秒でした。

対象のジョブは、SAP ERP の品目マスター テーブル MARA の主キー約 9,000 個を内部テーブルに読み取り、その内部テーブルをループさせて、主キーが指す行を 1 行ずつ抽出します。ただし、読み取るのは各行の最初の 3 列のみです。

まずは、かなり古いサーバー ハードウェアで仮想マシンを実行してテストを行いました。6 ～ 7 年前の世代のプロセッサです。このテストの目的は、正確な実行時間を知ることではなく、結果を比較することにあるため、さまざまな構成で、DBMS 側の測定値と SAP 側の測定値の違いを調べるつもりでした。

古いホスト上の仮想マシンを使用した最初のテストでは、実行後次のように表示されました。

SQL Server 側では、クエリあたりの平均実行時間は 89 ミリ秒です。このデータは、記憶に照らす限り、想定どおりです。クエリは主キーで行にアクセスしているため、きわめてシンプルなうえ、比較的列数の多いテーブルの最初の 3 列を読み取っているだけです。十分に適切なレベルと言えるでしょう。

次に、これを実行したときの SAP アプリケーション側の時間を測定します。ここで、「オーバーヘッド係数」の考え方を紹介しておきます。今回は、次のように説明できます。

「オーバーヘッド係数」は、SQL Server での純粋な実行時間以外に、ネットワーク転送にかかる時間や、ODBC クライアント内の処理で SAP ロジックの時間測定に至るまでの時間を加味した係数です。SQL Server 内でのクエリの実行に x ミリ秒かかり、ST05 での測定値が x の 2 倍であったとすると、オーバーヘッド係数は 2 となります。

このときは 2 層構成で実行しているため、ネットワークと処理の時間で数ミリ秒増えることは予想していました。今回のトレースの ST05 統計の集計結果は次のようになり、この結果には少し驚きました。

2 層構成で 362 ミリ秒と測定されたのです。ごくシンプルなクエリの実行ですが、SQL Server が必要とした時間に比べて、SAP 側で測定された応答時間は約 4 倍に増えています。言い換えると、「オーバーヘッド係数」が 4 ということになります。

次に、3 層システムの場合はどうなるのかをテストします。まずは、DBMS VM と SAP アプリケーション サーバー VM を同じホスト サーバー上で実行するケースをテストします。

この場合、ST05 の測定値は次のようになりました。

平均で 544 ミリ秒です。「オーバーヘッド係数」は約 6 に増えたことになります。

次に、それぞれの VM が同一サーバーでホストされていないシナリオを考えます。テストを行うために、同じプロセッサを搭載した同じタイプのサーバーを、2 つの別々のラックに設置しました。この場合、VM 間のトラフィックは少なくとも 2 つまたは 3 つのスイッチを経由することになります。この構成は ST05 トレースにすぐに影響し、次のような結果になりました。

「オーバーヘッド係数」は、8 を少し超えるまでに増えました。

結果を次の表にまとめます。

この結果を見ると、2 層構成から 3 層構成に移行するとオーバーヘッド時間が大幅に増え、特に、経由するネットワーク機器の個数が多くなると時間はさらに増えると考えられます。SAP ジョブの場合、今回テストしたような極端なケースでは実行時間が数倍に増えることもあるということです。SAP ロジックがアプリケーション層で利用できるリソースが増えれば、ネットワークの影響は少なくなります。

では、特に仮想化のケースでは、どのようにすればよいでしょうか。

• SR-IOV (https://msdn.microsoft.com/ja-jp/windows/hardware/drivers/network/overview-of-single-root-i-o-virtualization–sr-iov-、英語) などのアーキテクチャでネットワーク トラフィックを最適化するプライベート クラウド向けハードウェアの利用を試してみます。SR-IOV は、最新のリリースの VMWare でもサポートされます。ご使用の vSphere バージョンの資料を参照してください。
• 特に、16 vCPU 以上の大きな VM の場合は、vRSS (https://technet.microsoft.com/ja-jp/library/dn383582(v=ws.11).aspx) と NIC ドライバー (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/vmware-vsphere-pnics-performance-white-paper.pdf、英語) を使用します。

インフラストラクチャの観点からの設計原則としては、SAP の DBMS 層と SAP のアプリケーション層のコンピューティング インフラストラクチャは、できる限り接近させた「近い場所」に配置すべきです。「近い場所」とは距離的な意味だけでなく、メートルなどの長さの単位で測ることのできないネットワーク パスにおいて、ネットワーク スイッチ/ルーターやゲートウェイの個数を最小にするという意味でもあります。

Azure でのテスト

Azure でのテストは、まったく同じジョブを使用して、まったく同じ方法で行いました。

1 つの Azure VNet 内でのテスト

Azure での最初のテストのために、VNet を作成し、そこに SAP システムをデプロイしました。Azure の新しいネットワーク機能をテストすることも目的としていたので、すべての処理に DS15v2 VM タイプを使用しました。テストする新しいネットワーク機能とは、「Azure Accelerated Networking」です。詳細はこちら (/ja-jp/azure/virtual-network/virtual-network-create-vm-accelerated-networking) を参照してください。

2 層構成で対象のジョブを実行した結果は、次のようになりました。

SQL Server での単一のクエリの実行は 60 ミリ秒でした。ST05 の値を見ると、177 ミリ秒でした。

純粋に SQL Server でかかった時間と、SQL Server と同じ VM で実行されている SAP インスタンスで測定された時間の間の係数は、約 3 です。

3 層構成の最初のテストでは、2 台の VM (データベース インスタンスを実行する VM と、SAP アプリケーション インスタンスを実行する VM) を「Azure 高速ネットワーク」の機能なしでデプロイしました。この 2 台の VM は同一の Azure VNet 内にあります。

テストの結果、専用の SAP インスタンスの ST05 での測定値は次のようになりました。

570 ミリ秒という数値は、3 層構成ではほぼ 3 倍の時間になるという結果です。単一のクエリで SQL Server が必要とする時間との係数は、9.5 となります。

次に、両方の VM に新機能の「Azure Accelerated Networking」を構成しました。データベース VM と SAP インスタンス VM でこの高速化機能を使用しました。計測を再度行うと、次のような嬉しい結果となりました。

SAP アプリケーション インスタンスで測定された時間は短くなり、クエリの実行あたり 340 ミリ秒となりました。仮想化環境のネットワーク スタックによる影響を大きく減らすことができたのです。

SQL Server での純粋な実行時間に対するオーバーヘッド係数は、6 を下回っています。通信時間は 40% を超える削減となりました。

さらに、Azure の別の 3 層 SAP 構成でもテストを行いました。

• SAP インスタンス VM と DBMS VM を 1 つの Azure 可用性セット内に配置しました。
• SAP インスタンス VM が別のハードウェア クラスター上の VM となるように、VM の種類を変えてデプロイしました (SAP インスタンス VM は GS4、DBMS VM は DS15v2)。Azure VM サイズ ファミリについては、こちらのブログ記事 (https://azure.microsoft.com/en-us/blog/resize-virtual-machines/) を参照してください。

このようなデプロイメント (「Azure ネットワーク最適化」機能なし) で、ST05 の測定値に大きな変化は見られず、すべてのケースで、ST05 で測定された単一実行の値は 530 ～ 560 ミリ秒の間でした。

Azure に関しての結果は、次のようにまとめられます。

• オンプレミスの仮想化環境と比較して、通信のオーバーヘッドが増えることはありません。
• 新しい高速ネットワーク機能は、ネットワーク経由での通信とデータ転送にかかる時間に大きな効果があります。
• 異なるハードウェア クラスターで実行される 2 台の Azure VM 間で通信を行っても大きな影響はありません。

さて、抜け落ちているテスト シナリオはないでしょうか。実は、1 つあります。純粋なベアメタル対ベアメタルの測定です。このシナリオを行わなかったのは、ほとんどのお客様が 3 層アーキテクチャの少なくとも片側は仮想化を行っているからです (両側を仮想化しているお客様もいます)。たとえば、マイクロソフト社内の SAP 環境を見てみると、SAP ERP システムの DBMS 側以外はすべてのコンポーネントが仮想化されています。マイクロソフト社内の SAP 環境は 99% が仮想化されており、そのかなりの部分が既に Azure 上の仮想システムで実行されています。お客様は SAP 環境の仮想化をさらに進めている傾向にあるため、上記のテストの他にベアメタル システムで測定を行う必要はないと考えました。