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

The State of Distibuted Database In Japan

tzkoba
March 31, 2022

The State of Distibuted Database In Japan

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

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

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

    View full-size slide

  2. 3
    1. データベースにまつわる課題
    2. 分散SQLデータベースの要素技術
    3. 国内における分散SQLDBの事例
    4. YugabyteDBの特徴
    5. まとめ
    アジェンダ

    View full-size slide

  3. 4
    データベースにまつわる課題
    1

    View full-size slide

  4. 5
    古き良き時代のデータベース
    • システム内のデータベースはRDBのみ。
    • Primary-Replicaで冗長化、複数DCやリージョン跨ぎの要件は少ない。
    • Writeはスケールアップ、Readはレプリカ増やして対応。
    • アプリケーションからのIFはSQL。
    Applications
    P
    東京
    SQL
    R
    東京

    View full-size slide

  5. 6
    現在は、複数データベースを使い分ける時代に
    • RDB、NoSQLを用途に応じて使い分け。
    • マルチプライマリで可用性を向上させたり、リージョン跨ぎのレプリカも。
    • NoSQLでWriteスケール、RDBは相変わらず限定的な拡張性。
    • アプリケーションからはSQL、JSON、KVなど様々なIFが要求される。
    Applications
    P R
    東京 大阪
    SQL JSON KVS SQL JSON KVS

    View full-size slide

  6. 7
    これで満足していますか?
    • DBごとに異なる可用性、拡張性、そして一貫性。
    • それぞれのデータベースに、熟練したDevとOpsが必要。
    ⇒より使いやすく、ユニバーサルな分散SQLデータベースが求められている
    Applications
    P R
    東京 大阪
    SQL JSON KVS SQL JSON KVS
    • WriteもReadもスケールアウト、スケールダウンも可能
    • マルチプライマリ、マルチリージョンの構成で高い可用性
    • 複数のIFをサポートし、一貫性のあるSQLデータベース

    View full-size slide

  7. 8
    これまでのRDBでスケールアウトが難しかった理由
    Replication構成(例)
    Write
    R
    P
    R
    Read
    • 既存RDBの多くで可能な、レプリケーション構成。
    • PrimaryがWriteをすべて受け付け、書込みをReplicaへ同期する。
    【メリット】
    • 実績豊富で、クラウドでも構成可能。
    • ReadはReplicaを増やしてスケール可能。
    【デメリット】
    • 非同期ではラグあり、同期では耐障害性↓
    • Writeは全てPrimaryで捌く必要があり、
    スケールアップしかできない。
    ⇒拡張性に限界がある

    View full-size slide

  8. 9
    RDBにおけるマルチプライマリ構成の事例
    Hyperscale(Citus)の例
    Write
    Read
    Oracle RACの例
    Write
    Read
    • マルチプライマリで水平スケール可能な構成はこれまでも存在した。
    • しかし、SPOFやボトルネックなしで、一貫性のあるDBは実現が困難だった。

    View full-size slide

  9. 10
    分散SQLデータベースの要素技術
    2

    View full-size slide

  10. 11
    どのような技術で、分散SQLデータベースは実現されている?
    • WriteもReadもスケールアウト、スケールダウンも可能
    • マルチプライマリ、マルチリージョンの構成で高い可用性
    • 複数のIFをサポートし、一貫性のあるSQLデータベース
    • WriteとReadのスケールアウト、スケールダウン
     Sharding
     自動再配置
    • マルチプライマリ、マルチリージョン
     Raft
     同期+非同期
    • 一貫性のあるSQLデータベース
     分散トランザクション
     特別なHWを要求するケースも

    View full-size slide

  11. 13
    要素技術①:Sharding
    • Sharding自体は古くからあり、データを複数ノードに分散配置する手法。
    • ノードが所有するデータを一定範囲に限定し、負荷を分散する。
    Shard-3
    Shard-2
    Shard-1
    Shard-1-a
    Shard-1-b
    Shard-2
    Shard-3
    負荷増=分割
    負荷減=結合

    View full-size slide

  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を返す。

    View full-size slide

  13. 15
    Raftでマルチリージョンとは
    Raft Leader
    サイト
    Followerサイト
    Followerサイト
    • Raftによる合意は近郊サイトのFollower
    で完了するため、レイテンシが短縮可。
    • 大きなポイントとして、合意ベースの
    システムには3つ以上のサイトが必要。
    • この図では関東近郊が全面障害の場合、
    関西サイト単独では稼働できない。
    (合意に達しないため)
    • Raftでは過半数のackを待つが、それ以外は遅延があっても良い。
    • これを利用して、遠近のレプリカを使い分けてマルチリージョンを実現。

    View full-size slide

  14. 16
    要素技術③:分散トランザクション
    • 複数ノードにデータを配置する分散DBでは、トランザクションも複雑化。
    • 旧来の2PCを改良し、PaxosやRaftと組み合わせて現実的な分散トランザク
    ションを実現している。
    from 詳説データベース
    • 左図はCloud Spannerの例。
    • 複数Shard(図ではTablet)にまたが
    るトランザクションを実現している。
    • Cloud Spannerでは高精度GPSと原
    子時計を用いて、高い一貫性と低レ
    イテンシを実現している。

    View full-size slide

  15. 17
    国内における分散SQLDBの事例
    3

    View full-size slide

  16. 18
    スケールアップの限界⇒分散SQLDBへ
    • Aurora等のRDBの限界を感じて、分散SQLDBの検証を始める例は国内でも
    見られるようになってきた。
    • PayPayでは、MySQL互換の分散SQLデータベースを利用している。
    【課題】
    • Writeのスケールアウトが必要、
    スケールアップ時のDB停止が許容
    できない。
    • キャンペーンによってリクエスト数
    が劇的に増減する中で、DB性能(コス
    ト)も弾力的に変更したい。

    View full-size slide

  17. 19
    AI&データプラットフォームとして
    • 楽天モバイルでは、Autonomous NWを支えるプラットフォームとして
    を利用。
    • 1.5PB・約100台でのDBクラスタを、3つのデータセンタで稼働。
    【課題】
    • 膨大なNWデータを受け付けて処理でき
    る、低レイテンシのOLTPデータベースが
    必要。
    • 3つ以上のDCに分散して配置できる、
    可用性と拡張性が求められる。
    • SQLだけでなく、NoSQLとしてもアクセ
    ス可能な柔軟性が必要。

    View full-size slide

  18. 20
    クラウド上で分散SQLデータベースの利用が進む
    • 国内のスマホゲームでも、分散SQLDBが利用されている。
    • 大量のノードやストレージを管理する手間がなく、自動スケーリングなどの
    メリットも受けられるマネージドサービスとしての利用例。
    【課題】
    • MySQLから、よりスケーラブルな
    分散SQLDBへの移行。
    • 分散SQLDB自体の使い方の難しさに
    も直面、開発チームも含めたノウハ
    ウの共有が必要。

    View full-size slide

  19. 21
    YugabyteDBの特徴
    4

    View full-size slide

  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。

    View full-size slide

  21. 23
    = Cloud Native
    • YugabyteDBは複数のデプロイ方法に対応。
    • クラウドやKubernetesでの利用、そしてDBaaSとしての利用をサポート。
    • Apache 2.0ライセンスで提供されるOSSDB。
    • DockerやKubernetesでも利用可能。
    • 24*7の商用サポート。
    • クラウド、オンプレなど幅広く対応し、運用コストを低減。
    • フルマネージドなDBaaS。
    • Free Tierあり、開発・検証をすぐに開始可能。
    YugabyteDB Core
    Yugabyte Platform
    Yugabyte Cloud

    View full-size slide

  22. 24
    まとめ
    5

    View full-size slide

  23. 25
    2022年以降の分散データベース
    あなたのシステムにも
    分散SQLデータベースという選択肢を!
     RDBが課題としてきた下記を、分散SQLDBはサポート。
     Writeも含めたスケールアウト
     マルチプライマリ、マルチリージョンによる高い可用性
     今後はさらに運用性が向上し、サーバレス等の取り組みが
    進んでいくと見られる。
     利用には、分散データベースの仕組みを理解しておくことが
    今まで以上に重要。

    View full-size slide

  24. 26
    Questions?
    @tzkb
    @tzkoba

    View full-size slide