Azure 用に SAP を最適化

2022.02.21 Azure

本ポストは以下のブログ記事の翻訳です。

データセンターのイメージ

2021 年 6 月 15 日

マイクロソフトでは、財務や人事など、ミッションクリティカルなビジネス機能を実行するために、SAP エンタープライズリソース管理ソフトウェアを使用しています。オンプレミスモデルの物理コンピューティングリソースはコストが高く、使用率が低い場合があります。マイクロソフトは SAP システムを Microsoft Azure に移行することで、未使用のリソースを維持するという無駄を省き、現在および短期のニーズに応じてシステムをスケールアップおよびスケールダウンしています。マイクロソフトは、コスト削減と俊敏性、スケーラビリティ、柔軟性の向上のために、容量管理プロセスを微調整しました。

関連コンテンツを調べる

SAP はマイクロソフトのデジタル変革のバックボーンです。多くの大企業と同様に、マイクロソフトではほとんどの業務を実行するために SAP を使用しています。SAP とは、エンタープライズリソースプランニング (ERP) ソフトウェアソリューションです。マイクロソフトは SAP on Azure を実行しています。SAP on Azure は SAP に適したプラットフォームであり、デジタル変革に最適なプラットフォームです。

マイクロソフトは、業務上および運用上の利点を得るために SAP on Azure 環境を最適化しました。これにより、SAP 環境は俊敏で効率的になり、ビジネスに応じて SAP 環境を成長および変化させることができます。Azure 環境の最適化により、以下が実現しました。

Azure インフラストラクチャをより効率的に使用することでコストを削減する。
より俊敏で、スケーラブルで、柔軟な SAP on Azure ソリューションを構築する。

2018 年 2 月以降、マイクロソフトの SAP インスタンスは Azure に 100% 移行されています。SAP on Azure を最適化することで、マイクロソフトは SAP 環境がビジネスニーズに応じて成長し、変化できるようにしています。また、マイクロソフトはデジタル変革をリードし、組織内のすべての人がより多くのことを達成できるようにしています。Azure によって SAP はより優れたものになります。

マイクロソフトにおける SAP

Microsoft Digital は、マイクロソフトによる SAP システムとアプリケーション (アプリ) の管理に力を与え、保護し、変革する組織です。SAP には、金融、人事、サプライチェーン管理のようなミッションクリティカルなビジネス機能のためのシステムやアプリが備わっています。SAP on Azure は、クラウドでイノベーションを行うための実現可能で信頼できる道筋です。このソリューションは俊敏なインフラストラクチャを提供し、ダウンタイム、リスク、およびコストを最小化し、従業員の効率を向上させ、デジタル変革を推進します。

SAP ランドスケープ全体の各 SAP システム/アプリは、それぞれがサーバー、ハードウェア、コンピューティングリソース (CPU やメモリなど)、およびストレージリソースを使用しています。また、各システムは、それぞれがサンドボックスや実稼働のような個別環境を備えています。オンプレミスモデルでは物理サーバーや仮想化サーバーが使用されないままになることもしばしばで、SAP を実行するために必要なリソースによって多大なコストが発生しかねません。

一般的なオンプレミスシステムについて考えてみましょう。IT 業界では、資産が寿命を迎えるまで最大の使用効率とワークロードが維持されるという想定に基づいて、3 年先から 5 年先までを見据えてオンプレミスのサーバーやストレージインフラストラクチャのサイジングを行うことが多いです。しかしながら、多くの場合、ハードウェアの容量はピーク時以外では完全には使用されず、まったく必要とされないことさえあります。これらのオンプレミスシステムの維持管理には多大なコストがかかります。

マイクロソフトは Azure を利用することによって、インフラストラクチャの不十分な活用や過剰なプロビジョニングを回避しています。また、SAP システムのスケールアップやスケールダウンを 3 年先から 5 年先までを見据えて最大の負荷を想定して行うのではなく、現在のニーズや短期的なニーズに基づいて迅速かつ簡単に行っています。

容量管理によるコスト削減と俊敏性向上

マイクロソフトは、容量を管理し、Azure で SAP システムをサイジングすることで、複数の分野で改善を行うことができました。

