The State of Distibuted Database In Japan

#DSSAsia 2022のJapanese Trackから。
https://asia.distributedsql.org/

従来のRDBMSの課題を整理し、分散SQLデータベース、またはNewSQLと呼ばれるものが何を解決するかについて洞察します。

Transcript

1. The State of Distibuted Database In Japan Distributed SQL Summit Asia ,2022/3/31 Takahiro, Kobayashi
2. 3 1. データベースにまつわる課題 2. 分散SQLデータベースの要素技術 3. 国内における分散SQLDBの事例 4. YugabyteDBの特徴 5. まとめ アジェンダ
3. 4 データベースにまつわる課題 1
4. 5 古き良き時代のデータベース • システム内のデータベースはRDBのみ。 • Primary-Replicaで冗長化、複数DCやリージョン跨ぎの要件は少ない。 • Writeはスケールアップ、Readはレプリカ増やして対応。 • アプリケーションからのIFはSQL。 Applications P 東京 SQL R 東京
5. 6 現在は、複数データベースを使い分ける時代に • RDB、NoSQLを用途に応じて使い分け。 • マルチプライマリで可用性を向上させたり、リージョン跨ぎのレプリカも。 • NoSQLでWriteスケール、RDBは相変わらず限定的な拡張性。 • アプリケーションからはSQL、JSON、KVなど様々なIFが要求される。 Applications P R 東京 大阪 SQL JSON KVS SQL JSON KVS
6. 7 これで満足していますか？ • DBごとに異なる可用性、拡張性、そして一貫性。 • それぞれのデータベースに、熟練したDevとOpsが必要。 ⇒より使いやすく、ユニバーサルな分散SQLデータベースが求められている Applications P R 東京 大阪 SQL JSON KVS SQL JSON KVS • WriteもReadもスケールアウト、スケールダウンも可能 • マルチプライマリ、マルチリージョンの構成で高い可用性 • 複数のIFをサポートし、一貫性のあるSQLデータベース
7. 8 これまでのRDBでスケールアウトが難しかった理由 Replication構成（例） Write R P R Read • 既存RDBの多くで可能な、レプリケーション構成。 • PrimaryがWriteをすべて受け付け、書込みをReplicaへ同期する。 【メリット】 • 実績豊富で、クラウドでも構成可能。 • ReadはReplicaを増やしてスケール可能。 【デメリット】 • 非同期ではラグあり、同期では耐障害性↓ • Writeは全てPrimaryで捌く必要があり、 スケールアップしかできない。 ⇒拡張性に限界がある
8. 9 RDBにおけるマルチプライマリ構成の事例 Hyperscale(Citus)の例 Write Read Oracle RACの例 Write Read • マルチプライマリで水平スケール可能な構成はこれまでも存在した。 • しかし、SPOFやボトルネックなしで、一貫性のあるDBは実現が困難だった。
9. 10 分散SQLデータベースの要素技術 2
10. 11 どのような技術で、分散SQLデータベースは実現されている？ • WriteもReadもスケールアウト、スケールダウンも可能 • マルチプライマリ、マルチリージョンの構成で高い可用性 • 複数のIFをサポートし、一貫性のあるSQLデータベース • WriteとReadのスケールアウト、スケールダウン  Sharding  自動再配置 • マルチプライマリ、マルチリージョン  Raft  同期＋非同期 • 一貫性のあるSQLデータベース  分散トランザクション  特別なHWを要求するケースも
11. 13 要素技術①：Sharding • Sharding自体は古くからあり、データを複数ノードに分散配置する手法。 • ノードが所有するデータを一定範囲に限定し、負荷を分散する。 Shard-3 Shard-2 Shard-1 Shard-1-a Shard-1-b Shard-2 Shard-3 負荷増＝分割 負荷減＝結合
12. 14 要素技術②：Raft • 合意プロトコルであるRaftで、同期Replicationに近い一貫性・耐障害性と、 非同期に近いレイテンシを実現する。 • ShardごとにLeaderが存在し、マルチプライマリを実現。 Follower3 Write Read Follower2 Leader1 Leader3 Follower2 Follower1 Follower3 Leader2 Follower1 【Write Path 】 ①WriteはLeaderに送られ、Leaderのlogに 更新が記録される。 ②全てのFollowerにlogを複製。 ③Followerの過半数からackが返る。 ④Leaderは更新をコミット。 【Read Path 】 ①Readも原則はLeaderへ送られる。 ②LeaderはFollowerへハートビートして、 過半数からackを待つ。 ③自身がLeaderであることが確認できたので、 Readを返す。
13. 15 Raftでマルチリージョンとは Raft Leader サイト Followerサイト Followerサイト • Raftによる合意は近郊サイトのFollower で完了するため、レイテンシが短縮可。 • 大きなポイントとして、合意ベースの システムには3つ以上のサイトが必要。 • この図では関東近郊が全面障害の場合、 関西サイト単独では稼働できない。 （合意に達しないため） • Raftでは過半数のackを待つが、それ以外は遅延があっても良い。 • これを利用して、遠近のレプリカを使い分けてマルチリージョンを実現。
14. 16 要素技術③：分散トランザクション • 複数ノードにデータを配置する分散DBでは、トランザクションも複雑化。 • 旧来の2PCを改良し、PaxosやRaftと組み合わせて現実的な分散トランザク ションを実現している。 from 詳説データベース • 左図はCloud Spannerの例。 • 複数Shard(図ではTablet)にまたが るトランザクションを実現している。 • Cloud Spannerでは高精度GPSと原 子時計を用いて、高い一貫性と低レ イテンシを実現している。
15. 17 国内における分散SQLDBの事例 3
16. 18 スケールアップの限界⇒分散SQLDBへ • Aurora等のRDBの限界を感じて、分散SQLDBの検証を始める例は国内でも 見られるようになってきた。 • PayPayでは、MySQL互換の分散SQLデータベースを利用している。 【課題】 • Writeのスケールアウトが必要、 スケールアップ時のDB停止が許容 できない。 • キャンペーンによってリクエスト数 が劇的に増減する中で、DB性能(コス ト)も弾力的に変更したい。
17. 19 AI＆データプラットフォームとして • 楽天モバイルでは、Autonomous NWを支えるプラットフォームとして を利用。 • 1.5PB・約100台でのDBクラスタを、3つのデータセンタで稼働。 【課題】 • 膨大なNWデータを受け付けて処理でき る、低レイテンシのOLTPデータベースが 必要。 • 3つ以上のDCに分散して配置できる、 可用性と拡張性が求められる。 • SQLだけでなく、NoSQLとしてもアクセ ス可能な柔軟性が必要。
18. 20 クラウド上で分散SQLデータベースの利用が進む • 国内のスマホゲームでも、分散SQLDBが利用されている。 • 大量のノードやストレージを管理する手間がなく、自動スケーリングなどの メリットも受けられるマネージドサービスとしての利用例。 【課題】 • MySQLから、よりスケーラブルな 分散SQLDBへの移行。 • 分散SQLDB自体の使い方の難しさに も直面、開発チームも含めたノウハ ウの共有が必要。
19. 21 YugabyteDBの特徴 4
20. 22 分散SQLデータベースを超える、 tablet3 tablet2 tablet1 tablet3 tablet2 tablet1 tablet3 tablet2 tablet1 Distrbuted Txn Mgr Distrbuted Txn Mgr Distrbuted Txn Mgr SQL CQL Applications SQL CQL SQL CQL SQL CQL • Write/Readでスケールし、マルチリージョンの配置ができて、 SQLだけでなくNoSQLアクセスにも対応した、分散データベース。 Sharding＋Raftによる複製で、 高い可用性と拡張性、 マルチリージョン配置を同時に実現。 高い一貫性を担保する分散Txn Mgr。 SQL＋CQLをサポートするIF。
21. 23 ＝ Cloud Native • YugabyteDBは複数のデプロイ方法に対応。 • クラウドやKubernetesでの利用、そしてDBaaSとしての利用をサポート。 • Apache 2.0ライセンスで提供されるOSSDB。 • DockerやKubernetesでも利用可能。 • 24*7の商用サポート。 • クラウド、オンプレなど幅広く対応し、運用コストを低減。 • フルマネージドなDBaaS。 • Free Tierあり、開発・検証をすぐに開始可能。 YugabyteDB Core Yugabyte Platform Yugabyte Cloud
22. 24 まとめ 5
23. 25 2022年以降の分散データベース あなたのシステムにも 分散SQLデータベースという選択肢を！  RDBが課題としてきた下記を、分散SQLDBはサポート。  Writeも含めたスケールアウト  マルチプライマリ、マルチリージョンによる高い可用性  今後はさらに運用性が向上し、サーバレス等の取り組みが 進んでいくと見られる。  利用には、分散データベースの仕組みを理解しておくことが 今まで以上に重要。
24. 26 Questions? @tzkb @tzkoba