一歩一歩

目標と振返り | 読書記録 | 技術メモなど

TiDB User Day 2023に参加しました

はじめに

　 2023/07/07、TiDBUserDayというPingCAP社主催のパブリックイベントに参加してきました。私は2022、DB Techshowcaseに登壇したこともあり、TiDBについてはそれなりに理解した状態で臨みました。
　TiFlashという分析系で使用するコンポーネントは使ったことがなかったので、分析系の事例紹介が多くて勉強になりました。と同時に、まだまだ勉強不足であることを痛感しました。NoSQLやその他製品との比較ができるまで深めて理解していきたいと思います。
　さて、ここでは備忘も兼ねて事例紹介時にとったメモを起こしておきます。全8セッションでしたが、最初のセッションは英語であったことと、同時通訳してくださっていたトランシーバーが故障か何かで翻訳が聞こえなかったため、メモを取ったのは7セッションです。
　こういう時のためにも英語は堪能になっておくべきだと感じたので、英語の勉強もちゃんとやります。

総評、個人の感想

・まだまだ勉強不足。低レイヤー層まで理解できる力をつける。NoSQLとRDBも。

・英語の勉強をちゃんとやる。目標は、CTOやCEOと英語で会話できるようになるレベル。

・TiDBを採用するメリットは、管理コストが削減できるところにあると感じている人が多い。
　メンテナンスに向けた準備に取られる工数が削減できると感じている人が多い。
　ただし、TiDBそのものの金額はあまり変わらないという意見もある。

・PingCAP社のサポートがかなりしっかりしていて信頼できる。
ドキュメントも充実、サポートも少数精鋭で優れている。
→私も同感。かなり手厚く支援してくれている印象。

・今回のセッションでは、TiDBCloudを使っている人がほとんどだったのでは。
→マネージドサービスではなく、ソフトウェアを使った事例も聞きたい。

各セッションの記録

TiDBによる大規模ログデータ管理の挑戦！シャーディングなしで大量インサートをさばくには？
- LINE株式会社 大塚 知亮　氏

社内クラウドでMySQLサービスを提供している。
サポートするインスタンスは6000以上！！
<運用上の課題>
　・スケーラビリティ：ディスクサイズ3TB、CPU負荷、レプリケーション遅延
　・シャーディングによる運用コスト増
　　⇒TiDBを活用することで解決できるのでは。
　・社内のHA構成ツールのマルチリージョン対応
おっしゃる通り、TiUPをつかったデプロイは非常に簡単だった。

PDにもダッシュボードがあり、実行計画等、クエリの統計情報などを可視化できる

TiKV max-replicaは、TiKVのデータ管理単位を変更できるパラメータ。
設定値を5にすることで、多重障害への対策を取っていた。
補足：TiKV1インスタンスのRegion数が30000を超えるとCPUが跳ね上がるらしい
　　　Regionは96MB単位なので、30000 * 96 = 2,880,000MBくらい

<疑問点>
PDリーダーの障害試験
　クエリ停止時間は数秒だった→何秒だったのだろうか。
　私が検証した時は約15秒ほどかかっていたので、当時よりは改善されていそう。

<後で調べること>
・TiDBOperator：K8s上で動かすコンポーネント

決済システムにおけるTiDB導入の検証とその効果
 - SBペイメントサービス株式会社 - 前島 竜太郎　氏

私にもなじみのある決済サービス上での検証だった。
<検証した背景>
・メンテナンス時のダウンタイムによるサービス影響が顕著であった。
・クエリチューニングのためのアプリ開発者 - DBAとQAが増え、開発のリードタイムが増加していた。

JMeterつかった検証実施している！

<検証内容>
TiDBCloudとAuroraの比較（マネージドサービスの比較）

性能はAuroraの方が良かった。
思ったこと：
　NewSQLが得意とするQPSがあるため、処理量が少なかったのかも、、、？
　まあ、純粋にAuroraの性能の方が良かったのかもしれない。

さくらインターネットとヤマト運輸によるSlackアプリ
- さくらインターネット株式会社 江草 陽太　氏

伝わってきたこと：
将来の容量がわからなくてもスケールできるので、最小構成から開始できる！

LBではなくDNSによる負荷分散を実施しているとのこと。

<後で調べること>
DNSによる負荷分散する実装について

