いまなぜ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とは大きく違う？
ミック：分析系での処理を想定していないものだと、データがきれいに設計されていないことがあります。技術的な問題が解決されたとしても、上のレイヤの問題が残ると思います。
