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

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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

4. Vitessとは
   4
   

   View Slide

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

   View Slide

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

   View Slide

7. Architecture
   7
   

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

13. Sharding
    13
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

23. 検証してみた
    23
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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"
    }]}}}
    

    View Slide

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)
    

    View Slide

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

    View Slide

31. Life of a Query
    31
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide