TiDB User Day 2023 に参加なぅ

TiDB User Day 2023

• ハッシュタグ #TiUD2023
• いつもの雑メモ
  • なんとなく全体的に大規模 Database には向いてそうな印象
  • 逆に小規模の Database だと難しい？
    • はてなさんのような使い方は一つ未来があるかもしれない
      • と思いつつ、共有 Database 状態になった時にガバナンスコントロールが求められるのがあれかもな
      • TiDB には Audit Log という概念があるのか、気になる
        • さらにそれを DB という単位でホゲホゲできたらいいんだけどな

ご挨拶

• アンケートに答えると Tシャツや2万円相当の資格試験の無料パスが当たる可能性が高くなるみたい

  • アンケートは次のセッションの開始前に行うといいとのこと
  • 移動するとオンラインに映ってしまうみたいなので移動は避ける

• 本日のイベント

  • 450 名以上のオンライン ＋ オフライン参加者
    • 会場には 120人以上
  • ｄb tech showcase 2022 で注目度1位
  • 事例紹介 18社
  • 採用企業 50社以上
  • 体制 26名
    • この人数想像よりも少なかったので改めてすごいなと思う

• 日本に根ざした活動

  • 日本語ドキュメントの整備
  • 日本語公式トレーニングの提供
  • 日本語公式認定プログラム
  • オンサイトワークショップの開催
    • 日本のどこに魅力を感じたのか聞いてみたいな
  • 魚の鯛をモチーフにした PingCAP Japan 公式キャラ ピンちゃん
  • Software Design に TiDB 特集の予定

TiDBとMySQLと未来

• 登壇者

  • PingCAP Inc. 共同創業者 兼 CTO Ed Huang
  • PingCAP Inc.　Senior Architect Sunny Bains

• Ed Huang さん

  • TiDB の沿革
    • ８年前から取り組んでいた
      • Ed Huang の前職は大手インターネット企業
      • 事業自体が急成長を遂げていた中、その成長に追いつかないような RDBMS に課題を感じた
      • SLA としてダウンタイムが許されなかった
        • 真夜中に作業が必要になった
      • システム障害や Crash 時の対応にも苦しんだ
      • ビジネスアプリケーションの対応もしていたが、SQL を書くことの制約によって SWE からの苦情を受けていた
        • JOIN やシャードを跨いだクエリなど
        • ビジネスの成長をゆっくりにしろと
    • その中で新たな DB を構築した
      • Open Source
        • Scalable
        • High Available
        • Storong Consistency & Cross-Row Transaction
        • 100% OLTP + Ad-Hoc OLAP
        • Cloud-Native
        • Easy to use and with Full-featured SQL
          • MySQL Conpatible
    • A Scalable OLTP database
      • はじめは小さいところからスタート
        • ２年間経って世の中に出す準備ができた
        • 2017 年にリリース
          • MySQL 互換性
    • From OLTP to HTAP
      • OLTP Workload
        • シンプルなクエリ
          • INSERT / UPDATE / DELETE / ...
      • 複雑なクエリを使用するユーザーに対応
        • 当時は OLAP には詳しくなかったらしい
          • JOIN / GROUP BY / ...
      • 2020 TiDB + TiFlash
        • TiFlash
          • OLAP 部分を独立させた Node を構築
          • OLAP と OLTP を共存できた
    • kept the evolution momentum on Cloud
      • Public Cloud 上で使いたいというリクエストが増えた
        • アプリケーション開発もクラウドに移行している
        • エンタープライズ企業では運用管理コストは無視できなくなっている
        • 更にコンプライアンスとセキュリティは無視できない
      • Multi-Cloud も同時に増えている
        • さらに Managed Database であるとよい
        • 企業がビジネスに集中できる環境
      • TiDB Cloud
        • 2020 年から始めた
        • 今後も引き続き投資を続ける
  • Next big thing for TiDB Cloud - Serverless
    • ChatGPT などによって Database の業界も大きく変わっていくだろうと思っている
    • どのような DB が求められているのか、生き残れるのか
      • Elastic Scalability
        • PB Level
      • Simple and intuitive
        • User Friendly
      • Consokidated
        • All in one solution
      • Always on and Always Fresh
        • Cloud-native
      • Open eco-system
        • Support OpenAPI and open source ecosystem
      • Low Cost
        • Pay-as-you-go, support scale to zero
    • Serverless TiDB
      • Launch without concern for deployment details
        • No Configurations
      • Elastic Scale as the workload scales
      • Pay-as-you-go at a finer granularity
      • Better and deeper integration with modern application development
    • Serveless Cloud の Technology
      • Compute-storage totally separation
      • Multi-tenancy by nature
      • Second-level launch time
      • Pay-as-you-go
    • 昨日 GA になった
      • Preview　期間の 6ヶ月で　Active 1０，０００ Cluster を超えた
  • TiDB Serverless の成功事例
    • Github からの Analyze　Tool OSSInsight Story
      • Huge Data Volume
        • ~ 12TB, 6 Billion rows of data
      • Mixed Workload
        • 分析クエリも対応
      • Short Deadline
        • １週間でできた
        • 当初のコストから 70% 削減
      • 70% のトラフィックが増えた
        • ピークになった時にスケールアウト、終わったらスケールインを実現
  • TiDB　の提供パターン
    • TiDB Self-Hosted
    • TiDB Cloud Dedicated
    • TiDB Cloud Serverless
  • Vision
    • TiDB Self-hosted　＋ HTAP + Serveless = Frictionless Developer Experience

