🐕

dbtech showcase 2024に参加なぅ

2024/07/12に公開

MySQL

dbts2024

tech

今日は dbtech showcase 2024 に参加しています。
今日は全部で書くつもりはあんまりないのですが。。ぬるっと書いてみますｗ

MySQLアプリケーション開発を爆速にする最新手法

2024.7.12 (金) 10:45 - 11:15

登壇者

大塚恒平さん
- ソフトウェア開発はしばしば複雑なプロセスが伴いますが、高品質な製品を迅速かつ効率的に開発するためには、開発とテストのプロセスを簡素化、自動化、最適化することが鍵となります。このセッションでは、Visual Studio Code, REST API, JavaScript, Kubernetes Operator などのツールを活用して、MySQLを使ったアプリ開発を劇的に効率化する最新手法をご紹介します。

MySQL とは

世界でもっと普及しているオープンソースデータベース
デュアルライセンス
- コミュニティ版
- 商用版
Oracle が開発-提供
- 専任開発者
- バージョンリリース
- パッチ提供

MySQL のバージョンポリシー

イノベーションリリース

バグ修正と新機能追加を行うリリース
リリース方針
- バグ修正
- セキュリティパッチ
- 新機能追加
- 機能やパラメータの日推奨かおよび削除
リリースサイクル
- 3ヶ月毎

LTS リリース

バグ修正のみを行うリリース
- リリース後 8年間サポート

ソフトウェア開発の効率化

効率化

年々複雑化するソフトウェア開発
高品質な製品をより早くより効率的に提供することに尽力する

MySQL と VS Code の統合

MySQL Shell for VS Code
- 次世代の開発プラットフォームと UI
- MySQL Shell の VSCode 拡張
- MySQL WorkBench の後継
VS Code のインストール後 MySQLShell 拡張を追加
- 接続を感単位作成し、テストし、保存可能
- KeyVault / キーリングに安全にパスワードを格納
- SSH トンネリング接続や OCI Bastion への接続も可能
  - OCI の場合は自動で Bastion を立ち上げる
Operations
- Monitoring
- DB Object Browser
- OCI Heatwave 統合機能
- クエリの実行
- MySQL Notebooks

MySQL Rest Service を用いた PWA の開発

Restful Webサービス
- テーブル、ビュー、プロシージャの自動REST化
- {JSON} による応答
- 結果のページング
- 開発者サポート (GUI、CLI、API)
MySQL Shell for VS Code
- MRS管理用のGUIフロントエンド
- RESTfulなWebサービス作成
- 対話的なドキュメント
- CLIとスクリプト実行のサポート
ユーザ管理機能の搭載
- 一般的なOAuth2認証をサポート
- ロール、グループ、階層管理の使用
- ユーザー管理GUI
- CLIとスクリプト実行のサポート

Untitled

TypeScript 対応
- 拡張統合により DB Notebook 内で TypeScript を実行可能
データ駆動型のアプリケーション開発を実現
PWA (Progressive Web App)

MySQL Server 内での Javascript サポート

Javascript アプリケーションが主流になってきている
- フロントエンドやサーバサイドの軽量なアプリケーションに威力を発揮
データ集約型のユースケースに対応
GraalVM を使用している

JavaScriptストアド・プログラムの定義

<strong>
</strong>CREATE FUNCTION gcd_js (a INT, b INT) RETURNS INT 
LANGUAGE JAVASCRIPT AS $$ 

   let [x, y] = [Math.abs(a), Math.abs(b)]; 
   while(y) [x, y] = [y, x % y]; 
   return x; 

$$;

$のデリミタで囲まれたところが Javascript となる - 必ずしも$

対応できる SQL の種別
容易なデバッグ
- 標準出力ストリーム
- エラー処理
デベロッパーライセンス
- 本番で利用はできないが学習開発用途で利用可能

MySQL Operator for k8s

自動化されたデプロイと管理
自己修復
バックアップリストア
スケールアップダウン
ローリングアップデート
- などなど様々な機能が定期ょスアれている
アーキテクチャ
VS Code で k8s 管理
- VSCode に k8s 拡張をインストールすることで管理可能

