Vitessへのいざない 2020/02/13 Cloud Native Meetup Tokyo #12 Graduated Project @cotoc88 1

自己紹介 • 茂 こと（しげる こと） • Cloud系プリセールスエンジニア – 〜2019/12 Oracle Japan – 2020/01〜 転職しました Vitessの過去の資 料:https://speakerdeck.com/cotoc 
 2 ※ 私個人の趣味であり、所属企業・部門見解を代表す るものではありません。

お品書き • Vitessとは • Vitessのアーキテクチャ • Vitessの気になるところ – プロビジョニング時の考慮事項 – MySQLとの互換性 – シャーディングの仕組み • Vitess as a Service 3

Vitessとは 4

Vitessとは • シャーディングによるMySQLの水平スケーリングのた めのOSSなデータベース・クラスタリング システム • YouTubeによって開発された技術 – First Commit in 2010 – In Production at YouTube since 2011 • GoogleによるYouTube買収は発表は2005年10月 • CNCFに16番目にホストされた プロジェクト – 開発当初からKubernetesをサポート(Borg時代から) • MySQL(5.6 - 8.0)とMariaDB(10.0 - 10.3) を公式にサポート 5

6

Vitessご卒業おめでとう 7 • 2019/11/5 8番目のCNCF Graduate Projectsに – 同時にVitess ver4.0を発表（現在最新はVitess 5.0） https://www.cncf.io/announcement/2019/11/05/cloud-native-computing-foundation-announces-vitess-graduation/ • 「卒業」とは何なのか – CNCFから卒業するわけではなく、プロジェクトの成熟度の目安 – CNCF Graduation Criteria v1.3 をクリアすることが条件 https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc • プロジェクトのガバナンス、コミュニティの広がり、コードコントリビューションの活性度、組織 力などで、成熟度が一定の段階に達し、CNCFの技術統括委員会（Technical Oversight Committee：TOC）に認定されたもの

• パフォーマンス – コネクションプーリングなどパ フォーマンスを最適化するため の機能の提供 – トランザクション管理、全体の スループットを最適化 • 拡張性 – シャーディング機能により、 シャーディングロジックをアプリ ケーションに追加せずにDBを 拡張可能 8 • クラスター管理・監視 – WebベースのGUI、マスター管 理ツール – パフォーマンスの監視・ 診断・分析ツールの提供 • MySQLとの互換性 – MySQLのクエリとの互換性 MySQLクライアントからそのま ま利用可能 – （一部非互換あり） Vitessの特徴

Vitessアーキテクチャ 9

Vitessのアーキテクチャ 高可用性Vitessクラスターに必 要なコンポーネント ● 2 VTGate Servers ● A redundant Topology Service ● 3 MySQL Servers with semi-sync replication enabled ● 3 VTTablet processes ● A Vtctld process 10

Vitessのアーキテクチャ Topology サーバー、シャーディング・スキーム などの構成情報を管理するメタデータ ストア etcd, ZooKeeper or Consul cluster をサポート（Kubernetesではetcdを利 用） VTgate アプリからのクエリを正しいVTtablet にルーティングし、結果をクライアント に返す軽量なプロキシサーバー MySQL ProtocolとgRPC protocol に対応 11

Vitessが提供するgRPC Client Library • 現在公式に提供されているClient Libraryは Java / Go の2種類 – 以前はPython等も提供されていたが 現在はリポジトリ、マニュアル(Vitess.io)から削除されている • 新しいユーザーにはMySQL Protocolの利用を推奨 12 と は 派、 は 派らしいです

Vitessのアーキテクチャ vttablet MySQLの前に置かれている プロキシサーバー MySQLと1:1、有害なクエリからMySQL を保護 MySQLとvttabletをセットでtablet と呼ぶ 13

Vitessのアーキテクチャ vtctl Vitessクラスタを管理するためのコマ ンドラインツール vtctld Vitessクラスタに対する管理操作を受 け付けるHTTPサーバー GUIを提供 14

Vitess in Kubernetes 15 vttablet vttablet etcd