• Sunny Bains さん

  • PingCap に入社して 1年半くらい
    • 以前は MySQL/InnoDB のリーダーとして Oracle で勤務していた
  • TiDB Unique Value
    • Easy to setup and start
    • MySQL Compatible
      • 互換性じゃなくて進んでいるところとかあるのかな？
    • Scalable by Design
    • Versatile
    • Reliable
    • Open Source
  • Partitioned Raft KV
    • 社内では Multi Rocks と呼ばれている
    • Reference　Archtecture
      • TiKV Node にある Region が最も重要なポイント
        • Region とは Logical な Unit として使用している
        • Region　をスケールアップやスケールアウトとして使用
        • 物理的には明確な境界線はない
    • Problems with Single-RocksDB
      • Write amplification
      • Latency Jitter
      • Lacks I/O isolation
      • Write throughput is limited
    • Multi-Rocks になるとこの部分が解消されるらしい
      • ロジカルと物理の分離を統合することによって解決
      • トラフィックが大きくなればなるほど Region が小さくなる
        • 逆に Cold Data では大きくい
      • heatbeat cost が 99% 削減
      • QoS Per region
      • 変更の適用に関するボトルネックの削除
        • 複数の Rocks で分散
        • 細かく分散して効果を得ることができた
        • 大きなファイルがあった場合に S3 に移すとかも可能
          • 物理的な分離も可能
    • メリデメ
      • 小さいデータだとあんまり恩恵を受けられない？
  • Resource Control
    • QoS を提供するには重要なポイント
      • ユーザーとしては Cluster を多く持ちたくはないらしい
    • 複数のアプリケーション、データベースがある時にコスト面でも大変
      • Database を跨いだ Join とか
    • データへのアクセスによって干渉が起こってしまう可能性がある
      • 予想外にクエリが多く発行されてしまった場合でも制約をかけてコントロールすることができる
        • この辺のコントロールって一つづつマニュアルですると結構大変そう
        • DB 管理の観点だとやりたくないかも。。
        • いい感じにやってくれないかな。。。ｗ
      • User Level, Session　Level, Statement Level でマッピングできる
  • Online DDL
    • Meta Data Lock
      • MySQL は Single Instance/Writer Model
        • DDL の変更を反映する時に Metadata Lock が発生する
        • 負荷の高い状態だと DML に問題が起こる可能性がある
      • Replication の問題は深刻
        • Replica Lag が発生してしまう
        • このラグが問題になる
    • 分散型の場合それぞれの Node が独立して実行できる
      • エンドユーザーに対しては一貫性を保証しつつ非同期のアップデートを提供できる
    • 全てのスキーマに対してバージョンを作る
      • 各バージョンは前のバージョンとも基本的には互換性がある
      • Public になったら全てが同じスキーマになる
      • バージョニングをすることによって Index を最初から最後まで構築できる
    • Aurora や Cockroach と比べても大きな改善をしている

[事例セッション] TiDBによる大規模ログデータ管理の挑戦！シャーディングなしで大量インサートをさばくには？

• 登壇者

  • LINE株式会社 ITSC データベース室 MySQL 1チーム ソフトウェアエンジニア 大塚 知亮　氏
    • みんな大好き @tom__bo さん
      • さっき会った時にハイタッチできたので個人的に今日は満足ｗ

• MySQLチーム概要

  • Line の MySQL の運用と管理
    • 主に国内向けサービス
    • 基本的にオンプレ運用 (VM/PM)
  • 主な仕事
    • スキーマ変更
    • トラブルシューティング
    • 設計相談
    • 運用自動化
    • プラットフォーム改善のための開発
    • インスタンス数 ６５００＋
      • 毎年１０００インスタンスずつ増えているような状態

• MySQL 運用における課題

  • スケーラビリティ
    • ディスクサイズ上限 ３TB (社内VMの制限)
    • Single Primary 構成による CPU 負荷上限
    • Write 量増加によるレプリケーション遅延
  • シャーディングによる運用コスト増
    • 垂直分割 5+
    • 水平分割 40+
      • めっちゃ大変そう・・・
  • 社内 HA 構成ツールのマルチリージョン課題
    • この量をマルチリージョン対応？！
  • MySQL のシャーディングソリューション
    • Vitess
    • Sharding Shere
    • Percona とか MariaDB とか
      • こっちの運用の方が大変だからやめてた
      • ここで目をつけたのが TiDB

• TiDB初期導入検証

  • 基本的なアーキテクチャ
    • TiDB Servers
      • クライアントからリクエストを受ける
      • 結果を返す
    • TiKB Cluster
      • データを 96KB 毎に区切っている
      • データそのものが入っている
    • PD Cluster
      • Heartbeat とか
      • TiKV のどのリージョンが Readerなのかとかコントロール
  • コンポーネント調査
    • TiUP
      • デプロイ管理ツール
    • TiDB Binlog
    • TiCDC
    • Backup & Restore
    • dumpling
    • TiDB Data Migration
      • ...
        • OLAP 系は調査から外した
  • MySQL との違い
    • ないもの
      • ストアど
      • トリガー
      • UDF
      • FULLTEXT index
      • charaset
        • collation は ３種類のみ
    • Auto Increment の値の払い出しが違う
      • いくつかのレンジに区切ってその中で払い出す
      • 同じにすることも可能だけどパフォーマンスが悪くなる
    • DDL
      • オンラインで実行される
      • 並行する DML はエラー
        • ６．３以降メタデータロックあり
  • 動作検証
    • デプロイ、手動での動作検証
    • Sysbench によるベンチマーク
    • 各ツールの動作検証
    • Grafana の画像
    • Dashboard のヒートマップなど
      • メトリクスは TiUP　を使うと Grafana とか一瞬で構築可能
      • PD にも Dashboard が内包されている
        • クエリの統計情報や実行時間の可視化までしてくれる
        • MySQL だと pt-query-digest とか使ってやっているが。。
          • めっちゃ便利そう
  • 初期調査所管
    • 速い！
      • 体感で rows_examined が多いところは速度を感じられる
      • latency は数十 ms ~ 数百 ms は増える感じ
    • エコシステムの充実度
      • 監視、マイグレーション、リカバリなど充実している
      • 周辺ツールの開発も活発
    • MySQL からの移行サポートが強い
      • DM(Data Migration)、sync-diff-inspector,dumpling など
      • DM の gh-ost / pt-osc 対応など
        • OSS にもバッチリ対応してくれたらしい
    • 運用に必要な情報がちゃんと入っている！！！

