まずはSAP HANAへのデータ統合から始めて次のステップでデータベース移行を考えるべし


移行の前にまずはインテグレーションツールでデータの統合を

DSC_2422SAP Tech JAMで「SAP HANAへのDB Migration最新状況」というタイトルで講演を行ったのは、SAPジャパン プラットフォーム事業本部の新井 智氏だ。新井氏は、まずはSAP HANAの生い立ちから振り返った。2010年にSAP HANAのSP1が登場し「当時は目新しいものという評価で、トランザクションは弱かった」と新井氏。それが2012年のSP5でOLTPにも対応、現在SPS 09まできた。「ここまでで、エンタープライズに必要な機能はほぼ網羅しました」と。2015年6月にはSPS 10が出る。さらにエンタープライズ向けの機能が拡充することに。

「ここ最近は、SAP HANAに既存のデータベースを移したらどうなるのかが気になる人も増えているようです。これは我々にとっては喜ばしいことです」(新井氏)

とはいえ既存データベースの移行を考える前に、まずはインテグレーションツールを使って外部からデータをSAP HANAに取り込む方法を新井氏は薦める。「まずはデータをSAP HANAに取り込みます。それだけでも相当なことが実現できます。次のステップでマイグレーションを考えるのがいいでしょう」と新井氏。移行となるとそれ相当の手間と苦労もある。まずはデータを移行しSAP HANAのメリットを享受すべきと言うわけだ。

そして新井氏も、SAP HANAはデータベースではなくプラットフォームだと強調する。さまざまな機能が内包されていることがメリットであり、その中にデータ連携をするインテグレーション機能もある。スマートデータアクセスは、たとえば欲しいデータがOracle Databaseにあるときに、SAP HANAの管理テーブルに設定するだけで自動的にOracleからデータをとってくる機能だ。データ元が汎用機のような仕組みの場合には、ファイル渡しになる。その際にはSDKが用意されているので、それを利用しデータの受け渡し機能を実現できる。

またデータインテグレータを使えば、どこからどのタイミングでデータを取り込むかが設定できる。データのやり取りは同期、非同期を設定可能で、ETLの変換処理もルール設定で自動化できる。スマートデータアクセスとデータインテグレータを使えば、外部データを使ってSAP HANAでの高速な分析環境も容易に実現可能だ。「まずはこれらを使えば、SAP HANAの高速性を活用できます」と新井氏。

Picture3

データベースの移行にはそれなりに手間と苦労が必要

マイグレーションは他のデータベースをSAP HANAに置きかえるもの。SAP ERPで利用しているOracleやSQL ServerをSAP HANAに置きかえる「Suite on HANA」の事例は、すでに数多くある。「HANA化することでメリットが生まれます。また新規であれば、SAP HANAベースのSAP S/4HANAを選択することでさらに多くのメリットがあります」と新井氏。

SAP ERPでは処理を効率化するために、数多くの中間テーブルを作成している。「1つのデータの更新で10以上の中間テーブルに更新が入る場合もあります」と新井氏。これがSAP S/4HANAになると、中間テーブルを一切作らなくなる。中間テーブルがなければ、そこに設定していたインデックス更新もいらなくなる。Suite on HANAやSAP S/4HANAの導入はSAP自体がサポートしガイドできるので、安心して移行できると新井氏は言う。

苦労が伴うのは、既存のカスタムアプリケーションの場合だ。SAP HANAでは、データだけでなく分析のロジックや集計、さらにはJavaアプリケーションなどもSAP HANA上で動かせる。すべてをSAP HANAに統合すればシステムはかなりシンプルにできるが、そこまで実現するには「移行の作業はかなり地道にやっていくしかありません」と新井氏。

まずはデータベースのどの部分をHANA化するかから考えなければならない。HANA化する部分が決まれば、POCを行いテストを実施する。同時に移行ロードマップを作ることに。移行先のシステム構成をどうするかも当然考えなければならない。HAやDRはどういう構成にするのか、データベース移行だけでいいのか、アプリケーションはどうするのか。考えるべきことはたくさんある。

実際に移行作業に入れば、データ型の変更やストアドプロシージャの移行なども考慮しながらSAP HANAにどういう手順で持って来るかを考える。データやストアドプロシージャを載せ替えたならば、当然テストを行い必要なら修正を施すことに。

「ここまでで6割くらいの作業が終わります。さらに他のシステムと移行システムの連携テストも行い、Go Liveとなるでしょう。Go Liveしても、月に1回か2回しか発生しない処理がきちんと動くかはチェックしなければなりません。運用を始めれば、移行過程では見えていなかったものが見えてくることもあります」(新井氏)

Picture2

移行にはマイグレーションツールを活用すべきだ

それではこの手間のかかる移行作業を誰が実施するのか。顧客自身の手でやる手もあるが、SAPが提供するGlobal Database Migration Factoryと呼ばれるチームと連携するSIパートナーがマイグレーションのサービスを提供している。TATAやIspirerもその一員。TATAは日本でのマイグレーションサービスを準備中で、Ispirerはすでにサービスを日本で展開している。

そんなIspirerがマイグレーションサービスで利用しているのが、マイグレーションツールの「SQL Ways」だ。

「移行は自分でやる、オフショアを使って安くやる方法もあります。マイグレーションツールは完璧とは言えません。自動移行できずに2割くらいはなんらかの修正が必要な部分として残るでしょう。しかしながら、これを利用するのが1番現実的な方法です」(新井氏)

SQL WaysにはCommanderというファイルベースで一括移行するものがある。これを使う際には、問題が発生すればログを見て対処することになる。Wizardではオンラインで1ステップずつ移行するものだ。Studioはオフラインで利用し、移行したいプロシージャなどを渡すと逐次SAP HANA用に変換してくれる。「ツールには何をどうすればいいかのノウハウが入っています。それを活用できるのがツールを利用する価値です」と新井氏。基本的な型変換やシンタックス変換などは自動で実施される。これらを手作業でやろうとすれば、SAP HANAについても元のOracleなりのデータベースについても、十分な知識を持っていなければ行えない。

トリガー、ファンクション、スキーマ定義など、自動変換できる部分に関してはツールを使えばテスト工数も減らすことができる。「移行は決めたけれど何から手をつけていいか分からない。そうなると作業はトライアンドエラーの連続になり工数もかかります。であれば、まずはツールを使ってみるのがいいでしょう」と新井氏。

Picture4

SAP HANAに移行する、これは新しいテクノロジーに置きかえることだと新井氏は言う。実際、データベースを移行すると捉えるよりは、そのように考えてプロジェクトを進めたほうがSAP HANAのメリットは享受しやすいだろう。発想を変えられれば、まずはインテグレーションツールでデータをSAP HANAに溜め、その上で既存データベースをSAP HANAに統合するという段取りも理解しやすい。場合によっては同時にアプリケーション機能まで含めSAP HANAへの統合を考慮すべきだ。SAP HANAへの単純なデータベース移行では、もったいないことになる。