いまなぜHTAPか？ 更新系と分析系を一緒にすることの難しさは？
谷川耕一（以下、谷川）：DB Onlineチーフキュレーターの谷川です。今日はDB Onlineの公開収録的な形で進めます。まずは自己紹介からお願いします。
野間愛一郎（以下、野間）：日本IBMの野間と申します。プログラマーやサーバー運用も経験し、長らくデータベースに携わってきています。Db2だけではなくNoSQLも、さらに最近ではクラウドも担当しています。今日はベンダーの立場でお話しします。
谷川：Microsoft SQL Serverも経験があるんですね。
野間：そうなんです。Db2だけではないのです。
苧阪浩輔（以下、苧阪）：日本IBMの苧阪です。野間と同じく、DB製品系のSEを長らくしています。業界では金融、製造、公共など、製品検証や障害対応まで。実は入社時のアドバイザーが野間さんでした。
谷川：Db2一筋のようですが、特に好きなところとかありますか？
苧阪：最近自動化が話題ですが、Db2はバージョン8から「オートノミック(*)」を強化しています。オプティマイザなど運用管理系の自動化は昔から充実しています。最近自動化が脚光を浴びてきて、ちょっとうれしいです。
* 自立型機能の意味、データベースが自分をモニタリングし、必要な場合にチューニングを実施するなどDb2に実装されている
ミック：ミックと申します。これはペンネームです。SIerに勤務し、データベースの大規模データ処理や統計処理などパフォーマンスが要求されるシステムの設計構築に携わっています。翔泳社のデータベース系書籍を執筆したり、勉強会に参加したりしています。今回はHTAPが現場のエンジニアにどのような影響があるかなどを議論させていただこうと思います。
谷川：ミックさんが経験したデータベースはDb2ではないとか。
ミック：Db2はほぼ触ったことがないですね。なのにここに呼ばれるのは謎なのですが（笑）。SIerの立場上、案件により使う製品は異なるのですが、Oracle DatabaseやPostgreSQLの経験が多いです。
谷川：今回はHTAP（Hybrid Transactional/Analytical Processing）について採りあげます。昔からデータベースでは「OLTPとOLAPは分けた方がいい」「いや、一緒のほうが効率的だ」を何度も繰り返してきました。近年インメモリデータベースやハードウェア進化の影響もあり、再び統合へと進んでいます。HTAPはIBMだけではなくガートナーも話題にしていますが、IBMはHTAPをどう捉えていますか？
苧阪：簡単に言うとHTAPは「OLTPとOLAPを一緒にしましょう」というものです。IBMはシェアードナッシングでクエリを分散して大量データの処理をしてきました。一方でインメモリデータベースなど技術進化もあります。最近では「BLUアクセラレーション(**)」にて、1つのインスタンスでトランザクションに強い行型の表と集計に強いインメモリの列型の表を持ち、どちらも同時にこなせるように取り組んでいます。このBLUをベースに、今後さらに強化すると開発方針を出したところです。
** Db2 に実装される列指向型エンジンの総称。以降BLUと表記
谷川：現状はどこまで進展しているのでしょうか？
苧阪：開発方針を表明した段階ですので、まだ「できた」とは言えない段階です。今後の方向性を表明し、継続開発中ですので、まだ完全なゴールには至っておりません。
谷川：ミックさんはHTAPについて、どういう印象を持っていますか？
ミック：第一印象は「また出てきたか」ですね。発想としては珍しくないです。「基幹系と情報系を一元化したい」という発想は合理的で、意思決定を早くすることが期待できます。バッチが必要なくなる、アジャイルのように速いサイクルでデータ連携を回すなど。運用側からするとコンポーネントを減らせば障害点を減らすことで、TCO削減も期待できます。ただしこれまでなかなかうまくいかなかった歴史が続いています。最近だと2000年代後半、仮想化が進み、基盤統合の流れがありました。こうしたコンセプトをもとにアプライアンスも出ました。そういう意味で新しい考えではないと思っています。
谷川：2007年にオラクルからExadataが登場した時は「1台に両方入れられる」という発想でした。IBMはどんな流れでとらえてきたのでしょうか。
野間：オラクルがアプライアンスで統合していたとき、IBMは適材適所でとんがったアプライアンスを出したりしていました。その前は1台で全部できるものを出すなど、「分散しましょう」「統合しましょう」を世の中のニーズに合わせて出してきました。2000年代後半ごろだと、開発方針を表明した段階ですので、まだ「できた」とは言えない段階です。今後の方向性を表明し、継続開発中ですので、まだ完全なゴールには至っておりません。一方、今はネットビジネスやIoTなど、データが生まれる場所がクラウドへと移ってきました。こうした新しいデータをどうさばくかという課題に対しての一つの解がHTAPだと考えています。
谷川：1台に統合したように見えても、実装としては内部的に分けていたりすることもあるようです。HTAPに限らず、ミックさんは一緒にすることの是非はどうとらえていますか？
ミック：基盤統合を経験したとき、苦しんだところはリソース競合でした。情報系システムは一般にリソースを食います。特にストレージ。近年SSDの登場でリソースパワーが改善されてきたのですが。10年、あるいは5年ほど前までの統合系案件では、情報系が優先度の高い基幹系に影響を及ぼすような「巻き込み事故」がたまに起きていました。システム障害に巻き込まれる、あるいは応答がなくなるなど。これらはリソースを共有することで起きていました。
基幹系か情報系か関係なく、リソースの観点から競合を考えると他の課題もあります。例えば近年グローバルでリソースを共有するシステムがあります。日本では深夜でも、欧米では日中です。日本の深夜に重いバッチ処理をすると、欧米の業務時間のパフォーマンスに影響を与えてしまうこともあります。リソースコントロールの設計が重要になってきています。
谷川：グローバルでなくても、ニアリアルタイムなどできるだけ最新の情報を見ようとするとき、基幹系と一緒にしている情報系で細かいバッチ処理を回すと聞きます。そういう時にも巻き込み事故は起こりますか？
ミック：バッチ処理を小さくして回すというのは一つの回避策となります。なるべくリソースをフロントやキャッシュなどにオフロードするとか、設計で集中を回避することも。
こうした課題に対して「究極的な問題はどこか」と考えたことがあります。基本的にRDBはシェアードナッシングが難しく、ストレージを共有するため、そこにボトルネックが発生してしまうのではないかと考えています。シェアードナッシングができてスケールできるのなら回避できるかもしれません。問題はそれがなぜ容易にいかないのかですね。
谷川：それがなぜ容易にいかないのか、野間さんに聞いてもいいですか？
野間：更新系処理と情報系処理を一緒にすると困難に直面します。数十TBの規模感で情報系を運用する場合、大量のデータをロードしながら裏でバッチを実行したりします。IO競合しないようにシェアードナッシングで横並びにして、かつパーティションキーを設定してノード間でデータをを移動しないようにするなど、現状で両方回るようにするにはいろいろと工夫が必要となります。
谷川：オラクルやIBMのzとかはかたくなにシェアードディスク型ですよね。IBMはオープン化したときにシェアードしないタイプではじまり、シェアードするのも出すようになりました。そういう選択肢があるのは一緒にできない意思表明と捉えているのですが、どうでしょう？
野間：IBMにはオープン系Db2でpureScaleというのがあります。シェアードディスク型で、IBMのホストの技術を用いてIO競合しないような作りになっています。トランザクション数が多く、高可用性のさらに上の連続可用性を実現するための設計になっています。大量データの参照でも利用されていますが、コアの使い方など、OLTP寄りのデザインになっています。コアの使い方など、トランザクションをさばくことに注力しているため、情報系で使うと厳しいところがあります。
谷川：データウェアハウスだとシェアードナッシングのほうがいいのでしょうか。
ミック：性能は定量的な話なので、どの程度のデータをどの程度の時間で処理したいかによります。近年はハードウェアやアーキテクチャが進化しています。ストレージではSSDなどのフラッシュ、インメモリやカラムナなど。こうした進化が著しいのでテラバイト級程度までならシェアードディスクでも実現は可能かと思います。
一方、別のレイヤで難しいと思うことがあります。Hadoopをはじめとした分散系処理でデータのスケーラビリティを出そうとしたとき、技術以外にビジネスプロセスを変えることが必要になるのです。データを分散できる形で整形しなくてはならないからです。そこがムズイと思います。
谷川：OLTPとは大きく違う？
ミック：分析系での処理を想定していないものだと、データがきれいに設計されていないことがあります。技術的な問題が解決されたとしても、上のレイヤの問題が残ると思います。
古くて新しい危険思想か？あるいは理想形か？
谷川：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の話をしよう
