Building Distributed-SQL with Kubernetes

Cd891a89dfec6ca7bd278b5f5bd87c90?s=47 tzkoba
April 18, 2020

Building Distributed-SQL with Kubernetes

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

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

Cd891a89dfec6ca7bd278b5f5bd87c90?s=128

tzkoba

April 18, 2020
Tweet

Transcript

  1. 2.

    2 最近やっていること • Cloud Native Days Tokyo 2019 “Cloud Native

    Storageが拓く Database on Kubernetesの未来” • PGConf.Asia 2019 “Building PostgreSQL as a Service with Kubernetes” + =∞
  2. 5.

    7 背景と目的:②NewSQLの台頭 • 複雑なデータストアを使い分け、管理するコストが増大。 • 統合DBとしての、スケールアウト型SQLデータベースが必要。 • Spanner: Google’s Globally

    Distributed Database(2012) が発表され、 2017年にGoogle Cloud Spannerとしてクラウド利用が可能となった。 • 国内でもスマホゲームの大量アクセスや、決済トランザクションを捌くプ ラットフォームとして利用されている。 <<特徴>> • SQL準拠、ACIDトランザクションをサポート。 • 地理分散が可能な、分散型SQLデータベース。 • 従来RDBが弱いとされた、Writeもスケールアウトが可能。
  3. 6.

    8 当研究の目的 <<問題意識>> • マルチデータストアはアプリケーションに複雑性を注入。 • その複雑性は特定ワークロード専用で無駄が生じる。 • Managed Serviceでなくとも、分散DBは現実的に管理できるか。

    <<研究目的>> • 汎用ワークロード向けの、single and real-time source of truthを、 Kubernetesと分散SQLデータベースの組み合わせで実現する。 • リソースを自律的に管理しながら、ミッションクリティカルなデータベース を動かすプラットフォームを探索する。
  4. 11.

    13 従来手法の調査:(3) SpannerとOSSクローン • Shardingを用いた分散、Raftによるレプリカで高可用性とRead/Write両方 の拡張性を担保。 • TrueTime APIにより、高い一貫性と同時実行性を担保(Spanner)。 •

    PostgreSQL、MySQLなどのクエリプロトコルに準拠、生産性が高い (クローン:CockroachDB、YugaButeDBなど)。 • Kubernetesを利用したdeployが可能(クローン)。 • Pros • SQLインターフェース • 線形スケーラビリティ、地理分散可能な構成 • Cons • 原子時計など特殊なHW依存、ない場合の制約がある • センタ間レイテンシなど分散限界は存在。
  5. 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かつ 冗長化される。
  6. 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によりマルチマスタ構成を実現している。
  7. 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プロトコルによるクエリのレイテンシ低下
  8. 16.

    18 提案体系:構成イメージ Stateless Applications Region1 Region2 SQL SQL SQL SQL

    SQL SQL • アプリケーションと同一クラスタで管理可能な、単一IFのデータストア。 • マルチマスタ、Replication Factor調整による高い可用性。 • Daemonsetによるdeployで自動スケールを可能とする構成も検討する。
  9. 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である。このレベル調整も必要。
  10. 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 (未取得) (未取得) (未取得)
  11. 19.

    21 まとめ • 複雑なマルチデータストアは、アプリケーション開発にも複雑性を招き、 対応可能なワークロードも絞られる。 • NewSQL、特にSpannerの成功は、これまでのRDBMSの可用性・拡張性・ 一貫性に対する見方を大きく変える可能性がある。 • さらにKubernetesと結びつくことで、Managed

    Serviceでしか恩恵を 受けられなかった分散SQLデータベースの構築・運用を自動化できるように なってきている。 • 小規模からスタートできる、single and real-time source of truthな データストアとして、NewSQL+Kubernetesが実用に耐えうるかを今後も 検証していく。