のパフォーマンスと運用性を 検証してみた @cotoc 結局Kubernetesのストレージどうするの？ - cndjp第8回勉強会

自己紹介 • しげる こと（@cotoc） • 日本オラクル株式会社 • プリセールス・エンジニア – Oracle Database 数年 – Docker/Kubernetes 2ヶ月くらい – Vitess/MySQL 2週間くらい • わたしとVitessの出会い – 会社の先輩の紹介 • まずはお友達から 2

内容 • Vitessとは • Architecture • Sharding • 検証してみた – Backup/Restore – Performance 3

Vitessとは 4

Vitessとは • VitessはシャーディングによるMySQLの水平スケーリ ングのためのデータベースクラスタリングシステム – https://vitess.io • YouTubeによって開発された技術 – First Commit in 2010 – In Production at YouTube since 2011 • CNCFの16番目にホストされたプロジェクト – 現在は Incubating • 今回はKubernetes上で動作させる前提で調査、検証 5

特徴 • Sharding – Live ReshardingやSharding Schemeのカスタムが可能 • Performance – パフォーマンスを最適化するための機能の提供 • トランザクション管理、全体のスループットを最適化 • Database protection – 潜在的に問題のあるクエリーから防御 • Cluster management – Webベースの管理GUI、マスター管理ツール • Monitoring – データベースのパフォーマンスを監視/診断/分析可能なツールの提供 6

Architecture 7

Architecture 8 app server app server app server batch job Vitess Topology VTctld App VTgate VTtablet mysqld Query

用語 • Topology – サーバー、シャーディング・スキームなどの構成情報を管理する メタデータストア • Kubernetesではetcdを利用 • VTgate – アプリケーションからのクエリを正しいVTtabletにルーティングし、 統合された結果をクライアントに返す軽量なプロキシサーバー • アプリケーションはデータの配置（Shard）を意識することなく、 VTgateに対して処理を投げるだけ 9

用語 • VTctld – Vitessクラスタに対する管理操作を受け付けるHTTPサーバー • GUIも提供 • VTctl – Vitessクラスタを管理するためのコマンドラインツール • VTtablet – MySQLデータベースの前に置かれているプロキシサーバー • MySQLインスタンスと 1：1、有害なクエリからMySQLを保護 • tablet – mysqldとVTtabletの組み合わせ • tabletはmaster/replica/rdonlyなどのタイプが割り当てられる 10

Vitess in Kubernetes 11 pod pod app server pod etcd VTgate service etcd service pod pod VTctld VTctld service Admin pod batch job VTgate pod Shard 1 Shard 2 tablet tablet Master Replica Ronly Master Replica Ronly

サポートされているクライアント • クライアントとVitess間、Vitessサーバー間の通信にgRPCを使用 – 現在提供されているコネクタ • Java – JDBC-compatible interface • Go – database/sql driver • Python – PEP 249-compatible interface • mysqlクライアントから直接接続することも可能 SQL Parserが間に入るため、全てのSQLを実行できるわけではなさそう 12

Sharding 13

Sharding • Shardingとは – 2つ以上のデータベースにデータを分割し格納すること • Shardingのメリット – Shardを追加することでスケールアウト – 負荷分散によるパフォーマンス向上 • Vitessは2種類のShardingをサポート – Vertical Sharding(垂直): 非Sharded Keyspaceから別のKeyspaceにテーブルを移動 – Horizontal Sharding(水平)：Sharded KeyspaceからShardを分割またはマージ • 手動か自動で設定可能 14