• 大規模案件での TiDB検証

  • システム要件
    • 複数のシステムから kafka にログ集約、分析用に RDB に格納
    • 8日間で 11TB　の Insert (MySQL 換算)
    • どうにか MySQL で管理したい
      • DR にも対応しダブルライトする
  • パフォーマンス要件
    • １日 12億レコード
    • ピーク時秒間 5 マンレコード
    • ほとんどが Insert
    • 直近７日分はいつでも SELECT
    • シャーディング対応不可
  • MySQL で対応する時の課題
    • ディスクサイズ
      • 社内の標準スペックでは対応負荷
      • SDS 剪定とか
    • 更新速度
      • 感覚的には 10k ~ 20k レコードを超えるとレプリケーション遅延が発生してしまう
        • ピークの 5万レコード/s だと難しい
    • 運用難易度
      • SELECT が現実的な時間で応答可能か
      • スキーマ変更に現実的に対応可能か
  • 対応方針
    • 8日分(11TB) のみ保持
      • 日次でパーティションを切る
      • 日時で 8 日前のデータを Dump したら DROP Partition
      • dump したデータは必要になったらリストア
    • レプリケーション遅延を許容
    • TiDB でも対応可能かも？
  • 簡易比較実験
    • 実験方法
      • ｍｙｓｑｌｓlap コマンドで一行 Insert を並列で実行
    • 結果
      • MySQL で 15000QPS
        • 並列度を上げても遅延が25分以上発生
      • TiDB だと 60000QPS
  • 検証項目
    • 非互換な仕様を回避可能か
    • ディスクサイズ比較
    • パフォーマンス
      • INSERT 速度の限界
      • データ量増加によるパフォーマンス影響
      • インスタンス障害時
    • 安定性
      • １０TB 以上のデータを投入
  • ディスクサイズ比較
    • 負荷試験データを１億行ずつ生成
      • 1レコード 1kB
        • TiDB の方が MySQL に比べて１．２倍
          • 実際にはデータの冗長性が３倍になっているのでその分すごい
  • システムの統合負荷テスト
    • アプリケーション含めシステム全体での統合テスト
    • 継続テスト・ピーク時再現テスト
  • 安定性の検証
    • 本番同党のデータ量で計↑雨滴に負荷をかける
      • １０TB のデータを入れる？！
        • こんなデータ用意できないｗｗｗ
    • 結果
      • Bulk Insert を上げるとパフォーマンスを上げることができた
        • Bulk の方がすごいのね
      • DDL (Drop Partition)
        • ブレとしては 8% 程度低下
        • 想定の範囲内
      • インスタンス障害
        • TiKV 1ノードで プロセスKILL
          • 数秒間の停止
        • TiKV ノードの強制停止
          • 数秒間停止
          • ９０％程度を維持
        • PD も同様
  • 課題
    • 高負荷環境で利用できる PITR 手法がない
    • max-replicas = 3 での多重故障
    • 障害時リシャードの挙動理解
    • Storage 4TB 制限
  • PITR 検討
    • TiDB binlog
      • Drainer が SPOF、故障したらバックアップからやり直し
      • 変更分を受け取るために TiDB クラスタ全体のパフォーマンスに影響
    • TiCDC
      • TiCDC に PITR はない
    • gc-time を伸ばして復旧時点のデータを抽出 (historical read)
      • その時間内に抽出が必須
    • ｖ６．２ 以降は BRコマンドで可能になった
  • max-replicaｓ = 3 での多重故障
    • デフォルトは 3
      • region の過半数に満たないとその region にアクセスできない
    • 故障したリシャード
      • リシャード中にノードが落ちると全体停止
    • 対策
      • max-replicaｓ = 5
        • 2台までの同時故障には対応
      • placement-rule の活用
        • どのリージョンにデータを配置するか
      • max-store-down-time を 最小の10分にする
  • 障害時リシャードの挙動理解
    • TiKV のステータスに Pending Offline がある
    • 異常があるとこのステートでスタックしがち
    • 対策
      • ディスク容量に余裕を持たせる
      • max-replicas + 1 以上の TiKV ノードで運用
  • Storage ４TB 制限
    • TiKV 1 インスタンス中の Region が 30k を超えると CPU が跳ねる
      • 実際に本番同様の環境でテストする重要性を再確認
  • 最終的な構成
    • とりあえずすごいサイズｗｗｗ
      • １日 7.2TB のInsert
      • ８日で 57.6TB
      • オペミスなどによって +α の容量を持っておく
  • TiDB の運用の現状
    • 大人の事情でこの案件がなくなった ｗｗｗ
    • MultiAZ 対応が必要な社内システムで運用中

[事例セッション] 決済システムにおけるTiDB導入の検証とその効果

• 登壇者

  • SBペイメントサービス株式会社 システム運用統制部 推進課 前島 竜太郎　氏
    • @dohq さん
    • 現在はインフラプラットフォームの構築・運用・改善を担当

• 会社紹介

  • SBペイメントサービス
    • オンライン決済サービス
      • 加盟店と決済機関の間に Hub となってサービスを全て一本化

• NewSQL を検証した背景

  • ダウンタイムの影響が顕著になった
    • 日々の取り扱い件数の増加
    • メンテナンスや障害の発生
  • 複雑化したクエリのチューニングのためん DBA と QA が増え開発のリードタイムが増加
    • めっちゃわかる！！！
  • NewSQL めっちゃ興味あった

• 求めた要件

  • ACID Tx をサポートしているDB
  • MySQL互換
  • マネージド・オンプレミス両方の環境構築が可能
    • 決済系だからね
  • メンテ等での影響が限りなく少ない
  • 細かいチューニングをあまり気にしなくても性能が出る
  • スケールが容易
  • 環境構築で terraform 等 IaC ができる
    • 大事ね！
  • 手厚いサポート

• 検証内容

  • 構築
    • Webコンソールの操作性
    • Terraform Provider の使い勝手
  • 開発
    • 既存アプリを利用した互換性確認
    • 性能
  • 運用
    • 監視
    • アップデート時の影響
    • 障害時の影響
  • 既存DB と同じ使い勝手を求めつつさらに現状の課題を解決できるか確認したかった
    • 既存アプリとの互換性
      • どれくらい既存アプリに手を加えないといけないか
    • クエリレスポンスタイムの変化
    • アップデート時の影響
    • 障害時の影響
  • 検証環境
    • JMeter -> API Gateway APP (20req/s)
      • 既にある既存のサービスを活用して裏側を作成
        • Total 300q/s くらい
    • TiDB Cloud 最小構成
      • Aurora MySQL との比較

