Building Distributed-SQL with Kubernetes

WSA研#6の発表資料です。
前提知識として、以下をあげておきます。

https://qiita.com/tzkoba/items/5316c6eac66510233115
https://qiita.com/tzkoba/items/3e875e5a6ccd99af332f

Transcript

1. Building
   small/large Distributed-SQL
   with Kubernetes
   WSA研#6 , 4/26
   @tzkb
   

   View Slide

2. 2
   最近やっていること
   • Cloud Native Days Tokyo 2019
   “Cloud Native Storageが拓く
   Database on Kubernetesの未来”
   • PGConf.Asia 2019
   “Building PostgreSQL as a Service
   with Kubernetes”
   ＋ ＝∞
   

   View Slide

3. 5
   1. 背景と目的
   2. 従来手法の調査（RDB、NoSQL、NewSQL）
   3. 提案体系
   4. 評価
   5. まとめ
   アジェンダ
   

   View Slide

4. 6
   背景と目的：①データストアの複雑化
   • モノリシック・単一のRDBに限界があり、より拡張性の高いNoSQLが生まれ
   たが、RDBの置換えではなく補完であった。
   • 結果、生まれたのはRDB＋キャッシュ＋NoSQLのような複雑なデータストア。
   Stateless Applications
   M S
   Region1 Region2
   SQL JSON KVS SQL JSON KVS
   

   View Slide

5. 7
   背景と目的：②NewSQLの台頭
   • 複雑なデータストアを使い分け、管理するコストが増大。
   • 統合DBとしての、スケールアウト型SQLデータベースが必要。
   • Spanner: Google’s Globally Distributed Database(2012) が発表され、
   2017年にGoogle Cloud Spannerとしてクラウド利用が可能となった。
   • 国内でもスマホゲームの大量アクセスや、決済トランザクションを捌くプ
   ラットフォームとして利用されている。
   <>
   • SQL準拠、ACIDトランザクションをサポート。
   • 地理分散が可能な、分散型SQLデータベース。
   • 従来RDBが弱いとされた、Writeもスケールアウトが可能。
   

   View Slide

6. 8
   当研究の目的
   <>
   • マルチデータストアはアプリケーションに複雑性を注入。
   • その複雑性は特定ワークロード専用で無駄が生じる。
   • Managed Serviceでなくとも、分散DBは現実的に管理できるか。
   <>
   • 汎用ワークロード向けの、single and real-time source of truthを、
   Kubernetesと分散SQLデータベースの組み合わせで実現する。
   • リソースを自律的に管理しながら、ミッションクリティカルなデータベース
   を動かすプラットフォームを探索する。
   

   View Slide

7. 9
   従来手法の調査：(1)RDBの拡張手法
   • 高可用性は、Master-Slaveの冗長構成で担保し、ログまたはStatementの
   コピーで同期/非同期にデータ複製を行う。
   • 拡張性は、Readではスケール可能（但し非同期時は遅延あり）、Writeでは
   Shardingやマルチマスタ構成で一部スケールするが、制約はある。
   • Pros
   • SQLインターフェース
   • ACIDトランザクション
   • Cons
   • 制限のある拡張性
   • 2PCなど旧式のトランザクション調停手法
   • デフォルトで低い分離レベル、発生する種々のアノマリー
   

   View Slide

8. 10
   従来手法の調査：(2)NoSQLの登場と進化
   • （以下はCassandraを想定）
   • 高可用性は、通常3台以上のデータレプリカを用意することで担保。
   • 拡張性は、Read/Writeともに台数を増やすだけで可能だが、一貫性レベル
   によっては読取り遅延が発生する。
   • Pros
   • 線形スケーラビリティ
   • 一貫性（C）と可用性（A）を調整可能
   • Cons
   • SQL非準拠
   • 完全でない同時実行制御、どんなアノマリーも発生しうる
   

   View Slide

9. 11
   （参考）分散SQLデータベースの類型
   WAL
   M
   S S
   【PostgreSQLのReplication】
   高可用性＋リードレプリカ
   SQL
   【Vitess】
   Shardingによる分散DB
   SQL
   

   View Slide

10. 12
    （参考）マルチマスタの分散データベース
    【Oracle RAC】
    共有Disk型のマルチマスタDB
    【Cassandra】
    Shared NothingのKVS
    KVS
    SQL
    

    View Slide

11. 13
    従来手法の調査：(３) SpannerとOSSクローン
    • Shardingを用いた分散、Raftによるレプリカで高可用性とRead/Write両方
    の拡張性を担保。
    • TrueTime APIにより、高い一貫性と同時実行性を担保(Spanner)。
    • PostgreSQL、MySQLなどのクエリプロトコルに準拠、生産性が高い
    （クローン：CockroachDB、YugaButeDBなど）。
    • Kubernetesを利用したdeployが可能（クローン）。
    • Pros
    • SQLインターフェース
    • 線形スケーラビリティ、地理分散可能な構成
    • Cons
    • 原子時計など特殊なHW依存、ない場合の制約がある
    • センタ間レイテンシなど分散限界は存在。
    

    View Slide