Horizontal Sharding例：Range-Based Sharding 15 Shard -40 40-80 80-C0 C0- Keyspace ID … 7F FF FF FF 80 00 00 00 80 00 00 01 … { "sharded": true, "vindexes": { "hash": { "type": "hash" }}, "tables": { “X”: { "column_vindexes": [ { “column”: “A列", "name": "hash" }]}}} VSchema.json 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 A列 B列 … … 1234 1235 1236 … … … 出典：https://vitess.io/resources/openworld-2015-vitess.pdf ※ Shardの名前はKey Range（キー範囲）の開始と終了 16進数で表示されハイフンで区切られる Hash X表 Vindex

用語 • Keyspace – シャードを複数まとめた論理的なデータベース • アプリケーションからは単一のデータベースとして見える • VSchema – テーブルが複数のShard間でどのように編成されているかに関するメタデータ • 表、Vindex を定義 • アプリケーションからクエリが発行されると適切なShardにルーティングするための情報 16

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

Sharding Schemes 18 Shard -80 Shard 80- A列 B列 C列 … … … 1235 20181004 yyy 1236 20181005 zzz … … … Replica Master Ronly Replica Master Ronly A列 B列 C列 … … … 1234 20181003 xxx … … … VTworker(Pod) A列 B列 C列 … … … 1234 20181003 xxx 1235 20181004 yyy 1236 20181005 zzz … … … VTtablet mysqld Ronly Tablet Shard 0 VSchema Shardingのルール を定義 Topology(etcd) Keyspace

Shardingの手順（手動） • VSchemaの定義 • 新しいShardのtabletの立ち上げ • 新しいShard毎に最初のマスターを選択 • オリジナルShardからスキーマをコピー • オリジナルShardからデータをコピー（VTworkerがバッチプロセスを実行） – ※ この間オリジナルRonly Shardへのレプリケーションが停止 • データの整合性をチェック（VTworkerがバッチプロセスを実行） • 新しいShardに切り替える • オリジナルShardの削除 19

Shardingの手順（自動） • VSchemaの定義 • 新しいShardのtabletの立ち上げ • 新しいShardごとに最初のマスターを選択 • VTworkerを起動 • ワークフローを作成、実行 – GUIで作成 – VTctlで作成 20

新しいShardに切り替える時のダウンタイムは？ 21 出典：https://vitess.io/resources/openworld-2015-vitess.pdf

• オリジナルShardからスキーマをコピー • オリジナルShardからデータをコピー（VTworkerがバッチプロセスを実行） – ※この間オリジナルRonly Shardへのレプリケーションが停止 • フィルタリングされたレプリケーションを適用（追いつき処理） • データの整合性をチェック • 新しいShardに切り替える • オリジナルShardの削除 • 上記手順をワークフローとして登録すると自動（One-Click）で実行可能 Live ReShardingの手順（手動） 22 更新処理停止 （未確認）

検証してみた 23

Backup • クラウド上でKubernetesを利用している場合、クラウドストレージに バックアップを取得 – 現在提供されているVitess BackupStorageプラグインインタフェース • A network-mounted path (e.g. NFS)、Google Cloud Storage、Amazon S3、Ceph • バックアップ取得コマンド – rdonlyのShard毎のtabletに対しバックアップを取るように指示 • tabletはレプリケーションを一時停止し一貫性のあるスナップショットを作成 24 $ ./kVTctl.sh Backup test-0000000104 Starting port forwarding to VTctld... $ ./kVTctl.sh ListBackups test_keyspace/0 Starting port forwarding to VTctld... 2018-09-29.180222.test-0000000104

Restore • 既存のtabletがダウンし復旧すると、最新のバックアップから自動的 にリストアされマスタからの差分のレプリケーションを実行 • ノードを追加した場合にも自動的にバックアップからリストアし、 マスタからの差分をレプリケーション • 手動でリストアする場合にはVTctlコマンドを利用可能 – VTctl RestoreFromBackup • 常に最新のバックアップでリストアされるため、適当な時点のバックアップを指定して リストアする方法は無さそう？ 25

検証内容 • バックアップ・リストア – バックアップを取得した状態で、VTtablet（Master/Replica/Ronly）全てを削除、 VTTabletを再作成したらどうなる？ • MySQLのデータはPodの emptyDirに配置 – emptyDirはPod用の一時的なディスク領域のため、Podを削除したらデータは消えてしまう • 新たにVTtabletを起動後、自動的に最新のバックアップから リストアされデータの復元を確認 26

検証内容 • Sharding前後のパフォーマンス – フル・スキャンするようなクエリーを実行、どっちがはやい？ 27 • NonShard • Shard 4 VTgate VTgate 0 -40 40-80 80-c0 C0- Client Client 1,000,000 249,643 VTtablet VTtablet VTtablet VTtablet VTtablet 250,169 250,387 249,801

テーブル定義/VSchema定義 • テーブル定義 28 CREATE TABLE messages ( page BIGINT(20) UNSIGNED, time_created_ns BIGINT(20) UNSIGNED, message VARCHAR(10000), PRIMARY KEY (page, time_created_ns) ) ENGINE=InnoDB • VSchema定義 { "sharded": true, "vindexes": { "hash": { "type": "hash" }}, "tables": { "messages": { "column_vindexes": [ { "column": "page", "name": "hash" }]}}}

データ増幅方法/クエリー • データ増幅 29 create procedure insert_messages(in x int) begin declare i int; set i = 0; set i = i + 1; INSERT INTO messages (page, time_created_ns, message) VALUES ( i, i+cast(now() as datetime) , SUBSTRING(MD5(RAND()), 1, 10)); end while; end ; call insert_messages(1000000); • 複数のShardにヒットするクエ リー(Scatter Query) select * from messages where message like '%abc%'; +----+-------------+----------+------------+------+---------------+------+---------+------+--------+----------+------- | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+----------+------------+------+---------------+------+---------+------+--------+----------+------- | 1 | SIMPLE | messages | NULL | ALL | NULL | NULL | NULL | NULL | 227016 | 11.11 | Using +----+-------------+----------+------------+------+---------------+------+---------+------+--------+----------+------- 1 row in set (0.70 sec)

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

Life of a Query 31

結果 初回 最速 3回平均 NonShard 2.29 s 2.10 s 2.22 s Shard 4 0.66 s 0.57 s 0.62 s 3.46 倍 3.68 倍 3.58 倍 32

Tips • データ増幅をVitess上で実施すると関数がシンタックス・エラー – VTgateはすべてのSQLをサポートしている訳ではない • ERROR 1105 (HY000): VTgate: http://VTgate-test-bzqjf:15001/: syntax error at position 127 • 別のMySQLインスタンスを用意しデータ増幅、それをexport/Import • SplitClone実行時に内部的に発行されるSELECTがエラー – 1．rpc error: … Row count exceeded 10000 (errno 0) • VTtable に -queryserver-config-max-result-size 1999999999 を設定 ※デフォルトは10,000 – 2．rpc error: … Too many connections (errno 1040) • MySQLの max_connetionsを10000に増やす（実際どのくらい必要だったかは不明） ※デフォルトは 100 • Running Vitess on Kubernetesのサンプルセットアップスクリプトにはmysqlユーザーのパスワード がハードコーディングされている（変えよう！） – User=mysql / Password=mysql_password 33

本当はやりたかったこと • オンライントランザクションのスケーリング・テスト – またどこかで、できたら頑張ります 34 出典：https://vitess.io/resources/openworld-2015-vitess.pdf

ご清聴ありがとうございました。