• 検証結果のピックアップ

  • 既存のコードを一切変更せずに TiDB で利用可能だった
    • 本当にありがたいと思う
    • 差はあるのでちゃんと公式見て、ね
  • TiDB の方が Aurora よりも遅かった
    • SELECT だと 16倍とか
    • やっぱり大きなシステムであればあるほど、だよね
  • アップデート時の影響
    • Aurora のアップデートはリクエストエラーや３〜１５秒程度の遅延が発生
    • TiDB はリクエストエラーはなく、１〜１．５秒の遅延が多少出たが突出した遅延にはならない
      • TiDB の圧勝
  • 障害時の影響
    • 疑似的に TiDB および TiKV をそれぞれ１台ずつ落とした
      • アップデート時と同じくリクエストエラーは無し
      • Insert 処理で10秒以上のクエリ遅延が１００件程度
        • 新しいリーダーを選出するインターバルが10秒
        • 仕様通りの挙動
          • ゆっても遅延で終わるなら OK じゃん

• まとめ

  • TiDB は既存の RDBMS と比べても決しておとりはしない
  • CRUD しか利用していない場合、既存コードにて入れなくて良い
  • クエリの Latency は高めなので向き不向きは考慮すべき
  • 各種試験時に1件もエラーが起きなかったのは驚き
  • ただし、クエリの遅延は発生するのでリトライやタイムアウトなど適切なハンドリングは必要
  • ここのユースケースを想定した事前検証は大事！！！

[事例セッション] 在宅ワーク時代における宅急便を活用したDXサービスの設計と仕組み：さくらインターネットとヤマト運輸によるSlackアプリ

• 登壇者

  • さくらインターネット株式会社　技術推進統括担当　執行役員 兼 CISO 兼 CIO　江草 陽太　氏
    • メインはアプリケーションエンジニア

• 社員間で宅急便を楽に送りたい

  • 働き方の変化に伴い、社員間の荷物が増加
  • 住所は聞けない、言えない
  • でも営業所留はめんどくさい
    • サービスの概要
      • 荷物を送りたい人が受け取る人を指定する
      • 受け取る人は住所を入れる
      • 荷物をファミマかヤマトに引き渡す
        • 自社でやっていた時は 「チュール便」 とよんでいた
          • 猫に因んでいるらしい
      • 送る人・受け取る人は Slack　APPで完結
        • 支払いも不要
          • 運賃は会社から毎月精算
            • すげぇぇ
      • ゲストも利用可能？
        • 契約時は無効
          • 管理者画面で変更可能
        • Connect も可能
        • 集荷依頼も可能
      • 管理機能
        • 地域だけしか見えない状態だから安心
  • 自社用に作ったがスケーラビリティとかその辺りは前提の設計が適用されていた
  • てか普通にこれ普段の中で使いたいｗｗｗ

• 技術的な話

  • Slack 3秒ルール
    • Event に対して3秒以内に応答しなければならない
    • ユーザーを待たせるとユーザー体験が悪いため
      • わかるぅううう、マジでハマる
  • 非同期処理が必須
    • Django　＋ Celery でできるだけ非同期処理に
    • ブローカーには Redis を利用
      • キューとかはここにある
      • その瞬間の状態を保つだけ
      • 多少データ欠損してもリトライでなんとでもなる
    • スケジューラーは Celery Redbeat を利用
  • 分散データベース TiDB
    • さくらのクラウド エンハンスドDB(TiDB) 利用で DB 運用が楽に

• 非同期処理

  • HTTP リクエストに対して応答を返した後に追加で処理を行う場合
    • 伝票情報のヤマト運輸システムへの登録
    • Slack DM の送信
  • スケジュール実行
    • 荷物追跡情報の取得更新
    • 請求金額の更新
    • 有効期限切れの伝票の削除
      • etc.

• エンハンスド DB (TiDB)

  • さくらのクラウドで10秒でデータベースが使用可能
    • DB名、パスワードを指定して作成するだけ
  • MySQL 互換なのでいつも通り利用可能
    • 一部互換性のない機能もある
  • pungcap/django-tidb
    • Django の Database として利用可能
      • （Django ４．２ LTS でもリウ用できるワークアラウンドあり）
    • MySQL ８．０ 互換性があるわけではないので一部書き換えが必要

• エンハンスドDBのメリット

  • すぐに使える
    • 5秒で作れる
      • クラスタを作るのではなく Database を作るから
        • なるほど！！
      • レプリケーションしたいとかマイグレーションしたいとかどうするんだろう？？
  • 容量を気にせず利用できる
    • 使っている容量に応じて課金される(予定)
    • 最初から大きなディスクを用意しなくて良い
      • スケールするからこそのメリット
  • スペックを意識せずに利用できる
    • 同時接続数を後から増減できる(予定)
      • 今は 50 しかない
  • アップグレードやノード障害を意識しなくて良い
    • コネクションが切れてもすぐに再接続ができる
  • 05-18 に拡張
    • 東京リージョンの追加
    • IP アドレス制限を追加

• エンハンスドDBの設計

  • さくらのクラウドを利用
  • TiDB をシンプルに構築して利用する方針
  • GSLB(DNS) による負荷分散
  • SSL 終端やアクセス制限をするためのリバースプロキシサーバーを独自に開発

• 構築・運用

  • Terraform + Ansible + TiUP による IaC
    • Terraform
      • さくらのクラウドでのインフラ構築と設定
    • Ansible
      • Linux ユーザーの設定
      • TiDB 以外のパッケージ等のインストール
      • その他 TiDB　以外に設定すべき設定
    • TiUP
      • TiDB クラスタのセットアップ
  • TiUP による TiDB のメンテナンス
    • TiUP によるバージョン更新が素晴らしい
      • tiup cluster upgrade clustername v7.1.0
        • シンプルなコマンドで確実に可能
    • ノード追加もシンプル
      • tiup cluster scale-out clustername scaleout.yaml
        • 簡単な yaml 書いて実行で OK
        • 削除も同じ要領で