総保有コストを削減。リソースが必要になったとき、その必要なリソースに対してのみ料金を支払っています。また、使用されていないハードウェアや継続的なサーバーの保守にかかるコストを削減しています。
コア数 (マシンの CPU 数) を約半分に削減。マイクロソフトが移行したほぼすべてのサーバーについて、64 コアの物理マシンから 32 コアの仮想マシンへの切り替えを行っています。
俊敏性を大幅に向上。現在のニーズに基づいてサイジングを行い、必要に応じてセットアップを簡単に追加/変更して新機能に対応しています。たとえば、マイクロソフトは、短期的なニーズを満たすために、ものの数分で 8 CPU の仮想マシンを 16 CPU に変更し、メモリを倍増させ、Azure Premium Storage を追加したことがあります。そして後日、コスト削減のために、簡単に元のセットアップに戻しました。

最適化で必要となること

最適化では、CPU リソース、ストレージスペース、メモリ、入力/出力 (I/O)、ネットワーク帯域幅のようなハードウェア要件の計算が必要になります。最適化を行う場合、現在の状況に応じてサイジングを行っています。インフラストラクチャ、リソース、およびコストを評価した後、できるだけ小さくなるようにシステムをサイジングしています。また、所定のイベント (製品リリースや四半期ごとの財務報告など) でパフォーマンスの問題を発生させることなくビジネスプロセスを実施できる十分なスペースがあるか確認しています。これによって、ストレージとコンピューティング能力を最適化でき、柔軟性とオンデマンドの俊敏性を得ています。

サイジングのヒント

負荷、ビジネス要件、および行動パターンは常に変化する可能性があるため、サイジングは継続的なタスクになります。このセクションでは、マイクロソフトが使用するプロセスに基づいて、考慮事項やヒントをいくつかご紹介します。

スケールアップやスケールアウトを簡単に行えるように設計します。実際のビジネスニーズが生じる数か月/数四半期前からスケールアップやスケールアウトを行うのではなく、必要になったときにだけサイズを大きくします。できるだけ最小のコンピューティング容量で開始します。後でキャパシティを追加することや、環境内のビジネスプロセスの変更前、または新しいプロセスの稼働前にサイズを変更することは簡単です。自動スケールアップや自動スケールアウトを用いると、現在の状況や使用パターンに自動的に対応できるため、さらなるメリットが実現されます。簡単なスケールアップのための設計には、SAP HANA データベースと SAP インスタンスの構成も含まれます。仮想マシン (VM) の使用可能なリソースに基づいて、使用されるメモリの容量または作業プロセスの数を動的に調整できるように構成します。インスタンスの設計はシンプルさを保つようにし、1 つの VM で 1 つの SAP インスタンスが動作するようにします。
システムで必要となる仮想マシンの台数を特定します。マイクロソフトの実稼働システムとユーザー受け入れテスト (UAT) システムには多数の仮想マシンが含まれますが、サンドボックスと品質保証については、通常は単一の仮想マシンを割り当てます。また、SAP アプリインスタンスとデータベースインスタンスが同じ仮想マシン上に存在していることもあります。
CPU とメモリだけでサイジングを行わないようにします。ストレージの I/O やスループットの要件についても考慮してサイジングを行います。
データ移動やアプリ間通信におけるアップストリームとダウンストリームの依存関係について検討します。たとえば、アプリをパブリッククラウドに移行すると仮定します。オンプレミスとパブリッククラウドのアプリ間の通信時間が 20 ミリ秒から 40 ミリ秒長くなると、依存関係に影響を及ぼす可能性があり、お客様、またはビジネスパートナーとのサービスレベルアグリーメント (SLA) に影響を及ぼす可能性もあります。
すべてのシステムで Azure Premium Storage が必要となるか判断します。短いダウンタイムで Azure Standard Storage から Premium Storage にストレージを変更できます。このとき、手動でデータをコピーする必要はありません。次に、マイクロソフトがこの機能をどのように使用しているか例を示します。マイクロソフトは、アーカイブシステムで Azure Standard Storage と小規模な仮想マシンを使用していました。マイクロソフトは、システムにデータをロードする際に、メモリと CPU を一時的に倍増させ、データベースのログファイルドライブ用に Azure Premium Storage を追加しました。データをロードした後、コスト削減のために、仮想マシンの規模を再び小さくし、Premium Storage ドライブを削除しました。
すべてのアプリを継続的に実行する必要があるか判断します。月曜日から金曜日まで 1 日 8 時間いくつかのアプリを実行する可能性はありますか。そのような場合は、一時停止によってコストを削減できます。多くの場合、夜間、または週末や休日の間、使用しない開発システムやサンドボックスシステムを一時停止させることができます。また、テストシステムや、場合によっては一部の実稼働システムを一時停止の対象として特定することを検討します。一時停止のスケジュールを作成し、主要な担当者が、必要に応じてシステムの一時停止を解除できるようにします。個別のビジネス継続性システムを所有している場合、そのシステムのハードウェアを一時停止させると、コンピューティングの使用料金を支払わずに、ストレージの料金を支払うだけで済みます。また、可能な限り小さなサイズを使用することも検討します。障害が起きている場合、実稼働システムを開始する前により大きなサイズに変更します (例: ビジネス継続性用のデータベースサーバー)。
システムやリソースの容量を継続的に監視して管理します。問題が起きる前に変更を行います。ストレージの使用状況、増加率、CPU、ネットワークの使用状況、および仮想マシンで使用されているメモリリソースを監視します。再び、自動スケールアップと自動スケールアウトについて検討します。監視によって、システムが明らかに大きすぎるということが判明した場合は、調整して小さくします。

