青いセーターを着た人がコンピュータで作業している
Microsoft Base ロゴ

技術ブログ

Azureに関する技術情報

SAP on Azureの自動スケーリングがマイクロソフトにもたらすメリット

Azure

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

How auto-scaling SAP on Microsoft Azure is benefitting Microsoft

2021 年 2 月 11 日 | Douglas Gantenbein

Microsoft Azure 上の SAP の自動スケーリング プロジェクトを担当したチーム メンバー (左上から時計回りに)、Niranjan Maski、Santosh Rajput、Amit Ganguli、Karan Parseja、Sofia Ahmed の各氏 スクリーンショット

Microsoft Azure 上の SAP の自動スケーリング プロジェクトを担当したチーム メンバー (左上から時計回りに)、Niranjan Maski、Santosh Rajput、Amit Ganguli、Karan Parseja、Sofia Ahmed の各氏。

マイクロソフトでは、SAP ワークロードの効率的な実行を支援する、Microsoft Azure 上の SAP の自動スケーリングを実装しました。

いったいなぜ、と思う方も多いかもしれません。

多くの企業と同様に、マイクロソフトの基盤には SAP が稼働しているのです。

マイクロソフトでは、サプライ チェーンにおけるサーバーの追跡から、自社従業員 140,000 人の給与支払い期日の遵守まで、あらゆる処理に SAP を活用しています。マイクロソフトは世界最大規模の SAP デプロイメントを有する企業でもあるのです。

実際マイクロソフトでは、50 テラバイトの SAP データ (デジタル写真 700 万枚に相当する量) を 700 台の Microsoft Azure 仮想マシンで管理しています。使用量も年々倍増しており、毎月 3 億件もの SAP オペレーションが発生しています。

SAP ビジネス プロセス サービスの大量のデータを仮想マシン 700 台に移行する大規模なリフトアンドシフトは、2017 年にマイクロソフト Core Services Engineering (CSE) チームが主導しました。

移行の目的は、マイクロソフトの運用コストを削減しつつ信頼性を向上することでした。そして、この目的は達成されました。

しかし、CSE のシニア ソフトウェア エンジニア Sanoop Thrivikraman Nampoothiri は、できることはまだ残されていると語ります。

「いくつか手を入れるだけで、Azure 移行のメリットは大幅に広がると考えました。そこで、SAP アプリケーションの稼働に使われているリソースの管理を効率化する方法を考案しました」と Nampoothiri は言います。

この時点で CSE チームはすでに歩みを前に進めることに成功していました。オンプレミス ハードウェアとウォーターフォール型のエンジニアリング手法から脱却し、アップグレードをデプロイしたことで、Microsoft Azure オペレーションを開始してからの 2 年間で、SAP ワークロードの管理コストは 18% 削減されていました(この取り組みについてはこちらを参照)。

さらにマイクロソフトの SAP ワークロードを Azure にリフトアンドシフトしたことで、SAP アプリケーションを容易にスケーリングし、使用量の爆発的増加にも対応できるようになりました。

しかし CSE のエンジニアは、さらなる効率化を目指します。彼らは、仮想マシンでの SAP 実行によるコストの上昇、マイクロソフトの画一的なサーバー構成アプローチ、複雑な設定なしに SAP ワークロードを動的にスケーリングする方法がないといった問題点を認識していました。

[マイクロソフトによるエンドツーエンドの SAP 監視手法についてはこちらをご覧ください。マイクロソフトによる Microsoft Azure を活用したエンタープライズ環境のエンドツーエンドの健全性監視手法についてはこちらをご覧ください。マイクロソフトの重要な財務システムを Microsoft Azure に移行した方法についてはこちらをご覧ください。]

SAP をクラウド時代に適応させる

クラウドでの SAP 管理における 1 つの問題は、クラウドベースの SAP ユーザーは 2 億 2,000 万人を超えているにもかかわらず、今日の柔軟なクラウド インフラストラクチャに対する最適化が不完全という点です。

