今年も TiDB User Day に参加しています！
去年に引き続き今年もライブブログやってみようと思います。(めっちゃ久々ｗ)
最初のセッションはごめんなさい、ちょっといろいろあってライブブログはスキップしています
東京ガス内製開発チームリーダーが語る TiDB本番運用の今
講演者
東京ガス株式会社 リビング戦略部 デジタルプロダクト推進グループ
Platform Team Lead 青木 翔平 氏
Software Engineering Team Lead 中島 潤耶 氏 → 迫田 賀章氏
- 東京ガス
- 第３創業期
- 脱炭素化による地球環境への貢献 & デジタル化による収益拡大
- 第３創業期
- アプリケーション開発 Team から見た TiDB
- 内製開発の取り組み
- エネルギー公理全面自由化による変化
- 選ばれる存在になったことで、デジタル接点によるお客様の獲得や体験価値の向上が喫緊の課題になった
- エンジニアリングチームを立ち上げ、内製開発を推進
- 選ばれる存在になったことで、デジタル接点によるお客様の獲得や体験価値の向上が喫緊の課題になった
- 事業組織内にプロダクト開発・運用の内製化に必要な人材が在籍し、ビジネス・デザイン・テクノロジーの距離感が近い状態で開発を行なっている
- 同じ組織にいるからこそ、一体となって価値を届けられる
- プロダクト組織内にプロダクト開発の内製化に必要な人材が在籍し、プロダクト開発を推進
- エネルギー公理全面自由化による変化
- my TOKYO GAS
- ガス料金、使用料等をみえる
- リニューアルのタイミングで完全内製化を実現
- フロントエンド領域の内製化
- 最初はフロントから、バックエンドは外注という形で進めたが。。。
- 現状の課題
- レガシーシステムの API 改修が困難であったため、BFF 内部にドメインに変換する処理が構築されている、内製開発がフロントエンド領域に限定されていたことで開発の柔軟性が低下
- my TOKYO GAS で扱うデータは他サービスでも有用であることから my TOKYO GAS というサービス自体が他の BtoC サービスの共通基盤として機能しており、開発の柔軟性が低下
- 現状の課題
- 最初はフロントから、バックエンドは外注という形で進めたが。。。
- バックエンド領域への内政化の拡大
- ドメイン層のマイクロサービス化と共通基盤化
- 料金やポイントなど、東京ガスとして汎用的に利用できるドメインの処理・データをマイクロサービスとして切り出し共通基盤化
- my TOKYO GAS 以外のサービスも共通利用できるように開発
- 料金やポイントなど、東京ガスとして汎用的に利用できるドメインの処理・データをマイクロサービスとして切り出し共通基盤化
- データベースの選定
- my TOKYO GAS は 500万弱のユーザーが利用しており、それに耐えうるアーキテクチャが必要となった
- 将来的に1000万以上のユーザーになる可能性
- ユーザーが登録するデータのレコード数は膨大
- 内政チームの置かれている状況
- 内製化のためのエンジニアを多く抱えているわけではない
- 障害対応や保守運用も自分たちで担う
- エンジニアも事業を考え、技術鵜を通じて事業に貢献することが求められている
-
エンジニアもビジネスに深く関わり、ビジネス価値に直結する開発にエンジニアの力を注ぎたい
- TiDB の導入検証へ
-
エンジニアもビジネスに深く関わり、ビジネス価値に直結する開発にエンジニアの力を注ぎたい
- my TOKYO GAS は 500万弱のユーザーが利用しており、それに耐えうるアーキテクチャが必要となった
- ドメイン層のマイクロサービス化と共通基盤化
- TiDB 導入に向けて検証したこと
- MySQL との互換性は？
- 特定の製品仕様にアプリケーションコードを依存させたくない
- 本当に期待したパフォーマンスを出せるか？
- 500万弱のユーザーの生成できるデータを保存でき、パフォーマンス劣化が生じないか
- MySQL との互換性は？
- 結果
- TiDB の導入を決定、一部課題があった
- ID の採番方式
- AUTO INCREMENT
- 単調増加しない
- AUTO INCREMENT(MySQL 互換モード)
- 単調増加する
- 書き込み性能が劣化する
- AUTO_RUNDOM
- ランダムに採番
- AUTO INCREMENT
- Connection Pool
- クラスタにあるノードのうち一台が落ちた場合、Connection が破棄されるまで負荷が集中する
- コネクションのライフサイクルを短めに設定し、短時間で接続が分散されるようにする
- クラスタにあるノードのうち一台が落ちた場合、Connection が破棄されるまで負荷が集中する
- 外部キー制約
- 外部キー制約はパフォーマンスの低下を起こす可能性があり、利用を慎重に検証する必要あり
- 負荷試験の結果
- 131rps で 5分間の負荷をかけた結果、多数のリクエストでタイムアウトが発生
- TiDB は共有ロックを持っていないため排他ロックになってしまう
-
INSERT する前後だけ、そのセッションにおける外部キー制約チェックを OFF にする処理をアプリケーション側で実装
- 結果として大幅改善ができた
-
INSERT する前後だけ、そのセッションにおける外部キー制約チェックを OFF にする処理をアプリケーション側で実装
- バッチ処理での利用
- バッチ処理は大規模なデータを取得するものだったが、２つの TiDB ノードに交互にリクエストを投げている様子が観測された
- 暫定的な対応としてメモリ解放のための時間を設けた
- Node Group が GA
- 現在検証中
- バッチ処理は大規模なデータを取得するものだったが、２つの TiDB ノードに交互にリクエストを投げている様子が観測された
- ID の採番方式
- TiDB の導入を決定、一部課題があった
- さまざまな検証の結果本番プロダクトでの TiDB の採用を決定
- 導入してみて
- 1年弱運用した中で DB 起因での問題は発生していない
- いくつか TiDB であることを気にする必要がある
- データ量による影響が限定的な点は大きなメリットであり、設計・運用工数を削減できる
- データベース設計・運用工数を抑え、鍵ラテ他開発チームのリソースをよりビジネス領域に充てられた
- 内製開発の取り組み
- Platform Team から見た TiDB
- 開発期間での悩みポイント
- どの TiDB 製品を選択すべきか
- TiDB Self-Managed
- TiDB Cloud Serverless
- TiDB Cloud Dedicated
- TiDB Cloud Dedicated を採用する場合、クラスターの単位をどうするか
- クラスタを一つに集約するか、サービスごとに分離するか
- 当時
- 全ての環境で TiDB Cloud Dedicated を採用
- 本番環境、STG環境では可用性確保、安定運用、監査ログの取得
- DEV 環境はその要件はなかったが、一旦運用面から DEV も採用
- 全ての環境で TiDB Cloud Dedicated を採用
- TiDB クラスタ構成の方針検討
- 新規マイクロサービス開発を気に SW チームとクラスタ構成について議論を実施
- 新規マイクロサービスを既存 TiDB クラスタに集約する方針で開発を進める
- バッチ処理による負荷をオンライン処理から分離するために Node Group の利用を検証する
- 新規マイクロサービス開発を気に SW チームとクラスタ構成について議論を実施
- どの TiDB 製品を選択すべきか
- Node Group の検証
- オンライン処理中にバッチ処理を実行する負荷テストを実施
- 各 Node Group で処理実行中の時間のみに負荷が発生するようになった
- Node Group を分離してもバッチ処理が正常に終了
- オンライン処理中にバッチ処理を実行する負荷テストを実施
- TiDB を採用して良かった点
- TiDB を起因とするトラブルは未発生
- 日常的なメンテナンス工数が少ない
- 気にしないといけないところ
- TiDB Cloud ユーザーの権限粒度
- 求めているレベルよりも粗い
- API を活用し、GitHub Actions などで細かい権限設定をしている
- オートスケーリング
- Native としてのオートスケーリングはない
- コスト管理
- API で自動起動・停止する仕組みを実装
- リソースコントロール、Node Group でリソースを管理
- TiDB Cloud ユーザーの権限粒度
- 開発期間での悩みポイント
- TiDB 導入の最大の利点は・・・
- エンジニアが事業貢献に集中できる
Aurora→TiDB：1年間の移行プロジェクトとマルチテナント運用の全貌
レバテック株式会社 レバテック開発部 DevOps推進グループリーダー 金澤 伸行 氏
ざっくりまとめ
- Aurora から TiDB への移行で約40スキーマを1年かけて完了、DMS 移行の課題や AUTO INCREMENT 問題を地道に解消
- 移行後はインデックス最適化や Node Group 活用などでメモリ・パフォーマンス課題を改善し、運用を安定化
- 運用工数が大幅削減され、権限管理やバックアップの自動化など DevOps 体制が進化して「運用が楽になった」
- 移行作業について
- 体制
- 移行には時間とコストがかかる
- 役割分担をして開発部全体の協力を得ながらスムーズな移行を目指す
- 責務を明確にした
- 移行には時間とコストがかかる
- 移行方法
- メンテナンスはこのタイミングでは入れた
- Amazon DMS を採用
- 移行時にスキーマ名が重複するケースがあった
- 積極的におすすめはしない
- 移行時にスキーマ名が重複するケースがあった
- 事業調整 → 移行準備 → 移行をひたすら繰り返す
- 移行状況
- 約40スキーマを Aurora から TiDB に移行完了
- 体制
- 移行に伴って発生した問題
- データ移行でのつらみ
- DMS でテーブル定義を連携すると必要最低限しか連携されない
- 外部キー制約やインデックスが作られない
- デフォルトの COLLATION や CHARASET が異なる
- Timestamp がずれる
- UTC → JST の変更が必要
- DMS でテーブル定義を連携すると必要最低限しか連携されない
- AUTO INCREMENT 問題
- 連番を AUTO INCREMENT で担保していたシステムが存在
- 接続する TiDB が切り替わると ID が飛んだリ戻ったりする
- パフォーマンス
- Aurora によって隠蔽されていたクエリ自体の問題が表面化
- Aurora にいかに助けられていたかを改めて実感
- TiDB に移行しただけではパフォーマンスが上がることはない
- TiDB に合わせたチューニングが必要
- Aurora によって隠蔽されていたクエリ自体の問題が表面化
- メモリ管理
- 検索系のページで実行されるクエリ
- クエリ結果が大量
- 大量同士の JOIN
- TiDB ノードで JOIN する際のデータ量が多くメモリを逼迫
- OOM によってノードの入れ替えが発生すると瞬断
- 検索系のページで実行されるクエリ
- RU の管理
- Request Unit
- 単一のリクエストで消費されるリソースの単位
- どう頑張っても予測できないので実際に移行するまでわからない
- 概算は出る
- RU が消費されるタイミングはシステムによってばらつきがある
- それぞれのピークに合わせて RU の最大値を設定
- 場合によってキャパシティを超えてしまう
- クラスタの上限に合計値を合わせる
- 余分にリソースがかかってしまう
- Request Unit
- データ移行でのつらみ
- 対応
- AUTO INCREMENT
- MySQL モードで対応
- デメリット
- 一台のノードで 4000毎に ID をキャッシュする
- TiDB Node 再起動や入れ替えによって ID が最大 4000飛ぶ
- キャッシュする範囲は変えられない
- ID の偏りにより TiKV で適切なリージョン分割がされない
- ID の発行を1台の Node に依存することになる
- 一台のノードで 4000毎に ID をキャッシュする
- デメリット
- Sequence テーブルも検討したが現時点では利用していない
- 連番じゃなくてもいいけど ID が大きく飛ぶことを避けたい場合
- AUTO_ID_CACHE=2 みたいな使い方を一部で検証したがキャッシュの生成頻度増加などパフォーマンスに影響が出る
- PK に依存した形には避ける
- MySQL モードで対応
- パフォーマンス
- まずは INDEX をつけていく
- INDEX Lookup を減らす
- カバリングインデックスを設定する
- 書き込みへの影響は考慮が必要
- JOIN の最適化
- JOIN 前に必要なデータをシェラス
- STRAIGHT_JOIN 等の仕様
- JION を諦める
- TiFlush に頼る
- クエリの速度はある程度改善したケースがあったため、恒久対応ではなく、暫定対応とした
- メモリ管理
- パフォーマンス改善に取り組むことで解消されるケースが多い
- INDEX の活用
- JOIN の最適化
- システム変数メモリ上限を設ける
- 想定外のメモリ消費には高係
- 一部システムとしての要件を満たせなくなるケースあり
- Node Group を活用し TiDB Node を分割する
- データ連携用の Node Group
- 移行用の Node Group
- 通常運用用の Node Group
- データ取得を TiFlush に寄せる
- チューニングが難しいケースで有効
- JOIN が TiFlush ないで全て消費され、結果のみを TiDB に返すようになる
- パフォーマンス改善に取り組むことで解消されるケースが多い
- RU の管理
- 現状大きな問題にはなっていないため、最適化できていない
- 今後 RU 設定値の見直しとプライオリティの調整を行う予定
- とはいえ必要なこと
- 基本的に、まずは普通のチューニングをやる
- MySQL で適切なクエリが実行されていれば、特別なチューニングはほとんど必要ない
- Aurora でやれることをやっていればもっと楽に移行できた
- AUTO INCREMENT
- 運用で工夫したこと
- ユーザーやリソースグループをコード管理
- 誰がどのスキーマにどの権限でアクセス可能かを可視化したい
- 採用や異動による権限変更を容易にしたい
- 変更の履歴を残したい
- 全てスクリプトで実施
- スキーマ毎のバックアップの仕組みの構築
- 公式のバックアップはクラスタ単位
- 復元の際は別クラスタを立てる方式
- テーブル単位のバックアップとリストアの仕組みの構築を試みる
- tiup dumping によるバックアップ作成
- import into でリストア実行
- 現在検証環境で利用しながら構築中
- 公式から仕組みが提供されることに期待
- 公式のバックアップはクラスタ単位
- ユーザーやリソースグループをコード管理
- 今後の展望
- NewRelic 連携による監視強化
- メトリクス
- RU は過去1日までしかデータ見れない
- その他のメトリクスは過去7日
- アラート
- RU に対するアラート設定ができない
- 柔軟なトリガーが設定できない
- メトリクス
- TiProxy 導入による可用性改善
- 現在は Node 再起動や入れ替えによって瞬断が発生する
- これを解消したい
- 現在は Node 再起動や入れ替えによって瞬断が発生する
- 他にも
- 動的なスケーリング
- TiCDC によるデータ連携
- 分析観点での TiFlush の活用
- ベクトル検索
- ,,,
- MySQL のように使うための工夫 → TiDB としてどう活用するか
- NewRelic 連携による監視強化
- まとめ
- 移行は大変
- ほとんどは Aurora に隠されていた問題が顕在化されただけ
- DB の機能に依存した実装はしないほうがいい
- Aurora でやれることをやってから TiDB を検討することをお勧め
- 運用は非常に楽になった
- 移行期間中にバージョンアップ
- メンテナンスなしで無事終了
- チケット起票して見守るだけ
- 手厚いサポート
- 困った時はいつでも相談できるサポート体制
- DB エンジニアがチームに増えたと錯覚するレベル
- 移行期間中にバージョンアップ
- 移行は大変
モンスター級のデータを捌け！ “助けて！”を助ける モンスターハンターワイルズのDB
株式会社カプコン モンスターハンターワイルズ
リードサーバーエンジニア 筑紫啓雄 氏
サーバーエンジニア 戎脇涼 氏
ざっくりまとめ
- クロスプレイ実現のためにモンハンワイルズでは自社ネットワーク＋AWS基盤上で構築、膨大なリアルタイムトラフィックを捌く必要があった
- 救難信号レコード管理に TiDB を採用し、自動シャーディング・スケールインアウト・TTL などで爆発的なデータの生成削除に対応
- 結果としてノーメンテでスケール調整可能な高可用DB運用を実現、TiDB が“モンスター級”の負荷を支える基盤となった
- 前作とのネットワークにおける大きな違い
- 自社ではネットワークを管理せず、1st パーティプラットフォームのネットワークを利用してオンラインを実現
- 別プラットフォームとは一緒に遊べないという課題があった
- 自社で管理するネットワークを用意することによってプラットフォームを超えて一緒に遊べるクロスプレイを実現
- 自社ではネットワークを管理せず、1st パーティプラットフォームのネットワークを利用してオンラインを実現
- モンスターハンターワイルズは AWS 利用
- EKS on Fargate + VPC Lattice
- リアルタイムサーバは霊天使をできるだけ少なくするため複数リージョンに設置
- こっちは Fargate は使っていない
- AWS リソースへのアクセスは API サーバを経由
- クエストセッションは P2P 通信
- ピーク時 100万人以上同接
- API サーバ 1600 vCPU
- リアルタイムサーバ後継 18000vCPU
- …
- API サーバはスケールアウトでトラフィックを分散
- 場合によって別リージョンから拝借
- データを扱う部分がスケールが難しい
- 単一の DB では耐えられないトラフィック
- 途中でスケールが簡単にできる
- 巨大なトラフィックに耐えられる
- 運用負荷が少ない
- Dynamo DB
- 対象を一人に取るデータを扱う機会が多い
- 事前申請したユニットベースで性能が決まる
- スケールアウトは Quota 申請した分まで可能
- 複雑な検索に弱い
- モンスタハンターワイルズでも複雑なクエリが必要になるケースがある
- カーディナリティも低い
- DynamoDB では耐えられず、RDB を使わざるを得ない
- RDB
- カーディナリティが低いので INDEX 効果が薄い
- リードライト両方の頻度が高い
- レコード数も多い
- チューニング後に取れる解決方法は？
- 性能でゴリ押す・・・
- 水平分散
- 台数に応じて増やすことができる
- アプリの複雑化やユーザー数でてを入れる可能性が高い
- 水平分散
- 性能でゴリ押す・・・
- チューニング後に取れる解決方法は？
- TiDB を利用
- 開発当初は Aurora Serverless v2 を利用
- 水平分散の複雑さを考慮して TiDB
- ダウンタイムなしでスペック変更可能
- 台数増減も簡単にできる
- マネージドサービス
- MySQL 互換なので移行も楽
- 他の選択肢
- DSQL
- Spanner
- Cockroach DB
- 単一の DB では耐えられないトラフィック
- ワイルズのどこで TiDB を使ったのか
- 救難信号！
- オーダー
- クロスプラットフォーム
- 検索条件を増やしたい
- 前作より便利に
- 満員時の挙動
- ホスト切断時の挙動
- クエスト P2P セッションは別サービスで
- オーダー
- 立ちはだかる壁
- クエストセッション(実態)は外部サービス
- 独自サーバからセッションの開始・終了が取れない
- でも、終了したクエストのレコードは消えて欲しい
- 検索条件の種類は開発初期に確定
- 諸々合わせて 10 種類
- 各条件、どんな組み合わせが使われるかは不明
- データの傾向が事前に読めない
- 全世界・全プラットフォーム同時発売は初めて
- 初日の同接数が全然読めない
- クエストセッション(実態)は外部サービス
- 救難信号レコードの特性
- 揮発性が高いデータ
- 最長でも生存期間は1時間程度、平均 10~20分程度
- レコードの作成・削除が常に行われ続ける
- これ、本当に RDB で管理していいのか？
- カーディナリティがとても低い
- 常に作成・削除が行われるレコード
- 検索条件は複雑だけど構造化されている、全文検索までは不要
- 総レコードは数万から数十万くらいの想定
- 他に適したプロダクトが思い浮かばない
- 最初は Aurora Serverless v2 を使用
- 設計
- DynamoDB RDB の二重管理
- DynamoDB には「クエストセッション情報」
- RDB には「検索レコード」
- RDB の懸念
- 検索条件は 10種類程度
- 毎回全条件指定されるわけではない
- 何が来るかわからないので頻出クエリを絞れない
- 全パターンをカバーするインデックスを貼ると 100以上
- レコード作成・削除時のインデックス再構築コストを懸念
- このカーディナリティならフルスキャンでも変わらない？
- そんなことはなかった。。。
- 検索条件は 10種類程度
- テーブル分割
- いくつかの条件をテーブル名で持つ
- クロスプレイ設定、プラットフォーム、フィールド、難易度
- 絶対に無くならない・使用頻度が低い条件
- 200テーブル程度になった
- クロスプレイ設定、プラットフォーム、フィールド、難易度
- これらの条件は検索クエリに含めない
- 4条件指定されている時は対象テーブルを一意に特定
- 条件を満たすテーブルから複数選んでクエリを投げる
- 1テーブル15インデックス程度に収まった
- 定義ファイルや各種SQLは自動生成
- いくつかの条件をテーブル名で持つ
- 未解決問題
- 「条件の偏り」はみ考慮
- 条件毎に参照頻度が異なる
- クロス有効・無効で大きくレコード数が異なる
- 人気クエストは少数のテーブルに集中しそう
- 規模的に1node では負荷を捌けない
- 一般対策
- テーブルを複数ノードにシャーディング
- とりあえず今すぐ動くものが必要
- 全てを棚上げして月日が経つ
- テーブルを複数ノードにシャーディング
- 「条件の偏り」はみ考慮
- TiDB を使うことによって棚上げしていた問題が解決した
- 何が解決したのか
- 自動データベースシャーディング
- 水平方向のシャーディングは TiDB にお任せ
- 1テーブルの孵化を複数ノードで処理
- テーブル分割自体はそのままにしておく
- 大した管理コストではない & インデックス構築の負荷は厳しそう
- 水平方向のシャーディングは TiDB にお任せ
- 自動データベースシャーディング
- 流石に考えが甘かった
- 負荷試験でそれなりに詰まる
- レコードの作成・削除の頻度が高いことによる負荷
- TiDB は追記型
- 履歴データが大量に溜まって性能悪化
- 履歴データを減らす、見ないようにする対策を入れる
- Compaction Filter の無効化
- In-Memory Engine の利用 (当時は experimental なので検証だけ…)
- 負荷試験でそれなりに詰まる
- その他のチューニング
- レコード作成リクエストのキューイング
- API サーバー → SQS → レコード更新ワーカー
- API レスポンスタイムへの DB 性能影響軽減
- ワーカー数により TiDB への同時アクセス数を制御
- API サーバー → SQS → レコード更新ワーカー
- クエリキャッシュ導入
- 共通キャッシュサーバを利用
- 同一検索クエリは3秒間だけキャッシュ
- アプリケーションレイヤーでの実装
- レコード作成リクエストのキューイング
- 何が解決したのか
- OBT、本番リリース時
- 負荷が下がってきたタイミングでスケールインを実施
- TiDB, TiKV
- ノーメンテナンス、オンサービス
- 全くトラブルなし
- 一部のクエストのみが遊ばれるような環境
- ２、３テーブルにレコードが集中
- TiDB 側に分散を完全に任せたが特に問題なし
- 最大レコード数は 10万レコード程度
- 負荷が下がってきたタイミングでスケールインを実施
- 揮発性が高いデータ
- TiDB を導入して嬉しかったこと
- いつでも性能調整できる安心感
- スケールイン・アウトがサービス影響なしで行える
- 気軽に増やせて、気軽に減らせる
- TTL の利用
- どうしても消え残るレコードが存在
- TTL で勝手に消えてくれて助かる
- 水平シャーディングは完全に任せきり
- 任せきりでもうまく分散してくれた
- レコード０状態から急激なレコード増加がある場合は注意おかも。。。
- 削除が多い場合も注意
- いつでも性能調整できる安心感
- 救難信号！
- まとめ
- TiDB は大規模でダウンタイムなしなプロダクトの DB では有力候補
AI駆動開発時代におけるTiDB Cloud活用術
クラスメソッド株式会社 クラスメソッドゲームソリューション部 ソリューションアーキテクト 頴川 武生 氏
ざっくりまとめ
- 生成AIがコードを書く時代では、AIが理解しやすく扱いやすい「AI-Ready」なデータベースが重要
- TiDB Cloud は MySQL互換・標準SQL・HTAP構成により、AIとの親和性が高く自然言語SQL生成やベクトル検索にも対応
- クラスメソッドは Auth0 や Kong などと組み合わせて、AI駆動開発を支えるモダンなクラウドアーキテクチャを提案
- message
- 生成 AI がコードを書く時代、データベースも ”AI-Ready” であるべきだ
- 誰もがフルスタック開発者に
- アーキテクチャ設計
- 自然言語で要件定義
- 技術スタック最適化
- コード実装
- フロントエンド
- バックエンドAPI
- テストコード
- デプロイ
- CICDパイプライン
- メトリクス
- 監視
- アーキテクチャ設計
- データベースで詰まる現実
- 技術選定
- 何を選択すればいいのかわからない
- ローカル環境での起動方法
- デプロイ
- ホスティングとは別にリソースが必要
- コスト
- 起動しているだけで料金がかかる場合が多い
- 技術選定
- AI が書きやすいデータベースとは
- 学習データが豊富
- MySQL, PostgreSQL
- シンプルで予測可能な構造
- 正規化されたテーブル設計
- 明確な外部キー関係
- 一貫性のあるデータ型
- 標準的な構文に準拠
- SQL標準
- NoSQLは方言が多く、AIが生成するコードが動かない可能性
- クラウドネイティブ
- API ベースのアクセス
- TiDB Cloud は AI 駆動開発に最適
- 学習データが豊富
- MySQL 互換
- 標準的な構文
- 特殊な方言が少ない
- 予測可能な動作
- ACID,外部キー
- クラウドネイティブ
- 学習データが豊富
- AI のよくある失敗は TiDB Cloud のツールで解決
- 学習データが豊富
- AI-Ready なデータベースとは？
- AI がその能力を最大限に発揮できるように設計された、AI にとって「気が利く」データベース、とここでは定義
- 3つの要素
- 言葉で対話できる
- Chat2Query
- 自然言語で SQL を生成
- API も提供可能
- Chat2Query
- 意味を理解する
- ベクトル検索
- セマンティック検索で RAG 実装が簡単
- 一部のリージョンでは自動埋め込みにも対応
- ベクトル検索
- 常に最新の情報を持つこと
- HTAP アーキテクチャ
- OLTP と OLAP が共存
- HTAP アーキテクチャ
- 言葉で対話できる
- 3つの要素
- AI 工藤開発の完璧な相棒
- AI が書きやすい
- AI アプリに必要
- コスト
- 充実した無料枠
- 高速な開発が生む「次の課題」
- シャドウITの増殖
- 認証・認可の複雑化
- セキュリティ
- クラスメソッドと始めるモダン開発
- Auth0やKong など、モダンな SaaS を適切に組み合わせる
- AWS だけではない
- 全体最適を提案できる
- Auth0やKong など、モダンな SaaS を適切に組み合わせる
- AI がその能力を最大限に発揮できるように設計された、AI にとって「気が利く」データベース、とここでは定義
TiDBを活用したクラウドネイティブミッションクリティカルシステムの実現
TIS株式会社 サービスプラットフォーム第１部 セクションチーフ 根来 和輝 氏
ざっくりまとめ
- 日本の多くのミッションクリティカルシステムがレガシー技術に依存し、DX や最新技術導入の足枷になっている
- TIS は「Lerna」スタックを開発し、Design for Failure思想と TiDB を組み合わせて高可用・高一貫性・ゼロダウンタイム運用を実現
- TiDB のリソース制御や分散トランザクション特性を活かし、クラウドネイティブ環境でも99.9999%稼働を目指す高レジリエンスな基盤を構築
- なぜ実現する必要があるのか？
- ミッションクリティカルシステムはレガシーな技術に頼ってきた
- ビジネス機会損失に直結するため 24/365 稼働が必須
- 金額等を不整合なく更新しなければならない
- FT サーバを採用すると障害発生リスクや開発コストの観点で過去資産の利用が最適解になりやすく古いプログラミングデータや固定長データといったレガシー技術への依存が生じやすい
- レガシーシステムが日本の IT 活用の足枷になっている
- 日本企業の61％が保有するレガシーシステムが足枷になり DX が進まず産業競争力が低下の一途を辿っている
- 生成 AI などの最新テクノロジーを活用しおづらい
- 技術者の確保が難しい
- 利用技術の撤退や一方的な値上げなど
- 状況の変化に対応しずらい
- 日本企業の61％が保有するレガシーシステムが足枷になり DX が進まず産業競争力が低下の一途を辿っている
- 脱却したいが、その壁
- 99.999% の効果養成を実現する必要があるがインフラ障害が必ず発生する前提に立つ必要がある
- 分散することで通う政治向上を図る設計が必要だが、データを分散すると一貫性の維持が難しくなる
- システムの構成変更をオンデマンドで実施したいが無停止で行う必要がある
- 従来とは異なる方法論が必要
- Lerna ソフトウェアスタックを開発
- Design for Failure な設計思想
- 高いレジ離縁シートスケーラビリティ
- ゼロダウンタイムな運用
- データベースには TiDB を採用し、トランザクションの高い可用性と強い一貫性を実現
- 「高レジリエンスオプション」サービスを始めた
- Lerna をはじめとする TIS のノウハウを活用
- ミッションクリティカルなシステム開発
- Lerna をはじめとする TIS のノウハウを活用
- ミッションクリティカルシステムはレガシーな技術に頼ってきた
- どのように実現するのか？
- クラウドネイティブなシステムでは障害が必ず起きる前提に立った設計が必要
- AZ 間のネットワーク障害に備える
- TiDB は一貫性を維持する代わりに孤立した AZ のクエリを拒否する
- 重要なワークロードの即応性を保護する
- オンライン処理のワークロードが最も重要
- TiDB のリソース制御構造でオンライン処理の即応性を保護
- オンライン処理のワークロードが最も重要
- その他の検討事項
- 障害が発生してもシステム関連系の整合性を保つ
- キャパシティの変更を無停止で実施する
- バージョンアップを無停止で実行する
- …
TiDB導入、本当に大丈夫？〜不安を解消する開発・運用サポートの舞台裏〜
アイレット株式会社 カスタマー支援事業部 事業部長 本田 卓 氏
ざっくりまとめ
- TiDB は「MySQL のすごい版」という期待に対し、PingCap の手厚い技術支援が不安を払拭してくれる
- Slack 上での即時対応や負荷試験・構築・スケール運用まで具体的かつ実践的なサポートを提供
- 初めての TiDB 導入でも「わからないから教えて」で安心して進められる環境が整っている
- TiDB に抱く夢と現実と希望
- 開発現場が抱く夢
- TiDB はMySQLのすごい版
- めんどくさいシャーディングやスケーリングを全てやってくれる
- 現実
- TiDB の利用経験が少ないけど使いこなせるか
- MySQL 互換だからとすぐに飛びついてしまっていいか？
- 問題が起きた時にインターネット上にあるだけで解決できるか
- 希望
- 開発現場が抱く夢
- PingCap はどんなサポートをしてくれるか？
- Slack に Join してくれその場で質疑応答に対応してくれる
- テンプレ返答が返ってくることはない
- 負荷試験やレビュー資料なども確認、協力してくれる
- TiDB 利用での問題などを定期的に確認してくれる
- 実際のサポート事例
- 主キーに設定する ID の生成方法について
- Snowflake で大丈夫、と明確に返答をもらえる
- 別のアルゴリズム所感ももらえる
- 開発環境の構築はどう使い分けたらいいか？
- 細かくわかりやすく教えてくれる
- 負荷試験をサポートしてくれると聞いたが。。。
- PingCap 側でも時間を共有すれば伴走してくれる
- 事前に対応したほうがいいことなどのアドバイスももらえる
- プライベート提供なども先行提供してくれる
- スケールイン・アウトにかかる時間について
- 標準的な時間を明確に示してくれる
- 曖昧な返答はない
- ローカル環境の構築について (TiDB Software 版の利用)
- OS レイヤーのサポートもしてくれる
- 有償版使えば解決などに促されない
- 緊急メンテナンスウィンドウの連絡
- 直接連絡をくれる
- 影響範囲を明示してくれる
- 主キーに設定する ID の生成方法について
- まとめ
- チャットベースなので質問をしやすく返答も早い
- リリースまでに生じる疑問や不安の解消にとことん付き合ってくれる
- 返答と共にベストプラクティスのアドバイスがついてくることが多い
- 初 TiDB で自信がなくても大丈夫
- わからないから教えて、で大丈夫
- かなり親身に相談に乗ってくれる
- わからないから教えて、で大丈夫
リリース時のアクセス急増をいかにしてノーメンテで乗り越えたか 〜『Shadowverse: Worlds Beyond』におけるTiDB採用のゲームサーバー設計〜
株式会社Cygames サーバーサイド エンジニア 青木 淳 氏
ざっくりまとめ
- Shadowverse: Worlds Beyond は TiDB を採用し、AWS ECS 環境でシームレスなスケールアウト／アップを実現
- リリース直後のアクセス急増時もノーメンテで対応し、最大 50万 QPS を安定処理
- TiDB の分散構造と MySQL 互換性を活かしつつ、エンジニア側もホットスポット対策やインデックス設計を最適化して最高のゲーム体験を支えた
-
Shadowverse WB の構成について
- Cloud
- AWS ECS
- Rest API
- PHP
- リアルタイム通信
- Magic Onion (C#)
- データベース
- TiDB
- Cloud
- システム構成図
- API サーバ
- 外部からアクセス可能なサーバ
- 内部通信専用サーバ
- ALB を経由して通信
- リアルタイム通信
- コンテンツごとにクラスタを分けて適用
- クライアントと直接通信
- TiDB Cloud
- ゲームサーバと VPC ペアリング
- API サーバ
- 従来の RDBMS の問題点
- 負荷増加のジレンマ
- システムスケールが必要
- メンテナンス時間が必要
- ユーザーに迷惑をかける
- 複雑化の悪循環
- 単一 DB では限界
- 従来の RDBMS のスケールアウト
- 水平分割
- 垂直分割
- 計画通りにいかない
- 想定以上のユーザーが殺到
- プロダクトとしては成功したが、システムは悲鳴をあげてしまう
- メンテナンスが必要でサービスが一定期間停止してしまう
- 機会損失が連鎖する
- 負荷増加のジレンマ
- シームレスなスケーリングで解決
- TiDB の選択
- データの完全性を担保できる
- TiDB は分散型でありながら完全性を担保
- Cygames では MySQL を使用している
- MySQL 互換性が高くアプリケーション開発者としては扱いやすい
- サーバリソースを効率的に活用できる
- バランスよく利用可能
- Node はステートレスなのでコスト削減にもできる
- Cygames の Engineer Blog に出ている
- データの完全性を担保できる
- まとめ
- 従来の問題点
- メンテナンスが必要
- システムが複雑化する
- 課題解決のため
- シームレスなスケーリングが必要
- 従来の問題点
- TiDB の選択
- TiDB を使うために行ったこと
- 考えを変える必要性
- MySQL 互換といえども従来の意識で実装するのはNG
- ホットスポット
- 特定のノードに負荷集中する危険性
- インデックス設計
- 分散キーを意識しないと性能劣化
- ホットスポット
- MySQL 互換といえども従来の意識で実装するのはNG
- 対応例
- MySQL ではインデックスを使う前に Primary Key を検討する
- TiDB では時系列にソートできるランダム文字列である ULID を使う
- TRUNSACTION 分離レベル
- デフォルトは REPEATABLE READ
- Shadowverse では READ-COMMITTED に変更
- 事前準備
- 負荷試験
- 障害試験
- 耐久試験
- スケーラビリティ試験
- TiKV はいずれも問題なし
- 状況に応じてスケール戦略を選択する方針に
- TiDB はスケールアウト以外の操作でエラーが発生
- コネクションが切断される
- 確実性をとってサービス稼働中はスケールアウトのみにする方針にした
- TiKV はいずれも問題なし
- まとめ
- TiDB に合わせてエンジニア思考もアップデート
- ホットスポット、インデックス設計、トランザクションん分離レベル
- 準備
- 負荷試験、障害試験、耐久試験、スケーラビリティ試験
- TiDB に合わせてエンジニア思考もアップデート
- 考えを変える必要性
- リリース
- 不確実性に対して
- 安定したサービス提供が必要
- サーバリソースをうまく使った運用方法を追求
- ２つの戦略
- スケールアウト
- サーバ台数を増やす
- スケールアップ
- サーバのスペックを上げる
- スケールアウトを基本としつつ、スケールアップも手段に入れ、両輪の戦略でリリースを迎える
- サーバのスペックを上げる
- スケールアウト
- リリース直後
- 徐々に流入が始まる
- リリース時間に合わせて右肩上がり、期待以上の反響だった
- システムは想定以上の負荷に直面
- API サーバの CPU 使用率が8割近くなったのでシステムスケールを判断
- CPU 使用率が急激に増加したのでスケールアウトで素早く対応
- グラフの上がり方から 1.5倍の台数で落ち着くと予想
- TiDB の CPU 使用率が 8割近くなったのでシステムスケールを判断
- CPU 使用率が急激に増加したのでスケールアウトで素早く対応
- 1.2倍の台数にし、少しずつ様子を見ることにした
- API サーバの CPU 使用率が8割近くなったのでシステムスケールを判断
- ノーメンテでシステムスケールを実行
- 安定化
- 負荷は緩やかな上昇
- 安定化
- PingCap との相談の上、TiKV のスケールアップを検討
- ピーク時の使用率が 60% まで上がっていた
- 夜の更なる負荷増加が予想
- 夜のピークタイムは昼以上のアクセスが発生
- 夜間バックアップ処理による追加負荷
- TiKV のスケールアウトは以下の理由による除外
- データリバランスによって CPU リソース消費
- 処理完了時間が不明
- 1日のピークタイム前のため安全性を重視
- TiKV のスケールアップを念の為再試験
- ダウンタイム０でエラーなくスケールアップが可能か確認
- エラーなくスケール処理が完了することを確認
- 夜間のスケールアップを実行
- ダウンタイム０でエラーなくスケールアップが可能か確認
- 20:30 ~ スケールアップ開始
- 20:40頃から TiKV の各ノードが 1つずつローリングアップデートされていく
- QPS は 40万程度出ていたがノーメンテで実施
- ピークタイムは 50万 QPS 、システムはすでに増強していたため危険域には届かなかった
- 翌日以降も上がったが問題になることはなかった
- 20:40頃から TiKV の各ノードが 1つずつローリングアップデートされていく
- まとめ
- 期待以上の反響でリリース告知時間からアクセスが急増
- ノーメンテのシステムスケールで最高のゲーム体験を提供
- API サーバと TiDB のスケールアウトでノーメンテ対応
- 夜のピークに向けた TiKV のスケールアップ
- ノーメンテのシステムスケールで最高のゲーム体験を提供
- 期待以上の反響でリリース告知時間からアクセスが急増
- 徐々に流入が始まる
- 運用上の課題
- オンライン DDL
- lock wait timeout 頻発
- 統計情報の履歴を保存する機能の問題
- analyze table の旅に統計情報を自動記録する
- 各テーブルは自動で analyze する
- Shadowverse ではこれを OFF に設定
- tidb_enable_historical_status
- オンライン DDL
- 不確実性に対して
- まとめ
- 最高のゲーム体験のため ECS TiDB で柔軟なシステムを実現
- TiDB に合わせてエンジニアの思考もアップデート
- リリースもノーメンテで乗り越えた
ecforceサービス運用者が語るTiDB Cloud本番運用1年半のリアル
株式会社SUPER STUDIO SREグループ 執行役員 田幸 久志 氏
ざっくりまとめ
- RDS/Aurora で350超のDBを運用していた複雑な環境をTiDB Cloudに集約し、運用コストを最大40%削減見込み
- 移行作業では DM や binlog 設定、AUTO_ID_CACHE の扱いなど細かな課題を地道に解消し、現在は安定運用中
- パフォーマンス調整・スケーリング制約・再起動運用など課題は残るが、PingCapの支援と継続的な改善でクラウドネイティブDB運用が定着
- TiDB 以降の背景と現状
- 350超の DB クラスタがそんｚ内することで DB 管理が複雑化
- 物理コスト・運用コストの増大
- サービスを停止するメンテナンス作業
- 他サービスと連携するアーキテクチャを考える制約
- 検討・導入経緯
- 2023/07: コミュニティ版評価開始
- 2024/01: TiDB Cloud 評価開始
- 2024/05: 本番導入開始
- 現在全体の 70% くらい移行完了
- コスト効果
- 移行前の水準で RDS を継続運用した想定と比べ 15% 程度削減されている
- 最終的に 40% くらいの削減を見込んでいる
- 350超の DB クラスタがそんｚ内することで DB 管理が複雑化
- 移行作業の詳細
- 移行概要
- 350超の DB クラスタ (RDS, Aurora)
- ショップごとに Database が存在
- Database を TiDB に DM でいこうし、アプリケーションの参照先を切り替える
- 移行手順
- 移行元の DB の binlog を有効にする
- 移行元の DB と TiDB クラスタを VPC ペアリングで接続する
- 移行元の DB からスキーマを dump
- スキーマのデータを一部加工し TiDB にインポート
- AUTO_ID_CACHE の追加
- 注意点
- 1ずつ増えることを保証していない
- 特に再起動などで亡くなった時に値が数千番規模で飛ぶ
- 単調増加することを保証するくらいの感覚で使用する
- 注意点
- AUTO_INCREMENT の値の削除
- 移行し始めてから判明した問題に対して対応
- スキーマを dump して TiDB にインポートし、DM で同期するまでの間に移行元 DB のデータが増えるとデータが追加できない問題が発生する
- 移行し始めてから判明した問題に対して対応
- AUTO_ID_CACHE の追加
- 切り戻し
- TiDB から提案された手順に従って実施
- 移行時に発生した問題の対応
- DM は RCU が設定できるが、RCU の数字を挙げると移行元の負荷が上がるので、移行元の DB スペックに合わせて RCU の数字を調整する
- 移行元 DB は binlog を有効にする必要がある、binlog を有効にした後、移行が完了するまでに大量アクセスがあると、RDS のディスク使用量が急に圧迫されることがあるので注意する
- DM を途中で止めた時、DM の中継サーバと移行元 DM の間でプロセスが残ってしまうことがあるので、DM を止めた場合は DM のプロセスが残っていないかどうか確認する
- DM で同期し、TiDB に切り替えたショップでレスポンスが悪く、analyze table を実行して解消するケースが時々発生
- 移行概要
- 運用の変化と対応
- 基本的に問題なく運用できている
- アプリケーションの機能はほとんど手を加えないで動作している
- RDS と比べて運用の手間が増えていることはない
- パフォーマンス問題への対応
- RDS と比べてクエリのレスポンスが遅くなる (ms 単位)
- 完了までに多くのクエリを必要とする処理が遅くなる
- ページのレスポンスが遅くなる
- ジョブの実行時間が長くなる
- 地道にロジックを修正することで対応
- N+1 のロジックの修正
- 繰り返し呼ばれるクエリを redis に逃す
- 完了までに多くのクエリを必要とする処理が遅くなる
- 単純に遅くなる以外の障害例
- ページのレスポンスが長くなった結果 API のレスポンスが遅くなり ELB のタイムアウトに引っかかり 504 エラーに
- ジョブの終了が遅くなることにより、終わる時間を想定して設定していた他の処理に影響
- redis にクエリを逃したことで redis のレスポンスが悪くなりアプリケーション全体のレスポンスが悪くなる
- クエリあたりのメモリ使用量の上限
- 今まで引っ掛からなかった一つのクエリを処理するためのメモリ使用量の上限が設定されている
- 複雑なクエリを生成するロジックで発生
- TiDB の設定値で調整することも可能
- データマイグレーション
- DDL に時間がかかる (最低 0.5s くらいかかる)
- 数百ショップ分のリリースが同時に実行されるとデータのマイグレーションの worker が詰まり、リリース時間が数時間伸びる
- TiDB 設定で調整できるか検証中
- その他
- 今まで ID 順に帰ってきたクエリ結果がバラバラになり、並べ替えをするよう修正
- 特定の処理で deadlock が起こりやすくなり、TiDB 側の設定を変更
- サブクエリで ON句がサポートされておらず、クエリを修正
- TiDB のデータサイズ時制限の問題があり、TiDB の設定を調整
- RDS と比べてクエリのレスポンスが遅くなる (ms 単位)
- TiDB クラスタのスケーリング
- TiDB 移行済みのショップについては細かな調整をする必要がなくなった
- 大きなキャンペーンを計画されている場合のみ DB 側を対応
- サーバのスケーリング台数を大きく設定できるようになった
- TiDB node をスケールする基準はわかりやすいが、TiKV node をスケールする基準が掴めていない
- TiDB クラスタのスケーリング制約
- TiDB node の台数を変更するときはあまり制約なし
- TiKV node の台数を変更するときは 3台単位
- コストインパクトが大きい
- スケールが完了するのに時間がかかる (3→9台で 36時間)
- スケール中に変更ができない
- TiDB クラスタの node の再起動
- データの性質の問題か、メモリの使用率があがりがち
- メモリの使用率が高い状態が続くとクエリがキャンセルされることが発生するため、時々再起動をする運用をしている
- TiDB Cloud コンソールには再起動をするオプションがないのでスケールアップダウンを実施して対応
- node を個別指定して再起動できないので 全node で再起動
- テーブル数の削減
- ショップごとに Database があり、それぞれ数百程度の Table がある
- 移行元の DB で partition を作成していると TiDB 移行後、それが table として認識される
- アラート設計
- TiDB Cloud で設定できるアラートは memory, CPU, ストレージのみ
- メトリクスで見れる指標でアラートを仕込みたい
- NewRelic の活用
- TiDB のログ
- クエリの実行ログは S3 にエクスポートできる
- RDS で保存できた生ログが保存できない
- 長期保存されていない
- 監査関連
- 基本的には問題ない運用ができている
- ユーザーの権限設定は大まかなグループでのみ設定可能
- ユーザー管理に該当する API がない
- コスト関連
- RDS コスト以外に VPC Endpoint の料金が追加で発生している
- 評価環境を作るのに追加でかかる
- リストアがクラスタ単位
- PingCap のサポート
- 特に問題なく対応
- 問い合わせ窓口の他に担当エンジニアがいる
- 深夜対応にも対応してもらえている
- TiDB クラスタのスケーリング制約
- TiDB 移行済みのショップについては細かな調整をする必要がなくなった
- 基本的に問題なく運用できている
- 今後の運用課題
- パフォーマンス改善
- TiDB へ移行するしないに関わらず、サービスのパフォーマンスの改善
- hotspot の改善
- アクセスが多い場合はスケーリングで解消できる
- メモリ使用率の最適化
- 再起動運用を解消したい
- パフォーマンス改善
スケールと信頼性を求めて：メルカリ流TiDB移行とベストプラクティス
株式会社メルカリ Platform 小山 智之 氏
株式会社メルカリ Platform 前田 敦史 氏
ざっくりまとめ
- 40TB超のオンプレMySQLをTiDB Cloudへ移行、ProxySQL＋DM/Dumpling＋TiCDC＋独自クエリリプレイで低ダウンタイムかつ互換性・スケール・運用性を確保
- Graceful maintenanceを徹底、connection poolingや監視分界を整理しつつPingCapと協働でシャットダウン挙動を改善して全クラスタに展開
- Resource ControlやDatadog連携を実装し、RU配分・優先度制御・SQL Bindingで障害回避とコスト按分を実現、可観測性も強化
- プロジェクトの概要・移行の流れ
- DB サーバのデータ量
- 4年間で倍増、40TB+
- アプリケーションは Google Cloud、DB サーバはデータセンターに MySQL がインストールされている
- DB サーバは 50台以上
- データサイズは 40TB+
- 課題
- Scalability
- ハードウェアのキャパシティ
- Elasticity
- 新たに DB サーバのセットアップに 1.5日
- Operation
- DDL 適用に数時間から数日
- Scalability
- 解決策として TiDB Cloud
- 移行先を Public Cloud に決定
- PoC
- 観点
- Scalability
- Elasticity
- Operation
- Compatibility
- プロジェクト概要
- 移行対象
- オンプレミスの MySQLサーバ
- 期間は 2024-10 ~ 2025-10
- 影響範囲
- メルカリとメルペイの一部
- 移行対象
- 移行の流れ
- 事前準備
- TiDB は分散データベースであるためクエリレーテンシの増加が懸念された
- アプリケーションの影響を評価
- ProxySQL で再現
- 評価観点
- API レイテンシ
- エラー
- モバイルアプリのレスポンス体験
- マシンの用意
- 2台のレプリカを作成
- Relay
- MySQL から TiDB への動機用のレプリカ
- Fallback
- Relay
- 2台のレプリカを作成
- データの同期
- ダンプデータを Dumpling で同期
- GTID をメモしておく
- ダンプデータを Dumpling で同期
- 差分データの同期
- メモしておいた GTID を使って差分同期を実施
- Fallback の付け替えとレプリケーション停止
- Fallback 用の MySQL へのデータ同期 (TiCDC)
- Relay から Fallback へのレプリケーションを停止
- TiCDC を作成
- TiCDC で TiDB から Fallback へデータ同期
- sync-diff-inspector の実行
- Relay と Fallback のデータを比較して差分チェック
- Master から Relay へのレプリケーションを再開
- クエリリプレイ
- TiDB のクエリ負荷やリソースの使用量を確認するために独自にクエリのリプレイツールを開発
- eBPF ベースのライブラリを使った軽量なパケット処理を実現
- SELECT クエリのみ再送
- 切り替え
- 透過的に TiDB に切り替えるために ProxySQL を設置
- READ のトラフィックを TiDB に切り替え
- ダウンタイム
- ダウンタイムを最小限にするために、スクリプトを作成し以降の手順を自動化
- Master を読み取り専用モードに切り替え
- DM がオンメモリに持っているデータをディスクに書かせるために空の DDL を発行
- 同期確認をするために GTID を比較
- TiCDC の Checkpoint TS の値と READ ONLY 後の Checkpoint を発行した直後のタイムスタンプを比較
- ダウンタイムを最小限にするために、スクリプトを作成し以降の手順を自動化
- Proxy SQL の宛先を MySQL から TiDB に切り替えることで Master を切り替え
- 元の MySQL と GTID が異なるためリセットを行う
- 元の MySQL にレプリケーションを向ける
- 事前準備
- まとめ
- 40TB+ のオンプレミスの DB が存在
- スケールの限界、セットアップ所要時間、DDL 時間適用の時間
- 解決策として TiDB Cloud の採用
- 書き込みのスケール、柔軟な台数の増減、オンラインDDL、MySQL との互換性
- 移行
- レイテンシ増加の影響評価
- クエリリプレイ評価
- ProxySQL を使った透過的な切り替え
- 整合性のチェック
- 40TB+ のオンプレミスの DB が存在
- DB サーバのデータ量
- graceful maintenance への取り組み
- 接続タイムアウトの影響
- シナリオの仮定
- 通常の処理が 3ms
- 接続タイムアウト 3s
- サーバ5台、うち1台がタイムアウト
- この状態だと通常の1000倍の時間がかかる
- シナリオの仮定
- 既存接続
- 発生事象
- 長いトランザクションが中断される
- 対応
- 既知の処理時間ｗの酒メンテナンスを行う
- 長くない接続についてはある程度緩める
- メンテナンス時間とのトレードオフ
- 発生事象
- 新規接続
- 発生事象
- connection refused
- connection timed out
- 特にタイムアウトは大きな影響が発生する
- ProxySQL connection pooling
- 方針
- 新規接続の回数を減らす
- ある程度 backend で非同期咲かされることで解消される部分もある
- スケールアウトが遅くなるなどのデメリットもある
- 方針
- ProxySQL connection pooling
- 発生事象
- ProxySQL の恩恵
- 都度接続のアプリケーションに対しては大きな効果を発揮する
- connection pooling によりエラーが軽減
- 都度接続のアプリケーションに対しては大きな効果を発揮する
- Managed Service で Proxy SQL を利用する際の注意
- ProxySQL と監視責任分界点
- デフォルトの設定では異常があれば切り離す
- エンドポイントを使用している時に注意が必要
- バックエンドの切り離し、隔離に配慮が必要
- ProxySQL と監視責任分界点
- Graceful Shutdown 事態の改善
- 直接修正はできないが、改善に向けて取りうる手を取る
- 発生している問題の仮説と改善を整理して提案
- PingCap 社とメルカリの協働により問題が解消
- 5月にリリースされ、全Clusterに適用
- 発生している問題の仮説と改善を整理して提案
- 直接修正はできないが、改善に向けて取りうる手を取る
- まとめ
- PingCap と協力しながら graceful maintenance 化を実現
- graceful でないものには配慮が必要
- 接続タイムアウトの影響
- Resource Control (RC)
- MySQL では 8.0 〜 Resource Group が利用可能
- TiDB の Resource Control
- TiDB, TiKV で個別の制御が必要
- RU の制御
- ランナウェイクエリの検出
- セッション管理
- SQL Binding の活用
- TiDB, TiKV で個別の制御が必要
- RC は何に活用できるか
- Monitoring 指標
- 優先度制御・リソース割り当てによる全体障害の回避
- クエリの制御によるリソース利用料の最適化
- コスト按分
- RC の導入方法
- ユーザーレベルの設定、ヒント句の設定、SPM(specific query patterns) による設定など用途により多様な設定が可能
- 導入例
- リソースを利用しているユーザーを特定
- TiKV Top5 SQL などから負荷傾向を解析
- 負荷を発生させているユーザーを特定
- 影響を与えているクエリを特定
- SPM で対処可能な場合はアプリケーションｗの変えずに SPM で一時的にリソースグループを付与
- リソースグループを割り当てると様々なメトリックが観測できる
- TiKV のリクエスト数
- TiKV CPU 利用時間
- 読み取りバイト数
- 書き込みバイト数
- リソースグループを割り当てると様々なメトリックが観測できる
- SPM で対処可能な場合はアプリケーションｗの変えずに SPM で一時的にリソースグループを付与
- 実際に制限を入れる
- 実際の観測
- statements_summary の観測
- slow query の観測
- その他の導入例
- CDC ユーザなどの優先度を下げる
- 危険なクエリを KILL
- 処理量の多いクエリの優先度を下げる
- 豊富な QUERY LIMIT パラメータがあり、様々な条件で活用できる
- 実際の観測
- リソースを利用しているユーザーを特定
- まとめ
- RC はすごくおすすめ
- RC には柔軟な設定方法がある
- 導入ステップや監視項目の例について紹介
- Datadog APM の活用
- Database への AI 活用
- APM に保存されるベースライン情報の蓄積、活用は最も可能性のあるものの一つ
- datadog はメルカリにはフィットしていた
- API の充実
- MCP 対応
- すでに多くのサービスで活用されていた
- datadog monitoring は素晴らしい
- 現状 TiDB では利用できない
- 似た機能はあるが Datadog の方が優れている
- 実装することにした
- 現状の機能がどのように実装されているか
- MySQL と TiDB の差分を理解
- どうしたらいいかを考えて実際
- MySQL と TiDB の統計情報の違い
- MySQL の Performance Schema は利用できない
- クラスタ、ノードレベルで統計が存在する
- などなど統計情報は難しい
- 丁寧に紐解いて行った結果 Datadog で見ることができるようになった
- Datadog のバックエンドに手を加えずに使える範囲でやれることを実施
- できるようになった
- 時間ごとのクエリ数の数、所要時間の統計
- Explain Plan の確認
- datadog 標準機能との連携
- できていないこと
- 待機イベントの解析
- TiDB 固有の統計情報の蓄積、活用
- Datadog に提出したPR 自体は Close されることとなった
- メルカリでは利用を継続することを許可してもらった
- できるようになった
- まとめ
- 既存の Datadog の backend を回収しなくていい範囲で動作するものを開発
- 現在の取り組み
- コスト効率の改善
- Auto Scaling の実装
- datadog database monitoring for TiDB の活用
- Database への AI 活用
Views: 0