12. 14
    （参考）SpannerクローンとKubernetes
    • Kubernetesによるdeploy・管理が可能な
    tablet3
    tablet2
    tablet1
    tablet4
    tablet2
    tablet1
    tablet4
    tablet3
    tablet1
    tablet4
    tablet3
    tablet1
    Distrbuted
    Txn Mgr
    Distrbuted
    Txn Mgr
    Distrbuted
    Txn Mgr
    Distrbuted
    Txn Mgr
    syscatalog syscatalog syscatalog
    • Spannerに似た分散DB
    でWriteヘビーに強い。
    • PostgreSQLのSQLエン
    ジンと分散ストレージ
    としてのDocDBで構成
    される。
    • データはShardingかつ
    冗長化される。
    

    View Slide

13. 15
    （参考）NewSQLはマルチマスタ構成か
    Tablet2
    Tablet1
    Tablet2
    Table1
    Tablet2
    Tablet1
    Tablet3
    Tablet3
    Tablet3
    • etcdなどは単一Raft
    グループで構成される
    分散KVS。Leaderは
    当然一つ。
    • YugaButeDBなどはマ
    ルチRaftグループで、
    グループ毎にLeader
    が存在。つまりマルチ
    マスタの構成となる
    (hotspot問題はあり)。
    • 分散DBのレプリケーションにはRaft が使われている。
    • Multi Raft Groupによりマルチマスタ構成を実現している。
    

    View Slide

14. 16
    （参考）KubernetesによるDBクラスタの管理
    • PGConf.Asiaで発表された on Kubernetesの例(replication)。
    Productionとして大規模に展開済。
    

    View Slide

15. 17
    提案体系：Kubernetesで管理する小規模・高可用性DB
    • 従来のMaster-Slave型Replicationは、高信頼・低遅延のNWが前提で、
    頻繁に停止・起動が起こりえるコンテナ・オーケストレータには不向き。
    • 分散システムプラットフォーム=Kubernetesで管理されるには、前提が
    異なるSQLデータベースが必要。つまりNewSQL。
    • 小規模から始め、アプリケーションの拡張に応じて線形スケールが可能な
    単一データストア(single and real-time source of truth) を目指す。
    • 従来データベースよりも強く、アノマリーの発生しない（開発が容易な）
    トランザクション分離レベルを採用。
    <>
    • 現実的な時刻同期下での同時実行性（TrueTime APIなし）
    • Amazon Time Sync Serviceのような高精度サービスも存在。
    • Raftプロトコルによるクエリのレイテンシ低下
    

    View Slide

16. 18
    提案体系：構成イメージ
    Stateless Applications
    Region1 Region2
    SQL SQL SQL SQL SQL SQL
    • アプリケーションと同一クラスタで管理可能な、単一IFのデータストア。
    • マルチマスタ、Replication Factor調整による高い可用性。
    • Daemonsetによるdeployで自動スケールを可能とする構成も検討する。
    

    View Slide

17. 19
    評価：方法
    • PostgreSQLのStreaming ReplicationをKubernetes上に構成。Primary1つ、
    Secondary2つを対象とする。 ※リードレプリカは要検討。
    • YugaByteDBのクラスタを構築、RFは3(レプリカが3)及び5で評価を行う。
    • PostgreSQLのベンチマークツール:Pgbenchでは、serialization failureの
    発生時にリトライを行わないため、NewSQLが想定するトランザクション分
    離レベルでの評価が実施できない。
    • そのため、YugaByteのフォークであるysql_benchを用いてPostgreSQL、
    YugaByteDBの双方に負荷をかけ、レイテンシとスループットを取得する。
    • ysql_benchはserialization failureにより生じたエラー数も報告するため、エ
    ラー率にも注目する。
    • また、YugaByteDBのデフォルト分離レベルがSnapshot Isolationであり、
    PostgreSQLはRead Committedである。このレベル調整も必要。
    

    View Slide

18. 20
    評価：結果（暫定）
    • 今回完全な評価は出来ていない。
    • 同一AZ内にYugaByteDBクラスタを構築した際のレイテンシは30ms程度と
    なった。
    評価対象 分離レベル スループット レイテンシ エラー率
    YugaByteDB
    (RF=3)
    SI 111.9 tps 31.2 msec 12.7 %
    YugaByteDB
    (RF=5)
    SI (未取得) (未取得) (未取得)
    PostgreSQL
    (single instance)
    RC 1,439.7 tps 2.8 msec -
    PostgreSQL
    (streaming replication)
    RR (未取得) (未取得) (未取得)
    

    View Slide

19. 21
    まとめ
    • 複雑なマルチデータストアは、アプリケーション開発にも複雑性を招き、
    対応可能なワークロードも絞られる。
    • NewSQL、特にSpannerの成功は、これまでのRDBMSの可用性・拡張性・
    一貫性に対する見方を大きく変える可能性がある。
    • さらにKubernetesと結びつくことで、Managed Serviceでしか恩恵を
    受けられなかった分散SQLデータベースの構築・運用を自動化できるように
    なってきている。
    • 小規模からスタートできる、single and real-time source of truthな
    データストアとして、NewSQL+Kubernetesが実用に耐えうるかを今後も
    検証していく。
    

    View Slide

20. 27
    Questions?
    @tzkb
    @tzkoba
    

    View Slide