Nampoothiri は次のように説明します。「現在のシステムは 1990 年代に設計されていて、アーキテクチャは古く、Azure の各種サービス、特に Web サービスほどモダンではありません。その一方で、SAP は財務からサプライ チェーンのすべてを司る、マイクロソフトで最も忙しいサービスの 1 つでもあります。そして、私たちと同じこのような状況を、数多くのお客様が抱えています。」

その結果エンジニアは、SAP に代表されるミッションクリティカルなアプリケーションの管理に慎重姿勢をとり、常時アクセス維持のために十分な処理能力を確保するようになります。

「このようなシステムの設計は常にピーク負荷を前提としたものになり、マイクロソフトのお客様の大半も、同じやり方を採用しています。しかし Azure の柔軟性はかなり高いため、システムのサイズを最適化することが可能です」と Nampoothiri は言います。

ここで、SAP アプリケーション サーバーに自動化と最適化の大きな効果がもたらされます。Microsoft Azure Monitor による監視と Microsoft Azure Automation の機能を組み合わせることで、アプリケーション サーバーを自由自在にスケーリングできるようになります。

CSE では SAP の使用量と安定性を Microsoft Azure Monitor で綿密に監視し、予測分析などの技術を適用して、潜在的な問題を未然に特定しています。同じ監視機能で SAP インフラストラクチャの負荷も測定できるため、使用パターンを明確に可視化できます。

ハイデラバードの CSE でソフトウェア エンジニアを務める Karan Parseja は次のように説明します。「Microsoft Azure Monitor が提供するテレメトリにより、さまざまなワークグループのさまざまな負荷を把握できるようになりました。次のステップとして目指すことになったのは、負荷レベルを下げて実行すべきサーバーを判定し、それらのサーバーの処理能力を自動で縮小するソリューションの構築でした。また、必要に応じてアプリケーションを正常に停止できるソリューションも必要でした。」

そこで採用されたのが、自動スケーリング、タイトサイジング、一時停止のアプローチです。

700 台を超える仮想マシン (VM) を Azure に移行した後も、私たちはインフラストラクチャ リソースのさらなる最適化の余地を常に探していました。

– Santosh Rajput、シニア ソフトウェア エンジニア、Core Services Engineering

自動スケーリングにより Microsoft Azure の SAP 稼働を効率化

Microsoft Azure 上の SAP の自動スケーリングのきっかけは「ハッカソン」で生まれました。ハッカソンとは、参加者でチームを作り、彼ら自身で採用したアイデアの具現化に 1 週間かけて取り組む、マイクロソフトの毎年恒例のイベントです。

CSE のシニア ソフトウェア エンジニアである Santosh Rajput は言います。「700 台を超える VM を Azure に移行した後も、私たちはインフラストラクチャ リソースのさらなる最適化の余地を常に探していました。あるハッカソンで浮上したのが、SAP アプリケーション サーバーのスケール イン/スケール アウトを自動化/リアルタイム化するというアイデアです。」

これらすべてを踏まえ、CSE チームは、Microsoft Azure で実行される SAP の改善に次の 3 つのアプローチで臨みました。

自動スケーリング。CSE チームは、Microsoft Azure を必要に応じてスケール アップできる「インフラストラクチャ オンデマンド」のアプローチを一部に採用しました。これは、SAP Quick Sizer ツールを使用して必要な VM の処理能力を正確に見積もり、その数値に沿ってスケーリングするものです。これにより計画期間を数年から 6 か月に短縮し、需要に応じた精度の高い調整が可能になりました。

タイトサイジング。システム需要のピークは大半が予測可能で、特に集中するのは四半期末や年度末です。CSE チームは、予測されるピーク需要とシステムの処理能力が相関するように、SAP を実行する VM アレイを再設計しました。

一時停止。最も大きな変化は、常時オン状態というオリジナル設定から脱却したことでしょう。Microsoft Azure チームは Microsoft PowerShell を使用して、需要が発生しない時間帯にシステムを「スリープ」状態に移行できる機能を実現しました。ただし週末作業でアクセスを必要とするユーザーがいれば、仮想マシンは瞬時にオンラインに復帰して処理に対応できます。