SAP システムのサイジングにおける一般的な 2 つの戦略

マイクロソフトは、SAP システムのサイジングのために 2 つの一般的な戦略を使用しました。それぞれの戦略を、最適化プロセスにおいて、異なる方法で、かつ異なるポイントで使用しました。最適化プロセスの開始時には SAP Quick Sizer を使用しました。SAP Quick Sizer にはシンプルな Web ベースのインターフェイスが備わっており、最初からサイジング戦略を準備できたためです。後の段階で、仮想マシンのサイジングに関するいくつかのコンテキストを決定し、参照のために Azure で仮想マシンを提供できるようになった後、リファレンスサイジングを使用しました。

SAP Quick Sizer

Azure にシステムやワークロードをまだ展開していない場合は、まず SAP Quick Sizer を使用します。これは、ビジネスニーズに基づいてサイジングの要件に関するガイダンスを提供するオンラインアプリです。Quick Sizer は、容量や予算の計画に適したアプリです。このアプリでは、SAP のユーザー数、予想されるトランザクション数などの詳細情報を指定するアンケートが用意されています。データベースサーバーなどで必要となる SAPS (SAP Application Performance Standard) の推奨値が SAP システムによって示されます (SAPS は処理要件の測定値です)。

推奨値が 80,000 の場合、SAPS の合計値が 80,000 となるサーバーを活用する必要があります。

Azure 仮想マシンの SAPS について詳しくは、SAP Note #1928533 「Azure 上の SAP アプリケーション: サポートされる製品と Azure VM の種類」を参照してください (SAP へのログオンが必要です)。

SAP Quick Sizer を使用する場合は、いくつかの注意すべき考慮事項があります。ビジネスプロセスによっては SAP システムのカスタマイズや変種が存在している場合があり、それによってシステムの動作が変わっている可能性があります。あるいは、新しい SAP の展開環境で有効になっている機能やカスタムコードが存在していて、Quick Sizer を利用できないことも考えられます。また、ハードウェアベンダーがお客様に対して必要なサーバーやそれらの導入方法に関する指導を過去に行っていることも考えられます。Azure では、たとえば、データ容量の増大に合わせてストレージをどのように拡張するか、または CPU のコンピューティングリソースをどのように調整するかといった意思決定をお客様自身で行います。

リファレンスサイジング

システムが Azure で稼働するようになった後、リファレンスサイジングという手法が推奨されます。このアプローチでは、移行するシステムと負荷が類似する、既に Azure に移行したシステムのパフォーマンスを調べる必要があります。この比較によってサイジングの要件を正確に見積もることができます。たとえば、Azure に移行したいオンプレミスシステムがあり、そのシステムが、既に Azure にあるいずれかのシステムの 3 倍の規模である場合、Azure に既にデプロイされているシステムに基づいてサイジングを調整し、新しいシステムをデプロイします。

見積もりが正確ではなかったことが判明した場合、オンプレミスよりも Azure の方が、異なる仮想マシンサイズに切り替えることで、より簡単かつ迅速に CPU とメモリリソースを調整できます。オンプレミスでデータベースを調整するのはそれよりもはるかに困難です。より多くの CPU とメモリを搭載したサーバーを購入しなければならなくなる可能性もあるためです。オンプレミスの場合、既に所有しているリソースについて考察し、バッファを追加して、今後数年間でどのくらい負荷が増大するか考慮する必要があります。

技術面におけるいくつかの重要な考慮事項

SAP を Windows Server や SQL Server と統合する際にマイクロソフトが主に考慮する点は、保有コストと低い複雑性です。統合や参照アーキテクチャの計画を立てる際、運用しやすく、運用コストがあまりかからない技術環境であることを確認します。ビジネスクリティカルなシステムでは、メンテンナンスでスキルが高い人材が必要となるアーキテクチャがある場合や、ビジネス継続性が必要となる緊急事態がある場合、スケーリングを行うのは困難です。