MySQL最新情報と未来展望：進化するデータベース・ソリューションのすべて

2024.7.12 (金) 11:30 - 12:00

登壇者

生駒眞知子さん
- 市場で最も利用されているオープンソース・データベースとしてMySQLは進化し続けます。本セッションではMySQL 8.4 LTSおよびHeatWaveの最新イノベーションである生成AIやベクトル・ストアなどの新機能を一挙にご紹介します。さらに、データベースを効率的かつ安全に利用する上で重要なセキュリティや、運用監視、アプリケーション開発など盛りだくさんのトピックをお届けします。

HeatWave GenAI をリリース

HeatWave から生成 AI に
- HeatWave には OLAP, MLPlatform, DataLake 的なところは搭載されていたがここについに生成 AI が入った
  - 自動ベクトルストアを実装
  - インデータベースLLM を提供
  - スケールアウト可能なベクトル処理
  - HeatWave Chat
- 全ての OCI で利用可能
  - HeatWave 使っていれば追加費用はかからない

自動ベクトルストア

HeatWave ではデータが自動的に解析されエンコード
- 作成手順
  - ドキュメントの発見 → 解析 → 埋め込み生成 → ベクトルストアへの登録
    - heatwave_load を使うと一気に作れる
- ベクトルストア作成の全ての手順は HeatWave 内で完結
  - 全てのｒシステムリソースは HeatWave により最適化
- データ更新時はベクトルストアも更新
  - 内部的に自動で実行される
    - 構造化だけでなく半構造化・非構造化でも大丈夫
- Amazon Bedrock の knowledge bases よりも圧倒的に高速
  - コストで 1/4
  - 8~23倍程度高速

インデータベースLLM の提供開始

シンプル
- 外部 LLM の選択と統合は不要
- GenAI Apps をすぐに開発
低コスト
- LLMを使うための追加コスト不要
- システムリソースの最適化
柔軟性
セキュリティ & パフォーマンス
- データはデータベースから離れない
  - データの分離
- 共有サービスではない
  - パフォーマンスの分離
Auto ML との統合でパフォーマンス向上とコスト削減を実現
- 精度の向上
- パフォーマンスの向上
- コスト削減

スケールアウト可能なベクトル処理

標準SQLでセマンティック検索を実現
- 類似性検索のための新しい距離関数をサポート
  - L1/MANHATAN
  - L2/EUCLIDIAN
    - などなど
類似検索の性能比較
- HeatWave は高速
  - SnowFlake: 30x
  - Databricks: 15x
  - BigQuery: 18x
- コスト面
  - SnowFlake: 1.3x
  - Databricks: 6.4x
  - BigQuery: 3.0x

HeatWave Chat

チャット機能の提供
- アプリケーションが使用できるようにサーバに保存されるチャットコンテキスト
  - サーバが保持するコンテキスト
    - チャット履歴
    - テーブル
    - ドキュメント
    - モデルオプション
    - プロンプト
    - レスポンス
ユースケース
- パーソナライズされたレコメンデーション
- テクニカルサポート向けに開発されたアプリケーション
  - 既存のバグ対応履歴などをみてレポート作成 + 異常ログの要約
    - オペレータ向けに自然言語でインシデントレポートを作成
MySQL Shell for VS Code
- MySQL Workbench
  - 8.0 でリリース終了
  - 後継となる
- MySQL Enterprise Monitor
  - 2025年1月で EOL
    - Oracle Enterprise Manager for MySQL
      - Carrier Grade Edition の契約を持っていることが前提
    - OCI Database Management Service
      - 今後の機能拡張でオンプレ等にも対応予定
        
        2024年夏頃に GA 予定

MySQL の直近のリリース

8.4.0 LTS リリース
- リリース後8年間サポート
9.0.0 Innovation リリース
- 2年後に 9.7.0 というバージョンでリリース
  - 3ヶ月毎にリリース