Vitess in Kubernetes Install 1. minikube やお手持ちの k8s クラスターの準備 2. kubectl、Helm2のInstall（Helm3は未対応） 3. etcd-operatorのInstall 4. mysql-clientのInstall 5. Vitess ClientのInstall / Go 1.12+ のInstallが必要 6. git clone git@github.com:vitessio/vitess.git 7. helm install ../../helm/vitess -f 101_initial_cluster.yaml 参考 – 公式マニュアル： • https://vitess.io/docs/get-started/kubernetes/ – Percona Blog： • https://www.percona.com/blog/2020/01/14/setup-and-deploy-vitess-on-kubernetes-minikube-for-mysql-part-ii-of-iii/ 16

Vitess in Kubernetes Install 17

Vitessの気になるところ 18

プロビジョニング時における考慮事項 • サイジング指標 – VitessコンポーネントはCPUバウンドな処理傾向 (*MySQLを除く) • VTGate VTGateサーバー毎に2~4CPUコアの割当 • VTTablet mysqldと同数のCPUコアの割当 • mysqld 1500QPS毎に1コアの割当（新規ワークロードのプロビジョニング時） – VTGate/VTTabletサーバーのメモリ要件は、QPSと結果セットの サイズに依存 • 1コアあたり1GBを基準にプロビジョニング – ネットワーク遅延 • クエリ毎に2msのラウンドトリップを見積 19 ※ あくまで目安、実際は処理に依存

プロビジョニング時における考慮事項 • シャードサイズのプランニング – Vitessが推奨するプロビジョニング時のシャードサイズは約250GB • 上限値ではない • インスタンス障害時の復旧時間に基づいて検討すべきもの – シャードサイズが250GBである場合、15分以内でのバックアップからの 完全リカバリが期待できる • ほとんどのワークロードに対して有効 – CPUコアもメモリも比較的少なめのシャードインスタンス生成で済む – 大きめのインスタンスサイズで実行するよりも経済的でオトク！☻ 20 ※ あくまで目安、実際は処理に依存

MySQLとの互換性 • サポートしないSQL – 一部サブクエリ • サブクエリをサポートするが、GROUP BY操作と組み合わせたサブクエリは未サポート – ストアドプロシージャ • MySQLストアドプロシージャはまだ未サポート – ウィンドウ関数とCTE • ウィンドウ関数または共通テーブル式をまだ未サポート – その他詳細は ：https://github.com/vitessio/vitess/blob/master/go/vt/vtgate/planbuilder/testdata/unsupported_cases.t xt 21

MySQLとの互換性 • トランザクションモデル – MySQLのデフォルトは REPEATABLE READ Vitessはクロスシャード・クエリーを実行するときに READ COMMITTED • クロスシャードトランザクション – デフォルトではシャードにまたがるトランザクションは未サポート – Two-Phase Commitを利用することもできるが、クロスシャードの 変更が不要になるようにVSchemaを設計することを推奨 22

参考：分離レベルとデータの矛盾について の分離レベル（ ）はロックの保持期間によってデータに矛盾が発生す る つ現象と、それらの矛盾をどこまで許すか（どこまでデータの一貫性を犠牲にして よいか）で つの分離レベルを定義 矛盾の現象 分離レベル ダーティ・リード 非リピータブル・リード ファントム・リード 発生する 発生する 発生する 発生しない 発生する 発生する 発生しない 発生しない 発生する 発生しない 発生しない 発生しない 23 トランザクション内で、他のトランザクションで された行の変更が表示されてしまう現象のこと

シャーディング • シャーディングとは – 2つ以上のデータベースにデータを分割して格納すること – Shardを追加することでDBのスケールアウトし、パフォーマンスの向上を狙う技 術 • Vitessは2種類のシャーディングをサポート – 垂直分割: テーブルを別のデータベースに格納 – 水平分割: 1つのテーブルを複数のShardに分割し、複数のデータベースに分け て格納 24

Vitessのシャーディング 25 のルール を定義 id food price 1000 niku 500 1001 sakana 200 1002 tane 100 id food price 1001 sakana 200 id food price 1000 niku 500 1002 tane 100 水平分割 id name 1 inu 2 neco 3 tori id food price 1000 niku 500 1001 sakana 200 1002 tane 100 垂直分割 高負荷

