WSA研#6の発表資料です。 前提知識として、以下をあげておきます。
https://qiita.com/tzkoba/items/5316c6eac66510233115 https://qiita.com/tzkoba/items/3e875e5a6ccd99af332f
Buildingsmall/large Distributed-SQLwith KubernetesWSA研#6 , 4/26@tzkb
View Slide
2最近やっていること• Cloud Native Days Tokyo 2019“Cloud Native Storageが拓くDatabase on Kubernetesの未来”• PGConf.Asia 2019“Building PostgreSQL as a Servicewith Kubernetes”＋ ＝∞
51. 背景と目的2. 従来手法の調査（RDB、NoSQL、NewSQL）3. 提案体系4. 評価5. まとめアジェンダ
6背景と目的：①データストアの複雑化• モノリシック・単一のRDBに限界があり、より拡張性の高いNoSQLが生まれたが、RDBの置換えではなく補完であった。• 結果、生まれたのはRDB＋キャッシュ＋NoSQLのような複雑なデータストア。Stateless ApplicationsM SRegion1 Region2SQL JSON KVS SQL JSON KVS
7背景と目的：②NewSQLの台頭• 複雑なデータストアを使い分け、管理するコストが増大。• 統合DBとしての、スケールアウト型SQLデータベースが必要。• Spanner: Google’s Globally Distributed Database(2012) が発表され、2017年にGoogle Cloud Spannerとしてクラウド利用が可能となった。• 国内でもスマホゲームの大量アクセスや、決済トランザクションを捌くプラットフォームとして利用されている。<<特徴>>• SQL準拠、ACIDトランザクションをサポート。• 地理分散が可能な、分散型SQLデータベース。• 従来RDBが弱いとされた、Writeもスケールアウトが可能。
8当研究の目的<<問題意識>>• マルチデータストアはアプリケーションに複雑性を注入。• その複雑性は特定ワークロード専用で無駄が生じる。• Managed Serviceでなくとも、分散DBは現実的に管理できるか。<<研究目的>>• 汎用ワークロード向けの、single and real-time source of truthを、Kubernetesと分散SQLデータベースの組み合わせで実現する。• リソースを自律的に管理しながら、ミッションクリティカルなデータベースを動かすプラットフォームを探索する。
9従来手法の調査：(1)RDBの拡張手法• 高可用性は、Master-Slaveの冗長構成で担保し、ログまたはStatementのコピーで同期/非同期にデータ複製を行う。• 拡張性は、Readではスケール可能（但し非同期時は遅延あり）、WriteではShardingやマルチマスタ構成で一部スケールするが、制約はある。• Pros• SQLインターフェース• ACIDトランザクション• Cons• 制限のある拡張性• 2PCなど旧式のトランザクション調停手法• デフォルトで低い分離レベル、発生する種々のアノマリー
10従来手法の調査：(2)NoSQLの登場と進化• （以下はCassandraを想定）• 高可用性は、通常3台以上のデータレプリカを用意することで担保。• 拡張性は、Read/Writeともに台数を増やすだけで可能だが、一貫性レベルによっては読取り遅延が発生する。• Pros• 線形スケーラビリティ• 一貫性（C）と可用性（A）を調整可能• Cons• SQL非準拠• 完全でない同時実行制御、どんなアノマリーも発生しうる
11（参考）分散SQLデータベースの類型WALMS S【PostgreSQLのReplication】高可用性＋リードレプリカSQL【Vitess】Shardingによる分散DBSQL
12（参考）マルチマスタの分散データベース【Oracle RAC】共有Disk型のマルチマスタDB【Cassandra】Shared NothingのKVSKVSSQL
13従来手法の調査：(３) SpannerとOSSクローン• Shardingを用いた分散、Raftによるレプリカで高可用性とRead/Write両方の拡張性を担保。• TrueTime APIにより、高い一貫性と同時実行性を担保(Spanner)。• PostgreSQL、MySQLなどのクエリプロトコルに準拠、生産性が高い（クローン：CockroachDB、YugaButeDBなど）。• Kubernetesを利用したdeployが可能（クローン）。• Pros• SQLインターフェース• 線形スケーラビリティ、地理分散可能な構成• Cons• 原子時計など特殊なHW依存、ない場合の制約がある• センタ間レイテンシなど分散限界は存在。
14（参考）SpannerクローンとKubernetes• Kubernetesによるdeploy・管理が可能なtablet3tablet2tablet1tablet4tablet2tablet1tablet4tablet3tablet1tablet4tablet3tablet1DistrbutedTxn MgrDistrbutedTxn MgrDistrbutedTxn MgrDistrbutedTxn Mgrsyscatalog syscatalog syscatalog• Spannerに似た分散DBでWriteヘビーに強い。• PostgreSQLのSQLエンジンと分散ストレージとしてのDocDBで構成される。• データはShardingかつ冗長化される。
15（参考）NewSQLはマルチマスタ構成かTablet2Tablet1Tablet2Table1Tablet2Tablet1Tablet3Tablet3Tablet3• etcdなどは単一Raftグループで構成される分散KVS。Leaderは当然一つ。• YugaButeDBなどはマルチRaftグループで、グループ毎にLeaderが存在。つまりマルチマスタの構成となる(hotspot問題はあり)。• 分散DBのレプリケーションにはRaft が使われている。• Multi Raft Groupによりマルチマスタ構成を実現している。
16（参考）KubernetesによるDBクラスタの管理• PGConf.Asiaで発表された on Kubernetesの例(replication)。Productionとして大規模に展開済。
17提案体系：Kubernetesで管理する小規模・高可用性DB• 従来のMaster-Slave型Replicationは、高信頼・低遅延のNWが前提で、頻繁に停止・起動が起こりえるコンテナ・オーケストレータには不向き。• 分散システムプラットフォーム=Kubernetesで管理されるには、前提が異なるSQLデータベースが必要。つまりNewSQL。• 小規模から始め、アプリケーションの拡張に応じて線形スケールが可能な単一データストア(single and real-time source of truth) を目指す。• 従来データベースよりも強く、アノマリーの発生しない（開発が容易な）トランザクション分離レベルを採用。<<課題>>• 現実的な時刻同期下での同時実行性（TrueTime APIなし）• Amazon Time Sync Serviceのような高精度サービスも存在。• Raftプロトコルによるクエリのレイテンシ低下
18提案体系：構成イメージStateless ApplicationsRegion1 Region2SQL SQL SQL SQL SQL SQL• アプリケーションと同一クラスタで管理可能な、単一IFのデータストア。• マルチマスタ、Replication Factor調整による高い可用性。• Daemonsetによるdeployで自動スケールを可能とする構成も検討する。
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である。このレベル調整も必要。
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 (未取得) (未取得) (未取得)
21まとめ• 複雑なマルチデータストアは、アプリケーション開発にも複雑性を招き、対応可能なワークロードも絞られる。• NewSQL、特にSpannerの成功は、これまでのRDBMSの可用性・拡張性・一貫性に対する見方を大きく変える可能性がある。• さらにKubernetesと結びつくことで、Managed Serviceでしか恩恵を受けられなかった分散SQLデータベースの構築・運用を自動化できるようになってきている。• 小規模からスタートできる、single and real-time source of truthなデータストアとして、NewSQL+Kubernetesが実用に耐えうるかを今後も検証していく。
27Questions?@tzkb@tzkoba
tzkoba
mottox2
dahatake
coconala_engineer
nwiizo
kazuhitotakahashi
tkhresk
chumajin
yuya4
.jpg){kind=avatar}
oshanqq
nikkei_engineer_recruiting
kojira
minorun365
schacon
zenorocha
colly
62gerente
paulrobertlloyd
jennybc
deanohume
panda_program
lara
smashingmag
eileencodes
jacobian