10年前の登場から再び脚光を浴びる「HTAP」は何がスゴイのか？──野心的なTiDBの構成から紐解く

システム開発の黄金律：「基幹系」と「分析系」の分離

　システム開発の方法論やアーキテクチャは長い歴史の中で変遷してきた。開発のスタイルはウォーターフォールからアジャイル、システム基盤はオンプレミスからクラウドというように変化を遂げている。しかし、その中でも絶対といっていいほど変わってこなかった原則がある。それが基幹系（OLTP）と分析系（OLAP）の分離である。この2つのシステムを分離して、その間をデータ連携（ETL）の仕組みで接続するというのがシステムの長年のセオリーであった。

　基幹系はその企業にとってのコアとなるシステムであり、利益の源泉である。利用者も社外のエンドユーザーであることが多く、システムダウンは多額の損失や社会的信用の失墜を招く。一方、分析系というのは利用者は基本的に社内の人間であるため、そこまで高い可用性は求められない。それよりも大量データに対するクエリを高速に処理するパフォーマンスに重点が置かれる。

　前者のシステムに長らく使われてきたデータベース群が、Oracle、SQL Server、PostgreSQL、MySQLといった伝統的なRDBMSである。一方、後者に使われるのは、Teradata、BigQuery、Redshift、Snowflakeといったデータベースである。両者は、処理すべきクエリの性能特性の違いから、アーキテクチャが大きく異なる。後者で採用されるアーキテクチャは超並列分散処理（MPP：Massively Parallel Processing）と呼ばれる。CPU、メモリ、ストレージを備えたノードを多数用意してデータを分散配置し、すべてのノードを使ってクエリを並列処理するという仕組みだ。

　これは性能を極大まで高速にすることができるという点で優れたアーキテクチャだが、常にリソースを使い切る思想で動くため、クエリの多重度に比例してレスポンスタイムが悪化する。これはいつでも一定のレスポンスタイム（多くの場合、90%ile 3秒という指標が使われる）を確保したいOLTPにはまったく向かない。また、分析系の障害が基幹系に波及することは避けたいという理由もあり、OLTPとOLAPのデータベースは疎結合に保つのが長年のベストプラクティスであった。

定説を覆す「HTAP」の登場　近年注目される理由は？

　この黄金律に対する挑戦として、2014年にガートナー社によって「HTAP」と呼ばれるコンセプトが提唱された。一言で表すと、OLTPとOLAPの2つの異なるワークロードを1つのデータベースで処理できるようにしよう、というものである。

　「それは前節の話で不可能だという結論が出たのではないか」と思った読者もいると思う。その通り、両者のアーキテクチャは劇的に異なる。しかし、OLTPとOLAPを分離するアーキテクチャにも、分かりやすい欠点がある。それは分析のデータ鮮度が落ちることである。2つのシステムの間をETLでデータ連携する以上、どうしてもタイムラグは発生してしまう。OLAP側のユーザーから見ればデータ鮮度は高いに越したことはない──究極的にはリアルタイム分析ができるのが望ましい。2010年代に入ってビッグデータという言葉に代表される統計分析の隆盛と、その流れを引き継いだAI/MLのユースケースが勃興することで、リアルタイムのデータ分析に対する需要が高まった。そこで考えられたのが、2つのアーキテクチャを1つのデータベース内部に持って同期処理でデータ連携するという方式である。

　TiDBはこのような方式でHTAPを実現した。「TiKV」が通常のOLAP向けノードであり、データをローベースで保持する。特徴的なのは「TiFlash」である。こちらはカラムベースでデータを保持し、MPP方式でクエリを処理する。ユーザーは、利用の際にTiKVを使っているのかTiFlashを使っているのかを気にする必要はない。クエリエンジンがOLTPとOLAPのどちらのクエリなのかを自動的に判別して処理を振り分ける仕組みになっている。両者の間ではリアルタイムでデータ同期されるため、分析系のデータベースも鮮度の高いデータを利用できる。コロンブスの卵のような発想だが、データベースの長年の問題を解決する効果的な仕組みである。

　このようなローベースとカラムベースのというフォーマットの異なるデータストアを2つ用意するHTAPデータベースとしては、他にGoogleの「AlloyDB」やSnowflakeの「Unistore」などがある。HTAPのコンセプトの登場は前述のとおり10年以上前に遡るが、需要の高まりと技術の進展によって近年注目されるようになってきている。

