HANAによるOLTPのカラクリ

本編の2人目は、アクセンチュアの花木さんです。

花木敏久（はなき・としひさ）／アクセンチュア株式会社。鹿児島県出身。法政大学卒。国内SIer、サイベース、デルジャパンでの勤務を経て、2017年にアクセンチュアへ入社。趣味はオートバイとサックス。

「SAP HANA」におけるオンライントランザクション処理実装を概観することをテーマにした花木さんの講演は、まずインメモリデータベースの永続化の仕組みの紹介からスタートします。

「まずはデータベースの永続化です。メモリ上のデータベースはデータストアという領域にありますが、どこかのタイミングでディスクに書き出す必要があります。『SAP HANA』では、デフォルトで5分に1度書き込みを実施しています。インストール後にはすぐに全体を書き出しますが、その後は更新された差分を5分に1度書いていくわけです。

しかし、OLTPを扱えばこれだけでは追いつくことはできません。そこで、トランザクション単位の永続化が必要になってきます。

トランザクションはデータベースに書き込みますが、そのタイミングではディスクは更新しません。ただ、データベースに書いたという証拠を残す必要があります。メモリ上にログバッファという領域があるのですが、このログバッファがフルになるか、トランザクションがコミットを宣言したときに、ディスク上のログボリュームという領域に書き出すようになっています。

このようにトランザクションの永続化を実現しています」（花木さん）

次に花木さんはカラムストアの更新を高速化するために「SAP HANA」で行っている手法として、次の3点について説明します。

1. Write最適化ストア、Read最適化ストア

「OLTPは更新に弱いデータ構造を持っています。そこで、本来のメインストレージよりも書き込みのコストが低いストレージを作りました。

つまり、『SAP HANA』ではひとつのカラムは単一の領域で構成されているわけではありません。メインストレージとデルタストレージいう2つの領域からできています。

このWriteに最適化したデルタストレージでは、差分をのみを追加して更新するというシンプルな方式をとっています。Insert/Update/Deleteを全てInsertで実行するこの仕組を、Insert Onlyと呼んでいます。また、デルタストレージではソートや圧縮が行われることはありません。

これに対してReadに最適化したメインストレージでは、検索に有利になるようにソートされ、圧縮されています」（花木さん）

2.デルタマージ

「しかし、デルタストレージが大きくなるのをいつまで我慢すればいいのかと気になる方がいると思います。

この疑問を解決するのが、デルタマージと呼ばれる実装です。デルタマージとは、デルタストレージ上のデータをメインストレージへ移動する作業です。

デルタストレージ上のデータは、速く書くことを目的としていますから、書かれた時点で役割を果たします。後はユーザーの知らないところでメインストレージへ移動していれば都合がいいわけですが、それを実現するのがデルタストレージなんです」（花木さん）

3. コンシスタントビューマネージャ

「また、メインストレージとデルタストレージの2つにデータが書き込まれている場合、どちらが正しいのか整合性が気になりますよね。どんどん追加される更新の間に参照が入るわけですから、参照のトランザクションにとっては最新のものが正しいわけではありません。

こういった場合に適切なデータを抽出するのがコンシスタントビューマネージャです。

ユーザーからは見えないのですが、こういった機能によりスムーズな更新が実現しています」（花木さん）

花木さんはアニメーションを使ってOLTPとOLAPを同時に処理するうえで、コンシスタントビューマネージャやデルタマージがどのように働くのかを改めて解説。さらに下記をデルタマージを扱う上で重要な点として挙げました。

「まず、大切なこととして『SAP HANA』のカラムストアをオンラインでリアルタイムに更新するのは非常に高コストな作業であるという前提があります。具体的にはディクショナリの再作成やValueIDの再作成などのソートやマージ、さらに再圧縮などがコストのかかる作業です。

この作業をバッチ的にまとめて遅延して行う、というのがデルタマージのコンセプトなのです。それによりオンライン更新自身は軽くなりました。ただし、遅延させてバッチ的な負荷が60秒ごとにかかることは頭の片隅に入れなければいけません」（花木さん）

花木さんはOLTPの高速化についてまとめます。