ベクトルデータ型サポート
- データをベクトル化して保存し、ベクトル同士の近接性や類似性をベースに検索
mysql_native_password 削除
- 8.4 では非推奨になりプラグイン化
- 9.0 で削除される
パフォーマンス関連の改善も継続して実施している
LTS シリーズ内の Group Replication におけるローリングアップグレード / ダウングレードの変更
- LTS 内でのダウングレード / ロールバックが可能になった
削除された機能
- レプリケーション関連
  - Master - Slave という言葉を削除
- デフォルト設定も変更さている
MySQL for Developers License
- 学習、開発、プロとタイプ向け
  - 商用版と同じ機能を試すことができる

楽天グループの広告配信システムにおけるAerospikeの活用事例

2024.7.12 (金) 13:15 - 13:45

広告グループってまさに僕の古巣

僕が楽天に入社して初めてのグループだったはずなので興味高め

登壇者

高橋辰徳さん
- 楽天グループで広く使われている広告配信システムではデータベースとしてAerospikeが使われています。世の中には多数の優れたソフトウェアやサービスが存在しますが、その中からAerospikeを選択した理由をご紹介しつつ、これからAerospikeの検証や導入を考えているエンジニアの方の参考になるように、実際に Google Cloud Platform 上で運用中の構成やチューニングポイントについてご紹介します。

楽天グループの広告配信システム (Rakuten Unifided Ads)

楽天データを用いたターゲティングが可能な広告配信システム
- 株式会社 LOB という会社に委託する形で開始した
- 開発当初は 10名程度の人数でやっていた

広告配信システムで Aerospike を採用した理由

レイテンシーが広くばらつきが少ない
- 広告配信システムのデータベースの重要な要件の一つ
  - レイテンシー
    - Google Cloud BigTable
      - 99パーセンタイルで 1桁ミリ秒の霊天使を実現
    - Aerospike
      - 99パーセンタイルで 1.2m秒
- メモリのみの場合、ほとんどの読み取りリクエストが 1ms 以下
- 1ms を超えるリクエストは多い時でも全体の 0.02% 程度
安定稼働
- 運用実績
  - ソフトウェアの動作不良でプロセスが落ちたことはない
    - 過去のトラブル
      - ローカル SSD の故障
      - サーバ故障による再起動
  - CPU 使用率や Load Average が乱高下せず安定している
    - CPU 使用率が30% 程度で水位
      - クラスタリングすることで 1クラスタ落ちても問題ないように設計している
    - Load Average
      - 大体 0.5 程度で水位
- 仕組み
  - 特定のノードにアクセスが集中しづらくなるように自動的にデータがノード間を移動する仕組みがある
    - 各サーバに安定して割り振られている

特定のレコードの読み書きの性能を上げられる

トップページの広告を表示するときに特定のレコードの読み取りが多くなる可能性があるという懸念
- 当初は Google Cloud の BigTable を検討
  - BigTable の場合、特定の行にアクセスが集中するとノードの配置するデータを減らして性能を上げる設計
    - 若干不安があった
- Aerospike
  - スケールアップ、スケールアウトが可能
    - スケールアウトの場合、データの一貫性は犠牲になる
      - レコードが全てのサーバに配置されるまでのレイテンシー

Hybrid Memory Architecture が特許

蓄積された膨大な楽天データをそこそこ高速に取得したい
- メモリとディスクを併用したい (メモリのみだとお金がかかりすぎる)
- Hybrid Memory Architecture
  - メモリとディスクを併用する技術によって高パフォーマンスを実現
分散システム上でデータを特定するための情報をメモリに設置し、実データを SSD などのストレージに設置する仕組み
- DIGEST & TREE INFO
  - 分散ハッシュテーブルや分散ツリー構造の情報
- RECORD METADATA
  - レコードサイズなどの情報
- STORAGE POINTER
  - データが保存されている場所の情報

広告配信システムの設計例

Google Cloud で構築

データベース構成
- メモリのみの領域
  - 広告配信の設定
- Hybrid Memory Architecture
  - 楽天データ
