古くて新しい危険思想か？あるいは理想形か？
谷川：1つの箱に2つのシステムを入れるというのは、現状でもある程度は実現できています。手間や工夫が必要ですが。いまIBMやガートナーがあらためて提唱しているHTAPとは何が新しいのでしょうか？
苧阪：HTAPはデータ集約型です。リソース競合など課題はありますが、両立させたいというニーズはあると思っています。分析の手前で少し更新したいとか、基幹系だけど少し分析したいなどです。
一方で適材適所でデータをストアすることの必要性もあります。そうした施策について、少しお話をしてもいいですか？
谷川：はい、どうぞ。
苧阪：HTAPだと、分析系へのデータ移動やETLを不要とするところがいいところです。しかし現実的にはデータを適材適所でストアするのがいい場合もあります。昨今ではデータが別のDBだけではなくクラウドにあることもあります。そこでIBMはデータにアクセスする時の敷居を下げる取り組みも行っています。Common SQLEngineと呼ぶ共通インターフェースでデータのアクセス性を統一するようにしています。
谷川：HTAPは理想だけど、まだまだこれからなのでしょうか。ミックさんはSIの立場で、どう捉えていますか？
ミック：先述したように、第一印象は「古くて新しい危険思想」でした。リソースコントロールで苦労した経験があるので、現場としては身構えてしまいます。しかしHTAPの思想性や目指している姿は理想的なところもあると解釈しています。
統合か分散かは手段でしかなくて、ビジネスレベルで何を目指しているかが重要です。それは恐らく意思決定のサイクルを早くする、ビジネスのアジリティを高めることです。実現できれば十分意義があります。これからリソースやアーキテクチャで課題がクリアになり、実現できたとしたら、ベンダーやSIerだけではなく実際にデータを扱うユーザーさんにも努力が求められるようになると考えています。
谷川：HTAPで便利になると同時に、ユーザーは考えることも必要になるということですね。HTAPの理想と現実について、今までのところで野間さんからは何かありますか？
野間：HTAPを言葉の通り、基幹系と情報系の統一ととらえると、まだ発展途上で無理もあります。しかし昨今の業務を見ると「たまったデータをすぐ見たい」という要望は急速に高まっています。こうしたニーズに、データを移動せずにすませることができれば早く実現できます。小さい規模で使うものと考えれば、実現できればやはり便利でメリットは大きいかと思います。
谷川：最初HTAPを聞いたとき、ERPにDWHが乗っかるというイメージでしたが……
野間：そこはまだまだですね。
谷川：かなり遠い理想でしょうか。
野間：遠い理想ですが、データベースベンダーとしては目指していく方向かと思います。何よりもお客様が透過的に使えることを望んでいますので。
谷川：ミックさんはそうした理想をどうみますか？ 基幹系にDHWが乗ってしまうとか。
ミック：ありえる未来かと思います。今は苦労や工夫が要りますが、目指すべき方向かと思います。
谷川：理想を実現するなかで巻き込み事故の事例など、差し支えない範囲でエピソードとか教えていただけるとありがたいのですが。
ミック：近年パフォーマンスで問題が起きるとすると、巻き込み事故が多いですね。BIやDWHの重い処理が基幹系の業務に必要なリソースまで消費してしまうことがあります。自由に分析できる機能があると、1人でも障害を起こせます。
谷川：「犯人は誰だ？」とか。
ミック：そこはすぐ判明します。リソースにキャップをかけたり、優先度をつける機能は多くのDBMSが持っていますが、その最適配分が難しい。少数で障害を起こせる人はえてして権限を持つ人で、そういう人の優先度は高いので。ただビジネスのアジリティを高めるのはいろんな手段があります。データベースだけが「できません。分けます」とも言えないかなと感じています。
谷川：苧阪さん、IBMはHTAPをどんな仕組みやアプローチで実現しようとしているのか、教えていただけますか。
苧阪：IBMが今開発しているものはBLUをベースとしたインメモリカラム（列表）にて、OLTPでも利用できるトランザクション性能を実現することです。現時点でこの要件を実現しようとすると、インスタンスは1つだけど、行表を更新したら列表も更新するなど、リソースもプラスアルファが求められています。しかし今開発しているのはあくまで表としては1つで、分析も更新も両方早くできることを目指しています。
谷川：特別なハードウェアやメモリ構成が必要になるのでしょうか？
苧阪：現時点でこの要件を実現しようとすると、インスタンスは1つだけど、行表を更新したら列表も更新するなど、リソースもプラスアルファが求められています。
谷川：でも当然メモリはたくさん積まないといけませんよね。
苧阪：インメモリデータベースなので確かにメモリとコア数は多く必要になります。ただし他社のインメモリデータベースとは異なり、全ての表データをメモリに読み込む必要はありません。ダイナミックインメモリと言うこともありますが、必要とされるデータをキャッシュに先読みしたり、不要なデータはキャッシュアウトさせる工夫もあります。
ミック：IBMさんにおうかがいしてもいいですか。データベースではこれまで読み込みを速くする工夫は多くありました。インデックスに始まり、パーティショニングにインメモリ。しかし書き込み（更新系）を早くする技術はあまりありませんでした。近年ログ分析やIoTなど、大量の更新がネックになるケースも出てきています。ある意味、データベースが置き去りにしてきた問題が顕在化したとも考えています。こうした問題にIBMはどのようなアプローチで臨むのでしょうか。
野間：既存製品のアプローチだと、書き込みログで書き込みのバイト数を減らす、シェアードナッシングだとログを分散してトランザクションを増やす、シェアードディスクだとキャッシュやロックの管理を別のノードで集中管理させるなどがあります。書き込みに関するリソースを食うことを減らす努力をしています。
谷川：それってHTAPのアーキテクチャにつながる話ですか？
野間：HTAPは列指向型のデメリットを克服するものです。列指向型は分析、集計がありえないくらい早いけど、更新は苦手。それを通常（行表）のレベルに高めようとしているのがHTAPです。
ミック：期待しています！
苧阪：今、BLUにおいてHTAP向けの機能強化が進んでいます。今までならありえないくらいにインサート処理が速くなってきています。もしかしたら我々の予想以上に早くOLTP系処理の高速化が実現するかもしれないと期待しています。
谷川：基調講演でデータサイズごとの指針も出ていました。HTAPだと想定されるデータの規模感はどのくらいでしょうか。
野間：ソフトウェアで実現しようとしてる機能であれば、1TBくらいが上限かと思います。現状のデザインでどちらも速くしようとしたら、内部的にはデータを両方持ち、リソースパワーで力任せに回すことになります。そうではなく現状のHTAPで1つのノードでやるとなると、上限は1TB、多くても数TBになるかと思います。
谷川：ミックさんとしては使い勝手はどう予想していますか？
ミック：現在は分析系システムは大規模でないとコストメリットが出ません。有効な対象がごく一部となります。中小規模でもできるほど普及すれば使い勝手は良くなると思います。
谷川：ミックさんからIBMに理想とか要求とかありますか？
ミック：IBMさんより、情報システム担当やビジネスユーザーの皆さんにお願いしたいことがあります。
谷川：じゃあそれで。
ミック：ハードウェアやアーキテクチャの制約がなくなり、統一的に処理できる1つの箱が出てきたとしたとします。それでHTAPが実現するかというと、そう思っていません。なぜなら、上位レイヤのデータ問題が残ると考えているからです。特にレガシーデータになるとキーがない、コード体系が不規則、世代管理が適当など、汚いデータが珍しくありません。「これでどうやって分析するのか」と思えるものとよく遭遇します。このようなデータではどれだけ立派なHWも宝の持ち腐れです。
最初から分析も一つの重要な基幹業務として設計するにはユーザーの力が必要です。ビジネス的な目標を達成するにはユーザーの協力が必要になるということを、私の立場から申し上げておきたいと思います。
谷川：HTAPを実現するとともに、データを活用する人が基幹系の構造や粒度もイメージして設計すればHTAPの効果も高まるということですね。
ミック：そこまで一貫して解決することで、HTAPの概念は意味があると思います。
谷川：何年後くらいに実現できそうでしょうか。
野間：開発はオンゴーイングですので、自分たちもどう実装されるか興味津々です。東京オリンピック前後には実現できているといいなと思います。
谷川：数年後ですね。会場のみなさん、これから各社が発信する「HTAP」について、またデータを使う側の意識についても気にしておいてください。今日はここまでにします。どうもありがとうございました。
【関連記事】
・本音で話そう、Db2の好きなところ、イマイチなところ
・IBM Db2を選んでみたらこうなった
・Db2の新たな方向性にデータベース技術者が思うこと
・そろそろ、HTAPの話をしよう
