Upgrade to Pro — share decks privately, control downloads, hide ads and more …

20181204_Vitess_JKD_day1.pdf

cotoc
December 04, 2018

 20181204_Vitess_JKD_day1.pdf

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

cotoc

December 04, 2018
Tweet

More Decks by cotoc

Other Decks in Technology

Transcript

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

    Container / Kubernetes – Microservices / DevOps – Java SE/EE @hhiroshell • 茂 こと(しげる こと) • 日本オラクルのソリューション エンジニア – Oracle Database – Docker/Kubernetes 4ヶ月くらい – Vitess/MySQL 3週間くらい @cotoc
  2. Vitessとは • シャーディングによるMySQLの水平スケーリング のためのデータベース・クラスタリングシステム • YouTubeによって開発された技術 – First Commit in

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

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

    – 潜在的に問題のあるクエリ ーからの保護 8 • クラスター管理・監視 – WebベースのGUI、マスター 管理ツール – パフォーマンスの監視・ 診断・分析ツールの提供 • MySQLとの互換性 – MySQLのクエリとの互換性 MySQLクライアントからそ のまま利用可能 – (一部非互換あり) Vitessの特徴
  5. Vitessのアーキテクチャ 10 app server app server app server batch job

    Vitess Topology VTctld App VTgate VTtablet mysqld Query
  6. Vitessの主要な構成要素 • tablet – mysqldとVTtabletをセットでこう呼ぶ – tabletはmaster/replica/rdonlyなどのタイプが 割り当てられる • VTtablet

    – MySQLデータベースの前に置かれているプロ キシサーバー – MySQLインスタンスと1:1、有害なクエリか らMySQLを保護 12 VTtablet mysqld tablet
  7. 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
  8. サポートされているクライアント • gRPCのコネクタと、従来のMySQLクライアントをサポート • 現在提供されているコネクタ – Java:JDBC-compatible interface – Go:database/sql

    driver – Python:PEP 249-compatible interface • 中の人によると、今はMySQLクライアントの利用を推奨とのこと 15 ※ vitess.slack.com
  9. シャーディング • シャーディングとは – 2つ以上のデータベースにデータを分割して格納すること – Shardを追加することでデータベースをスケールアウトし、パフォーマン スの向上を狙う技術 • Vitessは2種類のShardingをサポート

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

    複数Shardにまたがるデータの配置を表現するメタデータ – アプリケーションからクエリが発行されたときに、適切なShardにルーテ ィングするための情報 • VTworker – シャーディングの分割処理を行うワークロード 19
  12. シャーディングのロジック 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とのマッピングに従ってデータを配置
  13. 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
  14. 1. 負荷分散による性能向上 – 複数のtablet(Shard)を跨るク エリー(マルチシャードクエリ ー)を実行 – シャーディング前後でクエリー の実行時間を確認、比較 2.

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

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

    Only Replica tablet VTtablet 1000000 フル・ス キャン クエリー 100万件のテーブルデータ Query
  17. 負荷分散による性能向上 • 複数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
  18. 負荷分散による性能向上:準備 • テーブル定義 • 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" }]}}}
  19. 負荷分散による性能向上:準備 • データ増幅 • クエリー 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 | +----+-------------+----------+------------+-
  20. 1. 負荷分散による性能向上 – 複数のtablet(Shard)を跨るク エリー(マルチシャードクエリ ー)を実行 – シャーディング前と後でクエリ ーの実行時間を確認、比較 2.

    スケーラビリティ – OLTPクエリーを実行 – Shardを追加することで1秒間に 処理できるのトランザクション 数(TPS)がスケールするか確 認 32 検証してみた!
  21. スケーラビリティ:準備 • 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
  22. スケーラビリティ:準備 • クエリーは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
  23. スケーラビリティ:準備 • 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
  24. エラーとの戦い… • 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
  25. Vitessと触れ合った感想 43 • Vitessを使いこなすうえで必要なスキルセット(独断と偏見) – スキーマ(シャーディング)設計 – MySQLの管理、チューニングスキル – Kubernetesの基本的な知識

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