レスポンス時間よりもターンアラウンド時間。SAP HANAを最大限に活用するための開発手法

レスポンス時間かターンアラウンド時間か

SAP Tech JAMのセッションで「SAP HANA 開発手法」というタイトルで講演を行ったSAPジャパン プラットフォーム事業本部 プリンシパルデータベースアーキテクトの花木敏久氏は、普段の商談活動の中でショッキングな出来事があったと言う。

「SAP HANAはデータベースなので、時にはベンチマークテストも行います。最近目にしてショックだったのは、本来はSAP HANAのアプリケーション開発機能を使わない手はないのですが、他社製品とデータベース機能の部分だけをベンチマーク比較していたことです」（花木氏）

データベースのシステムについては、レスポンス時間とターンアラウンド時間の違いに着目すべきだと花木氏は説明する。いわゆるTPCベンチマークのようなものは、決められた処理を行い結果をいかに迅速に返すか。これはレスポンス時間の比較となる。一方でターンアラウンド時間は、何らかのデータが投入され、それが処理され結果が返ってくるまでの時間だ。「レスポンス時間が高速化しても、それでPDCAサイクルが速くなるわけではありません。ビジネスのPDCAサイクル全体からすれば、レスポンス時間が関わる部分はほんのわずかしかありません」と花木氏。

SAPは、SAP HANAを3年前にインメモリー型データベースとして提供を開始した。現在では各社が「似たようなアーキテクチャ」のインメモリーデータベースを世に出している。どのデータベースでも、ストレージベースのものより100倍、1,000倍速い「レスポンス」を提供できる。ストレージベースよりは十分に高速、その状況で「データベースのレスポンス時間部分だけを比べても、何の意味があるでしょうか」と花木氏。

たとえばデータウェアハウスやデータマートを構築し、それらに対しバッチでデータを更新して1日後に分析ができる環境がある。これについてはどんなにレスポンスを高速化しても、分析環境を提供するのにかかる1日という時間が数秒に短縮されるわけではない。SAPがSAP HANAで目指すのはターンアラウンドを速くすること。1日かかっていた時間を、いかにして早くできるかを目指していると花木氏は言う。

これは、いわゆる基幹系と情報系のシステムを別々に持たざる得ないという既存データベースの制約による問題でもある。SAP HANAでは基幹系でデータが発生してから情報系でそれを認識できるようにするまでの時間を瞬時にできると花木氏は説明する。というよりも、そもそもそれを目的として改革を施したデータベースなのだと。

「SAP HANAは1つのアプリケーションに対し基幹系、情報系で1つのデータイメージとなります。そして、サマリーテーブルのようなものを極力持たない。アプリケーションに必要な集計処理は、ロジックだけを持って必要になったらいつでも瞬時に集計を行います。アプリケーションロジックをデータベースの中に持つことで、瞬時の処理ができるのです」（花木氏）

データベースを分けてそれをバッチ処理で結ぶ構成から、データとロジックを1つのデータベースで持つ形へ。このデータベースの中に持てるロジックが、豊富にあるのがSAP HANAの特徴。これを「アプリケーションロジック・プッシュダウン」とSAPでは呼んでいる。

「このアプリケーションロジック・プッシュダウンの機能をデータベースのおまけ的に考えていた人もいるかもしれません。しかし、これがあることこそがSAP HANAの強味なのです」（花木氏）

リアルタイム処理をするとはどういうことか

そもそもリアルタイムな処理とはどういうものなのか。リアルタイムであるためには「シングルデータイメージ」でなければダメだと花木氏は言う。SAP HANAではアプリケーションから参照された際に、必要となる集計データは動的に生成し提供する。元になるデータは1つのイメージしかないので、どのようなアプリケーションからの要求でも唯一のデータを使って処理される。なので、あらかじめ作ってある中間テーブルとの間でのデータの整合性問題もない。

このSAP HANAのシングルデータイメージでデータベースにロジックだけを持つアーキテクチャを活用するとなると「おのずとデータベースとアプリケーションの構築の仕方を、従来とは変えなければなりません」と花木氏。本来のSAP HANAの能力を発揮するには、データベースとアプリケーションをセットで開発する必要あると指摘する。

そのため、EclipseベースのSAP HANAの開発環境でもあるSAP HANA Studioにはランタイム環境、デザインタイム環境、リポジトリーというタブが用意されている。

「データベースの管理だけであれば、システムタブだけ利用していれば大抵のことはできます。アプリケーション開発となるとデザインタイム環境でアプリケーションを作ってそれをアクティベート、つまりコンパイルのような処理をします。作ったアプリケーションはリポジトリーで管理され、実際にアプリケーションを動かす際には、ランタイム環境からリポジトリーのアプリケーションを実行します」（花木氏）

ユーザーインターフェイスの部分については、データベースの中ではなくWebブラウザなどSAP HANAの外で動くようにする。とはいえ、その管理も含めてSAP HANAのリポジトリーで行うことができる。

アプリケーションの処理も含めてSAP HANAに最適化する

花木氏は、SAP HANAで開発する際に期待している機能に「Core Data Service」があると言う。これはデータベース製品に依存せずにオブジェクトを定義できるもので、1つの定義が異なるDB上で使えるようになる。データベースオブジェクトだけでなく、ジョインの定義のようにこれまで実行時SQLで定義せざるを得なかったものをデータ構造の一部として定義できるようになった。ジョインなど高度に技術的なSQL記述が劇的にシンプルになり、よりビジネスに近い思考と記述で開発することを実現するものであり、将来的な開発にも威力を発揮するだろうと言う。

「インフォメーションビュー」は、テーブルの結合関係をあらかじめ定義しておくものだ。BIツールで多次元キューブを作るといったことをSAP HANAの中で実現する。スキーマ構造は必ずしもスタースキーマなどでなくてもいい。「この機能があるので、あらかじめデータベースからデータを抽出しキューブに集計しておく必要がありません」と花木氏。

「XSアプリケーション」は、SAP HANAの中でサーバーサイドJavaScriptやODataサービスを動かすもの。SAP HANAという1つのデータベースの中で実行するので、コード体系の異なるシステム間のやり取りで発生する文字化けなどの不具合や、そもそもシステム間で繫がらないといった障害も発生しない。「これは大変便利な機能です」と花木氏。将来的にはJavaVMもSAP HANAの中で動くようになることを期待する、とのことだ。

もう1つ有効な機能として紹介したのが「予測分析モデル」だ。

「これは、中の分析ロジックを知らなくても利用できます。今ではそのようなロジックがSAP HANAの中に60以上もあります。これらをコーディングなしで簡単に利用できます。これは、分析という作業の敷居を大きく下げるもので、データベースエンジニアのスキルの幅を広げることにもなります」（花木氏）

たとえば、インフォメーションビューを使って集計できるようにし、その結果を取り込んでXSアプリケーションを用いWeb／モバイル環境で動かす。これに予測分析などの処理を加え、高度な予測分析を行うといったことまでを実行するのが、SAP HANA本来の力を発揮する使い方だと花木氏は言う

データベースにとって、それがインメモリーであるかどうかが重要な時代ではすでにないだろう。インメモリーである上で、シングルデータイメージ、アプリケーションロジック・プッシュダウンのようにロジックまでをも同じインメモリーデータベースで処理できる。それらが可能だからこそ、レスポンスではなくターンアラウンドを高速化できる。SAP HANAを最大限に活用したければ、アプリケーション処理も含めSAP HANAに最適化する「発想の転換」は必要となるだろう。