ディスク構成
- サーバ一台に月 4台のローカル SSD を設置
- ファイルシステムを作らずに Aerospike が直接アクセス (RAW)
Rack awareness
- レコードが複数のゾーンに複製されるように設定し、どちらか片方のゾーンがダウンしても耐えられるようにしている
- クライアントが同一ゾーンの Aerospike にアクセスするように設定することもできる
  - この場合ゾーン間データ転送費用が抑えられる上に通信時間もわずかに短縮できる

Aerospike のパフォーマンスチューニング

公式ページにチューニングポイントがまとまっている
- Swap を off にするという基本から OS のネットワークの設定方法など
- Linux 共通の項目と各種クラウドベンダー固有の項目に分かれている

Aerospike のモニタリング

Prometheus Exporter 経由でかなり詳細なデータを取得できる
- Datadog に喰わせて可視化

Enterprise Edition と Community Edition

Community Edition をサービスで利用すると困るところは？
- prefer-uniform-balance のサポートがない
  - データが特定のノードに偏ってしまうのでサーバに搭載するメモリの量や負荷の見積もりが難しくなる
- 休止状態 (Quiescing a node) のサポートがない
  - 停止命令を出さずにサーバを落とすとクライアントが停止したサーバを学習するまでリクエストを出し続けてしまう
    - 数秒程度かかる可能性もある

Aerospike を運用した所感

特別な技術がなくても安定した運用ができる
独学で運用方法を確立するのはすごく大変
レコードサイズの制約が厳しい (最初の設計が重要)
- メモリのみの場合最大 8MB(固定)
- Hybrid memory architecture の場合は推奨 128kb, デフォルト 1MB、最大8MB
フルマネージドサービスと比較して
- アプリケーションのパフーマンスが出ないときに 100% 開発側の責任にしづらい
- 工数がかなりかかる (Config, Operation, Monitoring, Tuning)

【TIS】止められない決済システムを支える技術として TiDB はふさわしいのか？

2024.7.12 (金) 15:30 - 16:00

登壇者

根来和輝さん
山田直希さん
- オンライン決済サービスが広く普及し、社会のインフラとして機能するようになりました。いつでもスムーズに決済したい。このようなニーズに応えるため決済サービスを支える決済システムは非常に高い稼働率を実現しなければなりません。このセッションでは、分散リレーショナルデータベースであるTiDBが、こうした高い稼働率を達成するための基盤技術として適しているかを弊社で検証した事例をご紹介します。耐障害性、性能、そしてデータ整合性に着目した検証でTiDBはどのような結果を残したのかを解説します。また、今回検証を通じて明らかになったTiDBの能力を活かすためのシステムアーキテクチャ上の考慮点についてもご紹介します。

TIS が直面する課題

従来後架養成が求められる決済サービスは高価なハードウェアを用いて実現してきた
決済手数料引き下げ圧力が高まっていく市況において低コストで実現することが必要となった
- Lerna Stack
  - 高可用かつ高スループットが求められるミッションクリティカルシステム向けソフトウェアスタック
  - 要件
    - 可用性
      - 24/365
    - 稼働率
      - 99.999%
    - オンラインレスポンスタイム
      - 99パーセンタイル 150ms
    - スループット
      - 1000TPS
    - スケーラビリティ
      - ダウンタイムなしでのスループット上限引き上げ可能
高価な専用サーバ
- エンタープライズシステムに特化した専用サーバを用いるアーキテクチャ
  - 高い可用性
  - 高い性能
  - ハードウェアロックイン
  - 学習ハードルが高い
- NoSQL を活用したアーキテクチャ
  - コマンドクエリ責務分離
  - イベントソーシングを用いて書き込みが得意な NoSQL, 読み込みが得意な RDB を適材低所で使うアーキテクチャ
専用の高価なサーバが不要で、高い可溶性とスケーラビリティが実現できて、尚且つアプリ開発者が扱いやすいものを検討
- NewSQL
  - ACID トランザクション
  - 分散DBであり、読み書き両方のスケーラビリティがある
  - マルチマスター構成のため高い可用性
  - DBaaS や OSS など幅広い選択肢がある
    - TiDB を選択
