Kubernetesが超強力な分散RDBに！ Vitessの真価を大検証してみた。 @hhiroshell / @cotoc 1

自己紹介 2 • 早川 博（はやかわ ひろし） • 日本オラクルのソリューション エンジニア – Container / Kubernetes – Microservices / DevOps – Java SE/EE @hhiroshell • 茂 こと（しげる こと） • 日本オラクルのソリューション エンジニア – Oracle Database – Docker/Kubernetes 4ヶ月くらい – Vitess/MySQL 3週間くらい @cotoc

コミュニティ活動：Cloud Native Developers JP • 本イベントのサポートコミュニティとしてお手伝いさせ ていただいています • 本発表はコミュニティ活動の成果を元にしたものです 3 ※ https://containerdays.jp

お品書き • Vitessとは • Vitessのアーキテクチャ • Vitessのシャーディングの仕組み • 検証してみた！ 4

お品書き • Vitessとは • Vitessのアーキテクチャ • Vitessのシャーディングの仕組み • 検証してみた！ 5

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

7

• パフォーマンス – パフォーマンスを最適化す るための機能の提供 – トランザクション管理、全 体のスループットを最適化 • データベースの保護 – 潜在的に問題のあるクエリ ーからの保護 8 • クラスター管理・監視 – WebベースのGUI、マスター 管理ツール – パフォーマンスの監視・ 診断・分析ツールの提供 • MySQLとの互換性 – MySQLのクエリとの互換性 MySQLクライアントからそ のまま利用可能 – （一部非互換あり） Vitessの特徴

お品書き • Vitessとは • Vitessのアーキテクチャ • Vitessのシャーディングの仕組み • 検証してみた！ 9

Vitessのアーキテクチャ 10 app server app server app server batch job Vitess Topology VTctld App VTgate VTtablet mysqld Query

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

Vitessの主要な構成要素 • tablet – mysqldとVTtabletをセットでこう呼ぶ – tabletはmaster/replica/rdonlyなどのタイプが 割り当てられる • VTtablet – MySQLデータベースの前に置かれているプロ キシサーバー – MySQLインスタンスと1:1、有害なクエリか らMySQLを保護 12 VTtablet mysqld tablet

Vitessの主要な構成要素 • VTctld – Vitessクラスタに対する管理操作を受け付けるHTTPサーバー – GUIも提供 • VTctl – Vitessクラスタを管理するためのコマンドラインツール 13

Vitess in Kubernetes 14 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 PV PV

サポートされているクライアント • gRPCのコネクタと、従来のMySQLクライアントをサポート • 現在提供されているコネクタ – Java：JDBC-compatible interface – Go：database/sql driver – Python：PEP 249-compatible interface • 中の人によると、今はMySQLクライアントの利用を推奨とのこと 15 ※ vitess.slack.com

お品書き • Vitessとは • Vitessのアーキテクチャ • Vitessのシャーディングの仕組み • 検証してみた！ 16

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

テーブルのシャーディング 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 { }

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

シャーディングのロジック 20 Shard -40 40-80 80-C0 C0- Keyspace ID … 7F FF FF FF 80 00 00 00 80 00 00 01 … 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 テーブル Vindex { } • Vindexを付与した列からKeyspace IDを算出（Hashなど複数種のサポート） • Keyspace IDとShardとのマッピングに従ってデータを配置

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

お品書き • Vitessとは • Vitessのアーキテクチャ • Vitessのシャーディングの仕組み • 検証してみた！ 22

1. 負荷分散による性能向上 – 複数のtablet（Shard）を跨るク エリー（マルチシャードクエリ ー）を実行 – シャーディング前後でクエリー の実行時間を確認、比較 2. スケーラビリティ – OLTPクエリーを実行 – Shardを追加することで秒間処理 できるトランザクション数 （TPS）がスケールするか確認 23 検証してみた！

1. 負荷分散による性能向上 – 複数のtablet（Shard）を跨るク エリー（マルチシャードクエリ ー）を実行 – シャーディング前後でクエリー の実行時間を確認、比較 2. スケーラビリティ – OLTPクエリーを実行 – Shardを追加することで秒間処理 できるのトランザクション数 （TPS）がスケールするか確認 24 検証してみた！

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

負荷分散による性能向上 • 複数tablet（Shard）を跨るクエリーを実行 26 G LoadBalancer Sysbench M Ro Rp G Vtgate M Ro Rp M Ro Rp M Ro Rp フル・ス キャン クエリー 100万件のテーブルデータを 4分割（約25万件/Shard） SQL

負荷分散による性能向上：準備 • テーブル定義 • VSchema定義（json） 27 CREATE TABLE messages ( page BIGINT(20) UNSIGNED, time_created_ns BIGINT(20) UNSIGNED, message VARCHAR(10000), PRIMARY KEY (page, time_created_ns) ) ENGINE=InnoDB { "sharded": true, "vindexes": { "hash": { "type": "hash" }}, "tables": { "messages": { "column_vindexes": [ { "column": "page", "name": "hash" }]}}}

