Voicyでバックエンドエンジニアをしているmasaです。
少し前になりますが、10月3日に開催された TiDB User Day 2025 に参加してきました。
この分野にはそこまで詳しいわけではなく、正直「どれくらい理解できるだろう…」という不安を抱えての参加でした。
しかし、実際にセッションを聞いてみると、Voicyでも直面していたような課題感に近い話が多く、想像以上に理解できる部分が多くありました。
また、セッションで話されていた企業の方々が話されてた導入前と導入後の課題が各社で似たようなものになっていたのは印象的でした。
導入前の課題感
TiDB導入前に抱えていた課題として多かったものは次の2点でした。
コストの問題
スケーラビリティの問題
コストの問題
スケールアウトを見越したインフラ構成は、料金面だけでなく管理面のコストも膨らみがちです。
事例によっては、TiDBの導入によりシャーディングの撤廃やクラスター統合が進み、インフラ＋運用の総コストが下がったという声もありました。
スケーラビリティの問題
従来のDBサービス(例：Amazon Aurora)を用いる場合、スケーラビリティに関して次のような課題があると思います。
- シャーディングの設計が難しい
- 設計が終わってもそれを実現させるのにもコストがかかる
- スパイクがあった時にスケールアウトやスケールアップがうまく対応できない
TiDBでは、複数のインスタンスを立てられ、データを自動的に複数インスタンスへ分散して処理できるため、利用者側でシャーディング設計を意識せずに負荷分散を実現できます。
また、リクエスト数に応じてインスタンス数を増減させることで、安定したスケーラビリティを保つことができます。
導入後に見えてきた課題感
一方で、TiDBを導入した後に出てきた課題も各社で似たようなところが多くありました。 例えば次のような点が挙げられていました。
idを連番で振れない
Auroraからの移行によってパフォーマンスの課題が露呈
idを連番で振れない
TiDBでは、複数のインスタンスを立てデータを扱っています。
この時、インスタンスAでは1~30000のidを振れるようにidをキャッシュしてインスタンス内で保持し、インスタンスBでは30001 ~ 60000のidを振れるようにキャッシュしてインスタンス内で保持するといった形になっています。
この構成になっていることによって、最初に保存できたデータのidが1番でも、次に保存できたidが30001になることもあり、例えばアプリケーションの中でidを「作られた順番を担保するキー」として取り扱っているところがあれば、そのプログラムを修正する必要が出てくるといったことがあります。
TiDBでは、このidが大きく飛んでしまう問題に対するソリューションとしてMySQLモードというものもあるみたいですが、このモードを使ったとしても、「必ず連番になる」という保証を取ることは難しいそうです。
MySQLモードを使ったとしても、idが、1 → 3 → 2 →... のように保存されることがあるみたいなので、「必ずしも連番は取れないが、限りなく近い数字でidを振ってくれる」という認識くらいがいいのかもしれません。 (この辺りはまだドキュメントなどにしっかりと目を通せておらず、断定的なことは言えないのですが、「単調性と連続性は違う」という特性の問題かもしれません。)
パフォーマンスの課題が露呈
これまでAuroraによって隠してもらってたパフォーマンスの問題が、移行によって可視化されたという話も印象的でした。
「なぜかクエリが重くなった」という箇所がいくつも出てくることがあり、「今までAuroraの性能によって隠れていたスロークエリがTiDBに移行することで露呈した」とセッション内で発表されていた方が多くいらっしゃり、Voicyでもそういった箇所があった(今も隠れて残ってはいると思いますが...)ので、すごく共感しながらセッションを聞いていました。
ただ、スロークエリの問題はTiDBに移行したことが原因の問題というよりかは、インデックスやクエリを正しくチューニングできていないことが原因であることがほとんどであるため、適切なチューニングをすることで解決できる問題となっています。
参加して感じたこと
今回TiDB User Dayに参加して、多くの企業が似たような課題を抱えながら改善に取り組んでいることを知ることができ、とても刺激になりました。
TiDBはまだ理解を深めている途中の領域ですが、今後さらに学び、自分たちのシステムをより良くしていくためのきっかけを得られたイベントでした。
