Save 37% off PRO during our Black Friday Sale! »

Vitess のパフォーマンスと運用性を検証してみた

6675c7b71b99f464ee9f504c6435e941?s=47 cotoc
October 04, 2018

Vitess のパフォーマンスと運用性を検証してみた

結局Kubernetesのストレージどうするの? - cndjp第8回勉強会
Vitess に入門したい方へ

6675c7b71b99f464ee9f504c6435e941?s=128

cotoc

October 04, 2018
Tweet

Transcript

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

  2. 自己紹介 • しげる こと(@cotoc) • 日本オラクル株式会社 • プリセールス・エンジニア – Oracle

    Database 数年 – Docker/Kubernetes 2ヶ月くらい – Vitess/MySQL 2週間くらい • わたしとVitessの出会い – 会社の先輩の紹介 • まずはお友達から 2
  3. 内容 • Vitessとは • Architecture • Sharding • 検証してみた –

    Backup/Restore – Performance 3
  4. Vitessとは 4

  5. Vitessとは • VitessはシャーディングによるMySQLの水平スケーリ ングのためのデータベースクラスタリングシステム – https://vitess.io • YouTubeによって開発された技術 – First

    Commit in 2010 – In Production at YouTube since 2011 • CNCFの16番目にホストされたプロジェクト – 現在は Incubating • 今回はKubernetes上で動作させる前提で調査、検証 5
  6. 特徴 • Sharding – Live ReshardingやSharding Schemeのカスタムが可能 • Performance –

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

  8. Architecture 8 app server app server app server batch job

    Vitess Topology VTctld App VTgate VTtablet mysqld Query
  9. 用語 • Topology – サーバー、シャーディング・スキームなどの構成情報を管理する メタデータストア • Kubernetesではetcdを利用 • VTgate

    – アプリケーションからのクエリを正しいVTtabletにルーティングし、 統合された結果をクライアントに返す軽量なプロキシサーバー • アプリケーションはデータの配置(Shard)を意識することなく、 VTgateに対して処理を投げるだけ 9
  10. 用語 • VTctld – Vitessクラスタに対する管理操作を受け付けるHTTPサーバー • GUIも提供 • VTctl –

    Vitessクラスタを管理するためのコマンドラインツール • VTtablet – MySQLデータベースの前に置かれているプロキシサーバー • MySQLインスタンスと 1:1、有害なクエリからMySQLを保護 • tablet – mysqldとVTtabletの組み合わせ • tabletはmaster/replica/rdonlyなどのタイプが割り当てられる 10
  11. 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
  12. サポートされているクライアント • クライアントとVitess間、Vitessサーバー間の通信にgRPCを使用 – 現在提供されているコネクタ • Java – JDBC-compatible interface

    • Go – database/sql driver • Python – PEP 249-compatible interface • mysqlクライアントから直接接続することも可能 SQL Parserが間に入るため、全てのSQLを実行できるわけではなさそう 12
  13. Sharding 13

  14. Sharding • Shardingとは – 2つ以上のデータベースにデータを分割し格納すること • Shardingのメリット – Shardを追加することでスケールアウト –

    負荷分散によるパフォーマンス向上 • Vitessは2種類のShardingをサポート – Vertical Sharding(垂直): 非Sharded Keyspaceから別のKeyspaceにテーブルを移動 – Horizontal Sharding(水平):Sharded KeyspaceからShardを分割またはマージ • 手動か自動で設定可能 14
  15. 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
  16. 用語 • Keyspace – シャードを複数まとめた論理的なデータベース • アプリケーションからは単一のデータベースとして見える • VSchema –

    テーブルが複数のShard間でどのように編成されているかに関するメタデータ • 表、Vindex を定義 • アプリケーションからクエリが発行されると適切なShardにルーティングするための情報 16
  17. 用語 • Vindex – キーとなる列とKeyspace IDの算出ロジックを定義 • 算出ロジックは選択可能 – 例:Hash/Functional/Lookup

    Unique/Lookup NonUnique • テーブルは複数のVindexを持つことができる – プライマリVindex:Shard分割に使用する一意な列を指定(Sharding Key) – セカンダリVindex:プライマリVindexを使用しないWHERE句の最適化を提供(クロスシャード Index) • Keypsace ID – 特定の行がどのShardに存在するかを決定・特定するために使用される値 • Vitessが内部的に使用 17
  18. 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
  19. Shardingの手順(手動) • VSchemaの定義 • 新しいShardのtabletの立ち上げ • 新しいShard毎に最初のマスターを選択 • オリジナルShardからスキーマをコピー •

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

    ワークフローを作成、実行 – GUIで作成 – VTctlで作成 20
  21. 新しいShardに切り替える時のダウンタイムは? 21 出典:https://vitess.io/resources/openworld-2015-vitess.pdf

  22. • オリジナルShardからスキーマをコピー • オリジナルShardからデータをコピー(VTworkerがバッチプロセスを実行) – ※この間オリジナルRonly Shardへのレプリケーションが停止 • フィルタリングされたレプリケーションを適用(追いつき処理) •

    データの整合性をチェック • 新しいShardに切り替える • オリジナルShardの削除 • 上記手順をワークフローとして登録すると自動(One-Click)で実行可能 Live ReShardingの手順(手動) 22 更新処理停止 (未確認)
  23. 検証してみた 23

  24. 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
  25. Restore • 既存のtabletがダウンし復旧すると、最新のバックアップから自動的 にリストアされマスタからの差分のレプリケーションを実行 • ノードを追加した場合にも自動的にバックアップからリストアし、 マスタからの差分をレプリケーション • 手動でリストアする場合にはVTctlコマンドを利用可能 –

    VTctl RestoreFromBackup <tablet alias> • 常に最新のバックアップでリストアされるため、適当な時点のバックアップを指定して リストアする方法は無さそう? 25
  26. 検証内容 • バックアップ・リストア – バックアップを取得した状態で、VTtablet(Master/Replica/Ronly)全てを削除、 VTTabletを再作成したらどうなる? • MySQLのデータはPodの emptyDirに配置 –

    emptyDirはPod用の一時的なディスク領域のため、Podを削除したらデータは消えてしまう • 新たにVTtabletを起動後、自動的に最新のバックアップから リストアされデータの復元を確認 26
  27. 検証内容 • 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
  28. テーブル定義/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. データ増幅方法/クエリー • データ増幅 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)
  30. クエリーが返ってくるまでの流れ • VTgateがクエリが複数のVTtableをヒットする必要があると判断する と分散クエリとして認識 • VTgateはVTtableにクエリを送信し、すべての応答を受け取った後に 結果を組み立て、クライアントに返す 30

  31. Life of a Query 31

  32. 結果 初回 最速 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
  33. 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. 本当はやりたかったこと • オンライントランザクションのスケーリング・テスト – またどこかで、できたら頑張ります 34 出典:https://vitess.io/resources/openworld-2015-vitess.pdf

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