このブログは、2023 年 5 月 19 日に SAP ジャパン公式ブログに掲載されたものを SAP ジャパン公式ブログ閉鎖に伴い転載したものです。

このブログは、Robert Waywell が執筆したブログ「Top 5 Reasons to Migrate SAP IQ Systems to SAP HANA Cloud, Data Lake」（2022 年 11 月 9 日）の抄訳です。最新の情報は、SAP Community の最新ブログやマニュアルを参照してください。

SAP HANA Cloud, data lake リレーショナルエンジンは SAP IQ の技術をベースに構築されているクラウドデータレイクです。SAP HANA Cloud, data lake リレーショナルエンジンには、SAP HANAとの互換性を高めたHANA マネージドのものとオンプレミスの SAP IQ 互換のスタンドアロンのものがあります。
このブログではオンプレミスの SAP IQ から、スタンドアロンの SAP HANA Cloud, data lake リレーショナルエンジンへ移行する理由トップ 5 について説明しています。

SAP HANA Cloud, data lake リレーショナルエンジンがオンプレミスの SAP IQ をベースに構築されていることは広く知られていますが、既存の SAP IQ システムのクラウドへの移行を検討中のお客様にとって、スタンドアロンの SAP HANA Cloud, data lake リレーショナルエンジンは最も適した移行先と言えます。

とはいえ、オンプレミスの SAP IQ のサポートは今後も継続されるため、SAP IQ からSAP HANA Cloud, data lake への移行を強制するものではありません。

例えばオンプレミスの SAP IQ の version 16.1 については、現時点で少なくとも 2027 年 12 月 31 日までのメインストリームメンテナンスはコミットされています。

一方で、オンプレミスのデータベースシステムの保守運用には多くの労力を必要とするため、クラウドへ移行してデプロイすることで、重要かつ時間を要する保守運用管理作業の負荷を低減することができます。

また、それによってデータベースチームはより価値のあるデータベース開発活動にフォーカスしてより多くの時間を割くことが可能になります。

もしオンプレミスの SAP IQ システムのクラウドへの移行を検討しているのであれば、ここで紹介する SAP HANA Cloud, data lake リレーショナルエンジンへの移行のメリットのトップ 5 が参考になるでしょう。

容易なプロビジョニング

オンプレミス環境で新しいデータベースをプロビジョニングするのは単純な作業ではありません。

ソフトウェアライセンスを取得していても、複数のベンダーから見積もりをとり、注文書を出し納品を待ち、ハードウェアが設定されるのを待つ、というハードウェアの調達プロセスを経る必要があります。

これらの全体プロセスには数か月かかることもあり、ハードウェア更新のサイクルによって 3 ～ 5 年に 1 度繰り返し行う必要があります。

SAP HANA Cloud, data lake リレーショナルエンジンでは、「Create Instance」をクリックしてデータベースを稼働させるまで数分で完了します。

そして何よりも、ハードウェアをアップグレードする必要はありません。

ダウンタイムがほとんどないアップグレード (Near Zero Downtime Upgrades ：NZDU)

アップグレードに関しては、オンプレミスのシステムの場合にはアップグレードする必要があるのはハードウェアだけではありません。

データベースソフトウェアもアップグレードする必要があり、これはハードウェアのアップグレードより頻繁に発生します。

ミッションクリティカルなシステムにおけるソフトウェアのアップグレードにおいて最大の課題は、ほとんどの場合とてもタイトなメンテナンス時間に合わせる必要のあるシステムのダウンタイムのスケジュールと管理です。

この点において、SAP HANA Cloud, data lake リレーショナルエンジンはクラウドインフラストラクチャーならではの制御を活用した真のイノベーションを実現しています。

全ての SAP HANA Cloud, data lake リレーショナルエンジンインスタンスは NZDU を実行するためのマルチノードのスケールアウト、あるいはマルチプレックスシステムであり、プロセス全体をとおしてシステムへの読み込みアクセスを維持します。

フレキシブルな vCPU 数の増減

プロビジョニングのトピックに戻ると、オンプレミスシステムの課題の一つがサイジングです。

サーバーもストレージも、ハードウェアの購入はあまり柔軟ではありません。

1 つのサーバー上で仮想ソフトウェアを使用して小さめのシステムを複数デプロイすることは可能です。

しかし、数十 TB、数百 TB、あるいは数 PB に拡大するデータベースシステムをデプロイする場合、サーバーを共有する選択肢はないでしょう。

成熟したオンプレミスのデータベースを担当している場合、今後 3 ～ 5 年のハードウェアサイクルでどの程度データ量が拡大するのか想定できるかもしれません。

しかしながら、新しいシステムと対面した時に、データ量やワークロードの初年度見積もりは確実でも、その先の見積もりの信頼性は低いものになる可能性があります。

オンプレミスのシステムでは、通常ハードウェアのライフサイクルに合わせて事業が拡大することを期待し、初年度はオーバーサイズのものを購入することになります。

しかしながら、そのサイクルの終了時にはアンダーサイズで終了する可能性もあります。

SAP IQ システムを SAP HANA Cloud, data lake リレーショナルエンジンシステムに移行することで、コンピュート（演算処理）のリソース、つまり vCPU とメモリを必要に応じてスケールアップしたりスケールダウンしたりすることができます。

ワーカーノードのサイズを増やしたり、そのシステムのワーカーノードを増やしたりすることでシステムに垂直的または水平的に行うことができます。

ストレージサイズの自動増減

SAP IQ が古く思えることの 1 つに、ストレージのスペースを複数の dbfile で構成される dbspace の形で事前に割り当てる必要があるということがあります。

