Azure パブリック クラウドで稼働させる SAP ソリューションのサイジングに関する最新ホワイト ペーパーを公開

執筆者: GoranCondric

このポストは、2015 年 12 月 1 日に投稿された New White Paper on Sizing SAP Solutions on Azure Public Cloud の翻訳です。

 

マイクロソフトは、Microsoft Azure パブリック クラウドで稼働させる SAP ソリューションのサイジング方法に関する最新のホワイト ペーパーを公開しました。このブログの最後からご覧いただけます。

このトピックについて言及した最初のドキュメントとしては「Azure 仮想マシンで実行する SAP システムのサイジング方法 (英語)」というブログ記事がありますので、そちらもご覧ください。

マイクロソフトが Azure 上で SAP SD Standard Application ベンチマークを実行し、結果を公表

サイジングは、SAP ソリューションをデプロイする際の重要なトピックであり、要求されたパフォーマンスを保証する十分なコンピューティング リソースがあることを確認する必要があります。

マイクロソフトはクラウド プロバイダーの責任として、SAP 2 層構成と 3 層構成の正式なベンチマークを実行し、結果を公表しています。Azure で認定され、リリースされた SAP ベンチマークは https://www.sap.com/benchmark (英語) から参照できます。また、SAP Note 1928533 - SAP Applications on Azure:Supported Products and Azure VM types 」にも掲載されています。

先日マイクロソフトは、Azure IaaS VM を使用した SAP クラウド環境のリリースに関する SAP Sales and Distribution Standard Application Benchmark の世界記録 (英語) について発表しました。

各ベンチマークには、ベンチマークに使用する構成、VM サイズ、ストレージの種類が明記されています。

サイジングのプロセスは複雑であるため、お客様およびパートナー様における作業を支援するために、ガイドラインとしてこのホワイトペーパーを作成しました。

「T シャツ」サイジング

ホワイトペーパーでは、Azure で稼働する 3 層構成 SAP ソリューションを対象とした「T シャツ」サイジングについて説明しています。本稼働SAP のユース ケースに適しているのは 3 層構成ですが、Azure での 2 層構成の SAP ソリューションについても説明しています。

図 1: T シャツ サイジング

SAP アプリケーションとコンポーネント

ワークロードの特性や要件は、SAP アプリケーションやコンポーネントの種類によって異なるため、ホワイトペーパーでは、SAP ECC 6.0、SAP Business Objects、SAP LiveCache、SAP Content Server、SAP Solution Manager、SAP BI Java と Enterprise Portal、SAP XI/PI、SAP NetWeaver Gateway、CTM Optimizer、SAP TREX といったさまざまなアプリケーションを取り上げています。またコンポーネントについても、SAP アプリケーション サーバー、SAP データベース サーバー、SAP ASCS/SCS インスタンスなど、SAP NetWeaver テクノロジ スタックのさまざまなコンポーネントを取り上げています。

Azure Premium Storage

高速ストレージは、データベース サーバーなど高性能なストレージを多く必要とする IO ワークロードに欠かせないものであるため、Azure の高速な SSD Premium Storage については独立で章を設けています。

Azure パブリック クラウドで SAP のサイズ変更を動的に行うメリット

SAP システムをオンプレミスで稼働しているお客様の多くは、ピーク時の負荷に耐えられるようインフラストラクチャのサイズを大きめにしています。ピーク時は、3 か月に 1 度のときもあれば (四半期の締めなど)、数日続くことも考えられます。しかし、ピーク時を除くほとんどの期間のシステム負荷は、ピーク時と比べると非常に低くなります。つまり、SAP システム用のインフラストラクチャ リソースの使用率は低い状態が続くことになります。

オンプレミス インフラストラクチャと比較して Azure クラウドが優れている点の 1 つは、リソースを動的に増減できることです。需要が増えればリソースも増やし、使用率が下がればリソースを減らしてコストを削減することができます。さらに、料金は使用したものを使用した分だけ支払えば済みます。

ここでは、SAP ユーザーの対話的操作に基づいて、SAP ワークロードを処理する SAP NetWeaver ABAP アプリケーション サーバー コンポーネントをスケールアウトする例について説明します (考え方としては、SAP バッチ、RFC、更新のワークロードの場合も同じです)。現在は、2 つの SAP アプリケーション サーバーが Azure VM 2 台で実行されています。SAP ユーザー ワークロードはログオン (SMLG) グループによって自動的に負荷分散されます。

新しいユーザーが SAP アプリケーション サーバーに追加されていくと、ある時点からパフォーマンスが低下し始めます。そして、さらにワークロードが増えると、サーバーは現在ログオンしているユーザーへのサービスで既にビジー状態にあるので、パフォーマンスがさらに低下します。極端なケースでは、アプリケーション サーバーが停止しているように見えることもあります。

図 2: SAP アプリケーション サーバー (AS) のスケールアウト – スケールアウト前の状態

この問題を解決する方法が、SAP アプリケーション サーバー層の動的スケールアウトです。つまり、新しい SAP ユーザーに対応する 3 つ目の新しい SAP アプリケーション サーバーを動的に追加できるようにします。追加のアプリケーション サーバーとして AS3 と AS4 を用意し、これらを 2 台の VM に事前にデプロイしておきます。2 台とも最初の状態ではオフラインであり、ごくわずかなストレージ コストを除いてコストは発生しません。

SAP AS がデプロイされている新しい VM は手動で開始することもできますが、Azure Autoscale を使用して開始すれば、自動スケールアウトを実現できます。

図 3: SAP アプリケーション サーバー (AS) のスケールアウト – スケールアウト後の状態

同様の考え方で、SAP ユーザーの負荷が少なくなった場合は SAP アプリケーション サーバーを縮小できます。一部の SAP アプリケーション サーバーを停止し、VM をシャットダウンします。これで、インフラストラクチャ コストは少なくなります。

一般的には、約 3 か月ごとにインフラストラクチャの使用状況を確認して、プロビジョニングされている Azure リソースが SAP ワークロードからの需要に合っているかどうかを判断することが推奨されます。

また、使用状況の積極的な監視により、使用状況パターンの把握とピーク期間の特定を行っておけば、SAP システムの Azure インフラストラクチャを事前にサイズ変更することもできます。

ホワイトペーパー: SAP NetWeaver: Azure パブリック クラウドでの SAP ソリューションのサイジング (英語)