再構築されたシステムは、障害点の削減や冗長性の大幅な向上といった部分でも設計が見直され、予期しない不具合への防御力を高めています。データベースも二重化され、一方がクラッシュした場合はフェールオーバーが自動実行されます。このことで、作業の需要を後回しにすることなく簡単にシステム アップグレードを実行できるようにもなります。

複数のサーバー、テレメトリ、複数の SQL データベース、Microsoft Azure Logic Apps で SAP インフラストラクチャを構成することで、Microsoft Azure による需要ベースの SAP のスケール アップ/スケール ダウンを実現しています。

しかしまだ最大の障壁が残されていました。これまで紹介した改善策をデプロイする方法を探す作業です。マイクロソフトの SAP インフラストラクチャのスムーズな稼働を維持しつつ、Microsoft Azure 上の SAP の自動スケーリングという変更を実装しなければなりません。これは、飛行中のジェット旅客機を外から修理するようなものです。

Rajput は次のように述べています。「システムの可用性を犠牲にしなくても完全にうまくいくことを、社内のステークホルダーに納得してもらう必要がありました。同じような心配は、SAP と Azure を稼働しているすべてのお客様に降りかかると思います。」

移行を「賭け」にしたくはありませんでした。Azure で SAP を実行する方法の、考えられる限りの最善策を周囲に示す必要がありました。そのため慎重を期してピーク負荷時の可用性を重視しました。ただ現在は、Azure が SAP ワークロードを処理できるという確信を得たことで、最適化の段階に歩みを進めています。

– Niranjan Maski、シニア プログラム マネージャー、Core Services Engineering

ハイデラバードの CSE でシニア プログラム マネージャーを務めるNiranjan Maski も同意見です。

「移行を『賭け』にしたくはありませんでした。Azure で SAP を実行する方法の、考えられる限りの最善策を周囲に示す必要がありました。そのため慎重を期してピーク負荷時の可用性を重視しました。ただ現在は、Azure が SAP ワークロードを処理できるという確信を得たことで、最適化の段階に歩みを進めています。」

SAP がお客様にもたらす成果をさらに広げるために

全体的には、Microsoft Azure 上の SAP の自動スケーリングによって SAP 実行のコストがさらに 18% 削減され、その過程を通してシステムの堅牢性がさらに高まるという結果になりました。

これらの改善点は現時点ではマイクロソフト内部だけの成果ですが、今後は Microsoft Azure と SAP を運用中のお客様にも実現していただくことが可能です。このような展開は、自社のクラウド サービスで SAP を稼働している競合他社に対して Microsoft Azure が肩を並べ、より優位に立っていくうえで重要な段階にもなるはずです。

「COVID-19 により、IT インフラストラクチャをクラウドに移行して回復性と柔軟性の向上を図る企業はますます増えています。SAP が実行するエンタープライズ リソース プランニング (ERP) が最大のワークロードであるというマイクロソフトのお客様は多く、クラウド移行によるコスト削減効果をマイクロソフト自身が実証することで、クラウドの採用をさらに加速できると思います」と Rajput は言います。

ハイデラバード在住の CSE プログラム マネジメント ディレクター Amit Ganguli は、自動スケーリングを Microsoft Azure のアドオンとして提供する選択肢もあると言います。現在プレビュー中で、GitHub でオープンソース コードを提供している Microsoft Azure Monitor を活用する可能性もあります。

彼らのチームにとって何よりも大きな満足は、これだけ少数のメンバーで重要な進化を成し遂げたことです。

Rajput は次のように語ります。「このチーム メンバーを本当に誇りに思っています。マイクロソフトの強みは、今回のような重要な問題が浮上したときに、チームを瞬時に編成して解決できることです。ただ仕事をこなしている、という感覚はありません。お客様にポジティブな影響を及ぼしているという確信が、私を奮い立たせています。」

マイクロソフトによるエンドツーエンドの SAP 監視手法についてはこちらをご覧ください。

マイクロソフトによる Microsoft Azure を活用したエンタープライズ環境のエンドツーエンドの健全性監視手法についてはこちらをご覧ください。

マイクロソフトの基幹財務システムを Microsoft Azure に移行した方法についてはこちらをご覧ください。

< 前の記事

> 次の記事

ページの先頭へ戻る