• TiDB の監視

  • tiup によって Prometheus も構築される
  • Alertmanager も設定される
    • 始めるのもかなり楽

• さくらインターネットの企業理念

  • 「やりたいこと」を「できる」に変える

[事例セッション]【わずか1ヶ月でリプレイスを実現！】アジアNo.1のマーケティングSaaSを目指すMicoworksがNoSQLからNewSQLに移行した理由

• 登壇者

  • Micoworks株式会社 プロダクト統括本部 SREチーム Senior Specialist 陳 瀚 (Chen Han)　氏
    • 2005年に来日
    • ２０２２年末 Micoworks に Join

• 会社紹介

  • 2017年10月30日設立
  • LINE を利用したサービス

• 旧アーキテクチャの概要

  • TiDB 導入前は DynamoDB、Aurora, Redshift を利用
  • データベースのパフォーマンスの最適化は難しい問題
    • ３０００万ユーザー数想定としてデータ設計の基準で考える
    • 属性情報と行動履歴を取得
      • 大量の属性データや行動イベントデータが流入
      • お客様の反応を蓄積することでさらに膨大なデータ流入を見込む
      • 全ての属性やイベントカラムに INDEX を晴れない
    • お客様のセグメントを分類する
  • 最初は DynamoDB と Redshift を使用
    • DynamoDB
      • 属性情報と行動履歴
    • Redshift
      • お客様のセグメントを分類
        • OLAP のデータ部分析

• 旧アーキテクチャの課題

  • システムの複雑度が高い
    • Dynamo -> Aurora and Redshift に同期
      • Dynamo はスキーマレスなので同期にカラム毎の処理が必要
      • カラム追加・変更・削除は各DBで揃えないといけない
    • DB 操作の抽象化レイヤが共通化しにくい
      • ORM が使えない
      • 生SQL を使用
        • SQLInjection を埋め込んでしまう可能性
  • Redshift のパフォーマンスを引き出せない
    • セグメントは毎回動的に検索条件を設定
      • 対象データは時間と共に増加していく
        • QueryCache や AutoAnalyze　を活用できていない
    • データ挿入時の重複レコードは場外できない
      • アプリ側で重複レコードを除外する一時テーブルを作成して利用
    • 同時実行にそもそも向いていない
      • Concurrency Scaling や Serverless を検討したがコスト高
    • 列指向のデータベースであるため従来の検索の方が有利な場合は恩恵を受けられない
      • よく利用されるカラムに Index を貼るとか難しい
    • サービス特性と Redshift の特性がマッチしていなかった
  • 運用の手間
    • モニタリング
      • それぞれに設定
    • 開発と調査
      • どこで問題になっているのか調査が難しく開発者の負荷になっている
    • バックアップとリストア
      • バックアップとリストアが別々の断面になるので整合性が取りづらい

• TiDB の導入

  • DynamoDB と Redshift がなくなった
    • 無駄な処理の削減
      • DB間の動機処理自体がなくなった
    • MySQL 互換性が担保されている
      • 抽象レイヤーの共通化が可能に
        • ORM の有効活用
      • 従来のノウハウが適用されている
        • Unique や INDEX 戦略の活用
  • 更新と検索を両立
    • 分散型 HTAP
      • TiKV と TiFlash を利用することでパフォーマンスが良くなった
  • ３０００万ユーザーを用いてベンチマークを実施
    • 求める要件を超えた
  • 運用性向上
    • モニタリング
      • ダッシュボードでさまざまなモニタリングが可能
    • バックアップリストア
      • WebGUI から自動バックアップ設定が可能
      • データ統合されるので整合性も取れる

• わかったこと

  • Optimizer が適切な実行プランを選べない時もある
    • 複雑なクエリになる時に不適切になる
    • 正しい実行プランの選択を DB エンジンに教えてあげる
      • SQL Hint
      • MPP モードの手動適用
      • Query の最適化
  • ある規模のユーザー流入イベントがあった際に特定の操作が重くなった
    • Key Vusyakuzer で HotSpot の発生が素早く発見できた
    • INDEX　戦略の実行までのインターバルが数時間のうちに完了

• まとめ

  • 高度な操作性とパフォーマンスがまとめられる
    • 属性情報と行動履歴の取得による大量挿入と更新
    • お客様のセグメントを分類による検索のレスポンス性能
  • Dynamo と Redshift を使ったがうまくいかず
  • TiDB によってパフォーマンスも求めるレベルに達した
  • TiDB ならではの運用もある
    • TiFlash の利用によるデータベース最適化
    • Key Visualizer によるモニタリング
    • メモリ最適化方法

[事例セッション] プロダクト分析サービスの超高速集計レイヤーとしてのTiDB

• 登壇者
  • 株式会社プレイド Lead Product Engineer 小川 拓也　氏
    • 2009年にYahoo に新卒入社
    • ２０１９年１２月にプレイドに入社
• 会社・サービス紹介
  • 株式会社プレイド
    • オフィスは打ち抜きでおしゃれ
    • KARTE　を軸としてプロダクトを提供
      • CX(顧客体験)プラットフォーム
        • Webサイトの訪問者の行動を顧客ごとにリアルタイムに解析
        • 一人一人に合わせた顧客体験を提供
      • データ規模
        • １９９億UU
        • 秒間 134000イベント
      • Insight の主な機能
        • 柔軟な条件で統計値を出す
        • 統計的にどういった特徴があるのか、などをシームレスに可視化
    • Wicle
      • KARTE よりもカジュアルに利用可能
• 分析基盤のアーキテクチャと課題感
  • アーキテクチャ概要 (データ分析周辺)
    • エンドユーザー -> APP Server -> Spanner/BigTable/BigQuery -> Client
      • Google Cloud ベースで構成されている
        • Spanner
          • ユーザーへの外部データ、CRMデータ
        • BigQuery
          • 過去全てのデータ
        • BigTable
          • ユーザー解析のためのユーザー統計値やイベントデータ
    • 分析機能
      • BigQuery をメインDBとして利用
      • マルチテナント構造で多様な特性を一元で扱う
      • 大量のレコード数を持つ immutable なイベントデータと Mutable な特性で大量の更新処理が必要なユーザーデータ
      • それぞれのデータを組み合わせた対話的な検索・可視化機能
      • イベントデータは自由度のあるスキーマレスな構成
  • 課題感
    • ０.x秒以内のオーダーで動作するインタラクティブなデータ分析体験を実現したい
      • BigQuery では数十TB以上の規模でのデータ集計処理にもスケールする
      • 一方でアンコントローラブルな部分も多く、UserFacingな層のDBとしての利用には向かない側面は多い
      • まだ最高の体験とは言い難い -> 伸び代
      • データ分析の待ち時間は作業コストとモチベーションに多大な影響を与える