マイクロソフトでは、管理と運用を簡単にするために、すべての SAP 実稼働システムで同じアプリ設計を使用しています。システム固有の要件に基づき、VM のサイズと数を調整するだけで済みます。

また、Azure で SAP ワークロードを実行するお客様の問題を回避するために、マイクロソフトは特定の Azure VM の種類だけを認定しています。これらの VM は、メモリ、CPU、および比率の要件を満たし、規定されたスループットをサポートする必要があります。SAP 対応として認定された Azure VM の種類について詳しくは、「Microsoft Azure で実行されている SAP の認定と構成」を参照してください。

技術的実装と技術機能

図 1 は、Azure 内の Microsoft SAP ERP/ECC 実稼働システムを示しています。マイクロソフトは、Azure に移行することで、SAP アプリケーション層で俊敏性とスケーラビリティを得ることができました。VM のサイズと数を増減することで、SAP アプリケーション層をスケールアップおよびスケールダウンできます。設計およびアーキテクチャには、単一障害点に対する高可用性の措置が講じられています。そのため、Windows Server または Microsoft SQL Server の更新、インフラストラクチャのメンテナンスの実施、またはその他のシステムへの変更が必要な場合でも、ダウンタイムは (あるとしても) それほど必要ありません。マイクロソフトは、標準的な SAP、SQL Server、SAP HANA、Windows Server、SUSE Linux 高可用性機能を使用して、Azure 上の実稼働システムのインフラストラクチャを実装しています。

技術の実装と技術的特徴のイメージ

図 1. Azure 上の現在の SAP BW/HANA 実稼働システム

高可用性とスケーラビリティ

高可用性を確保するために、マイクロソフトは Azure Availability Zones を活用し、複数のゾーンに VM を分散させています。図 1 には、マイクロソフトが Azure Availability Zones をどのように使用しているかを示す例が含まれています。1 つのゾーンで問題が発生しても、システムは引き続き利用可能です。

すべての単一障害点はクラスタリングによって保護されています。Windows オペレーティングシステムに対しては Windows Server フェールオーバークラスターを使用し、SUSE Linux に対しては Pacemaker クラスターを使用しています。データベースに対しては、SQL Server Always On と SAP HANA システムレプリケーション (HSR) を使用しています。これらのデータベースは、両方のローカル HA ノードで同期コミットが行われるように構成されていて (データ損失は発生せず、自動フェールオーバーが可能)、リモートのディザスターリカバリーノードに非同期コミットが行われるように構成されています。メインデータベースサーバーで問題が発生しても、SAP はローカルの高可用性ノードに自動的に再接続します。

セカンダリデータベースを使用できるため、ソフトウェアと SQL Server のアップグレード、前のリリースへのロールバック、自動フェールオーバーを、リスクなし、または最小限のリスクで実行できます。

SAP アプリケーション層のスケーラビリティと高可用性のために、複数の SAP アプリサーバーインスタンスが、ログオングループやバッチサーバーグループなどの SAP 冗長性機能に割り当てられています。これらのアプリサーバーインスタンスは、高可用性を確保するために、別々の Azure 仮想マシンで構成されています。SAP は、グループ定義ごとに、複数のアプリサーバーインスタンスにワークロードを自動的にディスパッチします。1 つのアプリサーバーインスタンスが使用できなくなっても、ビジネスプロセスは同じグループに属する別の SAP アプリサーバーインスタンスを使用して引き続き動作できます。

ローリングメンテナンス

SAP アプリサーバーインスタンスのスケールアウトロジックは、ローリングメンテナンスでも使用されます。実稼働に影響を与えずに、SAP システムから 1 台の仮想マシンとその仮想マシンで実行されている SAP アプリサーバーインスタンスを削除します。作業の終了後、その仮想マシンを再度追加すると、SAP システムは自動的にインスタンスを再び使用します。高い負荷が発生しスケールアウトが必要な場合には、SAP システムに仮想マシンを追加します。

SAP システムの自動シャットダウン

マイクロソフトでは、VM のコストを確実に管理するために、非実稼働 SAP システムに関する新しいポリシーを確立しました。それは、利用できない状態をシステムの既定の設定とするというものです。ユーザーは、Microsoft Power Apps の上に構築された一時停止アプリケーションを使用して、必要に応じてシステムを起動できます。システムは 12 時間利用可能で、その後、利用時間が延長されない限り、自動的に再シャットダウンされます。また、定期的に使用されるシステムには固定的な利用スケジュールを割り当てています。たとえば、「システムをユーザーの操作なしで金曜日の夜にシャットダウンし、月曜日の朝に再び起動する」というスケジュールを使用しています。週末にかけてシステムが必要になる場合、ユーザーは一時停止アプリケーションを使用してシステムを起動できます。