- TiDB
  - MySQL 互換の NewSQL
  - オープンソースで開発
  - OLTP, OLAP 両方をサポート
  - 技術サポートや日本語の情報が充実
  - 利用方法の自由度が高い
アーキテクチャの評価観点
- ミッションクリティカルシステムに要求される非機能要件を達成できるか
- 特定の構成要素だけに限定せず、エンドユーザー目線でサービスとしての非機能要件達成レベルを評価
- アプリケーション開発者目線で学習コストが抑えられるか
検証結果
- TiDB ベースのアーキテクチャはミッションクリティカルシステムに求められると想定される非機能要件を達成
  - 99.9999%
  - 1000TPS
  - 99パーセンタイル 120ms
  - 年間停止時間 0
- 高可用、工数ｒープットソフトウェアスタックのコア技術として採用できると評価
- 従来課題であった学習ハードルの高さも改善が可能と評価

検証

稼働率の検証

TiDB のアーキテクチャ
- TiDB: 外部とのインターフェースとしての役割
- TiKV: データの保存を担当
- PD: クラスタ全体の管理
検証環境
- AWS 常に模擬的な決済システムを構築
  - 負荷試験ツールはガトリングを使用
- 実際のサービスでも発生する可能性のある障害を再現
  - インスタンスダウン
  - NW 分断
- ダウンタイムの算出方法
  - ガトリングで負荷をかけて１件でも KO が発生する時間をダウンタイムとする
障害趣味レーション方法の方針
- 最悪ケースを想定
  - PD インスタンスダウン
    - PD インスタンスは稼働しているインスタンスの一つがリーダーで、それ以外はバックアップとして機能
    - リーダー以外のインスタンスがダウンしてもダウンタイムは発生しないためリーダーがダウンするシナリオを採用
TiDB インスタンダウンの考察
- すでにダウンしている TiDB インスタンスを利用しようとしてリクエスト失敗
  - ダウンしたインスタンスを接続先候補から一定時間除外
TiKV インスタンスダウンの考察
- TiKV のアーキテクチャ
  - データをリージョンという単位で管理
  - 複数ノードにリージョンのレプリカを保持
- インスタンスダウン時に起こる現象
  - TiKV で新しいリージョンリーダーを選挙
- データ量によってはダウンタイムが発生する可能性がある
PD インスタンスダウンの考察
- PD インスタンスダウン時に起こる現象
  - PD リーダー選出
  - ヘルスチェックようのSQL実行に時間がかかり、アプリケーションヘルスチェックがタイムアウト
  - 一定時間ガトリングのリクエストが全て失敗することでダウンタイムが発生
NW 分断
- TiDB 分断した NW の少数派だと失敗する
- 少数派の NW に属するアプリケーションを LB から切り離す必要がある
- NW分断時に起こる現象
  - PD リーダー選出
  - TiKV のリーダー選挙

運用時の検証

運用時の検証
- 各サーバのスケールイン、アウトが可能かどうか
  - スケールインを無停止でするには TiDB で一工夫必要だった
    - アプリ側のコネクションを全て閉じることで、安全にスケールインすることが可能

まとめ

ミッションクリティカルな決済システムを支える技術として TiDBはふさわしいと評価
アプリと TiDB の連携には一工夫が必要
今後 TiDB をコア技術とした高価ようシステムプラットフォームの立ち上げ
- 原則メンテナンスによるサービス停止なし
- 単発障害から数十秒以内に復活
  - など

【ELESTYLE】キャッシュレス決済SaaSがAurora MySQLからNewSQLデータベース「TiDB」に移行した背景と運用

2024.7.12 (金) 16:15 - 16:45

登壇者

浦力鑚さん
- 2019年にキャッシュレス決済サービス「elepay・OneQR」を運用開始以来、自動販売機、駐車場、飲食業、小売業を含むさまざまな生活シーンでの支払いを支えてきました。新型コロナウイルスの終息と経済活動の再開により、取引数が大幅に増加しました。特に、24時間365日稼働するシーンが多いため、メンテナンスウィンドウを設定することが困難になりました。この背景から、2023年にAurora MySQLからNewSQLデータベースTiDBへの移行が行われました。この移行を決定した背景、運用する中で感じたこと、課題について紹介します。

