3つの先行事例から学ぶ、「TiDB」を上手く使いこなす術──「分散」と「統合」の振り子関係の変遷

4億人超が利用する、インド巨大ECモールの急成長を支える

　第2回となる今回、見ていくユースケースは以下の3つである。

　いずれもNewSQLが持つメリットが遺憾なく発揮されている興味深いユースケースである。それでは、早速1つ目の使い方から見ていきたい。

ケース1：wirte-heavyなワークロードに対するハイパースケーラビリティ

　Flipkartは、インド最大のECサイトであり、4億人以上が利用する。一日あたりのページビューは1000万回に及ぶ。システム面で見ても、数千におよぶマイクロサービスを700以上のMySQLクラスタで運用していた。文字通りモンスター級のサービスである。

　Flipkartはビジネスが急成長するにともない、スケーラビリティの問題に直面するようになった。特に問題になったのが、writeの処理をマスタノードでしか受けられないことによって、注文処理が集中する特売期間にボトルネックになることである。一般に、RDBのレプリケーションを用いたリードレプリカ構成では、readはある程度スケールさせることができる。しかし、writeの処理は限られたマスタノードでしか受けることができず、早々に限界を迎えてしまう。

　これ以外にも、RDBで負荷分散を行うにはシステム側でシャーディングを行う必要があるし、マスタノードは単一障害点になりやすく、可用性の面でも不安がある。特売日のような負荷集中する日にダウンしてしまうと、その損失は天文学的な数値に上る。また、リードレプリカは常に最新の情報を返す保証がなく（いわゆる「レプリカラグ」）、データ整合性の面でも問題を抱えやすい。こうした問題を解決するため、FlipkartはTiDBの導入を決断した。導入後の構成図は下図のようになる。

　TiDBがコンピュートレイヤ、TiKVがストレージレイヤのコンポーネントである。TiFlashは高速化のためのインメモリ型ストアである。この構成をとることによって、write/readの両方の処理を自動的にスケールさせることが可能になった。また、Kubernetes上で動作することで障害時にもノードは自動復旧するため可用性も高い（近年のNewSQLはTiDBに限らずKubernetesをプラットフォームとするものが多い）。第1回でも述べたように、TiDBはMySQL互換であるため、移行も容易だった。

　これが1つのクラシックなNewSQLの使い方、すなわち「ハイパースケールRDB」である。TiDBは数百万QPSのスループットを実現することができる。しかし、この事例を見て、「ウチはそこまでのスケーラビリティは求めていないし、違う世界の話だな」と思った読者もいると思う。実際、日本では米国や中国、インドのように1億人超えのメガサービスというのは滅多にあるものではない。というか、現実問題ない。そこで、次にもう少し異なる角度からNewSQLの応用方法を見てみたい。

すべての企業必見、増えすぎたデータストアのコスト最適化

ケース2：分散したデータストアの再統合による運用効率の改善

　次に見るユースケースは、NewSQLが最初に考えられたときに想定されたのとは異なるものであるが、ある意味で非常に日本的なユースケースである。

　マイクロサービスを採用しているシステムは日本でも珍しくないと思うが、サービスが拡大するにつれて問題になるのが、分散したデータストアの運用管理コストの増大である。IT・Web業界に特化した人材サービスを提供するレバテックは、増えすぎたデータストアの運用問題に苦慮していた。また、それぞれのストアごとに最適なリソース設定を行うことも難しく、コスト面でも問題を抱えていたという。AWSのRDSやAuroraはアップグレード時にダウンタイムが発生してしまうため、無停止運用ができないという可用性の問題もあった。

　この問題に対して、レバテックはTiDBを導入することでデータストアの再統合を行った。これによって1つのTiDBクラスタのみを管理対象とすればよくなり、運用効率が大幅に向上。TiDBはローリングアップデートが可能なため、無停止運用も実現できるようになった。

　このようなマルチテナント収容を行う場合、いわゆる「ノイジー・ネイバー問題（うるさい隣人）」に対処する必要がある。すなわち、1つのクエリが大量にリソースを消費することで他のサービスのクエリに影響を及ぼすことは避けなければならない。TiDBにはこうした問題を抑止するためのリソース制御機能（Resource Control）が備わっており、クエリ単位や、ユーザー／ユーザーグループ単位でリソース使用量（CPU／メモリ／ストレージ帯域）を制御できる。これは、TiDBの強みの1つとなっている機能である。

　このような運用効率やリソース効率の改善、および可用性の向上という観点は、非常に日本的な発想である。先述のとおり、こうした観点は最初にNewSQLが考えられたときに想定されていたコンセプトとは異なるが、考えてみれば世の中ハイパースケールを必要とするシステムはそんなに見つかるものではない。日本企業の99%以上は中小企業であり、そこで求められるのはスケーラビリティよりもコスト削減や効率化である。その点で、これはNewSQLがマス層に浸透していく鍵となる利用方法であると筆者は思う。

「単一障害点」をTiDBに置き換えで打破　インフラをシンプルに

ケース3：異種混合データベース環境におけるRDBとNoSQLの統合

　3つ目に見るのは、RDBとNoSQLの統合という、両者の特徴を兼ね備えたNewSQLらしい事例である。

　DMM.comでは、認証APIの基盤としてMySQL、Couchbase、Cassandraという3つのデータベースを利用していた。認証APIは障害が発生すると60以上のサービスにすべてアクセスができなくなるミッションクリティカルな機能であるため高い可用性が求められるが、MySQLのマスタノードが単一障害点になってしまっていた。また、新たな機能が実装されるたびに3つのデータベースに対する機能追加が必要となり、開発効率に問題を抱えていた。3つのデータベースに習熟しなければならないというのも、エンジニアの学習コストを高くしていた。MySQLはリードレプリカ構成をとることでreadはスケールさせられるが、writeがスケールできないというケース1と同じ弱点を抱えていることも、将来的な不安としてあった。

　これらの課題に対して、DMM.comはTiDB Cloudを利用することで大幅にインフラの簡素化を実施。TiDBはMySQL互換であり、移行と開発効率のコストが下げられる点が大きなメリットであった。MySQLのマスタノードが単一障害点になってしまうという可用性の問題も解消した。そしてwrite/readともにスループットをスケールさせることができるようになった。これはケース1でも見た通りである。

振り子のように揺れながら進化する「統合」と「分散」の歴史

　レバテックとDMM.comの事例はどちらも、分散したデータストアの統合という共通した問題意識から出発してTiDBを導入した。歴史を振り返れば、かつてはデータベースというのはモノリシックなRDBが主流であった。それがマイクロサービスなどのアーキテクチャの進展により、分散データストアが一般化した。

　しかし、それによって運用効率の悪化などの問題が顕在化すると、今度はNewSQLによる再統合の流れが来ている、という状況である（しかし、そのNewSQLの中身はというと、第1回で見たように分散データベースなのが若干話をややこしくしている）。データベースに限った話ではないが、システムの世界というのはこのように統合と分散の間を振り子のように揺れながら技術の進化が促されるところがある。今後も、この「統合と分散」という軸でシステムを眺めてみると、思考を整理するのに役立つと思う。

　最終回となる第3回では、TiDBの特長の一つであるHTAPというコンセプトについて、ユースケースを見ながらその可能性を探ってみたいと思う。これもまた、データベースの統合による「スーパーデータベース」の創出という、データベースが長らく実現しようと挑戦してきた「夢」への挑戦である。