SAP システムの Microsoft Azure への移行に関する戦略を分析する

  • 10 分

SAP ワークロードを Azure にデプロイすることを検討している多くのお客様は、オンプレミスにある既存の SAP の実装を利用しています。 まったく新しいデプロイの数はそれほど多くありません。

通常、企業には、エンタープライズ リソース プランニング (ERP)、グローバル取引、ビジネス インテリジェンス (BI) などのビジネス機能用の SAP システムがあります。 それらのシステム内には、サンドボックス、開発、テスト、運用などの環境があります。

環境の例を示すダイアグラム。

上の図に示されている水平の各行は環境です。 各列は、ビジネス機能 (ERP や BI など) 用の SAP システムです。

下部にある行またはレイヤーは低リスクの環境であり、それほど重要ではありません。 上に向かうほどリスクが高く、より重要になります。 スタックを上に移動するほど、移行プロセスのリスクが高くなります。 したがって、運用が最も重要な環境であり、ユーザー受け入れテスト (テスト) の環境 (ビジネス継続性にも使用されます) がその次に重要です。

下部にあるシステムは小規模であり、コンピューティング リソースの数は少なく、可用性とサイズの要件は低く、スループットは小さくなります。 ただし、ストレージの量は運用データベースと同じです。

水平方向の戦略

水平方向の戦略では、スタックの一番下から始めます。これは、Azure を試して経験を積むのに安全な方法であるためです。 また、運用、デプロイ、承認のプロセスを再定義するときに使用するのにも適した戦略です。 これらのプロセスは、Azure に移行すると変更されます。 この戦略がどのように働くのかを次に説明します。

  • リスクを制限するため、影響の小さいサンドボックスまたはトレーニング システムから始めます。 何か問題が発生した場合、多くのユーザーやミッション クリティカルなビジネス機能に影響する危険性はほとんどありません。
  • その後、Azure での SAP システムの実行、ホスティング、管理に関する経験を積んだら、スタックで 1 つ上にあるシステムのレイヤーに、学習したことを適用します。
  • 各レイヤーごとに、コスト、コスト削減の可能性、パフォーマンス、最適化の可能性を推定し、必要に応じて調整します。

垂直方向の戦略

Azure で運用システムに関する経験を得るには、水平方向の戦略と並行して、リスクの低いシステムで垂直方向の戦略を使用することができます。 これにより、Azure に関する内部プロセスを調整し、チームのメンバーをトレーニングすることもできます。 これは、運用環境での問題を早期に発見するのに優れた方法です。 この戦略がどのように働くのかを次に説明します。

  • コスト、顧客、サービス レベル アグリーメント (SLA)、および法的要件への影響を確認します。 最初に、リスクが最も低いシステムを、サンドボックスから運用まで移動します。まず、ガバナンス、リスク、コンプライアンス システム、次にオブジェクト イベント リポジトリ (OER) システムです。 その後、BI や ERP など、それよりリスクが高いものを移動します。
  • 新しい SAP システムがある場合は、オンプレミスに配置して後で移動するのではなく、最初から Azure で開始します。 図では、OER がこの例です。 OER は、リスクの低い新しいシステムです。 水平方向の戦略を使用して他のシステムの一部を Azure に移動した後は、OER の垂直方向のスタック (サンドボックスから運用まで) の全体を Azure にデプロイできます。
  • 最も重要なシステムを最初に移動しないでください。 最後に移動するシステムは、最もリスクが高く、最もミッション クリティカルなシステムである、ERP 運用システムです。 最もパフォーマンスが高い仮想マシン SKU と最大のストレージが必要です。
  • スタンドアロン システムを最初に移動します。 一部のシステムは、他のシステムと密接に結合されています (ERP システムと GTS システムなど)。 この 2 つの間には、同期的なリアルタイム トラフィックが大量にあります。 ERP を Azure に移動しても、GTS をオンプレミスに残しておいたのでは、ネットワークの待機時間のためにパフォーマンスが低下するので、それらをまとめて移動します。
  • 複数の SAP システムがある場合は、上流と下流の依存関係を調べます (ある SAP システムから他への、または SAP から SAP エコシステムの外部にあるアプリへの)。 待機時間による影響を受けやすいトラフィック パターンと領域を調べます。
  • 緊密に接続されたシステムがある場合は、パフォーマンス分析を行って、移動による影響を確認します。 影響が大きくない場合は、Azure に個別に移動します (ERP に依存しないビジネス ウェアハウスなど)。 そうでない場合は、移行グループを作成し、まとめて移動します。
  • 場合によっては、待機することを検討します。 特定のシステムを Azure にすぐに移動したくないこともあります。 これは、処理要件が非常に高くて仮想マシンの大きさがまだ十分ではないという、サイズ設定の要件に関連する可能性があります。 テストを実行し、これらのシステムを移動しても顧客との SLA に影響しないことを確認します。