• TiDB　の評価ポイントと検証構成
  • OLTP/OLAP を両立する DB を持ってアーキテクチャを Simplify できるパターンは魅力
  • 大量かつスキーマレスな性質に対して分析特化型DBにある程度でも対抗できる性能があれば理想的な活用ケースの可能性が生まれるため OLAPの性能が第一に気になった
  • 列指向処理を行う TiFlash を重点的に検証
    • 列指向型ストレージコンポーネント
    • コストベース・ルールベースでオプティマイズ
    • 各Nodeで文ｓ何実行できる
    • MVCC で一貫性を保ってデータ連携される
    • 一貫性を犠牲にしてパフォーマンスを向上させるオプションもある
  • TiDB の検証を開始しようと考えたポイント
    • OSS であること
    • 独立的に開発されていてモダンな作り
    • TiKV/TiFlash を投下的に使える
    • 水平スケール性が重視されていて、マッチしていた
    • フルマネージド型サービス、PingCAP 社のサポートの存在
    • 当初 JSON_EXTRACT のサポートがなかったが次のバージョンで対応された開発サイクルの速さ
  • 懸念と感じたポイント
    • 大量のイベントデータは immutable が原則
    • この特性があるため、列指向ストレージ側でも読み取りのレーテンシーがトレードオフになっているかもしれないという懸念
  • 検証環境の区政
    • BigQuery をデータソースとして周期的にデータを同期しTiDB で OLAP を実行
      • ベストではないものの、サービスの特性上データの鮮度を落とすことが許容できるため採れた構成
    • BigQuery と TiDB には同じデータが入っている形になっている
      • ただし鮮度は BigQuery のほうが上
        • Dataflow で周期的に差分更新をかけている
        • 結構安定しているのでこのまま production でも動かしている
• チューニングポイント
  • テーブルスキーマ
    • JSON 関数がサポートされたものの並列で流すと一気にレーテンシーが高まった
    • Scale out/up で解決できるもののコスト構造をより最適化したいと考えた
      • あらかじめ重要なフィールドを定義しカラム化、それ以外は JSON を読みにいく
  • パーティショニング
    • TiFlash ではテーブルの読み取りはパーティションの単位で分離できる
    • 適切なパーティショニングが抜本的なクエリ負荷の軽減になる
    • 一方で分割単位が細かければ細かいほどパフォーマンスが上がるのかというとそうではない
      • データの特性に合わせた構成が必要
        • まだチューニング途中とのこと
        • 管理が割と手間
  • 各種パラメータ
    • ｖ6系では最適化されていないパラメータを設定していることもあったが ｖ7系で短く
    • tiflash_fastscah
      • データの一貫性の一部の処理を犠牲にしてそのまま読み取りに行く
      • late materialization 機能が使えなくなるのでパフォーマンスが落ちることもある
    • tidb_txn_mode
      • 楽観的トランザクションモードを有効にする
    • その他
      • サイズ制限緩和と使用量軽減のために設定
  • クエリ
    • TiDB Cloud で提供されている Monitoring 機能で色々確認できる
    • サポートも含めてキャッチアップをしていった
• 総合的な評価と今後
  • 現段階で BigQuery / TiDB それぞれの E2E のレーテンシーの比較
    • 割と速度向上が期待できることがわかった
      • 厳密にはフェアな状態ではないので一元で比較できるわけではないが
  • TiDB / Pinot / ROCKSET　での検証
    • Pinot
      • チューニング等も考えると人的コストがかなりかかる
      • ただし際立ったパフォーマンスが出ていた
    • ROCKSET
      • JSON とかも使えた
      • TiDB よりもちょっとパフォーマンス悪め？
    • TiDB
      • 平均的なレーテンシーを観測
  • 今後
    • ハイパフォーマンス・スケーラビリティ
      • ユースケースの懐は深い
    • 運用容易性
      • フルマネージドである
      • サポートの存在
    • コスト効率
      • さらに評価を深めたいポイント

[事例セッション] 金融業界のデータ処理ボトルネックを突破：技術革新の旅

• 登壇者
  • 株式会社SBI BITS Data Consulting部 DBA 木内 祐介　氏
• 会社紹介
  • SBI グループの 金融IT戦略の要として設立
  • コンサルティング、ソフトウェア開発、DBパフォーマンス分析および分析などもやっている
• SBIグループ内の分析基盤システムの背景と課題
  • 背景
    • 過去の膨大なマーケットデータを蓄積し、意思決定・予測等に活用
  • 課題
    • 日々増える膨大なデータ量に対し、既存のDBが性能を発揮できていない
      • テーブルロック等もかかってしまうので前日までのデータくらいまでしか分析できない状態だった
    • 当局からの紹介に備えた履歴データの保存方法
      • 該当のデータを探し出すとか様々なところにあると難しい
      • 金融業界はデータの保存期間も法律で決められている
• TiDBの検討経緯と採用理由
  • 検討経緯
    • TiDB V2 の時に検討を開始、多数のテストを実施
    • いくつかの課題があり採用に至らず
      • パラレルにクエリを流したり
      • 拡張や縮小の運用がめんどくさい
      • Oracle　とは違う排他制御
        • etc.
  • 採用理由
    • TiDB v5　と v6 での機能拡張