利用可能なスペースを監視し、ストレージサイズを増やすために、必要に応じて dbfile を追加するのは難しい作業ではありませんが、オンプレミンスの SAP IQ システムを管理する上で、しなければならない「もう 1 つのこと」です。

SAP HANA Cloud, data lake リレーショナルエンジンに移行すれば、データベースにデータを追加した時に必要なストレージサイズは自動的に割り当てられるので、この作業はもう必要ありません。

これは、所有コストの点でもオンプレミスの SAP IQ システムと比較してメリットがあります。

なぜならば、SAP HANA Cloud, data lake リレーショナルエンジンは使用しているストレージサイズに対してのみ課金されるからです。

<ごめんなさい。ストレージサイズを管理する必要はないため、画面ショットはありません 😊>

オンプレミスの SAP IQ システムから SAP HANA Cloud, data lake リレーショナルエンジンに移行するコスト面でのもう一つのメリットは、ストレージのユニット単位のコストを削減できることです。

ディスクベースのデータベースのパフォーマンスはディスク I/O のスループットに直接影響を受けます。

オンプレミスの SAP IQ システムは通常 SSD ストレージでスループットを最適化するようにプロビジョン（構成）されています。

一方、SAP HANA Cloud, data lake リレーショナルエンジンは、クラウドネイティブなオブジェクトストレージを使用し、各データベースページをオブジェクトとして格納します。

これにより、クラウドネイティブなオブジェクトストレージからの読み込みに非常に広い帯域幅のメリットを享受することができるため、クエリーパフォーマンスを維持、あるいは場合によってはさらに向上されることができるだけでなく、数 TB、数 PB ものデータを SAP HANA Cloud, data lake リレーショナルエンジンに格納するコストを大きく削減することができます。

dbspace 管理タスクがないことやストレージコストの削減では不十分であれば、SAP HANA Cloud, data lake リレーショナルエンジンにはオンプレミスの SAP IQ に対して、もう 1 つ大きなストレージ強化点があります。

SAP HANA Cloud, data lake リレーショナルエンジンでは、システムからデータを削除したり、truncate すると、ストレージサイズは自動的に縮小します。

これは、1 TB 単位で行われるため、ある程度の量のデータを削除する必要がありますが、ストレージのサイズ、それゆえにストレージのコストが、データ量の拡大、縮小に合わせて増減するということを意味します。

コスト効果の高いバックアップ

SAP IQ のようなオンプレミスのデータベースのバックアップを管理するのは、複雑で時間を要する管理業務です。

数十 TB、数百 TB、さらには数 PB にもおよぶ SAP IQ のデータベースのフルの、あるいはインクリメンタルなバックアップを運用管理するストレージコストもまた、特に災害対策のために重複するバックアップのコピーを別の物理データセンターに保持しなければならない場合には、とても大きなものになります。

SAP HANA Cloud, data lake リレーショナルエンジンによるクラウドネイティブなオブジェクトストレージの使用は、バックアップ方法の革新です。クラウドネイティブなオブジェクトストレージにより、SAP HANA Cloud, data lake リレーショナルエンジンは、アップデートまたは上書き時に各オブジェクトのスナップショットをとる「書き込み時のコピー」機能のメリットを利用します。

各データベースページは独自のオブジェクトとしてストレージするために書き込まれるため、各データベースページに変更が書き込まれると個別にバックアップされることを意味します。

SAP HANA Cloud, data lake リレーショナルエンジンは、カタログデータベースに対しては完全なバックアップとインクリメンタルなバックアップの組み合わせを使用しますが、「user_main」dbspace の完全なバックアップは必要ないため、バクアップストレージの総サイズは変更されたデータベースページとカタログデータベースのバックアップでのみ構成されます。

クラウドネイティブなオブジェクトストレージを利用することで、さらに災害対策のサポートも提供できます。なぜならば、ストレージはハイパースケーラーのリージョン内の複数の利用可能なゾーン、つまり複数のデータセンターにわたり冗長化されているからです。

オリジナルのブログはここまでです。

SAP HANA Cloud, data lake リレーショナルエンジンのコストは、「SAP HANA Cloud Capacity Unit Estimator」を使用して見積もることが可能です。

オンプレミスの SAP IQ 互換のスタンドアロン版を使用する場合の見積もりは、Service Types で Data Lake を選択します。

例えば、

16 vCPU（メモリーとシステムテンポラリーストレージを含む）
データ量 2 TB  (圧縮後のデータ量。1/10 程度に圧縮されることを想定すると元データは 20 TB)
1 か月の圧縮前データロード量 0.5 TB
1 か月のデータ更新/スキャン量 1 TB

であれば、
1 か月あたりの Capacity Unit は 6,840 になります。
年間では 82,080 Capacity Unit です。

例えば、

80 vCPU（メモリーとシステムテンポラリーストレージを含む）
データ量 8 TB  (圧縮後のデータ量。1/10程 度に圧縮されることを想定すると元データは80 TB)
1 か月の圧縮前データロード量 2T B
1 か月のデータ更新/スキャン量 8 TB
であれば、
1 か月あたりの Capacity Unit は 33,148 になります。
年間では、397,776 Capacity Unit です。

1 Capacity Unit の定価はこちらで確認することができます（現在表示されている単価は1年分のためご注意ください）。

SAP HANA Cloud 内のどのサービスを使用しても、Capacity Unit の単価は同じです。

SAP HANA Cloud を使用することができる契約であれば、SAP HANA Cloud, data lake リレーショナルエンジンも利用することができます。