4億人超が利用する、インド巨大ECモールの急成長を支える
第2回となる今回、見ていくユースケースは以下の3つである。
- ケース1：write-heavyなワークロードに対するハイパースケーラビリティ
- ケース2：分散したデータストアの再統合による運用効率の改善
- ケース3：異種混合データベース環境におけるRDBとNoSQLの統合
いずれもNewSQLが持つメリットが遺憾なく発揮されている興味深いユースケースである。それでは、早速1つ目の使い方から見ていきたい。
ケース1：wirte-heavyなワークロードに対するハイパースケーラビリティ
Flipkartは、インド最大のECサイトであり、4億人以上が利用する。一日あたりのページビューは1000万回に及ぶ。システム面で見ても、数千におよぶマイクロサービスを700以上のMySQLクラスタで運用していた。文字通りモンスター級のサービスである。
Flipkartはビジネスが急成長するにともない、スケーラビリティの問題に直面するようになった。特に問題になったのが、writeの処理をマスタノードでしか受けられないことによって、注文処理が集中する特売期間にボトルネックになることである。一般に、RDBのレプリケーションを用いたリードレプリカ構成では、readはある程度スケールさせることができる。しかし、writeの処理は限られたマスタノードでしか受けることができず、早々に限界を迎えてしまう。
引用：PingCAP Blog「Why Flipkart Chose TiDB to Replace Its Large MySQL Fleet」（2023年4月3日）
[クリックすると拡大します]
これ以外にも、RDBで負荷分散を行うにはシステム側でシャーディングを行う必要があるし、マスタノードは単一障害点になりやすく、可用性の面でも不安がある。特売日のような負荷集中する日にダウンしてしまうと、その損失は天文学的な数値に上る。また、リードレプリカは常に最新の情報を返す保証がなく（いわゆる「レプリカラグ」）、データ整合性の面でも問題を抱えやすい。こうした問題を解決するため、FlipkartはTiDBの導入を決断した。導入後の構成図は下図のようになる。
引用：PingCAP Blog「Why Flipkart Chose TiDB to Replace Its Large MySQL Fleet」（2023年4月3日）
[クリックすると拡大します]
TiDBがコンピュートレイヤ、TiKVがストレージレイヤのコンポーネントである。TiFlashは高速化のためのインメモリ型ストアである。この構成をとることによって、write/readの両方の処理を自動的にスケールさせることが可能になった。また、Kubernetes上で動作することで障害時にもノードは自動復旧するため可用性も高い（近年のNewSQLはTiDBに限らずKubernetesをプラットフォームとするものが多い）。第1回でも述べたように、TiDBはMySQL互換であるため、移行も容易だった。
これが1つのクラシックなNewSQLの使い方、すなわち「ハイパースケールRDB」である。TiDBは数百万QPSのスループットを実現することができる。しかし、この事例を見て、「ウチはそこまでのスケーラビリティは求めていないし、違う世界の話だな」と思った読者もいると思う。実際、日本では米国や中国、インドのように1億人超えのメガサービスというのは滅多にあるものではない。というか、現実問題ない。そこで、次にもう少し異なる角度からNewSQLの応用方法を見てみたい。
