私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT【イベントレポート】
近年データベースが急速に進化し、開発にも大きな影響を与えています。そこでファインディでは「私たちはなぜNewSQLを使うのか TiDBを選定・導入した5社が語る選定と活用」と題したイベントを開催。PingCAPの日下さん、LINEヤフーの佐伯さん、アイスタイルの鈴木さん、DMM .comのpospomeさん、コロプラの曽我さん、さくらインターネットの江草さんをお招きし、NewSQLの一つである TiDBについて語っていただきました。
■パネリスト
日下 太智さん / @ksk_tic
PingCAP株式会社 プロダクトマネージャー / シニアソリューションアーキテクト
SIerにて国内外問わずEC/小売/製造/サービス/メディア/出版など様々な業界の業務システム導入プロジェクトのPMや設計・開発〜保守運用など幅広く経験。
現在はTiDBの開発主体であるPingCAPにてプロダクト改善の取り組みや様々な業界のお客様にプリセールスや導入/移行支援を行っている。
佐伯 拓哉さん / @takusaek
LINEヤフー株式会社 DBA
2020年ヤフー新卒入社。現LINEヤフーにて、MySQL PFのDBAとして運用・保守・ツール開発をやっています。
鈴木 利房さん / @toshifusa
株式会社アイスタイル DBRE
2012年から@cosmeのDBAを担当。
pospomeさん / @pospome
合同会社DMM .com アーキテクト
DMMプラットフォームでアーキテクトとして働いている。専門はアプリケーションアーキテクチャ。
曽我 光瑛さん
株式会社コロプラ エンジニア
2018年入社 技術基盤本部 インフラストラクチャ部 第1グループ所属 ゲームインフラの横断的な負荷対策やコスト最適化を担当。
江草 陽太 (こたまご) さん / @chibiegg
さくらインターネット株式会社 技術推進統括担当 執行役員 兼 CISO 兼 CIO
大阪府生まれ。ネットワーク、データベース、情報セキュリティのスペシャリスト。洛星中学・高校のロボット研究部創立メンバー。ロボカップジュニアジャパンなどのロボコンに出場。その後、大阪大学工学部電気電子情報工学科に進学。NHK大学ロボコンやSECCON等に出場。学生時代より個人事業としてシステム開発を行う。
2014年10月、新卒採用によりさくらインターネットに入社。「さくらのVPS」等のバックエンド開発を担当。IoTプラットフォーム「sakura.io」の開発責任者を担当し、サービス設計と開発を行う。2016年7月、執行役員に就任。現在は、さくらインターネット全体の技術統括とコーポレートIT、情報セキュリティを担当。ISUCON9と13の作問やU-22 プログラミング・コンテスト 2024 実行委員長などを務める。
「最近たまに見かけるTiDBってなんだ？」｜PingCAP株式会社 日下 太智さん
NewSQLだけでなくHTAPのDBとしての顔を持つTiDB
PingCAPでは、MySQLと互換性のあるOSSの分散型SQLDB「TiDB」を開発しています。いわゆるNewSQLと呼ばれる物ですね。
そもそもNewSQLとはどのようなものなのか。端的に説明すると「RDBMSのようにSQLインターフェースを持ちつつトランザクションをサポートし、一方でNoSQLのようにスケーラビリティも持ち合わせているもの」だと言えます。
製品によって詳細は異なりますが、RDBMSとNewSQLの違いは下記の通りです。
RDBMSはマスターとReadの負荷分散のためにリードレプリカを設けているため、運用の際にはエンドポイント管理が必要となります。またデータはマスターに関して書き込みを行うため、Writeの性能はマスターの性能に律速される。裏を返すと、Writeのボトルネックはマスターだとも言えますね。加えて、旧来型のRDBMSでは機動的な性能の増減が難しい部分もあります。
一方で、NewSQLはコンピューティングのコンポーネントとストレージのコンポーネントが区分けされているケースが多いように思います。アプリケーション側から見ると、Computings Nodes が ReadとWriteを総合的に受け付けるマルチマスター的な設計です。
データについては、プライマリーのレンジごとに分割してチャンクで管理しており、チャンクはリーダーとフォロワーというような形で役割分担する形です。リーダーは読書担当、フォロワーはバックアップ担当ですね。Computings Nodes 側から見ると、各チャンクのリーダーに対して読み書きを行っていくというイメージです。データがシャーリングされているようなイメージで、ノードを追加することによってスループットの向上を図ることができます。
TiDBを含め多くのNewSQLでは、障害が発生した場合にリーダーの役割を生きているノードにスイッチさせることで可用性を担保する仕組みになっているのもポイントです。そのため、障害発生時でも自動フェイルオーバーし、バージョンアップ時にもダウンタイムなくローリングアップデートをかけることができます。
またTiDBの場合は、NewSQLとしてだけでなく、HTAPのDBとして振る舞うことができるのも特徴です。HTAPとはOLTP（トランザクションワークロード）とOLAP（分析ワークロード）、これらを一つのDBとして処理するものですね。
分析を行いたい場合のアーキテクチャとしては、各サービスが読み書きするリレーショナルDBやSQLからMessage QやETLを通じてDWHにデータを入れ、分析サービス側でDWHに対してデータを読み取りに行くといった仕掛けが多いと思います。しかし、TiDBならオプショナルコンポーネントを組み込むことによって、そういったケースをサポートできます。
TiDBのアーキテクチャと便利なコンポーネントたち
TiDBのアーキテクチャについてもお話しします。下記図の通り、アプリケーション側から見ると、一つのMySQLのDBのように振舞っていきます。
ただ、内部的にはいくつかのコンポーネントで構成されており、それぞれがネットワークを介してお互いに通信し合いながら、最終的には一つのRDBMSのように振る舞うといった仕掛けとなっています。
つまり、TiDBは分散型のアーキテクチャによってスループットや多様性の向上を目指している製品だと言えます。トレードオフとして、ネットワークを介して各コンポーネントのやり取りをしているため、一定のレイテンシのオーバーヘッドがあり得るのも事実です。
続いて、各TiDBのコンポーネントについてもご紹介します。TiDBのNewSQL的なストレージを担っているのはTiKVです。
ACIDサポートの分散型KVSで、チャンクを管理しています。ちなみにTiKVではチャンクのことをRegionと呼んでいますが、本日はチャンクとします。チャンクの物理的な配置情報管理やタイムスタンプ発行はPDというコンポーネントが担っている形です。
HTAP用途の場合は、TiFlashというオプショナルコンポーネントを用意しています。
TiKVとの違いは、カラム型のデータストレージであるという部分ですね。HTAP用途で使用される際は、TiDBクラスターにTiFlashを組み込んでいただく形となります。
最後に紹介するコンピューティングのコンポーネントであるTiDBは、マルチマスターのSQLレイヤーです。
アプリケーション側からMySQLのクエリを受け取り、TiKVやTiFlashからデータを読み込んでくれます。
最新のLTSではMySQL8.0系との互換性をサポート！
互換性について、最新のLTS（v7.5）では、MySQL8.0系との互換性をサポートしています。ただし、100%の互換性ではなく、ストアドやトリガーなどの機能はサポートしていません。詳細はブログにてご確認いただけますと幸いです。
なおTiDBをご利用いただく際は、InstanceやKubernetes、フルマネージドのTiDB Cloudといった3つのパターンが考えられます。InstanceならTiUP、KubernetesならTiDB Operatorなど、TiDBクラスターをマネージングするツールを用意しているため、比較的容易に運用いただけるかと思います。
TiDB CloudにはServerlessとDedicatedといった二つのラインアップがあり、前者に関してはクレジットカードの登録不要でご利用いただけるプランもあるため、ぜひお気軽にご利用ください。
「検証を通して見えてきたTiDBの性能特性」｜LINEヤフー株式会社 佐伯 拓哉さん
課題解決を求めてたどり着いたTiDB
LINEヤフーはインターネット広告事業やイーコマース事業、会員サービス事業などを展開しています。
複数のサービスを運用するなかでMySQLが使われているものについては、データサイズが大きいと社内VMのディスクサイズ上限（5TB）に引っかかってしまう、Write heavyなワークロードが1クラスタでは捌ききれない、大量のWriteに伴うレプリケーション遅延といった課題を抱えていました。
それらを解決するべく、現状ではシャーディングで対応していて、多いものでは50個以上のシャードに分割しています。しかし、そこでもアプリケーションロジックの複雑化、運用コストの増加、可用性の低下といった課題が発生していました。
そういった課題を解決したいと「MySQL互換で水平スケール可能なDBソリューション」を求めてたどり着いたのがTiDBです。本日は、3ヶ月ほどかけてTiDBとMySQLの性能を比較・検証した結果についてお話しします。
Writeのスケーラビリティの検証1
最初にお話しするのは、Writeのスケーラビリティ検証の結果です。ここでは、PingCAP社から提供されているgo-tpcのtpccシナリオを使用して「複数の販売区域と倉庫を持つ卸売業者」を模したOLTPベンチマークシナリオによるパフォーマンステストを行いました。
スレッド数は64から倍々に増やして最大4096、データサイズはWAREHOUSE（倉庫数）で、パラメータの値によって変化しますが、今回は1番を指定してMySQLだと950GB/node、TiDBだとトータルで1380GBのサイズとなりました。実行環境はMySQLが8.0.28、TiDBはv7.5です。
【結果】
横軸がスレッド数で、縦軸が1分間あたりのトランザクション数です。青い線がMySQLで、スレッド数を変えてもあまり変わらずに66k[tpmC]で頭打ちという結果でした。一方で、TiDBはスレッド数は2048程度までスケールし、「最小のTiDB×2、TiKV×3」の構成でもMySQL以上のtpmCを示しました。TiKVノードに対しても良好なスケーラビリティが得られて「TiDB×3、TiKV×6台」の構成ではマックス207k[tpmC]と、MySQLの3倍以上のスループットを達成しました。
Writeのスケーラビリティ検証2
続いて行ったのは、更新の内容をシンプルにした場合のWriteのスループットの検証です。
画像の一番上に記載しているUPDATEを超えるようにPrimary Keyでレンジスキャンしてアップデートするというシンプルなアップデートに対して、どれほどのスループットが出るのかパフォーマンステストを行いました。1Update当たりの更新件数がrangeというパラメータで、10から始めて最大100万。同じrangeでもどの範囲に対してアップデートを行うかは、1クエリごとにランダムです。スレッド数は検証1と同じで、実行したなかで最大のQPSを結果に採用しています。実行環境も検証1とほぼ同じです。
【結果】
横軸が1アップデートあたりの更新件数で、縦軸がQPSです。青い棒グラフがMySQLのQPSで、rangeに伴いマックスQPSは低下していますが、小さいrangeの範囲ではQPSを示しました。一方TiDBはrangeが増えてもQPS自体は安定していて、TiKVの台数を増やすとQPSが順調にスケールし、高いrangeにおいてはMySQL以上のスループットを達成しました。
各種クエリのレイテンシ検証1
レイテンシ検証では、複数のクエリを用意して比較しました。今回はその中でいくつかピックアップしたものをご紹介します。
一つ目は
SELECT c FROM t1 WHERE id={PK};
という単純なSELECTのクエリをMySQLとTiDB両方で単体実行し、レイテンシ結果を比較しました。
【結果】
結果は、MySQLが0.32ms、TiDBが1.38msでMySQLの4倍以上遅いという結果でした。EXPLAIN ANALYZEで内訳を見てみると、TiDBからTiKVのデータを引っ張ってくるRPCのリクエストがほとんどを占めています。コンピューティングとストレージのノードが分離しているため、ノード間通信がレイテンシに乗ってくるのだと思います。
各種クエリのレイテンシ検証2
次に紹介するのはInner Joinと相関サブクエリのレイテンシです。Inner Joinは外部表が100万件で、両テーブルのPKで結合するJoinクエリです。相関サブクエリは、TiDBでは相関解除されMerge Joinに変換されています。そのため、相関サブクエリも実質的には外部100万件のJoinクエリとなっています。
【結果】
検証1と異なり、こちらのクエリではTiDBがMySQLの1/5以下のレイテンシ、つまり5倍以上速いという結果でした。EXPLAIN ANALYZEで内訳を確認すると、外部表取得や結合処理がTiKVコプロセッサーにプッシュダウンされていました。複数のTiKVノードで並列処理されたことで、このような結果になったのではないかと考えています。
大規模かつ将来的にスケーラビリティが要求されるならTiDB
まとめとして、スループットについては台数に対して良好なスケーラビリティが出ました。レイテンシに関しては、小規模なクエリはMySQLの方が早く、大規模かつTiKVコプロセッサーにプッシュダウンできる場合はTiKVの方が速くなるケースがあるとわかりました。
QPS／実行クエリともに大規模かつ将来的にスケーラビリティが要求される場合はTiDBの強みが出てくると思いますが、小規模な利用であればMySQLの方がパフォーマンスが良いのかもしれません。
LINEヤフーとしては、今後は導入に向けて社内で議論を進めるとともに、実サービスに流れているWrite Heavyのワークロードでの検証も進めていきたいと考えています。
「@cosmeのTiDB採用までの道のりとか」｜株式会社アイスタイル 鈴木 利房さん
幅ひろい事業を支える150以上のシステムと数百台のDBサーバー
アイスタイルはスキンケアやコスメなどの美容製品の口コミサイト「@コスメ」を開発・運用している会社です。そのほかリアル店舗やEC、グローバルメディアなど、幅広い事業を展開しており、それらを150以上のシステムと数百台のDBサーバー（SQLサーバー／MySQL）で支えています。
NewSQLの採用状況としては、SQLサーバーからTiDBへ移行する「異機種移行」と、複数のMySQLをTiDBに集約する「同機種移行」という二つの事例があります。本日はそれら二つの事例についてお話しします。
異機種移行の背景にあったのはクラウド移行
異機種移行を行おうと決断した理由としては、オンプレからAWSへ移行するにあたって創業当初から採用していたSQLサーバーをどうするかが議論になったことが背景にあります。というのも、SQLサーバーは性能がいいものの費用が高いため、今後も使い続けるか別のDBMSに乗り換えるのか考える必要がありました。
そもそも、なぜSQLサーバーを使いづけていたのかというと、MySQLよりもSQLサーバーの方が高性能だからです。SQLサーバーは異なるDB間／サーバー間でのジョインが可能で、全てのDBを一つのクラスターで運用できます。私たちはその機能をよく利用していたため、乗り換え先がなかなか見つからないといった事態に陥っていました。
そこで「全てのDBを一つにまとめても問題なく動いて、無制限にスケーラビリティがあり、価格も高すぎない」RDBMSが必要でした。
比較表を作成して確認したところ、TiDBがより優れていると判断したため、採用を決断しました。
同機種移行における三つの課題
同機種移行について、クラウド化に際してMySQLからのAWS移行はAurora MySQLをデフォルトにしていました。しかし、移行が進むにつれて三つの課題を感じるようになりました。
一つ目は、相対的なコストの高さです。システム構築前にコストの見積もりを出すと、Aurora MySQLの値段が突出してしまうという問題がありました。安価に使えるTインスタンスクラスもありますが、それでは本番稼働ができず、Rインスタンスクラスではオーバースペックになってしまいます。ちょうど良い構成がなく、冗長構成をとると値段が2倍になってしまう。そのため、社内向けシステムはシングル構成で運用する事例が出ていました。
二つ目の課題は強制バージョンアップです。自動バージョンアップまでの猶予期間が短いケースもあり、対応がとても大変でした。またそれに付随するのが三つ目の課題で、バージョンアップ時に更新ができなくなる時間帯が発生するというものです。更新できない時間を発生させないためにはサービスを停止する必要があり、そのためには複数の部署と調整しなくてはいけません。その調整がとても負荷のかかる作業だったことに加えて、toCサービスとして年に何度もサービスを止めたくないとう思いもあり、大きな課題を感じていました。
では、これらの課題をどのように解決するのか。
高コスト対策に関しては、複数のMySQLを一つのTiDBクラスターにまとめることで、トータルコストを下げつつ、冗長構成も諦めないことが可能となります。具体的には、リソース制御で特定のユーザーがリソースを使いすぎることのないようにして、MySQLの移行先としてTiDBへの移行を進めているところです。
強制バージョンアップ対策については、TiDBのサポートに問い合わせて強制バージョンアップはないと確認しました。期限までにはバージョンアップをしなくてはいけないとのことでしたが、強制されることがないのであれば、特に問題はないと考えています。
またローリングアップデートで無停止バージョンアップが可能であるため、移行が完了した後は活用していきたいなと。
###TiDBへの移行を検討中
SQLサーバーからTiDBへの移行について、現在は移行の計画段階です。データ移行や本番切り替え前の常時同期や移行前後のデータ比較はAWS DMS、TiDBからSQLサーバーへの書き戻しはChangefeed、Aurora、DMSを組みわせる予定です。
MySQLからTiDBへの移行については、ツールが充実しているのもポイントで、例えばDumplingとTiDB Cloudのimportを利用すれば簡単にデータ移行できます。本番切り替え前の常時同期はDM、TiDBからMySQLへの書き戻しはTiCDCを利用予定です。移行前後のデータ比較は、sync-diff-inspectorを利用したいと考えています。
上記を踏まえて、「NewSQLの採用はもはや冒険ではない」というのが、私たちの感想です。アイスタイルがTiDBの採用を決めたのは2年前で、当時から現在に至るまでに機能も大きく向上しています。リソース制御によるワークフローの分離、Proxyサーバー、実行計画管理など、嬉しい機能がどんどん出てきていて非常に将来性を感じるとともに、データ移行やデータ検証ツールが一通り揃っている点も素晴らしいと考えています。
「DMMプラットフォームがTiDBを採用した背景」｜合同会社DMM .com pospomeさん
認証チームが抱えていた四つの課題
DMMは60以上の事業を20以上のグループ会社で運営している会社です。私が所属しているDMMプラットフォームでは、DMMが展開するサービスの基盤となる決済システムなどを開発しています。本日は、DMMプラットフォーム内の認証チームでTiDB Cloudを採用した背景についてお話します。
TiDB Cloudを採用する前の認証チームは、四つの課題を抱えていました。
一つ目はオンプレのMySQLをクラウド化したいという点。DMMはオンプレの基盤を持っているため、MySQLをオンプレで動かすことができます。しかし、オンプレはインフラ部によって管理されているため、場合によってはインフラ部に作業申請を出して待機しなくてはいけない時間が発生していて、その待機時間を削減するためにも、マネージドなDBを採用してワンチームでDevOpsを実現したいと思っていました。
二つ目はNoSQLの廃止です。DMMプラットフォームではMySQLの他にCassandra、CouchbaseというNoSQLを使用していたのですが、3種類のDBを使用しての開発運用は大変だったため、DBを一本化したいと思っていました。
三つ目は中長期的な要件に対応できるDBを求めていたという点。書き込みがスケールして、強整合性があり、耐障害性も高いDBがあると嬉しいなと思っていました。また一度移行したからには、中長期的に使い続けたいと考えています。
最後は、DB起因のダウンタイムを避けたいということ。DMMは全体としてマイクロサービス環境となっていて、認証チームが抱えるアプリケーションがダウンすると、DMMの全サービスがダウンするというミッションクリティカルなアプリケーションです。DBのバージョンアップで認証チームのアプリケーションが20分止まると、各サービスも20分停止する。そのため、ダウンタイムを伴うメンテナンス時には、各サービスのステークホルダーに承認を得るフローが発生しており、調整コストがとても高い状態でした。
完成度の高いSpannerではなくTiDBを採用した理由
四つの課題を解決するべく、NewSQLの採用を検討することとなりました。パフォーマンスはRDBに劣るものの、認証チームのアプリケーションはレイテンシにシビアな環境ではないため、大きな問題ではありません。それならばとGoogleのCloud Spannerを導入しようと採用準備を進めていたところ、PingCAPの営業である塚本さんからDMをいただいたのです。
DMをきっかけにTiDBを認知し、MySQLのプロトコル互換という点に価値を感じたため、検討候補に入りました。マネージド環境としてTiDB Cloudがあるため、認証チームで仮にTiDBを採用した場合にDevOpsができるという条件も満たしていましたしね。
ただ、社内で検証した結果、DBとしてはSpannerの方が完成されているという印象を持ちました。SpannerはGoogleの技術力と資金力によって開発されているものですし、Googleのデータセンターで動いており、TrueTimeAPIを動かすために原子時計を使用している。要はハードウェアも含めて最適化されているため、やはりDBとしての完成度はSpannerの方が高いだろうと。
また強整合性を保証できるデータのアクセスがリーダーだけではなく、レプリカにもアクセス可能であるため、TiDBよりもパフォーマンスが高くなる可能性があります。JOIN対象のテーブルを同一ノードに保存するインターリーブという仕組みがあるのもポイントです。GoogleCloudとの連携があるため、Spannerに対してCloudPub/Subを使ってCDCを実現するといったこともできます。
それなのになぜ、TiDBを採用したのかというと、やはりMySQLプロトコル互換であるという点が魅力的だったからです。
そもそも認証チームにはDBをクラウド化したいという思いがあり、DBを利用しているアプリケーションをリプレースする計画もありました。そのため、可能な限りレガシーなアプリケーションのコードを変更したくなかったのです。
TiDBはMySQLプロトコル互換の互換性が高く、DBの接続先をTiDBに変更してe2eテストを走らせると、コード変更なしでテストが通ります。レガシーアプリケーションに手を入れる必要もなく、テーブル定義の変更も不要で、既存の運用作業も変更する必要がありません。MySQLのエコシステムをそのまま使える上、エンジニアの学習コストも低く抑えられます。結論として、Spannerに比べてある程度劣る部分はあるものの、認証チームの要件であれば中長期的に使っていけると判断しました。
本番環境でも問題なく稼働中！
TiDB Cloudを採用した結果、本番環境でも問題なく動いており、TiDB CloudによってDevOpsを徹底できています。また想定以上にMySQLプロトコル互換が嬉しくて。移行作業がスムーズに進んだだけでなく、TiDBの採用前と変わらず開発・運用ができています。既存の知見を活用できるのが、とても嬉しいですね。なお、MySQLは廃止済みで、現在はCassandraを移行中です。
パフォーマンスについては、TiDB移行後の実績値として20～30ms、場合によっては60～50msほどAPIのレイテンシが高くなりました。100msくらいまでは劣化しない、というのが本番環境で稼働させた肌感です。
まとめとして、オンプレをメインで利用していてMySQLのノウハウやエコシステムを活用したい場合やレガシーシステムに手が入れられないけれどDBを何とかしたい、といった場合はTiDBがハマる可能性があります。DMMプラットフォームの場合は「MySQLの資産を活用したい」「レガシーシステムに手を入れたくない」という2点がうまくマッチしたためTiDBを導入して良かったと考えています。
「コロプラでの長期運用プロジェクトでMySQLからTiDB移行の検証について」｜株式会社コロプラ 曽我 光瑛さん
長期運用プロジェクトにおける課題
コロプラはスマートフォンゲームをはじめメタバース、ブロックチェーンなど、エンターテインメント領域を中心に事業展開している会社です。私が所属する技術基盤本部では、コロプラで提供しているゲームのインフラを横断的にサポートし、負荷対策やコスト最適化などを担当しています。本日はTiDBの導入に向けて検証してわかった課題についてお話しします。
現状の構成ではDBサーバーは全てクラウドサービス上に構築しており、DBはVM上に構築したシンプルなSource / Replica構成のMySQLです。一方で水平 / 垂直分割による負荷分散をしています。
これにより、長期運用プロジェクトで何が課題になるのか。
コロプラではサービスを停止せずにバックエンドのサーバーの運用を行うノーメンテナンス運用をポリシーとしており、その運用の中で長期運用で肥大化したデータの削減や過剰な構成を縮小する際に Source の切替という作業コストの高い作業が発生する場合があります。またセキュリティ対応でMySQLやOSのバージョンアップに追従するためにSourceの切替が必要で、その作業が頻発していたため、運用コストの大きさが課題となっていました。
Sourceの切り替えがどういったものなのかというと、下記図の通りです。
既存Sourceの下に新しいSourceとReplicaの組み合わせを作り、データの齟齬が発生しないようにオンラインで切り替えるといった形です。この方法ではSourceの停止なしでSourceのディスク削減や新しいバージョンのMySQLに入れ替えることが可能ですが、準備に時間がかかるため頻繁に対応するのは難しい状況でした。
これらの課題解決を目指してツールを調べた結果、コロプラではTiDBの導入に向けて検証を進めることにしました。TiDBを選択した理由はMySQL互換であり、スケールアウト / スケールインが比較的容易に実施できること、メンテナンスなしでバージョンアップが可能であることに魅力を感じたからです。また分割したDBをそのままエンドポイントに集約可能で、肥大化したデータを圧縮することでディスクの削減ができる点もポイントでした。
移行検証で見えてきた三つの課題
検証の結果についてお話しします。よかった点としては、データ圧縮が想定通りMySQLの3分の1程度まで圧縮できたことと、レイテンシの悪化もあらかじめ想定していた許容の範囲であったことです。ただ、実際に導入するためには、三つの課題があることがわかりました。
一つ目はデータ量による負荷です。
というのも「開発環境のデータを入れて、その中で開発環境のクエリを本番環境相当の量まで増幅させる検証」と「本番環境相当のデータを入れて、本番環境相当のクエリを流す検証」では、負荷の上がり方が異なりました。
大量のデータによってTiKV上でリージョンの分割が多く発生し、リージョン間のやり取りのプロセスにより、クエリの量以上にTiKVの負荷が上がってしまったために、目標のパフォーマンスが出なかったのではないかと考えています。
ただ、この点については、TiKVのリージョンにはPrimary Keyの連番でレコードが配置されるため、適切な Primary Key やインデックスを追加することで負荷を下げられるということもわかりました。
二つ目は得意でないクエリやデータが存在するということ。一部のDBで本番相当の負荷をかけた際に、クエリ量に対して負荷が高い状態となりました。どのくらい高かったのかというと、「TiDBでこのくらいのQPSを処理できてほしい」と期待していた数字の半分程度のパフォーマンスだったDBとクエリが存在しました。
最後の課題はトランザクション分離レベルです。TiDBはMySQLと同じREPEATABLE-READですが、実装が異なっており、本番相当のクエリ量で試験した時に意図しない動作が発生しました。具体的には、リトライによる多重リクエストのようなクエリで、二重インサート防止のためのアプリケーション側のロジックがInnoDBの挙動に依存していたためエラーが発生しました。
課題を踏まえて移行を検討
今回の検証を通して、小規模なデータや低頻度のアクセスでは発見できない課題があることがわかりました。適切な規模で負荷試験を実施することで、分散DB特有の問題を見つけることができます。また前述の通り、TiDBでは適切なデータ配置になるようなインデックスやPrimary Keyの設定をすることと、InnoDBの挙動に依存しているロジックについては改善する必要があるとわかりました。
「長期間TiDBを使ってきた話」｜さくらインターネット株式会社 江草 陽太 さん
TiDBのメリットは運用構築及びメンテナンスの容易さ
さくらインターネットの技術全般の執行役員であり、CISOとCIOも兼任している江草と申します。さくらインターネットではクラウドサービスを主力に事業を展開しており、TiDBをオンプレミスで長期間運用しています。本日は、そういった経験を踏まえてTiDBについてお話します。
さくらインターネットで最初に導入したのはTiKVで、LTEによるIoTプラットフォームのデータストアの機能として、端末（モジュール）からのデータを蓄積し検索する部分で使用していました。その後、それまではMariaDBやPostgreSQLをDBとして使っていたシステムにおいて、TiDBを採用するようになりました。また2021年からは「エンハンスドデータベース(TiDB)」というTiDBのSaaSサービスも提供しています。
最初に構築した際にはv5.0.0でしたが、そこから同じクラスターで稼働したままアップデートを続けており、途中でTiFlashノードを追加しているほか、基本的にLTSを選択しているため現時点でv7.5.0にアップデートするところまできています。
実際にTiDBを使用していて思うメリットは、メンテナンス作業が容易であること。構築用に用意されているTiUPコマンドを使用すると、Terraformのように自動で構築できます。また台数の増減もTiUPコマンドで可能です。
TiFlashを活用すればOLTPとHTAPが一つのシステムで実現するのも嬉しいですね。チューニングする余裕がない時にも、TiFlashを作ればパフォーマンスの力で通すことができます。それを実感した事例については後ほどお話しします。
またTiUPで構築すると、Prometheusが設定されるほか、Grafanaのダッシュボードが用意されるのも良いですね。加えてTiDBのダッシュボード機能もあり、QPSやクエリの遅延、GUI上でキーの分散状況がどうなっているかといったことが確認できます。TiKVのノードのデータ配置なども、こういったトポロジーで表示してくれます。
ちなみに上記はまだリリースしておらず、石狩と東京でマルチリージョンでクラスターを組んで見ているサービスのダッシュボードのスクリーンショットです。Storesの右にzoneで石狩と東京があり、サーバーが3台ずつあるといった構造のデータトポロジーも確認できますね。
そのほか、オープンソースのツール群の中にあるTiProxyというMySQL互換のTiDB向けプロキシを導入すると、無停止アップデートができる点もメリットだと思います。
実際に構築・運用する際は、まずTerraformとSacloudProviderでサーバー等のリソースを作成します。SSHの認証情報や認証設定などOSの基本的なセットアップはAnsiblで行い、その後にTiUPを流すとTiDBが構築されます。日常のTiDBのバージョンアップや設定変更等はTiUPのみで行っています。なおTiProxyをTiDBの外側に挟むことで、TiDBのアップデート時に既存の接続は維持されます。詳細はこちらで紹介していますので、よろしければご覧ください。
さくらインターネットにおけるTiDBの活用事例3選
先述した「エンハンスドデータベース(TiDB)」では、石狩と東京で運用されているTiDBクラスタを共有で提供しています。DB名とパスワードを指定するだけでDBが作成されて、数秒で利用可能となります。
この機能は独自のMySQLプロキシ等を開発することによって実現しており、上図のようにいくつかの項目、あるいはリージョンを選んでいただいて作成すると、接続先のホスト名、DB名で表示されます。
それをコマンドで繋いでいただくと、SQLとして使用できて、WordPress等も動作するといったサービスです。
「エンハンスドデータベース(TiDB)」を使用して、自社では「宅配便取次アプリ（Slackで宅急便が遅れるサービス）」「Antenna-eye（クラウドカメラサービス）」「ネットワーク品質計測可視化システム」などのサービスを開発しています。
「宅配便取次アプリ」は、Slackで荷物の情報等を入力していただくと、相手に住所の入力を促します。相手が住所を入力してくれたらQRコードが出てくるので、それを使って荷物を発送するというやり取りのバックエンドのDBに使用しています。
「Antenna-eye」はまだリリースしていないサービスですが、TiFlashが大活躍してくれた事例があるのでお話しします。
ある日、あるAPIのエンドポイントがとても遅くなったことがあり、原因は機能改修によるもので短時間での解決が困難な状況でした。そこで一時的にTiFlashを入れてみたところ、10秒程度かかるクエリが0.1秒程度に高速化したのです。その後クエリやインデックスを調整してTiKVだけでも問題ないようになったのですが、一部Manuel Hintを入れる形でTiFlashも継続利用しています。
「ネットワーク品質計測可視化システム」については、現在β版を公開しています。
ここで何を保存しているのかというと、メトリクスはPrometheus、それ以外の測定データや管理情報はTiDBに保管しています。時系列のTracerouteの結果などが入っており、このDBだけで約400GBほどあります。
ちなみにこれらのシステムは、ほとんどがPythonとDjangoを使用して開発しており、これまではPingCAPさんのdjango-tidbというDBドライバーを利用していました。過去形でお話ししている理由は、v7.5.0からMySQL8.0 compatibleになったためです。現在はdjango-tidbがなくとも動作するため、MySQL互換であるというのは大きなメリットだなと強く実感しています。
可用性が高くメリットが多いTiDB
運用していて改めて感じるTiDBのメリットは、可用性がとても高いという点です。MySQLかPostgreSQLであれば、例えば最小構成でも2台でアクティブ・スタンバイにして障害が起きた際にはVRRPで切り替えてVIPに付け替えるといったことができますが、やはり少し不安なところがあります。
しかし、TiDBであればノードの障害が発生してもすぐに別のノードに切り替わりますし、DBであっても分散システムの恩恵を受けられるのはとても嬉しいです。アップデートも頻繁に行えますし、台数を増やせるという安心感があるのもメリットですね。私たちの場合、データ量が大きいからではなく、可用性や運用面でのメリットからTiDBを選択しています。
一方でデメリットもあり、MySQLと比べてサーバーの台数は多くなってしまうため、コストが高くなっているようにも感じます。この点については運営の多様性やメンテナンス性が上がっていることで置き換えられると思いますが、コストだけで考えるとデメリットだと言えます。
また分散システムに慣れていないと複雑に見えてしまうため、人によってはその辺りもデメリットだと感じられるかもしれません。私個人としてはTiUPの運用などが非常に便利なため、そこまで大きな問題だとは考えていません。