アジアNo.1のマーケティングSaaSを目指すMicoworksがNoSQLからNewSQLに移行した理由
 - Micoworks株式会社 陳 瀚　氏

NoSQLからNewSQLへの移行をした。
思ったこと：
・分析で使える実システムがあるといいなあ。
　TiDBの特徴の一つはHTAPであり、せっかくならこの特徴も使えるシステムがいい。
・実行計画を読み解く力は必要。

プロダクト分析サービスの超高速集計レイヤーとしてのTiDB
 - 株式会社プレイド 小川 拓也　氏

データ分析基盤でのTiDB採用事例。
おなか一杯になってしまったので、メモはあまりとれておらず、、、
申し訳ありません。

金融業界のデータ処理ボトルネックを突破：技術革新の旅
 - 株式会社SBI BITS 木内 祐介　氏

金融業界（証券）のデータ処理基盤で採用。
マーケットデータを蓄積し、意思決定/未来予測に活用している。
リアルタイム分析ができると、マネーロンダリング等犯罪の検知にも活用できる！
<運用上の課題>
ロックがかかってしまうため、リアルタイム分析はできず前日のデータを使っている状態。
要求があった場合過去データをテープなどから復元する必要がある。

TiDBの優れているところは、暗号化や監査ログのセキュリティ。
誤ってログを覗いてしまった、などを防ぐことができる。


resource controlを用いて複数環境を共存させることで、検証環境の準備コストを削減できた！

検証結果で思ったこと：
prometheusエラーにより停止した際、復旧に時間かかったとのこと。
つまり、監視が停止してしまっていることになる。
これは運用上問題となるので、実システムに採用する際は要検証する必要あり。

<後で調べること>
データ移行ツール：
TiDB Lightning https://docs.pingcap.com/ja/tidb/stable/tidb-lightning-overview
TiDB DM https://docs.pingcap.com/tidb/stable/dm-overview
TiCDC ⇒ データ同期ツールの位置づけ？

【パネルディスカッション】ゲーム業界のデータベースを覗いてみよう
- PingCAP株式会社 林 正記　氏
- 株式会社Cygames 宮脇 剛史　氏
- 株式会社スクウェア・エニックス 神津 和之　氏
- ワンダープラネット株式会社 中山 智義　氏

ゲーム業界のDBについて。
ゲーム業界の参加者は半分くらいだった。
ゲーム業界はMySQLが多く使われているらしい。

<登壇者 紹介>
ワンダープラネット　中山さん
TiDBの調査、導入を担当
スマホ向けゲーム/データベースの構造決定などを行っている
特性：ユーザデータが溜まり続けている / 数億~数十億レコード / 負荷分散を意識
月数回の新機能追加、そのタイミングでDBメンテナンス実施
→メンテナンスタイミングが限られているのが課題

 

スクエニ　神津さん
ソーシャルゲーム、アーケードタイプ
コロナ前くらいからパブリッククラウドへシフト
PaaSもIaaSも増えている。

 

サイゲームズ　宮脇さん
データベースを水平分割、垂直分割でDBいっぱい
300万QPS！！！

 

◆コストメリットをどう考える？
ワンプラ：
TiDB採用については、管理コスト削減という面でメリットを感じている。
ゲームイベントによってユーザ増減あり、分割数を調整する管理が軽減できそう。
機能開発の手を止めることがなくなる面でメリットを感じている。
シャード分割が増えるだけ性能が下がる点を解消したい、
分割方法を考えること、分割をミスするのを防ぐことができる点でメリット。
金額だけで言うと同じくらいで、管理コストを考えるとメリットあり。
特定シャードに負荷がかかるとかありそうだから、オーバースペック気味にサイジングしておく必要はある。

スクエニ：
TCOの観点で、PaaSと比較している。
ワンプラ同様、ゲームのメンテナンスにあわせてDBもメンテナンス。
シャードが増える→障害対策を考える場所が増えるということ。
⇒これを削減したい

分析計クエリにヒント句を追加して、全てTiFlashから参照するよう制限すれば、分析用のDB（余計なもの）を減らすことができる

 

サイゲームズ：
TiFlashにはあまり興味ない。笑
2社同様、金額的に安くなるとは考えていない。
如何にゲームを楽しんでくれるかを考えていて、やはりスケールアウトがカギになりそうと感じている。
エンジニア2，3人が数カ月拘束して、スケールアウトを考えている実態。
→これを解消することができれば嬉しい。

 