「まず、『SAP HANA』はメモリ上で処理をおこなうため高速化されるというメリットがあります。ただし、OLAPも視野に入れカラムストアで処理を行うので、OLTPだけを見るとこの領域は遅くなります。

もちろん、遅いままではいけません。そこでこれまで説明してきた通り、Write最適化領域にはInsert Onlyの方式をとったり、更新を遅延したバッチ的に実行してRead最適化領域を再構成することでスピードをあげているのが『SAP HANA』なのです。

また、先ほどの新久保さんのお話の通り、ハードウェアレベルではローレベルロッキングや、『TSX』がOLTP高速化のポイントになっています。

このように『SAP HANA』にはOLTPとOLAPをひとつのデータベースで処理する仕組みがありますが、『SAP HANA』の上にデータベースさえ作れば同時に処理できるというものではありません。この問題は突き詰めていくと、ひとつのCPU、ひとつのメモリ空間で実行される異質な処理間の優先度とリソース配分の問題なのです。

ですから、アーキテクチャだけで解決できるものではなく、使う人のチューニングとワークロード管理が必ず必要だと私は考えます」（花木さん）

最後に花木さんはワークロード管理に関して、「CPUの使用の制御」「SQL文の同時実行、並立実行」「SQL文が使うメモリ量の制限」「アドミッションコントロール」などを時間の関係で簡単に紹介して講演を終了しました。花木さんの当日のスライドはこちらに公開されています。

AWS Quick Start For SAP HANA

最後の登壇は、アマゾンウェブサービスジャパンの河原さんです。

河原哲也（かわはら・てつや）／アマゾンウェブサービスジャパン株式会社 エコシステムソリューション部 パートナーソリューション アーキテクト。富士通のSAP認定テクノロジコンサルタントとして活躍した後、2015年にAWSジャパンへ入社。

アマゾンウェブサービスでは「SAP HANA」をすぐにスタートし、ビジネスに活用できるように「AWS Quick Start for SAP」というソリューションを提供しています。河原さんはこの「AWS Quick Start for SAP」について説明します。

「『SAP HANA』はハードウェアとソフトウェアが一体型となってアプライアンス製品として登場しています。『SAP HANA』の調達を一度でも体験した人はご存知だと思いますが、基本的にはハードウェアベンダーに『どういった要件で、これくらいのメモリサイズとデータベースサイズが欲しい』と注文し、ベンダーがセットアップをしてからデリバリーします。

この方式では数ヶ月といった時間が掛かってしまいますよね。そうすると、せっかくインメモリデータベースを使ってデジタルトランスフォーメーションに取り組もうと思っても、ビジネス環境が変化してしまうわけです。

この課題を解決するために私たちが提供しているのが『AWS Quick Start for SAP』です。

お客さまが欲しいときに必要な台数だけ従量課金で利用できるのが、クラウドサービスである私たちの特徴です。このメリットを基幹系システムでも享受したいというお客さまが非常に増加しています。2017年の11月時点で、グローバルで数千を越えるお客さまが『AWS』上で『SAP』のシステムを利用しています」（河原さん）

河原さんは「AWS Quick Start for SAP」の特徴について続けます。

「私たちの仮想サーバーである『Amazon EC2』は、『SAP HANA』の本稼働認定インスタンスです。現在、メモリサイズ244GB、488GB、1TB、2TB、4TBのラインナップがこの本稼働認定を取得しています。

これらが『Amazon EC2』ベースで稼働していますから、数分の作業でサーバーが立ち上がり、必要なソースを利用することができるわけです。

実は『SAP HANA』の認定を取得するには非常に高いハードルがあります。数千のお客さまを既に運用している事績を、ベストプラクティスとしてテンプレートに落とし込んだのが『AWS Quick Start for SAP』なのです。

『AWS Quick Start for SAP』のベースとなるのは『AWS CloudFormation』です。『AWS CloudFormation』のカスタムスクリプトが『SAP HANA』のセットアップを自動展開しているのです。これにより、『SAP HANA』の認定構成を1時間未満で簡単に自動展開することが可能です」（河原さん）

最後に河原さんは実際にセットアップするデモを披露して講演を終えました。