第1.0版　2014年10月29日オンプレミスで稼働中のSAPシステムをパブリッククラウドに移行する際の検討項目本表は、SAPシステムのクラウド化にあたり、オンプレミスでは出来ていたことで見直す必要がある事項を中心に整理しています SAP認定パブリッククラウドプライベートクラウド/仮想化環境・基本的にはSAP Noteを参照してお客様/SIerが実施。運用実績・サイジング要件はお客様/SIerが取りまとめ、HWベンダーに依・サイジング要件はお客様/SIerが取りまとめ、HWベンダーに依数が少ないこともあり、SIerによっては精緻なサイジングノウハ頼してSAP認定HWでの構成と見積を入手。仮想化ソフトウェア頼してSAP認定HWでの構成と見積を入手。SAP認定テクノロジーウを保有していないため、パートナー選定が重要 (ハイパーバイザー)もSAP認定製品を採用する。仮想環境を利用しパートナーによる20年以上の運用実績から精緻なサイジングが実・決められたSAP認定構成から選択する必要があり粒度が荒いた本番稼働の実績も5年以上積まれ、物理環境と同様に精緻なサイ施可能 (CPU/メモリスペックはインスタンスタイプが最小単位) ジングができるようになっている・HW要件は物理搭載可能な最小単位で細かく指定できる・SAP認定構成では性能の上限値が決まっている・仮想化ソフトウェアの仮想マシン上限(e.g. VMwareの場合で・認定HWの性能限界まで対応可能(IA機で8CPU/120コア/12TB ・インスタンスタイプの変更/追加により柔軟なスケールアップ/ス 64vCPU/1TBメモリ)まで対応可能サイジング物理環境メモリの強力なリソースが利用可能、高いIOPSを保証) ケールアウト構成が取れる（スモールスタートを実現）ため、精・物理ホストは最大8CPU/120コア/12TBメモリの強力なリソース・パフォーマンスを最大限発揮、QoSなど細かな調整も可緻なサイジングは必要ない。一方で変動要素が入り予算管理が難が利用可能なため、仮想マシンの集約率も非常に高く、低コスト・安全率や数年先のリソース増加を見据えた余裕のある設計が必しくなる。ただし、ERPのように業務処理量が予想できるシステムで構築できるようになってきた要であり、初期の無駄が多く、使用率が低くなる可能性もあるでは所要量変化への俊敏性および柔軟性が必要ない場合もあるた・Hot-Add機能で仮想マシンへの動的なリソース増設は可能なた・リソースの増減は高コストで構成変更にかかるリードタイムもめ要件を明確にすることが重要め、物理ホストのリソースに余裕がある限り柔軟なシステム変更長くなるが、適切なサイジングができるので予算計画が立てやす・共用型のためパフォーマンスはベストエフォートに対応い・UNIX環境は提供されないためIA(Windows or Linux)にOSマイグレーションが必要 (ベンダークラウドの場合) ・Oracle DatabaseはAzureでのみ認定されているため、AWSの・クラウド環境を提供するベンダーにサイジングを依頼する(裏で場合は他のSAP認定DBへのマイグレーションを検討する必要があ HW提供元のSAP認定テクノロジーパートナーが実施している場合るが多い) ・分散構成(DB/AP)は同一グループ内で構成する必要があるな・クラウドベンダーによっては高いIOPS性能には対応できない場ど、インスタンス配置やネットワーク設計に注意が必要合もある・従来のBASISスキルに加えて仮想環境の運用スキル＋パブリッ・従来のBASISスキルに加えて仮想環境の運用スキルが必要。す・ハードウェアの機能が進化してもBASIS作業自体はさほど変わククラウドのスキルが必要。BASISエンジニアのスキルはまだ成でに運用実績も豊富でノウハウは成熟してきているらない。ベンダーから説明を受ければ新機能は吸収しやすい熟していない。新サービスの展開が速く、SIerによっては最新機・正式サポートにはSAP拡張監視の追加設定を正しく行う必要あり能の適用が十分できない可能性があるため、パートナー選定が重・SAP Landscape Virtualization ManagementによるSAPシステ要ムコピー自動化など仮想環境と連携したBASIS運用自動化の実装・正式サポートにはSAP拡張監視の追加設定を正しく行う必要ありも可能 SAP BASIS ・ストレージのコピー機能を使った移行はできないため(NetApp Private Storageソリューションを除く)、一般的なSAPシステムコピー(R3Load、DB機能)で移行する。ただし、一時的なサーバ増強による並列エクスポート/インポートなどの工夫により移行時間の大幅短縮も可能。クラウド間もしくはクラウドからオンプレミスの場合、データ転送量(送信にかかる)の追加費用が発生することも認識しておく SAP認定パブリッククラウド・クラウド事業者の可用性ロジックに従う部分があり、SAP プライベートクラウド/仮想化環境・仮想マシン単位のHA機能が一般的で、vSphere HAやHyper-V 物理環境・HA構成はSAP/DB層ともに自由に選択(SAP認定HAソリュー NetWeaverアプリケーション層は共有型クラスター前提で設計さクラスタなどで仮想マシン障害に対応。FTやライブマイグレーションを選定すれば良い)。例えば、Windows環境での冗長化構成れているため基本的にSAP (A)SCS部分の冗長構成は取れないション機能など、より高度なHA機能も利用可能はMicrosoft Failover Cluster(MSCS/WSFC)が標準。DB層では・DB層はSQL Server データベースミラーリングやAlwaysOn、・アプリケーションレベルで高可用性が必要な場合は、ゲストOS SQL Server データベースミラーリング、AlwaysOn、Oracle Oracle Data Guardのような共有ディスクを必要としないDB機能クラスタリング(MSCS/WSFC)、Oracle RACなども実装可能 RACのようなDB機能によるHA構成を取ることも可能ソフトウェアクラスタによるHA構成のみ対応可・HWの冗長機能(パーティショニング、システムボード切替え)な（HA構成）・SIOS DataKeeperやNEC ClusterProのようなディスクコピー機ども選択可能能で疑似的な共有ディスクを作成することでHA構成も取れなくはないが非常に複雑・仮想マシンの障害時は他のインスタンスにディスクを付け替えることで復旧することもできる・DBソフトウェアの標準バックアップ機能で実施。生成された静・DB管理ツールやストレージのディスク複製機能など、さまざま・DB管理ツールやストレージのディスク複製機能など、さまざまバックアップ/リカバリ的なダンプファイルをディスクサービスのスナップショット機能な方法でバックアップの取得が可能な方法でバックアップの取得が可能で世代管理する・ストレージ機能もデータベースと連携しているためバックアッ・ストレージ機能もデータベースと連携しているためバックアッ・スナップショット機能はデータベースと連携しているか確認がプは整合性が保障されるプは整合性が保障される必要。連携していない場合、データベースのトランザクションレ・ストレージ機能の復旧では、瞬時に戻せるため最新のログ適用・ストレージ機能の復旧では、瞬時に戻せるため最新のログ適用ベルの整合性は保証できないのみで済みリカバリ時間も短いのみで済みリカバリ時間も短い・複数システムが連携している場合は、システム間のデータ整合・仮想化ソフトウェアと連動したゲスト環境のフルバックアップ・ストレージの遠隔地ボリュームコピー機能でDRを実現。転送量性維持を考慮した設計(全システムで同一の静止点を確立など)が必・APサーバーのような環境には仮想化ソフトウェアのスナップによっては帯域幅を確保する必要がありネットワーク費用がかさ要ショット機能も利用できるむ場合もある・上記の静的ファイルを遠隔地転送することで簡易的かつ非常に・仮想化ソフトウェアとストレージが連携したVMware SRM、安価なDRを実現 Hyper-Vレプリカといった仮想マシンの遠隔地複製機能でDRを実・復旧時はバックアップ媒体からのリストア(DBの再構築/リカバ現リ)が必要なため時間がかかる・APサーバーのような環境にはスナップショット(イメージ化)機能も利用できる SAP認定パブリッククラウドプライベートクラウド/仮想化環境・クラウド事業者のネットワークサービスの理解、NATインスタ・従来からの自社で蓄積したノウハウで運用可能ンス設計など新たな知識が必要。外部接続で設計のし直しおよび・仮想ネットワークの知識が新たに必要物理環境・従来からの自社で蓄積したノウハウで運用可能拡張が必要な場合もある・用途ごとのセグメント分離、マルチサブネットなど柔軟なネットワーク構成が難しい場合がある・仮想ネットワーク内ではプライベートIPアドレスしか使えない・パブリッククラウドへVPN接続するVPN装置の仕様やパラメータは、クラウド事業者側に合わせる必要がある。しかし、VPN装置の設定スクリプトが提供されているため設定は容易ネットワーク・基盤の物理ハードウェア/ネットワークの仕様が分かりづらい、性能保証されない・仮想マシンのサイズによってNICの帯域幅が異なる。どのサイズが何Mbps or 何Gbpsかは公開されていない・基幹系だとVPCが重要になるが、オンプレミスとクラウドをつなぐ専用線などの追加コストがかかる・オンプレミスとクラウドの間で大容量データを短時間で転送するためには、高速データ転送サービスが必要となり、追加コストが発生する。専用線一時利用サービスや高速転送製品の利用など・IaaSのためOSより上位層のメンテナンス(OS/DB/SAP Kernel ・計画停止が必要。HWのFWアップデートに関しては仮想マシン・計画停止が必要。ただし、クラスタリング環境の場合は切り替のパッチ、SAPのSPS適用)作業は従来通り利用者側で計画/実施すのライブマイグレーション機能のローリング更新でダウンタイムえによってHW/OS/DBのパッチ適用はダウンタイム最小化も可能る必要があるなしも可能・自社の運用スケジュールによって完全コントロールできる・クラウド基盤のメンテナンスに伴い数週間前の通知でシステム・自社の運用スケジュールによって完全コントロールできる停止を要求される場合がある。クラウド事業者の計画に従う必要計画停止（パッチ適用）があり、利用者が計画停止時期を制御できない・メンテナンスに伴い特定範囲の仮想マシンのみ再起動が要求されることもあるが、複数システムが連携している場合はシステム間のデータ整合性維持の観点から、事前にメンテナンス対象外も含む全てのシステムを停止するなど起動/停止順序も意識した運用設計が必要 SAP認定パブリッククラウドプライベートクラウド/仮想化環境・採用製品はパブリッククラウド向けのSAP認定に従う・採用製品は仮想環境向けのSAP認定に従う・OS/DB/SAPの製品サポートライフサイクルに従ったアップグ・ハードウェア保守切れに伴った一括更新作業(SWも一緒に更新) が一般的。通常HW製品は製造終了から5年程度でサポート終了、レード作業は従来通り利用者側で計画/実施する必要があるが一般的だが、仮想化されているためHWとSWのライフサイクルもしくは減価償却期間を考慮し、5年前後でHWリプレースを行う・サポート組み合わせや導入タイミングによっては、新しい製品/ を分離することも可能製品ライフサイクルお客様が多い・ハードウェアベンダーの保守サポート見解との兼ね合い(交渉に・ハードウェアベンダーの保守サポート見解との兼ね合い(交渉に・サービスが突然打ち切られる可能性があるため出口計画も意識より延長保守が可能な場合も) より延長保守が可能な場合も) する。新サービスの展開の速さについていけない場合のリスクも・製品元のサポートライフサイクルによりあらかじめ更新時期を・製品元のサポートライフサイクルによりあらかじめ更新時期を考慮する把握ができる把握ができる・更新プロジェクト時期は自社でコントロールできる・更新プロジェクト時期は自社でコントロールできる・SAPライセンスは一般的にBYOL(買い切り&持ち込み)。従量課金にしたい場合はSAP認定チャネルパートナーと MCaaS(Managed Cloud as a Servie)契約の締結が必要・データベースや3rdパーティー製品などソフトウェアライセンスがクラウド対応しているか要調査・柔軟なリソース増強がクラウドの強みだが、3rdパーティー製ソフトウェアライセンスも伴って追加費用が発生する場合があり、コンプライアンス違反にならないよう注意が必要・プリンタ/FAXなど物理デバイスと連携する帳票ソリューションなどは代替ソリューションなど要検討・24時間365日運用など基幹系で求められる要件をすべて満たそインフラ運用コスト・ハードウェア保守切れに伴った一括更新作業(SWも一緒に更新) 技術のテストができない可能性がある以下、その他 SWライセンス費用物理環境うとするとインフラコスト削減につながらない(オンプレより高くなる)可能性がある・エンドユーザー主体で自由に環境が作成できると利用料がかさむため、申請フローや管理体制の確立などガバナンスの効かせ方も要検討