　NewSQL系の製品というのは、基本的にこのような分析系のヘビークエリを処理するのには向いていない。CockroachDBを作ったエンジニアたちは、はっきりと「CockroachDBはトランザクション系のワークロードを処理するためのもので、分析系のクエリを処理したいなら他のデータベースを選ぶ方がよい」と明言している。また、Amazon Aurora DSQLが楽観的ロックを採用しているのも、多数のショートクエリを処理することを前提にしたロジックである。その中で、両方のワークロードに対応しようとするTiDBの立ち位置はユニークかつ野心的なものである。

事例：90億以上のOSSイベントデータをリアルタイムに分析

　HTAPには様々なユースケースが考えられる。たとえばECや金融業界では近年、ユーザー行動データのリアルタイム分析によるパーソナライズド・マーケティングや不正検知を素早く実行することが重要視されている。またIoTではセンサーデータから危険な故障を事前検知するといった仕組みにも応用が考えられている。ここでは、TiDBのHTAP機能を使用した「OSS Inshight」というサービスを見てみたい。

　OSS Insightは、HTAPの活用方法を伝えることを目的にPingCAPが開発したサービスで、オープンソースソフトウェア（OSS）プロジェクトに関するデータを分析し、視覚化することができる。このプラットフォームは、GitHub上の90億以上の膨大なイベントデータを活用して、OSSプロジェクトのトレンド、貢献者の活動、リポジトリの成長など、多角的な分析機能をリアルタイムで提供している。具体的には以下のような機能を提供している。

　GitHubは世界中の開発者が常に更新を行っているという意味で、24時間365日稼働するワールドワイドなOLTPシステムだと見なせる。その巨大システムからリアルタイムにデータを集計してインサイトを抽出するということは、従来のOLTP/OLAPを分離するシステム構成を前提にしては不可能なことである。HTAPデータベースによって初めて可能になった好例と言えるだろう。

HTAPの主流になるのはどっち？ 「密結合 vs 疎結合」　

　これは筆者が個人的に行っている分類なので特に公式なものではないが、HTAPを実現するアプローチには2種類あると考えている。それが密結合と疎結合である。前述のAlloyDBやUnistoreといった単独のDBMSの中に2つの異なるアーキテクチャのデータベースを包含するのが密結合だとすれば、疎結合の代表はAWSの「Zero-ETL」である。

　AWSは、OLTP（Aurora）とOLAP（Redshift）は分離しておこう、と言う。そこは保守的である。その代わり、両者を接続するETLをCDCによって極力リアルタイムに近い形でデータ連携を行う、究極的には「ETLをゼロにする」という方向の発想である。AWSはこのサービスをHTAPとは呼んでいないが、目的は分析のリアルタイム化にあるため、筆者は疎結合型のHTAPと呼んで差し支えないと考えている。

　密結合型の方が、トランザクション処理と高速な分析クエリを同一システム上でシームレスに実行可能というメリットがあるが、疎結合型の方にも様々なデータソースからデータ統合が可能というメリットがある。「密結合 vs 疎結合」のどちらがHTAPの主流になっていくかは、今後数年の動向を見る必要があるだろう。

まとめ

　さて、3回にわたってTiDBをモデルにNewSQLというデータベースのアーキテクチャやユースケースについて見てきた。データベースのようなバックエンドの技術は、フロントエンドの技術に比べると一般に技術革新のスピードが遅いが、NewSQLとHTAPは久々にデータベースの世界に訪れたビッグウェーブになる可能性を秘めている。当初、NewSQLは「ハイパースケールRDB」というコンセプトとして登場したが、第2回で見たように最初想定しなかった応用方法が発見されてきている。こうした新たなユースケースの発見が、社会へ浸透していく鍵になるだろう。

　同様に、HTAPの浮沈もそのユースケースにかかっている。ECや金融の不正検知だけでは市場が少し小さいだろう。今後エッジデバイスやロボット、車両にもAIが搭載されてエッジAIの用途が増えてくると、膨大な量のセンサーデータをリアルタイムに分析処理する必要が出てくるため、光の当たる可能性のあるコンセプトである。今後も2つのキーワードに着目してデータベースの技術を見てもらえると、理解の助けになるのではないだろうか。