Azure Monitor を使用したテレメトリと監視

SAP システムを Azure に移行したことで、さまざまな Azure Monitor サービスと簡単に統合してテレメトリと監視を強化できるようになりました。マイクロソフトでは、マルチレイヤーの概念を使用してテレメトリにアプローチしました。レイヤーの構成は次のようになっています。1) SAP ビジネスプロセスレイヤー、2) SAP アプリケーション基盤レイヤー、3) SAP インフラストラクチャレイヤー、4) SAP サラウンディング API レイヤー。

Azure Log Analytics により、SAP インフラストラクチャレイヤー用に多数の標準メトリックが提供されます。また Azure Log Analytics は、アプリケーション基盤レイヤーからカスタムメトリックを収集するために SAP と簡単に統合できます。

SAP ビジネスプロセスレイヤーと API レイヤー用にテレメトリを実装するのは、カスタム開発が必要になるため多少難しくなります。マイクロソフトでは、SAP から Azure Monitor Application Insights にデータを統合およびエクスポートするために、ABAP SDK のツールを使用しています。

マイクロソフトが技術的な部分とビジネスプロセスのテレメトリをどのように設定したかについては、次の Microsoft Inside Track の記事で詳しく説明されています。

教訓

マイクロソフトは、自社環境で Azure 向けに SAP を最適化することを通じて、継続的に学んでいます。以下の項目は、マイクロソフトが得た重要な教訓の一部を示しています。

仮想マシンを過剰にプロビジョニングしないようにすると同時に、システムリソースを毎週増やさずに済むように、十分なリソースをプロビジョニングするようにします。
インフラストラクチャとストレージを Azure 内でスケールできるように設計、構築します。マイクロソフトでは、待機時間を短くするために、開発システムおよびテストシステムでも Azure Premium Storage を使用することに決めました。プロジェクトの実施中、複数の開発者が開発システムを同時に使用する場合が多いため、このアプローチが最適です。
マイクロソフトが使用する仮想マシンストレージや Azure ネットワークの種類は、機能について得られた教訓によって左右されます。Azure クラウドプラットフォームは、お客様のフィードバックと要件に基づいて継続的に改善されています。
Windows Server フェールオーバークラスタリング、SQL Server Always On、および SAP 機能 (ログオングループ、リモートファンクションコールグループ、バッチサーバーグループなど) を使用して、実稼働システムで高可用性を実現できるように設計します。

将来の展望

マイクロソフトは、Azure 向けに SAP を最適化する作業を通じて、コスト削減と俊敏性向上を実現してきました。今後は、移行後の改善を進めながらより多くの教訓を得て、それらを共有していくつもりです。移行構想の設計について詳しくは、「SAP システムを Microsoft Azure に移行するための戦略」を参照してください。今後は以下のようなことを計画しています。

よりシンプルなシステムや環境のサイジングを自動化し、自動スケール機能を開発します。自動化や自動スケールの機能は中間層 (SAP アプリケーション層) に適用される度合いが高いものですが、データベース層やファイルサーバーの自動スケールアップや自動スケールダウンも行いたいと考えています。マイクロソフトは、現在の状況に基づいてシステムの自動スケールを行いたいと考えています。
ビジネス継続性のための自動化機能をさらに追加します。マイクロソフトは現在、オンプレミスで使用していたものと同じ半自動のビジネス継続性プロセスを Azure でも使用しています。障害が発生した場合、実稼働環境は別の Azure リージョンにフェールオーバーします。
新しいビジネス継続性に関する戦略やテクノロジオプションについて、それらを Azure に適用する際に検討します。
Azure Backup や保存データの Azure Data Encryption などの SAP シナリオを使用するお客様を支援します。次のような疑問を解決できるようにします。
- SAP ランドスケープでどのポリシーを適用すべきか。
- 何を暗号化すべきか。ディスクの暗号化やデータベースの暗号化を使用すべきか。
- 50 GB のデータベースに対して、10 TB のデータベースと同じバックアップ手段を使用する必要があるか。
新しい Azure の機能を追加して使用します。Azure でより多くの SAP シナリオを実行できるようにしたいと考えています (より優れた高速なストレージ、より大規模な仮想マシン、より優れたネットワーク接続、およびより多くの Azure 運用ガイダンス)。

詳細情報

技術ブログ

Azureに関する技術情報