この記事について
更新履歴
この記事は適宜更新・修正されます。ここに簡単に記載しています。
2020/5/17
・P30以上のManaged Disks（Premium SSDのみ）については、気づいたら予約できるようになっていたので修正しました。
2019/12/10
・ExpressRouteに関する記載を修正しました。
・検討ポイントにSQLServerのライセンスを追加しました。
はじめに
この記事は SAP Advent Calendar 2019 の12月2日の記事として投稿しています。
Advent Calendar 2019が始まってまだ2日め。明日以降に投稿される記事も楽しみです。
あ、1日目のteru4454さんの「#大手町ビル六階聖地化計画」読まれました？
ハードル下げてくださいましたので、少しゆるく書いていきたいと思います（笑）
筆者の課題認識
企業活動の一環としてのシステム構築には、たとえクラウド環境構築のトライアルであったとしても予算見積活動が必要となることが常です。そのため各クラウドベンダーは簡易見積ツールを提供しています。
しかしながら現実的な課題としてどういった構成にすればよいか分からないため見積ツールに入力する情報がないor迷うという壁に当たることが挙げられます。SAP on Azureのリファレンスアーキテクチャは存在していますが、レイヤーやシステムごとに2台ずつマシンを用意する構成ためToo muchに見えますし、そのような構成の背景が少し見えにくいのかな、と考えています。逆に背景が見えると迷いなどが無くなって前に進めるのかな、と考えています。
この記事で書かれていること
そこで本記事ではSAP NetWeaver のための Azure Virtual Machines の計画と実装を読み進める前、見積もりをする際に知っておきたいことをまとめています。流れとしてはAzureの特徴を簡単に把握しつつ留意事項を頭の片隅に留め、筆者が特に重要と考える検討事項を記載しています。
AzureということもありOS/DBは、Windows Server/ SQLServerを前提としています。HANAではないのですが、留意事項/検討事項はそのまま流用できると考えています。当然ながらSAP Business Suiteと運用管理ツール・帳票ツール等の周辺システムを構築・移行することを念頭に置いています。
「先にこういうこと知ってたら何度も設計を考え直さなかったんじゃないかな」という筆者の後悔から得た知見も含んでいますので、Too muchに見えるリファレンスアーキテクチャ通りにすべきなのか、あるいはもう少し簡単な構成にできるのか、本記事が読者の判断の一助となればと思います。
Azureでイケると判断した場合はSAP NetWeaver のための Azure Virtual Machines の計画と実装や各周辺製品のガイドラインに従ってAzureの道を歩み始めることができるでしょうし、そうでない場合もあるかもしれません。
対象読者
「Azureを触ったことはないけれどもクラウド移行検討の必要に迫られAzureの非機能の特徴を自分で調べずに楽して知りたい」、あるいは「Azureといっても他のクラウドと同じでしょ、他と同じように構成するから大丈夫（爆」と考えている、SAPベーシスな方々を想定しています。
（楽な道はないのですが、せめて知識を一気にインプットする高速道路くらいのお手伝いになれば・・）
Azureの特徴を知る
簡単にVMまわりのサービス説明
ここではVM設計を考えるために必須となるサービスの知識をサッと記載します。
以降、本文黒太字の箇所はこの記事から持ち帰っていただきたい箇所です。
仮想マシン
特段注意すべき箇所はありません。
仮想マシンについてはいくつものシリーズがありますが、導入しようとしている製品がどのシリーズをサポートしているか、くらい気にしましょう。「恐らく何でも良いだろう」とは考えず、分からなければ各製品のベンダーに問合せましょう。
SAP製品についてはSAPノート1928533にサポート対象が明記されています。
ストレージ
サービスの種類が多く、Azure理解の最初の壁です。理解を楽にするため少し雑に切り分けてみます。ディスクのタイプにはStandard / Premiumがあります。ストレージはストレージアカウントで管理するのですが、ユーザーに代わってAzure側で管理を実施してくれるものがManaged、そうでないものがUnmanagedです。導入する製品がどのディスクをサポートしているのか星取表を作成するために、下図の様なイメージを頭の中で持っておくと楽です。
StandardとPremiumの違いはIOPSです。Managed Disks の価格に詳しく書かれています。よく選ばれるであろう512GiBと1TiBのManaged SSDを比較すると下表となります。
このIOPSを見て分かる通り、余程の理由がない限りPremium SSD Managed Disksを選択します。触った実感としてはStandard SSD Managed Disksで構築したOSを触ったときはモッサリ感があったのですが、Premium SSD Managed Disksで構築したOSは普通でした。
Standard/Premiumの選択はIOPS以外にも後述の可用性で関わってきます。
少し古い記事ですがJapan Azure IaaS Support BlogのAzureディスクストレージの種類(2018年6月現在)も大変参考になりますので併せて読むと良いでしょう。
サービスの種類を理解したら、次はOSから見たディスクの話です。
AzureではWindowsのディスクにディスクロールと呼ばれる役割の名称を与えています。「OSディスク」「一時ディスク」「データディスク」の3つです。このうち「一時ディスク」に注意しましょう。
「一時ディスク」はVM構築時に自動的についてくる、永続性保証のないディスクです。つまりデータが消えます。Windows Serverで構築すると、通常はDドライブが一時ディスクとなり、ドライブ直下には下図のように注意書きのREADMEが自動的に配置されています。
↓ Azure Windows OSでこのファイルをみかけたらご用心
自社－Azure間のネットワーク
ネットワーク管理をなさった経験がないSAPベーシスの方は、自社のネットワーク担当者をプロジェクトに巻き込みます。ネットワークに関しては恐らくこれが一番の注意点です。
機能的には普通のネットワークなので、物凄く注意するといった箇所はありません。
あと、この章だけやたらとリンクが多いのですが、そこは察して下さい（笑）
AzureではExpressRouteと呼ばれるプライベート接続サービスがあります。
★2019/12/10 修正 Start
ExpressRouteについてはAzureリージョン（日本でいうと、東日本と西日本の2つのリージョンが記載時点であります）とは別に、ExpressRouteの場所を理解する必要があります。ドキュメントを読んでみましょう。
地理的リージョン内の少なくとも 1 つの ExpressRoute の場所に接続している場合は、その地理的リージョン内のすべてのリージョンの Azure サービスにアクセスできます。
この地理的リージョン・Azureリージョン・ExpressRouteの場所の関係を理解しないといけません。日本でいうと地理的リージョンは日本。そこに存在するAzureリージョンは東日本・西日本の2つ。ExpressRouteの場所は東京・大阪の2つです。
東京または大阪にExpressRouteで接続すれば、地理的リージョンである日本に含まれる東日本リージョン・西日本リージョンのいずれに構築されたVMに対してもExpressRouteで接続することができる、と言っています。
ExpressRouteに接続できる接続プロバイダーのリストがありますので、どの場所がどのプロバイダーに対応しているのか、こちらを確認しましょう。
地理的リージョンをまたぐ場合はExpressRoute Premiumを追加で利用すればよいです。「新規オフィスを立ててExpressRouteでSAPシステムに接続させるんだよなぁ、でも自社ネットワークを構築するの面倒だなぁ」という場合には、ExpressRoute Global Reachを申し込むことで、ExpressRoute側の回線を通して新規オフィスとネットワーク接続することもできます（このあたりはSAP on Azureに直接関係ないですが）。
★2019/12/10 修正 End
ExpressRouteの概要によればExpressRoute－接続プロバイダー間は冗長接続されているようです。このため、自社－接続プロバイダー間の回線も冗長化するようにしましょう。
ExpressRouteの拡張性を確認すると「バースト」という言葉が出てきます。「やったー、これでデータ伝送にかかる時間が半分だ！」と早とちりしないよう注意してください。最初、筆者もぬか喜びしました（笑）。Active-Active回線の両方を使うことを「バースト」と呼んでいるので、自社－接続プロバイダー間の回線がActive/StandByの場合はバーストできないと考えましょう。というか、この機能については無いものと思ったほうがいいです。
ExpressRoute 回線は、購入した帯域幅制限の 2 倍までの一時的ネットワーク バーストを無料で許容できるように設計されています。 これは、冗長なリンクを使用することで実現します。 ただし、すべての接続プロバイダーが、この機能をサポートしているわけではありません。 この機能を使用する前に、接続プロバイダーによってこの機能が有効になっていることを確認してください。
予約による割引 ★2020/5/17 修正
よくある、長期間の利用枠を予約することで割引となるサービスです。Azure の予約とはに記載されている通り、1年もしくは3年が選択肢です。注意点は予約の対象となる料金に記載の通りですが、Managed Disksについて予約できるのはP30以上のPremium SSDのみという点です。しかも1年単位。
非機能について
IPA「非機能要求グレード2018」に沿って網羅的に記載しているわけではなく、環境構築において気になった箇所をまとめています。
非機能を実現するためのサービスについても知識をインプットします。
可用性
稼働率100%は現実的には実現できません。割り切りましょう。
Azureで構築する際は基本的に可用性ゾーンまたは可用性セットの中で2台以上のVMを立てることで可用性を高めます。可用性ゾーンですが、本記事執筆時点（2019/11）では東日本リージョンで利用でき、西日本リージョンでは提供されていません。
そもそもVMのSLAはどうなっているのでしょうか？
Virtual Machines の SLAに下記のように記載されています（2019/11時点）。さっと読んでみましょう。
- すべての仮想マシンに、同じ Azure リージョン内の 2 つ以上の可用性ゾーンにまたがりデプロイした 2 つ以上のインスタンスがある場合、マイクロソフトは、99.99% 以上の時間において少なくとも 1 つのインスタンスに対する仮想マシン接続が確保されることを保証します。
- すべての仮想マシンに、同じ可用性セットにデプロイした 2 つ以上のインスタンスがある場合、マイクロソフトは、99.95% 以上の時間において少なくとも 1 つのインスタンスに対する仮想マシン接続が確保されることを保証します。
- すべてのオペレーティング システム ディスクおよびデータ ディスクについて Premium Storage を使用する単一インスタンス仮想マシンについては、マイクロソフトは 99.9% 以上の時間において仮想マシン接続が確保されることを保証します。
単一仮想マシンの記載ではStorageについて言及されており、Standard storageが紐付いているとSLAの対象外です。可用性ゾーンや可用性セットについてはPremium storageの縛りがありません。ただぶっちゃけ話をしますと、SAPシステムインストール後にAzure拡張監視のためのツール（azmon4sap）をインストールするのですが、Standard storageで作られたドライブが紐付いていると普通に警告が表示されます。そもそもSAPシステムに要求されるIOPSを考えると最初からStandard storageを選択する余地はありません。周辺システムについては検討の余地が大いにあります。
バックアップについて少し触れます。
Azureでのバックアップの基本はAzure Backupサービスを利用することです。しかしいくつか制約があります。よく寄せられる質問 - Azure VM のバックアップに下記の記載があります。Azure BackupのみならずクラウドはManaged Serviceですので、このような制約を受け入れる必要があります（結構大事な姿勢の話）。キックされたバックアップが直ちに開始されるわけではない、くらいに理解したほうがよいです。
スケジュールされたバックアップは、スケジュールされたバックアップ時刻から 2 時間以内にトリガーされます。 たとえば、100 個の VM のバックアップ開始時刻が午前 2 時にスケジュールされている場合は、最長で午前 4 時までに 100 個のすべての VM のバックアップ ジョブが進行中になります。 スケジュールされたバックアップが停電のために一時停止され、再開または再試行された場合は、バックアップがこのスケジュールされた 2 時間の枠外で開始される可能性があります。
もう一つ注意すべき箇所はAzure Backupのバックアッププロセスです。普通に考えるとスナップショットが完了すれば次のバックアップを開始することができそうですが、データがコンテナにすぐにコピーされない場合があると記載されています。
スナップショット データはコンテナーにすぐにコピーされない場合があります。 ピーク時には、数時間かかる場合があります。 毎日のバックアップ ポリシーでは、VM のバックアップの合計時間は 24 時間未満になります。
そもそもスナップショットを複数持てるか否かについては言及されていないので、転送完了まで待つ必要が出てくるかもしれません。実際に試した際、前のバックアップが転送完了する前に開始した次のバックアップは最後の最後でエラーとなったこともありました。このあたりは筆者が試した後に改善されているかもしれませんので、なんとも言えない。。。
性能
SAP製品やSQLServerのパフォーマンスを向上させるためには、CPUのクロック数を上げる・データをできる限りメモリにキャッシュする・データ領域のI/O性能を向上させるといった対応が必要です。特にABAPとSQLServerの処理についてはCPUクロック数が効いてきます（余談ですがHANA DB上の処理は分散されるため論理コア数を増やすと効果的です）。Azureでは任意のCPUクロック数を選択することはできませんし、メモリサイズを含めてVMシリーズのどのVMを選ぶか、という部分にかかってきます。提供されているサービスを受け入れるしかありませんのであまり考える余地はありません。問題はストレージです。こちらはSQLServerのベストプラクティスに従いデータとログを別のストレージに配置し、特定箇所へのI/Oの集中を避けましょう。
周辺システムについても同じ考え方で、CPUクロックが求められるのか論理コア数が求められるのか、メモリキャッシュは重要か否か、ディスクI/Oはどの程度を要求されるのか、といった製品ごとの特性を考えてVM選択・ストレージ設計を実施する必要があります。
こうしてみると、実はオンプレ時代とかかる労力はあまり変わっていません。
拡張性
拡張性についてはクラウドの十八番と思われるでしょう。クラウドの基本通りAzureも従量課金制です。先述の通り他社のクラウド同様に予約することでコストメリットを享受することも可能です。
運用保守性
監視の話をします。
監視については普通に実施する必要があります。何度も記載したと思いますが「落ちる」前提はオンプレからクラウドに移行しても変わりません。構成によってはオンプレ時代よりも監視対象マシン台数が増えることがありますので、監視対象サーバーの台数によって変動するライセンスの場合は予算面での注意が必要です。
セキュリティ
Azure Network Security Group(NSG)で通信の可否を制御します。このあたりは自社の要件やソフトウェア仕様に従ってIP/Portを開ける/閉じるだけなので特に注意することもなく作業します。Azure内だけに気を取られて、オンプレ環境からAzureにデータ移行する際のIP/Portを開け忘れることがないよう注意しましょう。
Azure内においてAPIを用いてサーバーからAzure Backupなどの命令を発行する場合、命令発行するサーバーから直接インターネットへ接続できることが条件です。自社のセキュリティ要件に従い、基幹システムから直接インターネットに接続してよいかどうかは判断が必要ですが、Azure Backupが使えないと「バックアップ大丈夫でしたっけ？」という話になりますので、内部→外部のインターネットアクセスは許可すべきです。なお、Azure Backup等のAPI発行に際してグローバルIPは不要なので、そもそも外部からは見えません。
AzureのVMはいつダウンするのか
普通わざわざこういうことを書かないと思っていたのですが、VM の再起動の原因となる可能性がある操作とイベントに纏められています。この記事のおかげでAzureの好感度upです（よくわからないSLAなどの言葉で濁すのではなく「こういう場合に落ちるよ、落ちないように考えてね」ときちんとユーザーに伝える姿勢が本当に良いと思いました）。
2点注意が必要です。「メモリ保護更新（メモリ保持メンテナンス）」と「制限を超えるIO」です。
メモリ保護更新から確認しましょう。
メモリ保護更新は、インプレース ライブ マイグレーションを実現するテクノロジによって完了します。 更新中は、VM の状態が "一時停止" になります。 この状態で、RAM 内のメモリが保護され、基礎となるホスト オペレーティング システムが必要な更新プログラムと修正プログラムを受信します。VM は、30 秒以内の一時停止で再開されます。再開後、VM のクロックは自動的に同期されます。
VMが30秒以内の停止状態となっている、つまり周りからは止まっているように見える、と考える必要があります。構成検討そのものや設計上のシステム間接続リトライ系のパラメータ、クラスタであればハートビートに大きく影響しますので、とても重要な情報です。
制限を超えるIOについても確認しましょう。
1 秒あたりの I/O 操作の量 (IOPS) がディスクの I/O の上限を超えているために、I/O 要求のスロットルが連続的に行われていると、VM が一時的にシャットダウンされることがあります (たとえば Standard ディスク ストレージは 500 IOPS に制限されています)。この問題を軽減するには、ワークロードに応じて、ディスク ストライピングを使用するか、ゲスト VM 内に記憶域スペースを構成します。
少し嫌なことが書いてあります。特にStandard storageはIOPSが低いので、この制約に引っかからないように注意しながら構成する必要が出てきます。もちろんPremium storageであったとしても、構成設計をミスすると引っかかります。
検討ポイント
SAP製品+周辺システムで、ダウンしてもよいシステムはどれか？
全ての検討の土台であり、これが判別できるとVMまわりの基盤設計はほぼ終わりです。ダウンしてもよいシステムを業務ユーザーと一緒にしっかりと検討しましょう。「止まるのが嫌だ」「無停止が基本」と思考や会話を停止するのではなく、本当にダウンを許容できないシステムは何か、逆に多少ダウンしてもよいシステムは何か（xx時～xx時はOKという話ではなく、24/7の中で落ちても軽微な影響で済むもの）、星取表を作ります。なぜダウンしてはいけないのか、理由も確認しましょう。きちんとした理由もなく豪勢な構成になってしまったとしても、システム利用費は最終的に業務ユーザーの部門に課金請求されるはずです。そこで「こんなに高くなるなんて！」と言われても互いに困ります。業務ユーザーと一緒に汗を流す場面です。
星取表ですが、例えばこんな表です（本当はシステムメンテも加味して数字を作ります）。
上図の星取表となった場合、Solmanとアーカイブについては可用性部分の話から、単一VMでしかもStandard storageを利用することが可能と判断でき、費用を抑えることができそうです。その他については99.99%となるためAzure Availability Zones での SAP ワークロードの構成を参考に構成しましょう。
既存システムをAzureへ移行する場合、オンプレミスでサーバーやストレージを構成する際に基盤要件としての稼働率目標を定めていたはずです。ただしその数字はシステム全体の基盤を十把一絡げに「本番環境のサーバー稼働率目標は99.99%とする」という具合に定められていたことでしょう。まずその当時の基盤要件を持って業務ユーザーと「実際どうなの？」と会話しましょう。オンプレミス導入当時とは業務側のビジネスプロセスは変化しており要望は異なっているはずです。クラウド化に当たってはシステムごとにきちんとした理由のある稼働率を定めることで、必要なリソースを確保するだけの予算として社内で申請することができます。
どのストレージを利用すべきか？
上述の星取表を作らないと検討できません。何度も言いますが「作れない」で止まるのではなく、もしも作れないのであればちょっと業務ユーザーのところに行って話をしましょう。
基本の発想は「単一VMはPremium SSD Managed Disks」、「可用性セットや可用性ゾーンにVMを構築するのであればSAPシステムはPremium SSD Managed Disks、周辺システムはStandard SSD Managed Disksも検討」です。
ただしデータアーカイブのように、大容量ディスクを必要としつつもコールドデータであるためそこまでのI/Oや稼働率を要求しないシステムについては単一VMをStandard storageで構築しても問題ないでしょう。
DBサーバーについては、Premium SSD Managed Disksの構成に注意しましょう。例えば1TiBのPremium SSD Managed Diskを購入し、OS上でそれらをドライブごとに分けて・・・ということはしないように。オンプレ時代同様にDBファイルとLogファイルを別のディスクにするため、DBファイルとLogファイルは別のPremium SSD Managed Diskを購入しましょう。I/Oパフォーマンスを目一杯出すためDBファイル単位で購入しても良いと思います。DBファイル4つにLogファイル1つで構成しているのであれば、計5つ購入ですね。
システムごとにVMを複数台持たせるか？
これも星取表を元に決定します。
99.95%以上の稼働率目標を達成するためには、可用性ゾーンもしくは可用性セットを利用する必要があります。この時点で2台以上が確定します。もう少し突っ込むとSQLServerで可用性ゾーンや可用性セット採用となった場合、AlwaysOnやクラスタの仕組みが検討の中に入ります。SAP製品の場合はそこにASCS/PAS/AASといったレイヤーの検討も加わります。
99.5%以下の稼働率目標であれば単一構成です。SAP製品だとセントラル構成でササッと組めますね。
例えば先の星取表を元にすると、ERP/CRM/BW/運用管理/帳票の5システムは可用性ゾーンに構築するため各2台ずつは確定。ERP/CRM/BWについてSQLServerをAlways Onにするため、DBサーバーを切り出してクラスタを作ることとなり、実はERP/CRM/BWはそれぞれ4台からスタートとなります。
だいぶ豪勢じゃないか？あのシステムそんなに使われてる？と感じるようであればそもそも稼働率目標が間違っているのかもしれません。ここまでくれば費用感は出ているので、一旦止まってもう一度業務ユーザーと会話するのもアリでしょう。
データ移行をどのように実施するか？
SAPシステムの移行であれば現在のシステムのデータサイズとシステム停止できる期間（データ移行とSAP NetWeaverアップデートなどの作業も含めて）、そして自社ネットワークの事情を考慮する事項です。身も蓋もない話をしますと、個社の事情により異なるので自社で答えを出すしかありません。他社事例は本当にJust Informationです。ただ、答えを出すべき項目は参考になります。開発・検証機を含めた全システムの「ダウンタイム」「移行時期」「移行手順」です。
例えば先の星取表のシステムで、3日のダウンタイムが許可され、データアーカイブをきちんと実施していることでキモとなるSAPシステムのデータ量がある程度抑えられており（例えばERP/CRMが500GB程度、BWが200GB程度）、現行システムからAzureまでの回線全体が1Gbpsとすれば、他タスクと併せてExpressRoute経由で特別なオプションがなくとも単純移行だけは達成できそうです。財務に関わるシステムであれば（SAPシステムは大抵会計システムなのでほぼ全てのシステムでしょう）、月次処理の時期や四半期・年次決算時期を避けるスケジュールとなるはずです。
このダウンタイム・移行時期時期・移行手順について、通常のプロジェクトであればほぼ間違いなくダウンタイムと移行時期が先に決まります。プロジェクト開始前に決まっていることも間々あります。このため、データサイズが大きい場合やダウンタイムが厳しい場合は、移行にかけられる予算を増やし移行手順の検討に力を注ぐという対応に迫られます。Near Zero Downtimeアプローチも検討が必要になってきます。その際SAP社のSystem Landscape Optimizationサービスの利用や、SNP社のTransformation Backboneを使えるパートナーを探すことも視野に入れましょう。
ExpressRouteは必要か？
考えるまでもなく必要で、検討すべきは帯域幅です。
移行すべきデータ量・移行手順を鑑みて決定します。移行時には帯域幅を増強してデータ移行にかかる時間を低減し、移行後にはネットワーク使用状況をみて帯域幅を低減させ費用を抑制しましょう。
予約でいくべきか、それとも従量課金か？
SAP製品に代表される基幹システムは、特に移行にあたってはActive User数やトランザクション量が急激に増減することは考えにくいため、本稼働後にはある程度の余裕をもたせた状態で予約することが妥当と考えられます。
既に本稼働済みだが展開の道半ばという場合は特にSAPシステムはPAS/AASを横拡張できるように準備し、移行そのものは予約で進める形が良いと考えられます。SQLServerについては極論利用しているストレージサイズの変更しかありません。そもそも予約の対象となる料金によればManaged Disksは予約による割引がないのでSQLServer用のVMについても予約で進められます。
本稼働前のプロジェクト期間については従量課金制を選択しましょう。プロジェクト上の都合によりVMスペックをリーズナブルに変動させることや、本稼働に向けどの程度のスペックで予約すべきか検討するタスクを鑑み、従量課金制とすることで予約にはない柔軟性を享受し固定化のリスクを排除すべきです。
バックアップはどうする？
Azure Backupを使いましょう。ただオンプレ時代にリストアポイントを作るためによく利用していたストレージ機能によるバックアップがないので、オンライン中にSQLServerのバックアップファイルを作り、あとはひたすらT-LOGバックアップを実行しましょう。バックアップデータにDR（テープの外部保管的な発想）を要求するのであれば、ページBLOBストレージのRA-GRS機能で、ペアリージョンにデータを飛ばすことを考えましょう。例えば東日本リージョンでVMを稼働している場合、ページBLOBは東日本リージョンで作成し、RA-GRSの機能で非同期で西日本リージョンにデータ送信してもらいます（こんな最後の最後に機能話を書いてスミマセン）。
SQLServerのライセンスは大丈夫？
SQLServerをクラウドのVMにインストールする場合、ライセンスに抵触しないよう注意する必要があります。専用ホスト クラウド サービスに関するマイクロソフト ライセンス条項の改定に記載されているように、一昔前は許されていた専有ホスト（Dedicated Host）型のサービスへのインストールにもSoftware Assurance（SA）が必要となっています。マイクロソフト社自身のAzureも対象に含まれていることが注意点です。
さらに踏み込むと、SAP社経由でライセンス供与されている場合はSAのみを単独購入できない可能性を考えて早めにSAP社/マイクロソフト社の営業担当とコンタクトを取り情報共有・確認すべきです。
まとめ
実際のプロジェクトではもっともっと検討すべき箇所が出てくるのですが、Azureを使いはじめる前に検討できるのはおよそ上述くらいかと思います。そして、上述の箇所が見えていれば、見積ツールのインプットもほぼ見えている状況となります。
少し長くなってしまいましたので、さっと纏めたいと思います。
Azureへの移行は他社クラウド同様の知識・感覚で実施できるか？
できません。AzureにはAzureの特徴があります。例えばメモリ保持メンテナンス時の挙動は知らないとシステム運用に影響する大きな特徴ですね。そういったAzureの特徴を理解してから臨みましょう。
SAPシステムをAzureに移行するとSAPベーシスのすべきことは変わるか？
少し変わります。オンプレのインフラ部分がバッサリ無くなったと思いましょう。インフラ障害対応で実機のところに行って機械を交換して・・・といった作業は無くなります。これは他社のクラウドでも同じでAzureだからということはないです。
この後どうしたらよいか？
まずAzureの場合の見積を作り、次に他社クラウドの場合の見積を作ります。SAP on Azureのリファレンスアーキテクチャの背景が理解できたと思いますので、他社サービスもそれぞれの背景があることを鑑み、リファレンスアーキテクチャを活用して同じ構成にしてみるのも良いかもしれません。
それらを比較し、どの会社のクラウドサービスを利用するのか決めます。
Azureを選択した場合は、SAP NetWeaver のための Azure Virtual Machines の計画と実装を読み進めつつ環境設計をはじめます。
SQLServerのライセンスについては、SAP社経由のライセンス供与なのか、それとも自社でライセンスを購入しているのか確認した後、それぞれの営業担当者と情報共有・確認しましょう。何も考えずにクラウド移行してライセンス違反とならないように。
おわりに
たまたま最近SAP on Azureに関わっていたことと、たまたま SAP Advent Calendar 2019 で投稿する機会を得ることができましたので、このような記事を書かせていただきました。機会をくださった皆様、ありがとうございます。
誤字脱字が見つかった場合や、後から思い立って追記することもあるやもしれませんが、追記の場合はいつ追記したか記載し、誤字脱字については黙ってこっそり修正します（笑）。
一応記載しておきますが、筆者の立場はクラウドベンダーに対して中立です。なので唐突にSAP on AWSやSAP on GCP、SAP on Alibaba Cloudなどの記載を始めるかもしれません。そのあたりはフワッとやっていければいいかなと思っています。
それでは！