分散DBって何者なんだ．．． Spannerから学ぶRDBとの違い

YAPC::2025 Fukuoka登壇資料
https://fortee.jp/yapc-fukuoka-2025/proposal/c76c16a2-057e-4190-923f-0f4e404f79c7

Transcript

1. 分散DBって何者なんだ．．． Spanner から学ぶRDBとの違い YAPC Fukuoka 2025 岩下 拳勝 (@iwashi623)
2. まずは、スポンサーの皆様 U29支援の制度を作ってくださって ありがとうございます。
3. 元気だしていきます！
4. Cloud Spanner って知ってますか？
5. 出典： https://cloud.google.com/spanner?hl=ja
6. 出典： https://zenn.dev/google_cloud_jp/articles/2f85d7dcd0ced7
7. 分散DBってなんだ …？
8. 出典： https://ja.wikipedia.org/wiki/%E5%88%86%E6%95%A3%E3%83%87%E3%83%B C%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9
9. ってか、 RDBの良さ・悪さってなんだったっけ …？
10. • はじめに • 普通のRDBMS • 分散DB（NoSQL ） • 余談 • Cloud Spanner ◦ メリット ◦ デメリット • まとめ アジェンダ
11. • はじめに • 普通のRDBMS • 分散DB（NoSQL ） • 余談 • Cloud Spanner ◦ メリット ◦ デメリット • まとめ アジェンダ
12. • Relational DataBase（物事を実態と関連で表現する） • みなさんが普段使っている（であろう）やつ。 • PostgreSQLとかMySQLとか。 • 様々な現場で知見が多いし、ファーストチョイスになりがち。 ◦ だし、それが悪いことだと私も思わない、自分もそう。 • 困ったときに助けてくれる人も多い。 普通のRDBMS
13. users, classesは実態テーブル、 user_classes（履修）が関連テーブル 普通のRDBMS
14. • なんといってもSQL！ ◦ これがあるから我々は豊かな発想で様々なデータを取得でき る。 • JOINやGROUP, ORDERなどで取得したいデータを制限、拡大、ソート できる 普通のRDBMS の良さ - SQL
15. • トランザクションにおけるACID特性 ◦ 原子性・一貫性・分離性・永続性 ▪ Commitされてない結果は保存しない ▪ DBの制約はちゃんと守る ▪ Commitされてない結果は外部に見せない ▪ Commitされた結果は消えない 普通のRDBMS の良さ - 強い整合性
16. Commitされてない結果は保存しない 普通のRDBMS の良さ - 強い整合性
17. Commitされてない結果は外部に見せない（READ COMMITED） 普通のRDBMS の良さ - 強い整合性
18. Commitされた結果は、きちんと返す （遅延レプリケーションなどのケースを除いて） 普通のRDBMS の良さ - 強い整合性
19. • トランザクションにおけるACID特性 ◦ 原子性・一貫性・分離性・永続性 ▪ Commitされてない結果は保存しない ▪ DBの制約はちゃんと守る ▪ Commitされてない結果は外部に見せない ▪ Commitされた結果は消えない (再掲)普通のRDBMS の良さ - 強い整合性
20. • トランザクションにおけるACID特性 ◦ 原子性・一貫性・分離性・永続性 ▪ Commitされてない結果は保存しない ▪ DBの制約はちゃんと守る ▪ Commitされてない結果は外部に見せない ▪ Commitされた結果は消えない (再掲)普通のRDBMS の良さ - 強い整合性 ？？？「当たり前では？」
21. んなわけあるか！！！！
22. • CHECK制約と組み合わせることで、数量カラムがマイナスにさせない ◦ 二重に決済して怒られるなどのことが発生しづらい • 障害が起きてもリカバリーできる ◦ COMMIT済みのデータはWALやbinlogから復旧できる ◦ 未COMMITのデータはちゃんと消えてくれる 強い整合性は超ありがたいもの
23. • CHECK制約と組み合わせることで、数量カラムがマイナスにさせない ◦ 二重に決済して怒られるなどのことが発生しづらい • 障害が起きてもリカバリーできる ◦ COMMIT済みのデータはWALやbinlogから復旧できる ◦ 未COMMITのデータはちゃんと消えてくれる 強い整合性は超ありがたいもの RDBMSはデータを守ってくれている！ 我々はソフトのウェアの開発に注力できる！
24. スケーリング • 垂直スケーリング ◦ すぐできるが、サーバースペックの上限がある ◦ ダウンタイムとメンテナンス時間が… • 水平スケーリング ◦ リードレプリカ ▪ そもそも書き込みがボトルネックであれば対処できない ▪ Writer一台だと将来的には限界が来るかも ◦ シャーディング ▪ アプリで実装、むずかしい ▪ データベースで統一の整合性を捨てる覚悟 RDBMS が苦手なこと
25. そんなあなたに分散 DB
26. • はじめに • 普通のRDBMS • 分散DB（NoSQL ） • 余談 • Cloud Spanner ◦ メリット ◦ デメリット • まとめ アジェンダ
27. 発表の都合で恐縮ですが、ここでいう分散DBは 分散DB（NoSQL ）です。 分散DB
28. DynamoDB（AWS）とかBigtable（Google Cloud）とか。 分散DB（NoSQL ）
29. DynamoDB（AWS）とかBigtable（Google Cloud）とか。 分散DB（NoSQL ） 出典： https://aws.amazon.com/jp/dynamodb/ 出典： https://cloud.google.com/bigtable?hl=ja
30. DynamoDB（AWS）とかBigtable（Google Cloud）とか。 分散DB（NoSQL ） 出典： https://aws.amazon.com/jp/dynamodb/ 出典： https://cloud.google.com/bigtable?hl=ja 無制限！！！
31. • 水平スケール ◦ テーブルを自動パーティショニングして、書き込み読み込みを複 数のノードへ分散 ◦ エンジニアを、スケールアウトの難問から解放 • 地理分散の容易さ ◦ RDBMSでは難しかったマルチリージョン対策もお手の物 ◦ リージョン単位の障害にも対応 ◦ コンソールでポチッとするだけ • スキーマが柔軟 ◦ DDL更新時のLockなどが発生しない 分散DB（NoSQL の良さ）
32. なるほど、 NoSQL はスケーリングが大得意！（雑）
33. これはRDBのデメリットを解消した 銀の弾丸なのか …？
34. 整合性とSQLという RDBMSのメリットが犠牲に… そうは問屋がおろさない
35. • 整合性が取りづらい ◦ CHECK制約などがなし ◦ 更新順序を守るために、強い整合性読み取り をすると追加課金が必要 • トランザクションに制限あり ◦ DynamoDB: トランザクションはあるが制限あり（最大25項目/合計4MB） ◦ Bigtableは複数行に渡るTxなし • 初期設計が命 ◦ あらかじめ定めたパーティションキーやセカンダリインデックス前提の検索 ▪ アドホックなクエリがやりたいときに辛い ◦ スキーマレスはメリットであり、デメリットにもなる 分散DB（NoSQL のつらみ）
36. • 整合性 ◦ データを不整合から守る責務は、DBに任せたい ◦ 中途半端なデータを弾く（FK, UNIQUE, CHECK） ◦ Commitされていない変更はちゃんと消す ◦ Commitされた最新のデータを読み込める • 柔軟な検索インターフェース ◦ データは書き物ではなく、読み物 ◦ アドホックな検索にも対応できると、障害対応時や分析が楽になる • 拡張性 ◦ サーバーの限界を超えることができる、水平スケーリングが容易であると、 ソフトウェアエンジニアが考慮すべき事項が一気に減る （個人的）データベースの重要ポイント
37. 整合性 検索柔軟性 スケーリング RDBMS ◎ ◯ みんな大好きSQL。 JOINをやりすぎるとひ どく遅くなるけど、大体 は対応できる。 △ 自前でシャーディングす るの難しい。 シャーディングしてノー ドを分けたら、DBで統 一の整合性が犠牲にな る。 NoSQL △ 強い整合性読み取り （DynamoDB）などもあ るけど、お金かかるし制 限ある。 △ アクセスパターンを先出 しした初期設計が必要。 複雑な検索をやりた かったらDWHへ。 ◎ RDBMS vs 分散DB（NoSQL ）
38. • はじめに • 普通のRDBMS • 分散DB（NoSQL ） • 余談 • Cloud Spanner ◦ メリット ◦ デメリット • まとめ アジェンダ
39. CAP定理（https://en.wikipedia.org/wiki/CAP_theorem ） 分散システムが、CとAとPの3つの特性を、3つ同時に満たすことはできないという定理。 • C（Consistency）: 一貫性、共有されているデータが唯一の値を持つ • A（Availability）: 可用性、読み込みと書き込みの両方で 100% の可用性が確保されている • P（Partition Tolerance）: 分断耐性、ネットワークの分断に対する耐性がある そもそも
40. CAP定理 CA CP AP サービス例 単一ノードのRDBMS 複数ノードのAuroraや RDS DynamoDB 解説 分断の概念がないた め、常に一貫性を提 供できる。 分散システムでは、 CAのサービスは原理 的に存在しない。 可用性を犠牲にして、 一貫性を体に入れる。 ネットワーク分断時に は、フェイルオーバー が走って、可用性が損 なわれる可能性があ る。 一貫性を犠牲にして、 可用性を手に入れる。 ネットワーク分断時に は、それぞれのノード に書き、読みが発生。 古いデータを返す可 能性がある。 最終的には、一貫性 を保とうとする。
41. 強い整合性、柔軟な検索、可用性が高く拡張が 容易なDBがほしい！！！
42. Spanner 「呼んだ？」
43. • はじめに • 普通のRDBMS • 分散DB（NoSQL ） • 余談 • Cloud Spanner ◦ メリット ◦ デメリット • まとめ アジェンダ
44. スペック連打いきます 魅惑のSpanner
45. スペック連打いきます • 一貫性のあるトランザクションを保証 魅惑のSpanner
46. スペック連打いきます • 一貫性のあるトランザクションを保証 • 非常に高い可用性（最大99.999%） 魅惑のSpanner
47. スペック連打いきます • 一貫性のあるトランザクションを保証 • 非常に高い可用性（最大99.999%） • 自動水平スケーリング（シャーディング） 魅惑のSpanner
48. スペック連打いきます • 一貫性のあるトランザクションを保証 • 非常に高い可用性（最大99.999%） • 自動水平スケーリング（シャーディング） • SQLへの対応とBQとの超簡単連携 魅惑のSpanner
49. スペック連打いきます • 一貫性のあるトランザクションを保証 • 非常に高い可用性（最大99.999%） • 自動水平スケーリング（シャーディング） • SQLへの対応とBQとの超簡単連携 魅惑のSpanner ぼく「夢かよ！」
50. 出典： https://cloud.google.com/spanner?hl=ja
51. 外部整合性 “現実世界で先に終わったトランザクションの効果は、必ず先に観測され る” 書き込み（Tx1）のあとの読み込み（Tx2）では、必ずTx1の結果が反映され ている状態 → 言うは易し。行うは難し。 外部整合性を提供するために True Time とCommit Wait という仕組み が採用されている 魅惑のSpanner - 一貫性のあるトランザクション
52. TrueTime APIは、 “誤差つきの時刻”を返す分散時計API（Googleの社内インフラ）。 実現にGPS受信機や原子時計を使っていることで話題。 TT.now() → [earliest, latest] 現在時刻は、earliestとlatestのどこかであることを明示する。 例：TT.now() = [10:00:00.496, 10:00:00.504] 順序判定用ヘルパ TT.after(t)：今が確実に t を過ぎたなら true（≒ earliest > t）。 TT.before(t)：今が確実に t より前なら true（≒ latest < t）。 True Time
53. TrueTime APIは、 “誤差つきの時刻”を返す分散時計API（Googleの社内インフラ）。 実現にGPS受信機や原子時計を使っていることで話題。 TT.now() → [earliest, latest] 現在時刻は、earliestとlatestのどこかであることを明示する。 例：TT.now() = [10:00:00.496, 10:00:00.504] 順序判定用ヘルパ TT.after(t)：今が確実に t を過ぎたなら true（≒ earliest > t）。 TT.before(t)：今が確実に t より前なら true（≒ latest < t）。 True Time “いまが確実にある時刻を越えた /まだ来てない ”を分散環境で判定できる
54. Commit Wait = “時刻 s が世界的に過去になった”ことの確認待ち。 • TT.now() → [earliest, latest] ◦ **今の“誤差つき時刻区間”**を返す（今はこの範囲のどこか）。 • s = max(now_latest, latest_time_stamp +δ) ◦ TT.now().latest…“未来から抜かれない”ための安全下限 ◦ last_commit_ts + δ…単調増加（前回より必ず新しい）を保証 ▪ 大きい方を s に採用。 • TT.after(s) ◦ 「今が確実に s を過ぎた」判定（≒ TT.now().earliest > s）。 Commit Wait
55. Commit Wait = “時刻 s が世界的に過去になった”ことの確認待ち。 • TT.now() → [earliest, latest] ◦ **今の“誤差つき時刻区間”**を返す（今はこの範囲のどこか）。 • s = max(now_latest, latest_time_stamp +δ) ◦ TT.now().latest…“未来から抜かれない”ための安全下限 ◦ last_commit_ts + δ…単調増加（前回より必ず新しい）を保証 ▪ 大きい方を s に採用。 • TT.after(s) ◦ 「今が確実に s を過ぎた」判定（≒ TT.now().earliest > s）。 Commit Wait timestampの時刻が確実に過去になってから更新をかけることで、 それよりあとの Txは原理的にそれ以降の時刻で読み書きすることになる。
56. （注：実際はもっと細かい時刻です） 原子時計に最初に聞いた、latestの値で ある10:00:02をTxAのcommit timestamp とする。 TxAは、10:00:03が原子時計上でearliest になるまで待機する。 → 10:00:02が確実に過去になるまで待つ。 すると、 その後に始まったTxBは、確実に10:00:03 より後に完了することになるので、Txの順 序が守られる。 魅惑のSpanner - 一貫性のあるトランザクション
57. インスタンスが作成されると、 リージョン内のゾーンにそれぞれコンピュートリ ソースとストレージを保持する。 シングルリージョン構成で99.99％、 マルチリージョン構成で99.999％の可用性。 （1年間でダウンタイム約5分） 魅惑のSpanner - 非常に高い可用性
58. Googleさん「SpannerはCPのシステムという認識」 https://cloud.google.com/blog/ja/products/gcp/inside-cloud-spanner -and-the-cap-theorem しかしながら、そもそもGoogleにおいてネットワークの分断はほとんど起 きない。 なので、犠牲になるAもほとんどない。 （コラム） CAP定理とSpanner CAP定理は、完全なるトレードオフではなくて、実際 のリスクとのバランス
59. テーブルのデータは、主キーの値よって分割をされ たスプリット という単位で保存される。 • 特定のKeyのレコードだけを読み取るときは特 定のスプリットの中のみを読み込む。 • 一括でテーブルのデータを読み込みたいとき は複数のスプリットに対して並列でクエリを実 行する。 統一のエンドポイントで、 異なるスプリットに対して読み込みができる。 アプリケーション側でシャーディングを意識する必 要がない。 魅惑のSpanner - 自動水平スケーリング
60. Spanner Data Boost + BigQuery View + External Query で 簡単に分析を環境構築できる Spanner Data Boost は、Spannerインスタンスとは別の独立したコンピューティングリソー ス。 アプリケーションのワークロードに影響を与えることなく、 Spannerのストレージに対してクエリ を発行することができるマネージドサービス。 BigQueryでは、外部接続という概念でSpannerとの連携ができる。 その際、コンピュートとしてインスタンスではなく、 Data Boostを選択できる。 魅惑のSpanner - BQ との超簡単連携
61. 魅惑のSpanner - BQ との超簡単連携 出典： https://docs.cloud.google.com/spanner/docs/databoost/databoost-overview?hl=ja
62. External Query BigQuery上で発行できるクエリ。 稼働中のCloud SQLやCloud Spannerに対してBQから直接クエリを実行できる。 あらかじめ設定していたSpanner外部接続（Data Boost）に対してExternal Queryを発行する ことで、BQにデータを読み込まずとも、Spannerの現時点でのデータを読み込むことができ る。 魅惑のSpanner - BQ との超簡単連携
63. ただし都度External Queryを書くのは大変。 なので、あらかじめBQのViewとしてExternal Queryのクエリ文を保存する。 もともとのテーブル名と同じ名前のViewを作っ ておくと、 SELECT * FROM `datasetname.tests `; のようなクエリをかける。 外部接続（Data Boost）+ External Queryを 使った状態でも、非常にシンプルにクエリを発 行できる。 魅惑のSpanner - BQ との超簡単連携
64. ここまでSpanner の 良いところばかり言ってる …
65. でも、お高いんでしょう？
66. 標準インスタンス1ノードで$854（約13万円） プラス ストレージ使用量 意外と安い？ Spanner
67. 標準インスタンス1ノードで$854（約13万円） プラス ストレージ使用量 意外と安い？ Spanner 高い！！！
68. そんなあなたに Granular Instance Sizing + Spanner CUD Granular Instance Sizing は、Spannerのノード「処理ユニット」単位で 分割して使用できる仕組み。1ノード1000PU。 最小単位は100PUなので0.1ノードの値段で使用できる。 Spanner CUD はリザーブドインスタンスのようなもの。 使用の確約をすると割引がされる。 1年確約で20％引き。3年確約で40％引き。 意外と安い？ Spanner
69. 0.1ノード（100PU）で3年確約のCUDを契約する ミニマムの構成であれば、 $854 * 0.1 * 0.6 = $51(約8000円) + ストレージ使用量 意外と安い？ Spanner
70. 0.1ノード（100PU）で3年確約のCUDを契約する ミニマムの構成であれば、 $854 * 0.1 * 0.6 = $51(約8000円) + ストレージ使用量 意外と安い？ Spanner 思ったよりも安いのでは？
71. • はじめに • 普通のRDBMS • 分散DB（NoSQL ） • 余談 • Cloud Spanner ◦ メリット ◦ デメリット • まとめ アジェンダ
72. 教えて下さい Spanner のデメリット
73. 教えて下さい Spanner のデメリット だってもう時間がない
74. 教えて下さい Spanner のデメリット だってもう時間がない 懇親会で話しましょう！
75. • はじめに • 普通のRDBMS • 分散DB（NoSQL ） • 余談 • Cloud Spanner ◦ メリット ◦ デメリット • まとめ アジェンダ
76. • RDBは整合性、一貫性に重きを置いたデータベース • NoSQLは、可用性、拡張性が非常に高いデータベース • Spannerは多機能ですごい ◦ 尺の都合で割愛したが、Spannerには無停止垂直スケーリングや INTERLEAVEな どの他の特徴もある ◦ そして最小構成なら意外とお安い • Spannerを始めとしたNewSQLは、RDBとNoSQLの良いところを掛け合わせたような データベース ◦ TiDBやAlloyDB、CockroachDBもNewSQL • 最初からある程度の規模になることが見込まれて、簡単なスケーリングの仕組みが欲し いプロダクトなら、導入しても良いのでは？ まとめ
77. Thank you!
78. • Google「Cloud Spanner と CAP 定理」 （https://cloud.google.com/blog/ja/products/gcp/inside-cloud-spanner-and-the-cap-theore m） • Google 「Data Boost の概要」 （https://docs.cloud.google.com/spanner/docs/databoost/databoost-overview?hl=ja） • Google「Spanner の仕組み: 厳格な直列化可能性と外部整合性について理解する」 （https://cloud.google.com/blog/ja/products/databases/strict-serializability-and-external-co nsistency-in-spanner） • Google「Spanner の料金」（https://cloud.google.com/spanner/pricing?hl=ja） • Google 「Spanner: TrueTime と外部整合性」 （https://docs.cloud.google.com/spanner/docs/true-time-external-consistency?hl=ja） • IBM「CAP定理とは何ですか?」（https://www.ibm.com/jp-ja/think/topics/cap-theorem） • @kumagi 「Spanner」（https://qiita.com/kumagi/items/7dbb0e2a76484f6c522b） • Yasui Michitaka「フツーのデータベースとしての Spannerを使うには」 （https://zenn.dev/google_cloud_jp/articles/2f85d7dcd0ced7） 参考文献