◆検証を通して分かったこと
ワンプラ：
TiDBへの期待：
・シャーディングなしでスケールが高い
・運用、学習コストが低い

シスベンチでwriteがスケールできるか確認。
→結果綺麗にスケールした。

TiDBCloudを用いることになると思う。
→DBに慣れていないエンジニアでもぽちぽちでできるため、学習コストは低そう。

互換性はありつつも、ストアド等のDB機能はあまりつかっていないのですんなり互換できた。
MySQLと同等性能なので、MySQLに戻すこともすんなりできる。

 

スクエニ：
MySQLとの互換性テストを実施。
互換性は問題なくつかえる。
ただしread-onlyで使っていたため、今後さらに検証は必要。
データの総量が圧縮されたが、どの程度圧縮されるのかとかは要検証。
→RocksDBの低レイヤ―層では圧縮がかかるようになる。
insertの検証は今後必要。

 

サイゲームズ：
性能試験→sysbenchをやっているケースが多い。
簡略化したシナリオを作って、Auroraと比較しようとした。
オートインクリメントを使うとスケールしない
インデックス使った検索がいまいち
→チューニングする必要がある。

 

Q：性能が出ていないとおっしゃったが、レイテンシーはどれくらいを目指している
→明確な基準はない。（都度クエリを最適化しようとしている）
→分析クエリ1秒未満を目指しているらしい。

 

◆アプリ開発側が気を付けた方がいいこと、MySQL互換について
ワンプラ：
アプリをそのまま持っていても動いた。
これまでのツールもそのまま使うことができた。
アプリ側で採番を行う設計に変更した。
→(個人の感想：アプリ側で採番することが当り前じゃないのか。)

DDLに時間がかかることがある。
→PingCAP社にサポートしてもらっているので、そんなに問題視はしていない。

 

Q：どんなDDL？
A：インデックスを作成するようなSQL。

 

スクエニ：
TiDBというよりMySQL全般の問題だが、オートインクリメントの数的な序列が維持できない。
最近は解決していると思うがレガシーシステムは考慮が必要。

 

サイゲームズ：
トランザクション開始時のスナップショット取得時間がいまいち。
(スナップショット取得時間に依存した処理をしているため。)
→リピータブルリードではなくリードコミットで十分と判断し、分離レベルを変更した。

 

◆今後のTiDBへの期待

ワンプラ：
融通の利くノードが増えると嬉しい。
でもフィーチャーリクエストは結構受け入れてくれている。

 

スクエニ：
同上

 

◆QA

Q：TiDBを知ったきっかけは？
ワンプラ
Spannerは知っていた。
CTOからTiDBの存在を聞かされ、調査を始めた。

 

スクエニ
Spannerの負荷試験を実施していた。
TiDBというよりも、NewSQLから入っていった。

 

サイゲームズ
上層部から教えてもらった。

 

Q：サブクエリを原則禁止している理由は？

水平分割してるので、同じテーブルに欲しいデータがないケースが多い。
またキャッシュに載ってるデータが多いので、キャッシュから取得した方が早い。

 

Q：パフォーマンスチューニングにて、TiDB側の設定変更はしたのか？

ワンプラ
まだそのフェーズではなさそう。
今後チューニングが必要な時期が来るので、そのタイミングで考えている。

 

スクエニ
まだパラメーターチューニングまでは進んでいない。
ブラックボックス化しているので安心している面がある。
モデレーター：多くのお客さんはパラメータチューニングはしていない。

 

サイゲームズ
基本的にはお任せしている。
今後チューニングが必要になる場合はある。

 

Q：クエリチューニングが必要になった時はどのように対応している？
基本的にはメトリクスや統計情報を確認している。

 

Q：TiDBCloudでサーバレスが追加されたが、サーバレスの検証は実施してる？あるいは視野に入れてる？

ワンプラ
コストがかからないので、開発環境で使おうかなと思っている。
本番環境では常に一定の負荷がかかっているので、おそらくこのまま。

 

スクエニ
開発環境で安く使えると思う。
本番環境でもできれば使いたい。
必要なディスクをサイジングして使っていたので、サイジングがなくなるといいと思う。

 

サイゲームズ
サーバレスは料金がわかりづらいので、あまり使おうとは思っていない。

 

Ｑ：Auroraだと、どのようなインパクトのある処理がある？
バージョンそのものをあげるものだと負荷が大きい。