負荷分散による性能向上：準備 • データ増幅 • クエリー 28 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); > select * from messages where message like '%abc%’; +----+-------------+----------+------------+- | id | select_type | table | partitions | +----+-------------+----------+------------+- | 1 | SIMPLE | messages | NULL | +----+-------------+----------+------------+-

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

おまけ）Life of a Query 30

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

1. 負荷分散による性能向上 – 複数のtablet（Shard）を跨るク エリー（マルチシャードクエリ ー）を実行 – シャーディング前と後でクエリ ーの実行時間を確認、比較 2. スケーラビリティ – OLTPクエリーを実行 – Shardを追加することで1秒間に 処理できるのトランザクション 数（TPS）がスケールするか確 認 32 検証してみた！

LoadBalancer ベンチマーク ツール Mas ter Read Only Replica tablet スケーラビリティ 33 VTtablet G Vtgate G Vtgate G Vtgate

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

ベンチマークツール • sysbench 1.0.15 – https://github.com/akopytov/sysbench – sysbenchはデータベースのベンチマークとして使用されるツール – Luaスクリプトで独自のベンチマークシナリオを作成することも可能 • なぜこのツールを選択したか – mysqlプロトコルでVTgateにアクセス可能 – 中の人のお墨付き 35

スケーラビリティ：準備 • テーブル – 1表のみ – 9,680件 – id列:Primary Index 36

スケーラビリティ：準備 • Vschemaテーブル – Shardの定義 – Vindexと表、列を指定 • VindexはShardのキーとなる列と 分散ロジックを指定 37 { "sharded": true, "vindexes": { "hash": { "type": "hash" }}, "tables": { "sbtest1": { "column_vindexes": [ { "column": "id", "name": "hash" } ], "columns": [{ "name": "c", "type": "CHAR" }, { "name": "pad", "type": "CHAR“ ---略--- }]}}} 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

スケーラビリティ：準備 • クエリーは2パターン用意 – 1. Simple：索引を利用したシンプルなクエリーのみ – 2. Default：1. SimpleクエリーとWhere句にbetweenを含むクエリー • oltp_read_only.luaスクリプトを使用 • betweenはシャードをまたがって処理される 38 > select c from sbtest1 where id = :vtg1 > select c from sbtest1 where id = :vtg1 > select distinct c,​ weight_string(c)​ from sbtest1 where id between :vtg1 and :vtg2 order by c asc > select SUM(k)​ from sbtest1 where id between :vtg1 and :vtg2 > select c from sbtest1 where id between :vtg1 and :vtg2 > select c,​ weight_string(c)​ from sbtest1 where id between :vtg1 and :vtg2 order by c asc 1. Simple 2. Default

スケーラビリティ：準備 • CPU使用率はmysqlが動作する コンテナに対して制御 • CPUのlimitsを100mに指定 – 1000m＝1vCPU – 100m = 0.1vCPU 39 ---略--- spec: containers: - name: mysql image: {{vitess_image}} volumeMounts: - name: syslog mountPath: /dev/log - name: vtdataroot mountPath: /vt/vtdataroot resources: requests: memory: "200Mi" limits: cpu: "100m" ---略--- 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 vttablet-pod-template.yaml

スケーラビリティ：結果 • Shardの数を増やすことでTPSがスケールすることを確認 12.87 15.59 16.81 25.21 55.99 74.69 0 10 20 30 40 50 60 70 80 1 2 4 default simple TPS tablet

エラーとの戦い… • ERROR 1105 (HY000): VTgate: http://VTgate-test-bzqjf:15001/: syntax error at position 127 – VTgateはすべてのSQLをサポートしている訳ではない（諦める） • UnsupportedなSQLはこちらを確認 • rpc error: … Row count exceeded 10000 (errno 0) – Vttable.yaml に -queryserver-config-max-result-size 1999999999 を設定 – またはクエリを実行する前に set workload=‘olap’ を設定 • rpc error: … Too many connections (errno 1040) – MySQLの max_connetionsを適当な量に増やす※デフォルトは 100 • その他… 41

Vitess Slack • https://vitess.slack.com – PlanetScale CTO @sougouを中心に技術的な相談に乗ってくれる • 今回かなり相談に乗っていただきました 42 https://planetscale.com/

Vitessと触れ合った感想 43 • Vitessを使いこなすうえで必要なスキルセット（独断と偏見） – スキーマ（シャーディング）設計 – MySQLの管理、チューニングスキル – Kubernetesの基本的な知識 – Goのコードを読めると尚良い – 諦めない心 • Vitessコマンドは独特なため慣れが必要 • Vite友募集中!!!! 0 1 2 3 4 5 Vitess MySQL(DBA/ Tun) Kubernetes Go App/Schema

Fin. 44