Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The State of Distibuted Database In Japan

Cd891a89dfec6ca7bd278b5f5bd87c90?s=47 tzkoba
March 31, 2022

The State of Distibuted Database In Japan

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

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

Cd891a89dfec6ca7bd278b5f5bd87c90?s=128

tzkoba

March 31, 2022
Tweet

More Decks by tzkoba

Other Decks in Technology

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