$30 off During Our Annual Pro Sale. View Details »

Building Distributed-SQL with Kubernetes

tzkoba
April 18, 2020

Building Distributed-SQL with Kubernetes

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

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

tzkoba

April 18, 2020
Tweet

More Decks by tzkoba

Other Decks in Technology

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
    従来手法の調査:(3) 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