シャーディングされたデータベースの構成 • Keyspace – Shardを複数まとめた論理的なデータベース – アプリケーションからは1つのMySQLデータベースとして見える • VSchema – 複数Shardにまたがるデータの配置を表現するメタデータ – アプリケーションからクエリが発行されると適切なShardにルーティングするため の情報 • VTworker – シャーディングの分割処理を行うワークロード 26

シャーディングのロジック 27 Shard -40 40-80 80-C0 C0- Keyspace ID 7F FF FF FF 80 00 00 00 80 00 00 01 Key Range ：00 00 00 00 – 3F FF FF FF ：3F FF FF FF – 7F FF FF FF ：80 00 00 00 – C0 00 00 00 ：C0 00 00 00 – FF FF FF FF 出典： ※ の名前は （キー範囲）の開始と終了 進数で表示されハイフンで区切られる { } • Vindexを付与した列からKeyspace IDを算出（Hashなど複数種のサポート） • Keyspace IDとShardとのマッピングに従ってデータを配置 id food price 1000 niku 500 1001 sakana 200 1002 tane 100

VindexとKeyspace ID • Vindex – キーとなる列とKeyspace IDの算出ロジックを定義 • 算出ロジックは選択可能 – 例：Hash/Functional/Lookup Unique/Lookup NonUnique – テーブルは複数のVindexを持つことができる • プライマリVindex: Shard分割に使用する一意な列を指定（Sharding Key） • セカンダリVindex: プライマリVindexを使用しないWHERE句の最適化を提供 　　　（クロスシャードIndex） • Keyspace ID – 特定の行がどのShardに存在するかを決定・特定するために使用される値 – Vitessが内部的に使用 28

新機能! VReplication • マテリアライズド・ビューライクなコアな機能 クエリーパフォーマンスの最適化や柔軟な運用 – Vitess 4.0から追加された新機能 – VReplicationは各シャードで行われた変更を認識し、他のシャードで主要データ の冗長コピーを使用できるようする • 使用例：リシャーディング、マテリアライズド・ビュー 　　　　リアルタイムロールアップ、データマイグレーション 29

30

31

分散クエリーが返ってくるまでの流れ • VTgateがクエリが複数のVTtableをヒットする必要があると判断すると 分散クエリとして認識 • VTgateはVTtableにクエリを送信し、すべての応答を受け取った後に結 果を組み立て、クライアントに返す 32

33

34

Vitess as a Service http://scoto.hatenablog.com/entry/2019/12/15/115147 申し訳ございません。スライド化間に合いませんでした。 35

Fin. 36

負荷分散による性能向上 37 G LoadBalancer Sysbench G Vtgate Mas ter Read Only Replica tablet 1000000 フル・ス キャン クエリー 万件のテーブルデータ SQL

負荷分散による性能向上 38 G LoadBalancer Sysbench M Ro Rp G Vtgate M Ro Rp M Ro Rp M Ro Rp フル・ス キャン クエリー 万件のテーブルデータを 分割（約 万件 ） SQL

負荷分散による性能向上：結果 • Shardを分割したことでCPU、I/O負荷が分散され 4倍 (苦しい) 近く実行時間が高速化 39 初回 最速 3回平均 NonShard 2.29 2.10 2.22 Shard 4 0.66 0.57 0.62 3.46 倍 3.68 倍 3.58 倍 Vitess 3.0を使用

スケーラビリティ • Shardを追加することで1秒間に処理できるのトランザクション数（TPS） がスケールするか確認 40 G LoadBalancer Sysbench G Vtgate Mas ter Read Only Replica tablet

スケーラビリティ • Shardを追加することで1秒間に処理できるのトランザクション数（TPS） がスケールするか確認 41 G LoadBalancer Sysbench M Ro Rp G Vtgate M Ro Rp M Ro Rp M Ro Rp

スケーラビリティ：結果 • Shardの数を増やすことでTPSがスケールすることを確認 TPS Shard数 Vitess 3.0を使用