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
2. 2 最近やっていること • Cloud Native Days Tokyo 2019 “Cloud Native Storageが拓く Database on Kubernetesの未来” • PGConf.Asia 2019 “Building PostgreSQL as a Service with Kubernetes” ＋ ＝∞
3. 5 1. 背景と目的 2. 従来手法の調査（RDB、NoSQL、NewSQL） 3. 提案体系 4. 評価 5. まとめ アジェンダ
4. 6 背景と目的：①データストアの複雑化 • モノリシック・単一のRDBに限界があり、より拡張性の高いNoSQLが生まれ たが、RDBの置換えではなく補完であった。 • 結果、生まれたのはRDB＋キャッシュ＋NoSQLのような複雑なデータストア。 Stateless Applications M S Region1 Region2 SQL JSON KVS SQL JSON KVS
5. 7 背景と目的：②NewSQLの台頭 • 複雑なデータストアを使い分け、管理するコストが増大。 • 統合DBとしての、スケールアウト型SQLデータベースが必要。 • Spanner: Google’s Globally Distributed Database(2012) が発表され、 2017年にGoogle Cloud Spannerとしてクラウド利用が可能となった。 • 国内でもスマホゲームの大量アクセスや、決済トランザクションを捌くプ ラットフォームとして利用されている。 <<特徴>> • SQL準拠、ACIDトランザクションをサポート。 • 地理分散が可能な、分散型SQLデータベース。 • 従来RDBが弱いとされた、Writeもスケールアウトが可能。
6. 8 当研究の目的 <<問題意識>> • マルチデータストアはアプリケーションに複雑性を注入。 • その複雑性は特定ワークロード専用で無駄が生じる。 • Managed Serviceでなくとも、分散DBは現実的に管理できるか。 <<研究目的>> • 汎用ワークロード向けの、single and real-time source of truthを、 Kubernetesと分散SQLデータベースの組み合わせで実現する。 • リソースを自律的に管理しながら、ミッションクリティカルなデータベース を動かすプラットフォームを探索する。
7. 9 従来手法の調査：(1)RDBの拡張手法 • 高可用性は、Master-Slaveの冗長構成で担保し、ログまたはStatementの コピーで同期/非同期にデータ複製を行う。 • 拡張性は、Readではスケール可能（但し非同期時は遅延あり）、Writeでは Shardingやマルチマスタ構成で一部スケールするが、制約はある。 • Pros • SQLインターフェース • ACIDトランザクション • Cons • 制限のある拡張性 • 2PCなど旧式のトランザクション調停手法 • デフォルトで低い分離レベル、発生する種々のアノマリー
8. 10 従来手法の調査：(2)NoSQLの登場と進化 • （以下はCassandraを想定） • 高可用性は、通常3台以上のデータレプリカを用意することで担保。 • 拡張性は、Read/Writeともに台数を増やすだけで可能だが、一貫性レベル によっては読取り遅延が発生する。 • Pros • 線形スケーラビリティ • 一貫性（C）と可用性（A）を調整可能 • Cons • SQL非準拠 • 完全でない同時実行制御、どんなアノマリーも発生しうる
9. 11 （参考）分散SQLデータベースの類型 WAL M S S 【PostgreSQLのReplication】 高可用性＋リードレプリカ SQL 【Vitess】 Shardingによる分散DB SQL
10. 12 （参考）マルチマスタの分散データベース 【Oracle RAC】 共有Disk型のマルチマスタDB 【Cassandra】 Shared NothingのKVS KVS SQL
11. 13 従来手法の調査：(３) SpannerとOSSクローン • Shardingを用いた分散、Raftによるレプリカで高可用性とRead/Write両方 の拡張性を担保。 • TrueTime APIにより、高い一貫性と同時実行性を担保(Spanner)。 • PostgreSQL、MySQLなどのクエリプロトコルに準拠、生産性が高い （クローン：CockroachDB、YugaButeDBなど）。 • Kubernetesを利用したdeployが可能（クローン）。 • Pros • SQLインターフェース • 線形スケーラビリティ、地理分散可能な構成 • Cons • 原子時計など特殊なHW依存、ない場合の制約がある • センタ間レイテンシなど分散限界は存在。
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かつ 冗長化される。
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によりマルチマスタ構成を実現している。
14. 16 （参考）KubernetesによるDBクラスタの管理 • PGConf.Asiaで発表された on Kubernetesの例(replication)。 Productionとして大規模に展開済。
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プロトコルによるクエリのレイテンシ低下
16. 18 提案体系：構成イメージ Stateless Applications Region1 Region2 SQL SQL SQL SQL SQL SQL • アプリケーションと同一クラスタで管理可能な、単一IFのデータストア。 • マルチマスタ、Replication Factor調整による高い可用性。 • Daemonsetによるdeployで自動スケールを可能とする構成も検討する。
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である。このレベル調整も必要。
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 (未取得) (未取得) (未取得)
19. 21 まとめ • 複雑なマルチデータストアは、アプリケーション開発にも複雑性を招き、 対応可能なワークロードも絞られる。 • NewSQL、特にSpannerの成功は、これまでのRDBMSの可用性・拡張性・ 一貫性に対する見方を大きく変える可能性がある。 • さらにKubernetesと結びつくことで、Managed Serviceでしか恩恵を 受けられなかった分散SQLデータベースの構築・運用を自動化できるように なってきている。 • 小規模からスタートできる、single and real-time source of truthな データストアとして、NewSQL+Kubernetesが実用に耐えうるかを今後も 検証していく。
20. 27 Questions? @tzkb @tzkoba