SAPシステムのHyperscalerへの移行 – Part 1

[ArataOgama]

はじめに

Hyperscalerと一括りにしてしまうとよく言えば多彩、悪く言えば雑多な内容となってしまいますので、このブログポストでは主に、既存のオンプレミス環境からIaaSとしてHyperscalerへ載せ替える予定のお客様を対象に、移行を検討する際の考慮点について、その考え方や考慮すべきポイントにフォーカスして、インフラ寄りのテクニカルな観点で記載しております。新規構築時にIaaSとしてHyperscalerを採用される予定のお客様も一部分はご参考にして頂ける内容となっております。普段よりHyperscalerへの移行を経験されているようなよくご存知の方にとっては、内容再整理の一助としてご参考にして頂ければと思います。

なお、移行先のDBは基本的にはSAP HANAをベースに記載しております。

 

今回のブログポストは、以下3回に分けての記載を予定しております。

Part 1: Hyperscalerへの移行概要とデザインアプローチ (1)

Part 2: デザインアプローチ (2)

Part 3: 移行アプローチ

 

Hyperscalerへの移行概要

プライベート・パブリック問わず既に様々なサービスの基盤となっているHyperscalerですが、SAPシステムにとってHyperscalerのIaaSは、従来のオンプレミスアプリケーションをパブリッククラウド上にほぼそのまま持ってくることを可能とするアーキテクチャシナリオとなりますので、それが故に、比較的容易にオンプレミスからクラウドへの移行を促すことのできるソリューションと位置付けております。

 

昨今プレミアムエンゲージメントサービス契約を通じて、プラットフォームデザイン関連のサービスを提供させて頂く中ではHyperscalerのIaaSをベースに計画、実装を進めていらっしゃるお客様がほとんどとなっており、改めてHyperscalerの浸透度合いが急速に高まっていると感じます。

 

その他のクラウドサービスと比較すると、OSの層を境に、お客様とサービスプロバイダーの責任分界点が存在することになります。

 

SAPシステムに対してサポートされているIaaSプロバイダは、SAP Note 1380654記載の通りで、Azure、AWS、GCPを始めとしたHyperscalerの他、まだ日本ではあまり馴染みのないIaaSプロバイダも含めて当ブログポスト執筆時点で9つにも及びます。

 

SAPシステムのインフラ基盤としてIaaSを採用する際の技術的なクライテリアとしては以下のような項目が挙げられるかと思います。

項目	例
ロケーション戦略	希望のリージョンでIaaSプロバイダがサービスを展開しているか、また該当のリージョンにおける機密事項などのデータ保持について企業のコンプライアンス上問題ないか
SLA、KPI、HA/DR要件	IaaSプロバイダが提供するSLAやダウンタイム、性能などの数値がビジネスの要件を満たせるか
Hybridあるいはクラウドファースト	オンプレミスとクラウドを混在させるHybridを推進するか、全てのオンプレミスをIaaSやそれに代わるPaaSやSaaSに移行するクラウドファーストを推進するかの方針が明確か（*移行のロードマップを描く際に重要な要素となります。）
セキュリティ要件	ネットワーク技術や暗号化技術など、IaaSプロバイダが提供可能なセキュリティの各方式が企業の求める要件を満たせるか
SAPのレディネス	OS/DBの種類やバージョンの要件含めたSAPアプリケーションの認定状況、あるいはVMのスペックが問題ないか
構築あるいはサービス購入	IaaSを利用するにあたってはDNSやLB、NFSなどHyperscalerが提供するサービスを購入して組み合わせることが必要となるが、企業のマルチベンダ戦略、マルチクラウド戦略などと合致しないといったことがないか

 

なお、クラウド移行のロードマップを定義する中で、ステップ・バイ・ステップアプローチとして現行の状態を含めて下図のように5ステップの状態を定義しておりますが、上述のHybridで行く方針なのか、全てをクラウドに移行する方針なのかなどによって、最終形態はもちろん、中間の形態も大きく変わります。

 

即ち、最終形態のみならず中間形態それぞれのステップごとに該当のシステムのテクニカルアーキテクチャだけでなく、システム間連携、変更管理、セキュリティ、運用など、システム群として技術的に実現可能なプランニングを検討する必要があります。

 

デザインアプローチ (1)

SAPではHyperscaler上にSAPシステムを構築する上でのテクニカルアーキテクチャ観点でのデザインアプローチとビルディングブロックを下図のように定義しております。全体としては先述の通りシステム間連携、変更管理、セキュリティ、監視などの運用要素も入ってきますが、本ブログポストにおいてはこの部分はフォーカスせず、別の機会にお譲りいたします。

 

Hyperscalerの一般的なメリットとして、リソースの自由な拡張や縮小があげられると思います。その文脈で言うと、SAPシステムも十分にその恩恵に預かれますが、しかしながら基幹システムとしての利用を想定する場合においては、ある程度の決まった範囲で安定的に運用できることの方が、両者を天秤にかけたときにメリットであると考えることもできます。

 

SAPではHyperscalerの各パートナー様と協力し、SAPのユースケースに沿った適切なパフォーマンスとスケーラビリティを確保することを一つの目的としています。そのために、サイジングについては引き続き重要なデザインのパートを占めます。

 

サイジングの要素としては、メモリ、CPU、ディスクサイズ、ディスクI/O、ネットワークという項目自体はオンプレミスと変わりありません。様々なパターンがあるためDBをSAP HANAと想定して記載させて頂きますが、どのHyperscalerでも、認定マシンについてはまずはメモリやCPUの事前定義済みのセットでVMインスタンスを選定することになります。

 

昨今カスタムマシンタイプとして、vCPUの数をカスタマイズするといったことも可能となっていますが、SAPとHyperscaler各社との間で定めた制約、例えばメモリとvCPUの割合などを考慮に入れる必要がある他、事前定義されていない構成=SAPの保証としても疑問符がついてしまうため、サポートチケットを起票頂いて確認頂くことをお願いしております。本ブログポストでは事前定義済みのセットをベースに記載いたします。

 

メモリサイズは経年分をあまり見込まずにスモールスタートし、経年とともにVMインスタンスのタイプを変更することも一つの手ではありますが、Reservedとして予め固定期間で固定サイズのVMを予約しておくことで大幅な価格の割引を受ける方式もあります。後者はHyperscalerならではのメリットですので十分に検討して頂きたい部分になりますが、見積りを大きく間違えてしまうと、場合によっては解約手数料などで逆効果となる場合もありますので要注意です。

 

Hyperscalerでも、データティアリングオプションは引き続き有用であるので、それを組み合わせるのもメモリ削減の観点やデプロイメントの観点では重要なポイントとなります。

 

上述の通り、認定マシンについてはメモリやCPUの事前定義済みのセットとなっているため、メモリだけでマシンを決定してしまうと、CPUが不足してしまうということがあり得ます。新規構築の場合はQuick Sizerを利用してSAPS値を導き出しますが、マイグレーションの場合は現在の使用状況などからおおよその必要となるSAPS値を導き出すこととなります。CPU使用状況の履歴とともに、現在のハードウェアを導入した際の、あるいはその後拡張などしている場合は、それぞれのタイミングでQuick Sizerなどを回し直されているかと思いますので、その際のSAPS値がいくつであったかという情報を収集しておくことをお勧めいたします。

 

Part 1はここまでとし、次回Part 2ではサイジング要素の後半から記載いたします。