導入前の DB 構成の課題

構成

OLTP: Aurora MySQL クラスタ
OLAP: Self Managed Clickhouse

課題

レプリカタイムラグ
- プライマリノードとレプリカノード間での同期のタイムラグ
DDL
- データ量が多いテーブルでは項目追加やインデックス追加時の性能が低下する
書き込み性能
- 単一ノードの性能に依存しており、書き込み性能が制限される
スケールアップ
- データ量の増加に伴いサービス停止なしでのスケールアップが困難
OLAP
- OLAP 専用データベース (Clickhouse) の運用コストが高い

なぜ TiDB を選んだのか

MySQL と高い互換性
ACID 特性
水平スケーリングの容易さ
Managed サービスの提供 (TiDB Cloud)
HTAP サポート

TiDB の導入

MySQL互換性注意点

Trigger 機能が使えない
STORED PROCEDURE が使えない
AUTO INCREMENT の値が順序通りに生成されない

TiDB の移行- 2週間で完了

TiDB DM で旧 Aurora MySQL のデータと TiDB を同期
TiDB CDC で Backup 用 Aurora MySQL を用意
Proxy SQL で切り替えを実施

TiDB 導入後の利点

開発時にレプリカデータの動機遅延を考慮しなくて済む
Aurora と Clickhouse を統合できた
管理運用面で楽になった

TiDB Cloud の利用

ゼロダウンタイムで TiDB Cloud UI で数クリックで拡張可能
モニタリングも楽にできた
- ダッシュボードの提供等様々なメリットがあった
日本でのビジネスサポートを提供

TiDB の課題

Primary Key を利用した検索は Aurora MySQL より遅い
大量データを削除した後スペースがすぐに解放されず、無駄なスキャンが発生しクエリの実行速度が低下することがある
トランザクション中にテーブルメタデータ（DDL）が変更されるとエラーが発生することがある
- version 6.3.0 から解消
- TTL も version 7 から提供
TiDB バージョンアップグレードや TiDB Cloud の k8s 環境 (EKS で構築している)のアップグレードにおいてトランザクション中のデータベース接続が切断される可能性がある
- デフォルト値を入れたカラムを追加した場合、NULL が返る可能性があった
- パッチの PR 出したら翌日に入った

TiDB x TiProxy

TiProxy とは
- TiDB に特化した Proxy
- 2024年9月にリリースされる見込み
主な機能
- TiDB のローリングアップグレード
- スケールイン
  - 接続している TiDB サーバがスケールイン
- スケールアウト
  - 新規 TiDB サーバに接続を振り分ける

TiDB Cloud Data Service

TiDB Cloud Data Service とは
- 完全管理型のローコードバックエンドサービス
主な機能
- HTTPS リクエストを開始て TiDB Cloud データにアクセエス
シナリオ
- モバイル、またはWeb アプリケーションから直接データベースにアクセス
- データ可視化プロジェクトとの統合
- MySQL インターフェースがサポートしていないサービスとの連携

【SBペイメントサービス】TiDBで私達は幸せになれたのか? ~止められない決済システムにTiDB Cloudを導入した理由~

2024.7.12 (金) 17:00 - 17:30

登壇者

前島竜太郎さん
- SBペイメントサービスではクラウドDBを実業務に適用してきた中で、さまざまな課題への対処として早くからNewSQL、そしてTiDBに着目してきました。
  ミッションクリティカルなシステムを維持しながら新技術を採用していくことには組織的な意思決定や検証が重要です。
  TiDBを実運用に適用するまでの過程における意思決定や検証、そして実際の運用フェーズにあった出来事まで一気通貫でお話しさせて頂きます。
  是非参考にしていただければと思います。

New SQL を検証した背景

日々増加する取扱件数に対して障害、メンテナンス時のダウンタイム影響が顕著に
複雑化したクエリチューニングのため DBA との QA が増え開発のリードタイムが増加
NewSQL に興味があった

求めた要件

