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

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

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

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

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

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

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

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