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

20181204_Vitess_JKD_day1.pdf

6675c7b71b99f464ee9f504c6435e941?s=47 cotoc
December 04, 2018

 20181204_Vitess_JKD_day1.pdf

JapanContainerDays v18.12
Kubernetesが超強力な分散RDBに vitessの真価を大検証してみた - 早川 博 , 茂 こと(日本オラクル)

6675c7b71b99f464ee9f504c6435e941?s=128

cotoc

December 04, 2018
Tweet

Transcript

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

  2. 自己紹介 2 • 早川 博(はやかわ ひろし) • 日本オラクルのソリューション エンジニア –

    Container / Kubernetes – Microservices / DevOps – Java SE/EE @hhiroshell • 茂 こと(しげる こと) • 日本オラクルのソリューション エンジニア – Oracle Database – Docker/Kubernetes 4ヶ月くらい – Vitess/MySQL 3週間くらい @cotoc
  3. コミュニティ活動:Cloud Native Developers JP • 本イベントのサポートコミュニティとしてお手伝いさせ ていただいています • 本発表はコミュニティ活動の成果を元にしたものです 3

    ※ https://containerdays.jp
  4. お品書き • Vitessとは • Vitessのアーキテクチャ • Vitessのシャーディングの仕組み • 検証してみた! 4

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

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

    2010 – In Production at YouTube since 2011 • CNCFに16番目にホストされたプロジェクト(現 在はIncubating) 6 今回はKubernetes上で動作させる前提で調査・検証しました。 i
  7. 7

  8. • パフォーマンス – パフォーマンスを最適化す るための機能の提供 – トランザクション管理、全 体のスループットを最適化 • データベースの保護

    – 潜在的に問題のあるクエリ ーからの保護 8 • クラスター管理・監視 – WebベースのGUI、マスター 管理ツール – パフォーマンスの監視・ 診断・分析ツールの提供 • MySQLとの互換性 – MySQLのクエリとの互換性 MySQLクライアントからそ のまま利用可能 – (一部非互換あり) Vitessの特徴
  9. お品書き • Vitessとは • Vitessのアーキテクチャ • Vitessのシャーディングの仕組み • 検証してみた! 9

  10. Vitessのアーキテクチャ 10 app server app server app server batch job

    Vitess Topology VTctld App VTgate VTtablet mysqld Query
  11. Vitessの主要な構成要素 • VTgate – アプリケーションからのクエリを正しいVTtabletに ルーティングし、統合された結果をクライアントに 返す軽量なプロキシサーバー • アプリケーションはデータの配置(Shard)を意識するこ となく、VTgateに対して処理を投げるだけ

    • Topology – サーバー、シャーディング・スキームなどの構成情 報を管理するメタデータストア • Kubernetesではetcdを利用 11 Topology VTgate
  12. Vitessの主要な構成要素 • tablet – mysqldとVTtabletをセットでこう呼ぶ – tabletはmaster/replica/rdonlyなどのタイプが 割り当てられる • VTtablet

    – MySQLデータベースの前に置かれているプロ キシサーバー – MySQLインスタンスと1:1、有害なクエリか らMySQLを保護 12 VTtablet mysqld tablet
  13. Vitessの主要な構成要素 • VTctld – Vitessクラスタに対する管理操作を受け付けるHTTPサーバー – GUIも提供 • VTctl –

    Vitessクラスタを管理するためのコマンドラインツール 13
  14. 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
  15. サポートされているクライアント • gRPCのコネクタと、従来のMySQLクライアントをサポート • 現在提供されているコネクタ – Java:JDBC-compatible interface – Go:database/sql

    driver – Python:PEP 249-compatible interface • 中の人によると、今はMySQLクライアントの利用を推奨とのこと 15 ※ vitess.slack.com
  16. お品書き • Vitessとは • Vitessのアーキテクチャ • Vitessのシャーディングの仕組み • 検証してみた! 16

  17. シャーディング • シャーディングとは – 2つ以上のデータベースにデータを分割して格納すること – Shardを追加することでデータベースをスケールアウトし、パフォーマン スの向上を狙う技術 • Vitessは2種類のShardingをサポート

    – Vertical Sharding(垂直): テーブル毎に複数のデータベースに分けて格納 – Horizontal Sharding(水平): 1つのテーブルを複数のShardに分割し、複数の データベースに分けて格納 17
  18. テーブルのシャーディング 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. シャーディングされたデータベースの構成 • Keyspace – Shardを複数まとめた論理的なデータベース – アプリケーションからは1つのMySQLデータベースとして見える • VSchema –

    複数Shardにまたがるデータの配置を表現するメタデータ – アプリケーションからクエリが発行されたときに、適切なShardにルーテ ィングするための情報 • VTworker – シャーディングの分割処理を行うワークロード 19
  20. シャーディングのロジック 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とのマッピングに従ってデータを配置
  21. 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
  22. お品書き • Vitessとは • Vitessのアーキテクチャ • Vitessのシャーディングの仕組み • 検証してみた! 22

  23. 1. 負荷分散による性能向上 – 複数のtablet(Shard)を跨るク エリー(マルチシャードクエリ ー)を実行 – シャーディング前後でクエリー の実行時間を確認、比較 2.

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

    スケーラビリティ – OLTPクエリーを実行 – Shardを追加することで秒間処理 できるのトランザクション数 (TPS)がスケールするか確認 24 検証してみた!
  25. 負荷分散による性能向上 25 G LoadBalancer Sysbench G Vtgate Mas ter Read

    Only Replica tablet VTtablet 1000000 フル・ス キャン クエリー 100万件のテーブルデータ Query
  26. 負荷分散による性能向上 • 複数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
  27. 負荷分散による性能向上:準備 • テーブル定義 • 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. 負荷分散による性能向上:準備 • データ増幅 • クエリー 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 | +----+-------------+----------+------------+-
  29. 分散クエリーが返ってくるまでの流れ • VTgateがクエリが複数のVTtableをヒットする必要があると判断す ると分散クエリとして認識 • VTgateはVTtableにクエリを送信し、すべての応答を受け取った後 に結果を組み立て、クライアントに返す 29

  30. おまけ)Life of a Query 30

  31. 負荷分散による性能向上:結果 • 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 倍
  32. 1. 負荷分散による性能向上 – 複数のtablet(Shard)を跨るク エリー(マルチシャードクエリ ー)を実行 – シャーディング前と後でクエリ ーの実行時間を確認、比較 2.

    スケーラビリティ – OLTPクエリーを実行 – Shardを追加することで1秒間に 処理できるのトランザクション 数(TPS)がスケールするか確 認 32 検証してみた!
  33. LoadBalancer ベンチマーク ツール Mas ter Read Only Replica tablet スケーラビリティ

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

    Ro Rp M Ro Rp M Ro Rp G Vtgate G Vtgate G Vtgate ベンチマーク ツール
  35. ベンチマークツール • sysbench 1.0.15 – https://github.com/akopytov/sysbench – sysbenchはデータベースのベンチマークとして使用されるツール – Luaスクリプトで独自のベンチマークシナリオを作成することも可能

    • なぜこのツールを選択したか – mysqlプロトコルでVTgateにアクセス可能 – 中の人のお墨付き 35
  36. スケーラビリティ:準備 • テーブル – 1表のみ – 9,680件 – id列:Primary Index

    36
  37. スケーラビリティ:準備 • 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
  38. スケーラビリティ:準備 • クエリーは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
  39. スケーラビリティ:準備 • 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
  40. スケーラビリティ:結果 • 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
  41. エラーとの戦い… • 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
  42. Vitess Slack • https://vitess.slack.com – PlanetScale CTO @sougouを中心に技術的な相談に乗ってくれる • 今回かなり相談に乗っていただきました

    42 https://planetscale.com/
  43. Vitessと触れ合った感想 43 • Vitessを使いこなすうえで必要なスキルセット(独断と偏見) – スキーマ(シャーディング)設計 – MySQLの管理、チューニングスキル – Kubernetesの基本的な知識

    – Goのコードを読めると尚良い – 諦めない心 • Vitessコマンドは独特なため慣れが必要 • Vite友募集中!!!! 0 1 2 3 4 5 Vitess MySQL(DBA/ Tun) Kubernetes Go App/Schema
  44. Fin. 44