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の応用方法を見てみたい。