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の立ち位置はユニークかつ野心的なものである。