ACID tx をサポートしている
MySQL互換
マネージド、オンプレミス両方の環境構築が可能
メンテ等での影響が限りなく少ない
細かいチューニングをあまり気にしなくても性能が出る
スケールが容易
IaC でできる
手厚いサポート
- TiDB が選定対象に

検証項目の策定

構築
- Web コンソールの操作性
- terraform Provider の使い勝手
開発
- 既存アプリを利用した互換性確認
- 性能
運用
- 監視
- アップデート
- 障害時の影響等

検証結果ピックアップ

既存の DBと同じ使い勝手を求めつつ、さらに現状の課題を解決できるかを確認したかった
- 既存アプリとの互換性
- クエリレスポンスタイムの変化
- アップデート時の影響
- 障害時の影響
検証環境
- JMeter
  - 200r/s
- total
  - 約 2500q/s
- Database
  - TiDB Cloud
    - 2vCPU 8GiB x2
  - TiKV
    - 2vCPU 8GiB x3
- Aurora MySQL も比較用に準備
検証結果
- 既存のコードを一切変更せずに移行することができた
- クエリレスポンスタイム
  - SELECT : 約16倍
    - 全体的に遅くなっている
      - リアルタイムシステムであれば影響は無視しても問題ない増加量だという結論
- アップデート時の影響
  - Aurora
    - Connection Reset により５件のリクエストエラー
    - DB インスタンス再起動時に起きたクエリ遅延によって 3 ~ 15 秒ほどのクエリ遅延が６０件程度
  - TiDB
    - リクエストエラーは発生せず
    - 多少の遅延は見られたが最大 1 ~ !.5秒程度 20件なので突出したものではなかった
- 障害児の影響
  - PingCap と連携し擬似的な障害テストを実施
    - アップデート時と同じく、リクエストエラー話
    - TiKV を落としたタイミングで Insert 処理が 10秒以上のクエリ遅延が 100件以上発生
      - 新しいリーダー選出インターバルが 10秒となっているため、使用通りの挙動
ここまでのまとめ
- TiDB は既存の RDBMS と比べても決してお取りはしない
- CRUD アプリの場合、既存コードに手は入れなくて容易
- クエリのレーテンシーは高めなので向き不向き八考慮すべき
- 各種試験時に1件もエラーが起こらなかったのは驚き
- アプリ側でリトライやタイムアウトなど適切なハンドリングは必要

TiDB 導入に向けて

AWS との接続は VPC Peering を使用している
PingCap が提供している terraform provider が用意されている

祝！サービスイン！

トランザクション数もSQLクエリ数も順調に伸びている

運用とメンテナンスの経験

サービスインを迎えてから半年
TiDB でもトラブルがいくつか発生していた
- 散発的に発生するスロークエリ
  - 継続監視を実施していると SQL クエリのレスポンスが一部跳ねていることが確認された
  - TiDB の提供しているダッシュボードで確認したところ、それなりの頻度で数百ms のスロークエリを確認
    - サービスイン当初から発生していた
    - INSERT に限らない
    - 普段 10ms くらいが 400ms 声になることもある
    - 発生頻度は定期的ではなく再現性がない
  - サポートチケットを切ったことで原因特定
    - PD で稼働しているプロファイラの負荷が高かったため TSO サービスに遅延が発生していた
      - (TSO) 分散トランザクションを実現するためのグローバルにユニークなタイムスタンプを提供するサービス
  - PingCap に依頼して、プロファイラを停止することで解消
- TiDB Cloud 基盤メンテナンス
  - サービス提供側が要因となるメンテナンスは切っても切り離せない
    - PoC 環境用クラスタでメンテナンスがあった
  - 利用者が何か作業する必要がない
    - PingCap がよしなに作業実施してくれる
    - 内容によってはアプリ ↔ DB 間のコネクションがキレるため、コネクションプールライブラリを適切に設定しないとコネクション再作成等ができないので注意が必要

運用メンバーは果たしてハッピーになれたのか？

リソース応答時間は余裕
Terraform を利用して自担ができた
PingCap のサポート本当に手厚い