• 運用面から見たTiDBの魅力
  • TiUP でのクラスタ全体の管理
    • バージョンアップとかめちゃくちゃ楽になった
  • Dashboard と Grafana による豊富な性能統計パネルの提供
    • ボトルネックが可視化された
  • データの読み書きをより安定させるためのパラメータを提供
    • thread pool の自動調整とか便利
    • リソースに応じた適切なパフォーマンスを提供できるようになった
  • TiDB の DM や TiDB Lightning を使用し、データ移行が簡単で早い
    • 想像を超える速さ
  • TiDB BR による様々なバックアップへの対応
    • 増分、差分バックアップ
    • PITR
  • TiDB CDC ツールでのデータセンタ間の同期が可能
    • DR 対応とかで絶対必要
  • 既存のDB利用者にも理解しやすい最適化手法
    • MySQL 以外の DB を触っていた人にとってもとっつきやすい
  • TiFlashによる運用の簡素化、並列処理の実現
    • 並列処理とかでフルスキャンにも対応できている
  • 業界のセキュリティ認証と互換性のある暗号化や監査ログなどのセキュリティ機能
    • エンタープライズ版には監査ログが提供されているだと
    • 機密情報を自動的にマスクしてくれる
• 実際のテストで遭遇した問題と解決
  • Prometheus が OOM などのエラーによりクラッシュした際、復旧時の Log Applyに時間がかかり、その間監視が停止する
    • 検証環境の用意にかかるリソースを Resourcef Control を用いて解決、複数環境を同居
      • DBaaS としても使用できるようになるのでは？
• 今後に向けて
  • 今後データベース全体のサイズが 300TB ~ 600TB に達することが予想される
  • 従来の DB では困難なサイズだが、PingCAP の技術スタッフと協力して挑戦していきたい

【パネルディスカッション】ゲーム業界のデータベースを覗いてみよう

• 登壇者

  • PingCAP株式会社　Japan CTO　林 正記　氏　(モデレーター)
  • 株式会社Cygames　シニアゲームエンジニア/サーバーサイド　宮脇 剛史　氏　(パネリスト)
  • 株式会社スクウェア・エニックス　　情報システム部 SocialGame Infrastructureチーム　神津 和之　氏　(パネリスト)
  • ワンダープラネット株式会社　テックリード・エンジニアリング＆デザインマネジメント室　中山 智義　氏　(パネリスト)

• 以下失礼ながら下記で記載

  • h) 林 正記さん
  • m) 宮脇 剛史さん
  • k) 神津 和之さん
  • n) 中山 智義さん

• ゲーム業界では TiDB が検討されてきている場が増え始めた

  • ゲーム業界の方、会場に半分くらいいる！！
  • ゲーム業界の方は MySQL をよく使っているらしい
    • そうなんだ！ちょっとどころじゃなく気になっちゃうｗ

• テーマ①　ゲーム業界の事情について

  • n) 全社的なクラウド選定等をおこなっている
    • TiDB 開発で使っていこうというフェーズになった
    • パブリッシャー・デベロッパーのうちデータベースが得意な方が構築・管理を担当
    • テーブルやクエリの管理はデベロッパーの責務
    • 基本的にユーザー様のデータは溜まり続ける前提
      • リリースする時からスケールを検討していく必要がある
    • 月数回の新機能搭載やイベントやバグフィックスのDDLを実施することがある
      • メンテナンス入れて運用している
      • メンテナンスタイミングが絞られてしまう
  • k) ソーシャルゲーム系のインフラ担当
    • ゲームタイトルやサービスによってオンプレを使い分けている
    • パブリッククラウドは AWS/Google　Cloud だけでなく他のものも利用中
    • PaaS の DB を採用するケースが増えているが IaaS での DB構築も継続
    • DB を構築してデベロッパーに提供することもあるが、高ｔ区からおまかせすることも
    • NoSQL （MongoDB とか） メインは少なく NewSQL利用が増えている
      • h) NoSQL に対する期待感は？　MySQL の代替？
      • k) 負荷に応じてシャーディングを増やしていかないといけない
        • そこがめんどくさいところでもあり NewSQL が増えている
  • m) サーバサイドの横断的なチームのエンジニア
    • データベースには MySQL を使用
      • 水平、垂直分割を併用
    • 各シャードのデータベースはそれぞれマスター１台とレプリカ２台
    • サービスのクエリは全てマスターを使用
    • クエリは Primary のSELECT UPDATE が多くを占める
      • SubQuery や JOIN を禁止
    • 多い時では 300万QPS を捌いている
      • ある機能だと１６とか６４とかで分割している
  • h) 結構違うなと思ってもらったともうけど、一方で TiDB つかえるかも、と思ってもらえたのではないか

• テーマ② コストメリットをどのように考えるか

  • n) 単純に金額的にコストメリットがあるというのではなく、スケールアウトすることによって Write を捌けるので管理コストが楽になる、というところが言える
    • ビジネススケールで調整が必要になる中その管理面が TiDB だとスムーズにできる
      • 普通にいくと 1ヶ月以上の調整が必要だった
        • これが少なくなったの
      • シャードが増えると開発コストが増えていく
        • サービスのアジリティという点でもちゃんと元を取れている
    • h) 特定のシャードにだけアクセスがきちゃうとか考えるとオーバースペック気味に構築する？
      • n) その通り、やっぱりそれを考えると Aurora だとオーバースペックになる
  • k) 運用コストを気にしている
    • TiDB 安ければ問題なかったが。。。
    • Aurora 便利に使っているが、インパクトがあると問題になる
      • メンテナンスとかに調整が必要
      • 負荷が大きいとインスタンスタイプを大きくしていく
        • 最大まで行ったら今度はシャーディング
        • 障害が起こるポイントを多く抱えることになってしまう
      • 耐障害性というところでも TiDB に期待できる
    • 分析周り上手くできるといいとは思うが、hint 句を使って TiFlash を使えばいい感じに分析できるようになるかもしれないからそこをこれから検証したい
    • h) 分析とか入れるとさらにコストメリットが出るのではないかと
  • m) TiDB 採用したからと言ってすぐにコストメリットがあるとは考えていない
    • スケーラビリティの点では非常に優れている
    • これまでの DB ではエンジニア数人が２〜3ヶ月準備に追われている
      • 管理コストが下がるとやはり生産性が上がるのでいいと思う

