SAP HANA on Azure への移行

執筆者:  Michiel van Otegem

このポストは、2017 年 7 月 1 日に投稿された Migrating to SAP HANA on Azure の翻訳です。

 

SAP HANA DBMS 上の S/4HANA は、SAP Business Suite 7 の多くの機能を強化し、ビジネス プロセスに付加価値を与えるものになっています。このため、お客様に DBMS として SAP HANA を使用する SAP S/4HANA に移行することを、説得力を持ってお勧めできるようになりました。また、S/4 HANA への移行をお勧めするもう 1 つの理由は、SAP ノート #1648480 – 「Maintenance for SAP Business Suite 7 Software」で詳しく説明されているように、ABAP スタックを基盤とするすべての SAP Business Suite 7 アプリケーションのサポートが 2025 年に終了してしまうことがあります。上記の SAP ノートには、すべての SAP Business Suite 7 アプリケーションのサポートと SAP Java スタックの各バージョンのサポート期限が記載されているのでご確認ください。

注: リンク先の SAP ドキュメントを参照するには、SAP のアカウントでログインが必要な場合があります。

HANA への移行戦略

SAP HANA は SAP が販売する高性能インメモリ データベースです。SAP ERP や SAP BW などの SAP NetWeaver ベースのアプリケーションのほとんどを実行できます。機能的には、SAP をサポートしている他の DBMS (SQL Server、Oracle、DB2 など) 上で NetWeaver アプリケーションを実行する場合と、ほとんど違いはありません。詳細については、SAP 製品のリリース一覧 (英語) を参照してください。

一方、次世代の SAP プラットフォームである S/4HANA および BW/4HANA は、HANA に特化した設計となっており、SAP HANA DBMS の能力を最大限に活用できます。S/4HANA への移行戦略としては、次の 2 つをお勧めします。

HANA への移行については、どちらの戦略を採用するかがカギとなります。各戦略の影響とメリットは、SAP、ユーザー、Azure の観点で大きく異なります。2 番目の移行戦略の最初のステップは技術的な移行のみで、ビジネス プロセスの観点からはわずかなメリットしかありません。一方、S/4HANA への移行 (1 番目の直接移行、2番目 の 2 つ目のステップ) は機能的な移行となります。機能的な移行は業務やビジネス プロセスに与える影響が大きく、移行に必要な工数も増えます。通常、SAP S/4HANA への移行には、ビジネス プロセスのマッピングの大幅な変更が伴います。このため、マイクロソフトのグローバル システム インテグレーターが関与する S/4HANA プロジェクトの多くでは、各種 SAP 製品や LOB 製品へのビジネス プロセスのマッピングや SaaS サービスの使用方法の完全な見直しが必要となっています。

HANA とクラウド

S/4HANA を基盤にビジネス プロセスのマッピングの再構築と統合を行う以外にも、S/4HANA と SAP HANA DBMS の両方またはいずれかを使用する場合には、SAP のワークロードを Microsoft Azure などのパブリック クラウドに移行することを検討する余地があります。多くの場合、Azure を使用することで、移行コストを最小限に抑えながら SAP 環境の柔軟性を向上させることができます。SAP HANA ではほとんどのデータをメモリ上に保持する必要があるため、それまで使用されていたサーバー ハードウェアと比較するとサーバー インフラストラクチャのコストが上昇する傾向があります。

一方、Azure は TCO が低く、SAP HANA を基盤とするワークロードをホストするパブリック クラウドとしては理想的です。また、リソースを柔軟に取得したり解放したりできるため、コスト削減にも効果があります。たとえば、SAP のような多層システム環境では、処理負荷に応じて SAP システム内の SAP アプリケーション インスタンスの数を柔軟に増減させることができます。また、最新の発表では、SAP HANA に特化した パブリック クラウドで最大規模となるサーバー SKU が Microsoft Azure で提供されることがアナウンスされました。

現在の Azure SAP HANA の機能

下の図は、SAP HANA 実行環境としての Azure 認定状況です。

HANA ラージインスタンスは、大規模な HANA ワークロードを実行するベア メタル ソリューションです。最大 20 TB までのスケールアップと、複数の HANA ラージインスタンスによる最大 60 TB までのスケールアウトが可能です。HANA ラージインスタンスは、インスタンスのサイズに応じて 1 年または 3 年の契約で購入できます。3 年契約の場合は大幅な割引が適用され、非常に手頃な価格で高い性能が得られます。HANA ラージインスタンスはベア メタル ソリューションであるため、注文プロセスは Azure 仮想マシン (VM) の注文やデプロイとは異なります。VM は Azure ポータルから作成でき、数分ほどで使用可能となります。HANA ラージインスタンス ユニットは、発注してから数日以内で使用を開始できます。HANA ラージインスタンスの詳細については、「SAP HANA on Azure (L インスタンス) の概要とアーキテクチャ」ドキュメントを参照してください。

