The State of Distibuted Database In Japan

The State of Distibuted
Database In Japan
Distributed SQL Summit Asia ,2022/3/31
Takahiro, Kobayashi

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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 Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

21
YugabyteDBの特徴
4

View Slide

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 Slide

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

View Slide

24
まとめ
5

View Slide

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

View Slide

26
Questions?
@tzkb
@tzkoba

View Slide

The State of Distibuted Database In Japan

The State of Distibuted Database In Japan

tzkoba

More Decks by tzkoba

Other Decks in Technology

Featured

Transcript