• テーマ③　検証・実証実験を通じてわかったこと

  • n) 期待しているところとしてはシャーディングなしでスケーラビリティ高いところ、ってのを検証していた
    • 問題なかった、基本的な性能は色々記事がでているのでそこを見ると良いと思う
    • Sysbench で検証したら線形に綺麗にスケールしていった
    • スケールアップ・ダウンもオンラインで可能だったかどうか
      • TiCloud だとなれないエンジニアでもぽちぽちでできたので運用面も問題なさそうだった
      • 突発的なアクセスによるスケールアウトしても問題なく使えた
    • 学習コスト面ではそのまま移植で問題なかった
      • 。。。けど。。。外部キー無い？！？！？
        • TiDB v６．６ で対応されたとのこと
      • TiDB to MySQL も可能
        • h) （TiDB に）入りやすく逃げやすいということですね (笑)
  • k) MySQL との互換性テスト
    • 本番の Aurora を Clone して移植してテスト
      • 実際の作業としても MySQL Client を通してやったりもしていたが問題なかった
      • まだ Read だけ、Write はこれから
    • S3 -> TiDB に import でたくさんエラーが出た
      • ４TBくらいでエラーになった
      • h) import のタイミングが TiDB が最もサポートするタイミング
    • データサイジング的にもよかった
      • ９TB -> 4.5TB くらいになった
        • もちろんワークロードによる
      • h) データが小さくなったという話だが RocksDB の下の層には圧縮が効いてくるようになっている
  • m) 性能試験をやってほしいと言われた
    • 世間的には Sysbench を使うのが一般的に言われている
    • Cygames でそのまま使えるか、って言えないと思っていた
      • Cygames で使えるかを判断するためにサービスで使っている機能をシナリオを検証
      • TiDB におけるテーブル設計のガイドラインが作れるくらいになった
        • 再現なくデータが増えていくようなテーブル
          • そのまま持って行っても性能が出ない
          • Auto Increment 使うと hotspot ができて性能が出ない
          • Index Scan も時間がかかる
            • テーブル設計を変える必要性
            • PK の中に Sort 用のカラムを突っ込んでしまうとかやってる
        • TiDB 用にチューニングが必要になる感どころはある
      • h) ちなみにレイテンシー目標はある？
        • m) 会社的な基準はないがゲームの内容による

• テーマ④ アプリ開発側が気をつけたほうがいいことや MySQL　互換について

  • h) Unsupported がある
    • 外部キーとか Trigger とかない
    • まじか、ちょっと残念・・・
      • 外部キーは v6.6 で対応したとのこと
  • n) 互換性的には問題なかった
    • アプリの作り的にシンプルに作っていたからこそ
    • 基本的にはドキュメントに必要な情報が整っているのでそこを見ると良い
      • が、実際にアプリを作る時には気をつける
      • hotspot みたいなのがやっぱり
        • なので ID 採番をアプリ側でやるようにした
      • ALTER の多重を実行するとエラーになる
        • 「,」 で繋いで複数の DDL を入れるとか
    • 一部の Online　DDL に時間がかかる
      • INDEX の追加の部分
  • k) 触る分には MySQL　とそんなに変わらないイメージ
    • MySQL と完全互換であるとは言いづらい
      • 特に Auto Increment の部分
      • とはいえこれは NewSQL 全般っぽい気がする
    • SPATIAL が使えないところ
      • 地理ゲーで使えないかなと
  • m) 検証初期の段階で気づいて
    • トランザクション最初の段階で Snapshot 取得のタイミング
    • Select for UPDATE だと Lock が取られたタイミング
      • 排他制御のタイミングが違う
        • TiDB は BEGIN の瞬間
        • 無駄に止めてしまう事になる
      • 最終的には READ　COMMITED で十分と判断
        • READ　COMMITED を使うことで回避

• テーマ⑤ 今後の TiDB への期待

  • n) 結構 feature request　出したがそれが実現された
    • もっと小さい単位で扱えるようになるとありがたい
  • k) その昔は 8CPU を選んだらそれが最初で増やしたら戻せない状態だったが今は戻せるようになったので
  • m) 自動化周りをもっと拡充してほしい

質疑応答

会場) 林さんに質問、来年はどうなるんでしょう？
h) 去年は 50名、今年は120名、来年は東京ドームで開催したい

会場) TiDB を知ったきっかけはどこだったか？
n) CTO から情報を仕入れた
k) New SQL では Spanner　を使っていた、TiDB に関しては New　SQL を積極的に使っている会社からもらった構成図に書かれていたことから知った
m) 上からこれの検証をしてほしいと言われた

Zoom) Cygames の方に質問、Join や SubQuery を禁止している理由は？
m) 水平分割や垂直分割をしていることから Join とか使っても情報が取得できない

会場) TiDB ならではの Performance Tuning　について聞きたい
n) まだそのフェーズではないがドキュメントに書かれているところから確認していくようにしたい
k) まだパラメータチューニングのフェーズまで入っていないがいい感じに TiDB がやってくれていると思っているのでそこは TiDB に期待したい
Insert オンリーでデータを持っているだけ、という場合にはディスクコストがもったいないところがあるのでそこは外に出してもいいかもしれない
m) 基本的に TiDB のチューニングは TiDB にお任せしたい

Zoom) ワンダープラネットの方に、クエリチューニングが必要になった場合にはどのように対応するか？
おもにサーバエンジニアが対応しているという背景から
n) TiDB Cloud だとモニタリング機能が提供されているのでそこからドリルダウンしていこうと思う

会場) TiDB Serverless が GA されたが、その検証は視野に入っているか？
n) 今のところは開発環境では使おうと思っているが本番環境はおそらく使わないだろうと思う
k) まだ触っていない、が開発環境で使えそうだと思っている、本番でもできれば使いたい
m) Serverless 料金分かりづらいのと突然の負荷増に対応できるか、というところが気になる
申し込みとか問い合わせページとかならいいかもね
h) 意味合いとしては Aurora Serverless とは意味合いが違う部分はある
小さいインスタンスタイプもあるので最初からそっちを使うとか
一分間の負荷を見てスケールする

Zoom） スクエニの方に質問、例えば Aurora だとどのようなインパクトある更新が入ってきたりするのか？
k) ZDP とか最近できたが古めのバージョンだと再起動が必要になる
バージョンアップではやはり更新が必要