HANA ラージインスタンスを発注する際には、SAP HANA on Azure に関する情報のリクエストへの記載をお願いします。

上の図を見るとわかるとおり、すべての Azure SKU ですべての SAP ワークロードを実行することが認められているわけではありません。HANA ワークロードは大規模な VM SKU でのみ認定されています。開発/検証用ワークロードでは、DS13v2 や DS14v2 などの比較的小規模な VM サイズを使用できます。メモリ負荷が非常に高い場合、既存 SAP 環境の HANA on Azure への移行のために、HANA ラージインスタンスが必要になります。

先日 Jason Zander のブログ記事で新しいサイズの Azure VM が発表されました。この新しいサイズと合わせ、既存の VM サイズの一部の認定が Azure のロードマップで予定されています。新しい VM サイズの導入により、SAP HANA や S/4HANA、BW/4HANA のインスタンスを Azure に移行する場合に、より柔軟な選択が可能になります。認定に関する最新情報については、SAP HANA on Azure のページをご覧ください。

複数のデータベースを単一のラージインスタンスに統合

Azure は、SAP システムや SAP HANA システムを実行するプラットフォームとして非常に優れています。Azure を使用すると、オンプレミスやホスト型のソリューションよりもコストを削減できるうえ、高い柔軟性や堅牢な災害復旧機能が得られます。大規模な HANA データベースのメリットについては既に説明しましたが、比較的小規模な HANA データベースの場合はどうでしょうか?

中堅中小企業や部署単位のシステムでよく使用される比較的小規模な HANA データベースは、1 つのインスタンスに統合すると、低コストで高性能を得られるという大規模インスタンスのメリットを享受できます。SAP HANA では以下の 2 つのオプションを選択できます。

  • MCOS – 複数のコンポーネントを 1 つのシステムで運用
  • MDC – マルチテナント データベース コンテナー

この 2 つの違いの詳細については、SAP の Web サイトのマルチテナントに関する記事 (英語) を参照してください。マルチテナント オプションのさらに詳しい情報については、SAP ノートの #1681092 (英語)#1826100 (英語)#2096000 (英語) を参照してください。

MCOS は、単一顧客向けのオプションです。SAP ホスティング パートナーが HANA ラージインスタンスを複数の顧客で共有する場合は、MDC を使用します。

SAP Business Suite (OLTP) を SAP HANA 上に展開したい場合、SAP HANA を HANA ラージインスタンスの一部としてホストできます。SAP アプリケーションレイヤはネイティブ Azure VM でホストされ、その柔軟性を活用できます。M シリーズ VM が利用できるようになれば、SAP HANA の部分についても VM でホストでき、より高い柔軟性が実現できます。

SAP ワークロードを Azure に移行する動き

Azure は、さまざまな業界のお客様の間で、SAP ワークロードを実行するプラットフォームとして大きな注目を集めています。Azure は SAP HANA のプラットフォームとして理想的ではあるものの、多くのお客様はまず SAP NetWeaver システムを Azure に移行するところから始めています。Oracle、SQL Server、DB2、SAP ASE を実行する環境をクラウドに移行する場合だけでなく、UNIX を基盤とするプロプラエタリなオンプレミス システムを、Azure 上の Windows/SQL Server、Windows/Oracle、Linux/DB2 の SAP システムに移行したお客様もいます。

マイクロソフトと協業しているシステム インテグレーターの多くは、このようなお客様が増えていることを実感しています。ほとんどのお客様は、SAP Business Suite 7 アプリケーションの SAP HANA への移行をスキップし、S/4HANA への移行に集中して長期的に行うという戦略を取っています。要約すると、この戦略は下記の通りです。

  1. 短期: SAP 環境を Azure 上の標準的の OS プラットフォームに移行し、コスト削減に集中する
  2. 短~中期: 開発・検証用の S/4HANA を Azure に展開。Azure の柔軟性を利用して、ハードウェアを購入することなく、迅速に POC (概念実証) 環境や開発環境の作成 (および削除) を行う
  3. 中~長期: Azure に S/4HANA ベースの SAP アプリケーションの本稼働環境をデプロイする