SAP IQシステムからSAP HANA Cloud, data lake (Standalone Data Lake) へ移行する理由トップ5
作成者:伊藤 沢 投稿日:2023年5月19日
このブログは、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すると、ストレージサイズは自動的に縮小します。
これは、1TB単位で行われるため、ある程度の量のデータを削除する必要がありますが、ストレージのサイズ、それゆえにストレージのコストが、データ量の拡大、縮小に合わせて増減するということを意味します。
コスト効果の高いバックアップ
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(メモリーとシステムテンポラリーストレージを含む)
データ量2TB (圧縮後のデータ量。1/10程度に圧縮されることを想定すると元データは20TB)
1か月の圧縮前データロード量0.5TB
1か月のデータ更新/スキャン量1TB
であれば、
1か月あたりのCapacity Unitは6,840 になります。
年間では82,080 Capacity Unitです。
例えば、
80 vCPU(メモリーとシステムテンポラリーストレージを含む)
データ量8 TB (圧縮後のデータ量。1/10程度に圧縮されることを想定すると元データは80TB)
1か月の圧縮前データロード量2TB
1か月のデータ更新/スキャン量8TB
であれば、
1か月あたりのCapacity Unitは33,148になります。
年間では、397,776 Capacity Unitです。
1 Capacity Unitの定価はこちらで確認することができます(現在表示されている単価は1年分のためご注意ください)。
SAP HANA Cloud内のどのサービスを使用しても、Capacity Unit の単価は同じです。
このオリジナルブログが掲載されているSAP CommunityのSybase関連タグをフォローして、最新技術情報をキャッチアップしてください(フォローには登録が必要です)。
SAP Communityの関連タグ
・SAP HANA Cloud, data lake ブログ / Q&A
・SAP IQ ブログ / Q&A
・SAP SQL Anywhere ブログ / Q&A
SAP Communityでは質問も投稿することが可能で、世界中のSAP社員やユーザーのアドバイスを受けることができます。
———————————————————
SAPジャパンブログ内関連記事:
SAP HANA Cloud, data lake
SAP HANA Cloud, data lake 2022年12月版、2023年3月版、6月版の主な新機能
SAP HANA Cloudの「マルチ環境」のサポートとSAP HANA CloudのKyma環境からの使用
SAP HANA Cloud : データレイクおよびデータティアリング(階層化)概要
SAP IQシステムからSAP HANA Cloud, data lake (Standalone Data Lake) へ移行する理由トップ5
SAP IQまたは、SAP HANA Cloud, data lakeリレーショナルエンジンのインスタンスから別のインスタンスへログインをコピーする
SAP HANA Cloud, data lakeリレーショナルエンジンで非同期でテーブルをロードする
Jupyter NotebookとPySparkでSAP HANA Cloud, data lake Filesを使用する
SAP HANA Cloud, data lakeストレージのオブジェクトストレージへの変更によるパフォーマンス向上とペタバイト規模データの対応およびコスト低減
SAP HANA Cloud, data lakeでマテリアライズドビューを使用してパフォーマンスを上げる
SAP HANA Cloud, SAP HANA データベースとSAP HANA Cloud, data lake filesを使用する
SAP HANA Cloud, HANA データベースからSAP HANA Cloud, data lakeデータベースへの最速のデータ移行方法とテスト結果
SAP HANA Cloud, HANAデータベースから HANA Cloud, data lakeへのデータの高速移行とデータ移行速度に影響するパラメーター
SAP HANA Cloud, data lakeとSAP IQに共通するヒストリカルデータベースとDBSpaceサイズのキャプチャー方法
SAP HANA Cloud, data lake(IQ)をベースにしたNode.jsアプリケーションの構築
複数のSAP HANAソースからのデータを1つのSAP HANA Cloud, data lake(IQ)に集約する
SAP HANA Cloud, data lake Filesへの最初のアクセス設定
SAP HANA Cloud, data lakeおよびSAP IQにおけるスキーマのエクスポート/バックアップ
SAP HANA Cloud, data lake(IQ)にWindows端末からPythonで直接接続する
SAP HANA Cloud, data lakeへのデータロードにおけるvCPU数の影響
SAP IQのクラウドサービスが開始されました – SAP HANA Cloud, data lake (Standalone IQ)
SAP IQ
SAP IQのクラウドサービスが開始されました – SAP HANA Cloud, Data Lake (Standalone IQ)
SAP IQ – 隠れたイッピン(the hidden treasure) …
全てのSAP BW、SAP BW/4HANAリリースのSAP ニアラインストレージ(NLS)ソリューション – SAP IQ
SAP IQによるSAP ニアラインストレージ(NLS)のパフォーマンスを向上させる
SAP IQを利用したSAP Information Lifecycle Management(ILM)
DBA CockpitでSAP IQを有効にする
SAP IQのための容易なインストーラー - 「Q」
列指向データベースでもOLTPに対応したSAP Sybase IQ16の機能拡張
大量データの「圧縮率」と「ロード時間」を改善したSAP Sybase IQ16の技術解説
SAP IQ 16.1 SP05がリリースされました
SAP ASE
SAP ASE 16.0 SP03による高可用性(HA)+災害復旧(DR)の3ノードHADR
カスタム開発のアプリケーションにおけるSAP ASE Always-on機能へのDRノードの追加(パート 1)(パート 2)(パート 3)
SAP ASE 16.0 SP04の新機能
SAP ASEの新しい管理ツール「AMC」の紹介:インストール方法、メモリー管理、ワークロード分析機能、Workload AnalyzerのSSL設定について
SAP HANAプラットフォームを相互補完し進化する旧Sybase製品の今――SAP ASEとSAP IQ
SAPアプリケーション向けデータベースとしてSAP Sybase ASEが採用される理由とは
RDBMSのパフォーマンス向上の仕掛け――SAP Sybase ASE 15.7の最新アーキテクチャー解説
オンラインマニュアル:
SAP HANA Cloud
SAP HANA Cloud, Data Lake (SAP HANA DB-Managed)
SAP HANA Cloud, Data Lake (Standalone)
SAP Datasphereスペースを SAP HANA Cloud, data lakeに接続して、大量のデータを保存または利用できます。
SAP IQ
SAP SQL Anywhere(日本語)/(最新英語)
SAP ASE
SAP Community (ブログ/ Q&A) :
SAP HANA Cloud, data lake
SAP IQ
SAP SQL Anywhere (日本語ブログ一覧ページ)
SAP ASE
SAP Community Wiki:
SAP IQ
SAP SQL Anywhere
SAP ASE
sap.com 製品ページ:
SAP HANA Cloud, data lake
データレイクとは
SAP IQ
SAP SQL Anywhere(サブページ)
SAP ASE
デベロッパー向けチュートリアル
SAP HANA Cloud, data lake
その他:
SAP IQ テクニカル概要
SAP IQ 16.0 ハードウェアサイジングガイド
様々なストレージおよびネットワークテクノロジーにおける SAP IQ 16 Multiplex のパフォーマンス評価