〜進化の歴史から紐解く、スケーラブルアーキテクチャの設計指針〜 クラウドネイティブ DBは いかにして制約を 克服したか？ @bootjp クラウドネイティブ会議 2026 

今日の流れ 01 自己紹介と弊社について 02 クラウドネイティブDBとは 03 旅の出発点: ある SaaS の成長痛 04 制約 ─ すべての出発点 / 進化のマイルストーン 05 第 1 章: 書き込みスケールの壁 ─ シャーディングの系譜 06 第 2 章: I/O 負荷とスケーリングの壁 ─ ログ適用型ストレージの系譜 07 第 3 章: 強い一貫性の壁 ─ 分散合意とグローバル順序づけの系譜 08 3章の統合: NewSQLへの帰結 09 応用: 最適な選択基準の策定 10 まとめ: 分散システムの設計指針 

この発表が終わったときに目指す状態  3つの課題の整理 クラウドネイティブ DB が解いてきた 課題を整理して理解できる  適切なトレードオフの選択 要件（書き込みスケール / I/O / 一貫性） に対する適切な選択肢が見える  進化の歴史と系譜 DB の進化の歴史を辿って設計判断 の系譜が理解できる  背景にある制約の把握 各 DB の設計判断の背景にある制約を読み取れる  分散システム設計の 3指針を持ち帰れる ① 制約の明示化 ② 責任の分離 ③ トレードオフの選択 

自己紹介 Yoshiaki UEDA @bootjp 株式会社hacomono プリンシパルエンジニア （分散システム） 経歴（前略） 2018年〜2021年: Supership株式会社 ●スマホ向け大量配信システムの開発/運用 ●検索・検索連動広告 開発/運用 2021年〜2023年: 株式会社プレイド ●大量配信システムのリプレース ●分散システムの相談窓口 2023年〜2024年: btj.systems合同会社 ●Raftを用いた分散ストレージの研究/開発 2024年〜現在: 株式会社hacomono ●プリンシパルエンジニア（分散システム） ●基盤本部にて社内共通基盤を設計/開発 

5 会員管理・予約・振替・キャンセル・決済・請求管理・売上管理・債権管理 入退館・EC・POS・本人認証カメラ・QRリーダー・ ・総合フィットネスクラブ ・ヨガ・ピラティス ・パーソナルジム ・24時間ジム フィットネスクラブ ・屋外運動場 ・屋内運動場 ・体育館 ・水泳プール ・学校 ・レジャー施設 公共運動施設 ・Jリーグ（サッカー） ・Bリーグ（バスケットボール） ・野球チーム・サッカーチーム etc スポーツチーム ・スイミングスクール ・ダンス・バレエスクール ・ゴルフスクール ・テニススクール ・カルチャースクール ・空手・体操スクール ・サッカースクール 運動スクール ウェルネス施設の手続きをすべてデジタル化 ウェルネス産業を、新次元へ。 

12,000店舗・施設での導入実績 ヨガ・ピラティス パーソナルジム 24時間ジム 総合スポーツクラブ 運動スクール プロスポーツ（サッカー・バスケ） 公共運動・学校施設 ゴルフ サウナ・エステ コワーキング 

DB ではこう実現される 疎結合の実現 Compute / Storage 分 離 ステートレスな計算層と共有ストレージに よる柔軟な構成 管理力・回復性 マネージド運用 / 自己修 復 自動フェイルオーバと運用自動化による 低負荷な運用 DB固有の整合性 分散合意 + 時刻順序 分散環境下での強い一貫性と正しい実行 順序の保証 クラウドネイティブ DB とは何か CNCF Cloud Native Definition v1.1 の定義を登壇者が抜粋 近代的でダイナミックな環境において、 ● ① 動的にスケールできる能力 をもたらす ● ② 回復性・管理力・可観測性のある疎結合システム を実現 ● ③ インパクトのある変更を最小限の労力で 行える スケーラビリティ 動的スケーリング / Scale to Zero スケーラビリティの実現 (秒〜分単位の replica 追加・削除 一部 DB は Scale to Zero まで対応: Aurora Serverless v2 / Neon) 

クラウドネイティブ DB とは何か CNCF Cloud Native Definition v1.1 (登壇者抜粋 ) 近代的でダイナミックな環境において、 ① 動的にスケールできる能力 ② 回復性・管理力・可観測性のある疎 結合システム ③ インパクトのある変更を最小限の労 力で CNCF 定義の 3項目は、DB では 4つの実装パターンに分解される A ① 動的にスケールできる能力 B ② 疎結合・回復性・管理力 C ③ 最小限の労力での変更 1 スケーラビリティ 動的スケーリング / Scale to Zero 2 疎結合の実現 Compute / Storage 分離 3 管理力・回復性 マネージド運用 / 自己修復 4 DB 固有の整合性 分散合意 + 時刻順序 

旅の出発点 ─ あなたは急成長する SaaSのSRE／DBAです ストーリ設定 ● 単一プライマリのDBで運用している SaaS が成長期に入り、書き込みスループットが頭打ち ● スケールアップしたいが、もうこれ以上大きなインスタンスサイズがない ● 「将来の海外展開を視野に、整合性は今のまま維持する必要がある、レイテンシも今くらいで」 順番に立ち現れる 3 つの壁 (詳細は次スライド) 壁 ① 書き込みボトルネック トレードオフ : 運用負荷 書き込みが頭打ち 由来: 単一ノード性能上限 CPU/RAM/I/O 帯域) 壁 ② I/O 負荷とスケーリングの 壁 トレードオフ : ネットワーク帯域 従来型アーキテクチャでは困難な、需要に合 わせた柔軟かつ高速な拡張 壁 ③ 分散下の強い一貫性 トレードオフ : レイテンシ ネットワーク遅延や分散環境下での、データ 整合性とパフォーマンスの両立 

進化のマイルストーン ─ 「進化の歴史」の地図 19902000 201114 出発点 201516 分散化加速 202122 クラウドネイティブ 202425 次世代エコシステム 壁 ② I/O 負荷 とスケー リングの 壁 壁 ③ 分散下の 強い一貫 性 TrueTime Spanner Raft / HLC / TSO CockroachDB / TiDB / YugabyteDB ClockBound AWS OSS Aurora DSQL / YugabyteDB ClockBound統合 制約の明示化 → 責任の分離 → トレードオフの選択 という設計判断の進化 Paxos Lamport) マネージド シャーディング Aurora Limitless コンピュート /ストレージ分 離 インテリジェントストレー ジ Aurora シェアード ナッシング Spanner (サービス) コンピュート /ストレージ分離 インテリジェントストレージ Neon / AlloyDB ARIES MOHAN 壁 ① 書き込み ボトル ネック シェアード ナッシング Spanner (論文) シェアードナッシング CockroachDB / TiDB / YugabyteDB シェアード ナッシング Aurora DSQL マネージド シャーディン グ Vitess / Citus 

制約 ─ すべての出発点 壁 ① 書き込みの限界 単一ノードの上限と運用痛 ● 単一プライマリでの書き込み頭打ち ● 単一障害点 SPOF のリスク ● 手動シャーディングの運用負荷 壁 ② IO負荷/スケーリング スケーラブルなアーキテクチャへ ● 従来 RDB のアーキテクチャ限界 ● 可用性と拡張性の両立困難 ● ハードウェア故障時のリカバリ負荷 ● 高速なスケールアウトが不可能 壁 ③ 一貫性の困難 分散環境における整合性維持 ● ノードのクラッシュの復旧 ● 不可避な「時計のズレ」 ● レプリケーションラグの影響 ● イベント順序の非決定性による不整合 本日の核心 制約を克服する 3つの設計指針 ① 制約を明示化する ─ 暗黙の前提を捨て、API・構造・境界として「可視化」する ② 責任を分離する ─ compute / storage、replication / transaction... 層をまたぐ責任を切る ③ トレードオフを選ぶ ─ 何を守り、何を犠牲にするか意図的に決める 「なぜスケールし、何を犠牲にするのか」を問う 

第 1 章: 単一プライマリの書き込み限界 ボトルネックの要因 DISK IO / CPU（ロック競合、計算）/ 帯域 / RAM 垂直スケール（CPU/メモリ追加）の限界 物理由来: 単一ノード性能上限 CPU/RAM/I/O 帯域) 解決策 データを複数ノードに分散し、書き込み を並列化する ※ シャーディングによりスループットを水平にスケール シャーディングの配置場所による設計パターン 手動シャーディング アプリケーションに シャーディングロジックを持つ  マネージドシャーディング シャーディング ミドルウェアを用いる  シェアードナッシング ネイティブ シャーディング  

⼿動シャーディング ─ 出発点 アプリケーション側でシャードキーを管理する原始的な⽔平分割 得たもの ● 書き込みスケール ● データ局所性 ● 障害影響範囲の分離 失ったもの ● クロスシャード JOIN ● 分散トランザクション ● 透過的なリバランス 運⽤上の痛み ● シャード追加‧リバランスが⼿作業で重い ● アプリ側にデータ配置ロジックが漏れる ● シャードキー変更が事実上不可能 

マネージドシャーディング ─ ミドルウェアで隠蔽 ミドルウェア‧プロキシ層が複雑なシャーディング構造を抽象化 代表例 ● Vitess (MySQL 前段) ● Citus (PostgreSQL 拡張) ● Aurora PostgreSQL Limitless(Router Base) 進化点 ● シャード管理の⾃動化 ● 透過的なクエリルーティング ● リシャーディングの簡素化 重要な制約 ミドルウェアで隠蔽したとしても、データ局所性の設計は不可⽋ 分散クエリの効率低下: ノード間を跨ぐJOINや集計処理のパ フォーマンス劣化 

シェアードナッシング ─ ⾃動レンジ分割型 各ノードが独⾃の CPU/メモリ/ディスクを保持し、運⽤中に ⾃動 リバランス を実⾏ 代表例‧技術 ● Spanner ● CockroachDB ● TiDB ● YugabyteDB 利点 ● ノード追加による⽔平スケール ● ⾃動でのリバランス（Split, Merge） 課題 ● 特定ノードへの負荷集中（ホットスポット）： シーケンシャルなキー設計による書き込みの偏り。 ● 通信オーバーヘッドによるレイテンシ： ⼀貫性維持（Paxos/Raft）のためのノード間通信コスト。 ● 分散クエリの効率低下： ノード間を跨ぐJOINや集計処理のパフォーマンス劣化。 ※ 第 3 章「強い⼀貫性」で再登場します 

第 1 章のまとめと残る課題 第 1 章の総括: シャーディングによる克服 シャーディングはデータ局所性を制約として明⽰化し、責任の所在を移動させ、分散処理トレードオフを選択し た ① 制約の明⽰化: シャードキー設計＝「データ局所性」を明⽰的に設計に組み込む ② 責任の所在の移動: アプリ → ミドル → DB⾃⾝（隠蔽の度合いが向上） ③ トレードオフの選択: 分散処理（JOIN/トランザクション）やリバランスコストの受容 [SaaS 適⽤] 冒頭の SaaS なら、書き込みスケールの向上には シャーディングが有⼒な候補となる 残る課題 シャーディングでも解決しない別次元のボトルネック： ● 1 ノード内の I/O 負荷限界 ● リカバリ‧ノード追加の⾼いコスト ● より⾼速で柔軟なスケーリングの必要性 第 2 章へ → 

第 2 章: 従来 DB の I/O 増幅と悪循環 CONTEXT 「単⼀サーバー前提アーキテクチャ」における課題：多すぎる責務が I/O 増幅を招き、スケーリングを困難にする STEP 01 多すぎる責務 1 台ですべてを処理する構造 ● ログ⽣成 / ページ更新 ● チェックポイント作成 ● レプリケーション / バックアップ ● リカバリ STEP 02 I/O 増幅の発⽣ 1 更新が複数の物理 I/O に ● ログ⽣成 ● バックアップ⽤ログの⼆重書き ● フルページ書き込み ● データページ書き出し STEP 03 負の連鎖 (悪循環) スケール操作が更なる負荷に ノード追加には重いデータコピーが必 須。負荷が⾼い時にスケールアウトしよ うとすると、そのコピー処理でさらに負 荷が上がる⽭盾。 

悪循環をどう断つか — 「分離」と「ログ適⽤型スト レージ」 「単⼀サーバー前提」を超える解は、2つの設計転換の組み合わせ ① コンピュート / ストレージの分離 ● 単⼀サーバー前提を解く第⼀歩 ● スケール操作からデータコピーを切り離す ● ステートレス化されたコンピュート層で柔軟なス ケール ② ログ適⽤型ストレージ "Log is the DB" ● 分離だけでは I/O 増幅は解決しない ● 「redo log のみ送信」+「ストレージ側でログ適⽤ → ページ実体化」が本質 ● ストレージ層がページ転送を不要にする 続く3スライドで「なぜ分離が答えなのか」を3つの動機から詳説 ① ノード追加コストの解消 / ② きめ細かなスケーリング / ③ ⾮対称なリソース利⽤ 

なぜ分離するのか ① ─ ノード追加コストの解消 従来の課題 ● ノード追加 = データの物理コピーが必要 レプリケーション転送 / ストレージ上のデータコピー ● プライマリや既存ストレージの負荷増⼤ 解決：分離によるコストと時間の解消 ● ストレージを分離し共有すれば、コンピュート追加時のデータコピーが不要に ● 共有ストレージ参照のみで起動：ノードの追加が 数時間 → 数秒 に短縮 ⽭盾 ⽭盾: 負荷が⾼いからこそスケールしたいが、ス ケール操作が更に負荷を⾼める → 余剰確保で無駄 が発⽣ 

なぜ分離するのか ② ─ きめ細かなスケーリング コンピュートをステートレスに ● 必要な時に追加し、不要になったら削減でき る ● 分単位の弾⼒性を実現可能 Scale to Zero ● Aurora Serverless / Neon は「コンピュート ノード 0 台」の状態を作れる ● アイドル時のコストをゼロに ● リクエスト到来時に瞬時にスケールアップ  コンピュートとストレージが分離されているからこそ可能 ステートレスなコンピューティング層により、リソースの制約を受けずに⾃由なスケールアウト‧インが可能になります。 

Compute アプリ負荷に応じて分単位 で増減 スパイク型 Storage 削除を除き保存量は減らな い（IO負荷は別） 単調増加型 結果 ─ 責任の分離 ● I/O 増幅‧ノード追加コスト‧⾮対称性を すべてストレージサービス層に分離 ● クラウドネイティブ DB の 中核設計思想 として "compute / storage 分離" が標準に 同⼀サーバーに固めると⽚⽅の都合で両⽅を増減 → 別々にスケールが合理的 なぜ分離するのか ③ ─ ⾮対称なリソース消費 

Aurora の発想転換 "Log is the DB" Aurora 論⽂の問題設定 ● 制約の移動: 中⼼制約は compute/storage から network へ移った ● 並列化への拡張: ARIES の WAL 1ノード前提を、スト レージ並列化 に拡張 「THE LOG IS THE DATABASE」 ● コンピュート層: redo log record だけを⽣成‧送信 ● ストレージ層: redo log からページを再構築 多責務をストレージに押し出す哲学 単なる「分離」ではなく、以下の重要機能をストレージサービス側に集約: redo 処理 / fault-tolerant storage / self-healing / quorum = "Log is the DB" はクラウドネイティブDBの本質的な設計思想 

ログ適⽤型ストレージのしくみ Compute Node Storage Node 主な動作プロセス 01. Compute redo log のみを送信 ページ全体ではなく変更履歴（redo log）のみを送ることで、ネットワーク 負荷を最⼩化します。 02. Quorum 書き込みの確定 Auroraの場合、6コピー中4つのAckで完 了（Write 4-of-6）とする多数決⽅式で、 ⾼い可⽤性を実現します。 03. Storage ログ適⽤と実体化 受信したログの適⽤、ページの実体化、 バックグラウンドでのクリーンアップを ⾃律的に実⾏します。 

ログ適⽤型ストレージの効果：数値出典の整理 Network I/O & Throughput の劇的な改善 Network I/O 削減 7.7倍 出典: Aurora SIGMOD 2017 Table 1 Throughput 向上 35倍 出典: SysBench 30分テスト（Section 5）  数値の解釈に関する補⾜ これらの論⽂で⽰された劇的な数値は、クラウドネイティブ特有の「ログ適⽤型ストレージ」がネットワーク帯域 とStorage I/Oの増幅（Write Amplification）をいかに根本的に解決したかを証明するものです。 

業界横断のパラダイム: Aurora / Neon / AlloyDB Aurora AWS, 2014~ log-applied storage の元祖 ● 6-way / 3 AZ ● Limitless で⽔平スケール ● DSQL で multi-region active-active AlloyDB Google Cloud, 2022 Paxos + HTAP ● 内部: Log Processing Service (LPS) ● カラムナエンジンで HTAP 対 応 ● Omni でオンプレミス環境に も対応 Neon Serverless Pageserver + Safekeeper 構 成 ● Paxos-based consensus ● Branching / Scale to Zero ● 秒単位の課⾦体系 

第 2 章のまとめと残る課題 第 2 章の総括: ログ適⽤型ストレージによる「分離」 ● ① 制約の明⽰化: I/O 増幅を「redo log のみ送信 + ストレージ側で実体化」として明⽰化 ● ② 責任の分離: compute と storage を別の層として切り離す（"Log is the DB"） ● ③ トレードオフの選択: ネットワーク帯域 / quorum 待ちレイテンシ [SaaS 適⽤] 最適な選択肢 運⽤負荷軽減 ● 定常的な負荷→ Aurora / AlloyDB ● スパイクベースの負荷→ Neon / Aurora Serverless 詳細は弊社ブログ「クラウドネイティブなDBはなぜ分離 するのか」を参照 残る課題: 整合性の壁 コンピュートを分離しても、複数ノードに跨る 整合性‧順序づけは依然として別次元の難題 第 3章へ → 

第 3 章: 強い⼀貫性の壁 [現在地] 第3章のロードマップ STEP 1 課題: 複数ノードに跨る整合性 STEP 2 2PC では死ぬ → 分散合意 (Paxos / Raft) STEP 3 合意だけでは⾜りない → 時刻順 序が必要 STEP 4 各 NewSQL のアプローチ (TrueTime 他) [現在地] 第 3 章 / 3 章中 ─ 強い⼀貫性の壁 (本⽇の⼭場)  制約: 分散環境の物理限界 ノード間クロックのズレ / ネットワーク遅延 (RTT) / ⾮同期性 → レプリケーションラグ‧データ不整合‧イベント順序の⾮決定性を引き起こす  解の系譜: 分散合意+グローバルの⼀貫した時刻 分散合意: Paxos / Multi-Paxos / Raft 時刻同期: TrueTime / HLC / TSO / ClockBound  → 不確実性 API で明⽰化 + レイテンシでトレードオフを⽀払う commit wait / OCC retry / TSO 待ち ※ DB ごとに異なる選択 

課題: 複数ノードに跨る整合性 分散すると、複数ノード間での「合意」と「順序づけ」 が必要  1. replication 順序 レプリカ間でログ順序を一致させる (= 分散合意)  2. transaction 順序 実時間の順序づけ (= グローバル時刻 ) 両方解かないと 強い一貫性 には到達しない 

2PC では死ぬ ─ なぜ合意プロトコルが必要か 古典的な答え: 2PC Two-Phase Commit) ─ coordinator が prepare → commit を指示 だがこれが致命的に脆い : ! coordinator が死ぬと止まる 残った worker は commit/abort を判断できない ! 不確定状態のまま worker はロックを保持し続ける (= 連鎖的にハング) ! 死んだと思った coordinator が復活すると不整合が起きる 片方は abort 済み・もう片方は committed = 食い違って死ぬ  これは「トランザクション /レプリケーション層」の脆さ Paxos / Raft が解決 

分散合意 ─ Paxos / Raft 分散合意 ─ Paxos / Raft 多くの NewSQL が Raft を採用 Paxos 系：Spanner Multi-Paxos) / Neon Raft 系：CockroachDB / TiDB TiKV / YugabyteDB / etcd / Consul Raft が解いてくれること  自動フェイルオーバー リーダー障害時の自動再選出  データの自動同期 ログレプリケーション  一貫性の維持 リーダー経由 / コミット済みは必 ず読める / StaleRead なし  ネットワーク分断耐性 過半数側が継続、少数派は停 止 本発表では深掘りしない 詳細は別発表「NewSQL や分散データベースを支える Raft の仕組み (db tech showcase 2025 LT9」を参照 

しかし合意だけでは足りない 分散合意の限界 Paxos / Raft が解くのは "レプリカ間でログ順序 を一致させる" こと = replication 順序 分散トランザクションの要件 データ安全性は守れるが、もう一つの順序が必要 もう一つの順序 ＝ transaction 順序 transaction 順序 = 実時間順序 (T1 が T2 より先にコミットしたなら、誰から見ても T1 が先) これを解くには 時刻同期の仕組み が要る 一貫性を保証するためには、ログの順序だけでなく「時間」の合意が不可欠 

分散DB の中核処理は時刻に依存する 分散MVCC・Snapshot Isolation・Read at Timestamp 分散DBの根幹は「時刻」で動いている 分散MVCC 単一ノード : 「カウンタ」 ● PostgreSQL: xmin/xmax XID ● MySQL DB_TRX_ID 分散DB 「時刻」が必要 各ノードが独立にIDを発番できない ため、グローバルなタイムスタンプが 必要 ● Spanner: TrueTime ● CRDB / Yuga: HLC ● TiDB TSO Snapshot Isolation ● トランザクション開始時刻 (read_ts) を固定 ● その時刻のスナップショットを全期 間読む ● 全ノードで「どの時刻か」の合意が 必要 ※ TiDB / CRDB / Yuga の主要分離レベ ル Read at Timestamp / Time Travel ● 特定の時刻の状態を読む ● Spanner: ReadAt(timestamp) ● CRDB AS OF SYSTEM TIME ● TiDB: tidb_snapshot ※ クロックスキューが大きいと整合性が 壊れる 単一ノードはカウンタで足りた。分散DBは「時刻」を必要とする。 → だから時刻同期は本質課題（次スライドへ） 

物理的な限界 ● ノード間のクロックは必ずズレる ● NTP: ms 級 / PTP: μs 級 ● ネットワーク通信のラグ (RTT) 根本的な課題 「どのトランザクションが先か」を全 ノードで合意するのは本質的に困 難 分散システムにおいて 「実時間」を共有することは システムの整合性を保つ鍵となる 各 NewSQL によるアプローチ Spanner TrueTime API + Commit Wait ハードウェア(GPS/原子時計)を利用 CockroachDB / YugabyteDB HLC (Hybrid Logical Clock) 物理時刻と論理時刻のハイブリッド TiDB TSO + PD 集中型タイムスタンプ発番 詳細は弊社ブログ「分散システムにおける一貫した時刻の取り扱いの課題と解決策 」をチェック 時刻同期の難しさ では、なぜ分散 DBで時刻同期は難しいのか 

Spanner ─ TrueTime + Commit Wait T1 commit → timestamp s 割当 → TT.after(s) になるまで wait (= ε ms) → T1 可視化 → T2 (後発) は T1 の後に保証 External Consistency (外部一貫性 ) 「未来を待つ」ことで、分散システム上の実時間順序を タイムスタンプ順序として厳密に保証する Spanner は Commit Wait により、不確実性 ε を超えるまで待機することで一貫性を確保する 

基本概念: 時刻を「区間」として扱う 時刻を [earliest, latest] の区間として定 義。クロックの不確実性 (ε) を API として明示的に露 出する。 比喩: 「12:00:00 ± 3ms」の不確実区間のある時計。 12:00:00.003まで待てば、世界中のノード郡のどの時計でも 確実に「過去」と言える。 不確実性区間を小さくするための技術 ● 不確実性区間: 1〜7 ms (2012年論文時点) ● p99 < 1 ms (2023年 Google Cloud Blog) (出典: Google Cloud Blog "Strict Serializability and External Consistency in Spanner", 2023) Commit Wait: 不確実時間分の時刻を待機し、「未来を待つ」ことで最強の整合性を実現 ε 程度の待機時間を設けることで、実時間順序 = タイムスタンプ順序 を保証 ※ p99 < 1ms はデータセンター内 ε の値。実際のユーザ体感レイテンシには Replication と RTT が加算されます。 Spanner ─ TrueTime のアイデア 

CockroachDB ─ HLC (Hybrid Logical Clock) HLCの基本メカニズム 実時刻 (システム時計値) + 論理カウンタを組み合わせる方式 直感: 物理時刻だけでは因果が逆転する → Lamportの論理時 計を物理時刻に「進んでいる方に合わせる」形で重ね、ズレを吸 収 専用ハードなし : 汎用NTP環境でも因果順序を追跡可能 整合性の制約と異常系 strict serializable は提供しない 公式: single-key linearizable + serializable isolation (worst caseで sequential consistency) causal reverse 異常を許容 (例: 書込み直後のクライアントが他者後 続書込みを「自分のより前」と認識) 安全側への設計 (Fail-Safe) ノードの clock offset 平均値が他ノードの過半数に対して 400ms (=max-offset 500ms × 80%) を超えると自己 shutdown ※ 意識的な設計判断: commit wait を回避する代わりに、retry が多発しうる 

TiDB ─ TSO + PD 基本メカニズムとアーキテクチャ ● TSO (Timestamp Oracle): 集中型タイムスタンプ発番サービス ● PD (Placement Driver): TSO を提供。Raft で冗長化され、DC 内なら ms クラスで取得可能 ● Snapshot Isolation: 分離レベルの中心 強み (Advantages) 順序づけがサービス化（集中管理）されており、HLC のような複雑な時刻 ズレ管理から解放される 弱みと課題 (Challenges) ● レイテンシ : cross-DC 環境では TSO 取得自体がボトルネックとなる要因 ● 単一障害点 /スケーラビリティ : PD の可用性とスケール性能がシステム全体 の鍵 

YugabyteDB ─ HLC + ClockBound 基本メカニズムと新統合 ● 基本は CockroachDB と同じ HLC + Raft (per-tablet) ● v2025.2 LTS で AWS ClockBound 統合 ─ TrueTime に近い区間 API を活用 ● PHC (PTP Hardware Clock) 連携 ─ μs 級 skew を実現 実測パフォーマンス向上 ClockBound 有効時 (AWS APN Blog 実測値): ● Transaction Latency: 最大 3× 短縮 ● Throughput: 2× 向上 ● ※ 条件: RF=3 / geo-distributed 2025-2026 トレンド: クラウドが時刻不確実性 API を提供する時代へ AWS PHC (2023〜) + ClockBound OSS (2021〜) の組み合わせにより、TrueTime 相当の機能が汎用クラウドで利用可能 に 

各 DB の設計判断比較 指針②責任の分離 — どこに責任を分離したか Spanner (Google, 2012): TrueTime + GPS/原子時計 → トレードオフ: commit wait (代償: ε ms の wait / strict serializable) Aurora DSQL (AWS, 2025 GA): Time Sync Service + Journal → トレードオフ: OCC retry (代償: 競合時の retry / region-set 内) CockroachDB (2015〜): HLC (汎用 NTP) → トレードオフ: retry + causal reverse 許容 (代償: serializable で causal reverse を通す) TiDB (PingCAP, 2016〜): PD/TSO → トレードオフ: PD 取得待ち (代償: Snapshot Isolation / cross-DC レイテンシ) YugabyteDB (2016 / ClockBound 2025): HLC + ClockBound → トレードオフ: クラウド時刻 API (代償: AWS/GCP 限定 / Serializable まで選択可) → 「どれが優れているか」ではなく 不確実性コストをどこで払うか 

第 3 章のまとめ これまでのまとめ：強い一貫性の獲得とその代償 ① 制約の明示化 : 時刻不確実性をAPI に組み込む ② 責任の分離 : 時刻管理を分離する ③ トレードオフの選択 : commit waitによる書き込み / OCC によるリトライレイテンシ / TSO 取得レイテン シ Spanner/NewSQL は分散合意+時刻順序で 『強い一貫性』 を獲得し、 代償として レイテンシ (commit wait / OCC retry) を払う [SaaS 適用] 冒頭の SaaS なら： ● serializable 必須なら Spanner / CockroachDB ● Snapshot ISOLATION で OK なら DSQL / TiDB / YugabyteDB ここから ・3つを 1製品で統合した姿(= NewSQL) ・DB を超えた分散システム一般への応用 

NewSQL の要素技術 ・壁①のみ解く → シャーディング DB (Vitess / Citus) ・壁②のみ解く → クラウド RDB (Aurora / AlloyDB / Neon) ・壁③のみ解く → 分散 KVS (etcd / Consul) ・壁①②③すべて解く → NewSQL ★ 5つの NewSQL は 3軸でどう解いているか 製品 壁① 書込スケール 壁② I/O・分離 壁③ 強い一貫性 Spanner auto split/merge Colossus + Paxos TrueTime + Commit Wait CockroachDB range 分割 local + Raft HLC TiDB region 分割 TiKV + Raft TSO / PD YugabyteDB tablet 自動分割 DocDB + Raft HLC + ClockBound Aurora DSQL region-set Journal + 分離 Time Sync Service + OCC 同じ "NewSQL" でも、3軸の選び方で性格が変わる → 次スライドの選択基準へ 3 つの壁を統合する ─ NewSQL の正体 3 つの壁を統合する ─ NewSQL の正体 

銀の弾丸はない ─ 選択基準 壁① 書き込みスケールを優先 MySQL互換で大規模分割 → Vitess / TiDB PostgreSQL互換で水平分割 → Citus/ Aurora Limitless 壁② I/O負荷・運用負荷を優先 単一region・運用簡素化 → Aurora / AlloyDB Scale to Zero・コスト効率 → Neon / Aurora Serverless 壁③ 強い一貫性を優先 単一クラウドで強整合 → Aurora DSQL → Spanner マルチクラウド対応 → CockroachDB / YugabyteDB / TiDB 経験則 (発表者の現場観察 ): ● 3つの壁すべてが本当に必要 → NewSQL系が見合う ● 2つ以下しか必要ない → マネージド DBで十分 

3指針 × 5つの問い ① 制約を明示化する Q1: 何をスケール？ 書込み大量 → Limitless / Vitess / NewSQL 系　　読込中心 → Aurora ② 責任を分離する Q2: どこにデータ配置？ 単一 region → Aurora / Spanner 全大陸 → Spanner 2region active → DSQL Q5: 誰が複雑性を？ ベンダー全任せ → マネージド 自社運用 → OSS ③ トレードオフを選ぶ Q3: どの整合性？ strict serializable → Spanner / DSQL SI → TiDB / Yuga RC で十分 → Aurora Q4: 何を犠牲に？ commit wait 許容 → Spanner retry 許容 → DSQL causal reverse 許容 → CockroachDB TSO 待ち許容 → TiDB 

3指針 × 分散システム 同じ問いは メッセージングなどあらゆる分散システムに効く ① 制約を明示化する Q1: 何がボトルネックか ? (何が問題か ) 軸: スループット / レイテンシ / 容量 / 同時実行数 / 信頼性 例: DB→書込QPS・I/O / メッセージング→配信遅延 / 計算→CPU・メモリ / ストレージ→IOPS・帯域 ② 責任を分離する Q2: 状態の境界をどこに引くか ? 軸: ステートフル↔ステートレス / 共有↔局所 / 集権↔自律 例: DB→compute/storage 分離 / サービス→ステートレス+共 有ストア / 計算→イミュータブル+シャッフル Q5: 複雑性をどの層で吸収するか ? 軸: アプリ / ライブラリ / プラットフォーム / マネージド 例: DB→アプリ→ミドルウェア→DB自身 / サービス→アプリ →Service Mesh→Platform へ責務移動 ③ トレードオフを選ぶ Q3: どの一貫性レベルか ? 軸: Linearizable > Sequential > Causal > Eventual 例: DB→Strict Serializable / SI / RC / メッセージング →Exactly / At-least / At-most-once Q4: 何のコストを払うか ? 軸: レイテンシ / 可用性 / コスト / 運用複雑性 / 重複処理 例: DB→commit wait・OCC retry / メッセージング→重複 or 順序 or 遅延 同じ問いを問う限り、答えは変わっても設計の枠組みは変わらない ⚠ 大前提：分散システムを作らない！ 複雑なシステムは運用に困難が生じます。 制約を解決するために本当に分散システムが必要か、十分 に考慮してください。 

まとめ ─ 3 つの壁を越えてきた進化 制約 ↔ 分離 ↔ トレードオフ 壁 ① 書き込みボトルネック・運用負 荷 → シャーディング、そして自動化 (アプリ → ミドルウェア → DB 自身) 壁 ② I/O 負荷・スケーリング → ストレージ分離、ストレージインテリ ジェント化 (ログ適用型ストレージ) 壁 ③ 分散環境下の強い一貫性 → 分散合意アルゴリズム + 一貫した時刻の管理 commit wait / OCC retry / TSO 待ち / クラウド 時刻 API 選択は「最強」ではなく「最適なトレードオフ」 ● 自分の要件で要らない機能の代償を払わない 制約は消えない。 ①制約を明示化 し、②責任を分離 し、③意図的にトレードオフ を選ぶ 

本資料中で紹介した技術詳細の資料 hacomono hacomono Tech Blog 「クラウドネイティブなデータベースはなぜコンピュートとストレージを分離するのか」 (compute/storage 分離の詳細) https://techblog.hacomono.jp/entry/2024/12/18/000000 「分散システムにおける一貫した時刻の取り扱いの課題と解決策 - Spanner TiDB CockroachDB に学ぶ」 (時刻 同期の詳細) https://techblog.hacomono.jp/entry/2025/12/12/000000 db tech showcase 2025 LT9 「NewSQL や分散データベースを支える Raft の仕組み ─ 仕組みを理解して知る得意不得意」 (Raft 詳細) https://speakerdeck.com/hacomono/the-mechanism-behind-newsql-and-distributed-databases-raft-understanding-and-learning-the-mechanism-strengths-and-weaknesses 

Thank You & QA / 参考文献 主要論文 (1/2) ARIES (1992) ─ MOHAN https://web.stanford.edu/class/cs345d-01/rl/aries.pdf Paxos (Lamport) https://lamport.azurewebsites.net/pubs/paxos-simple.pdf Spanner (OSDI 2012) https://research.google.com/archive/spanner-osdi2012.pdf HLC: Logical Physical Clocks ─ Kulkarni https://scispace.com/pdf/logical-physical-clocks-3ncmjqu0fu.pdf What's Really New with NewSQL? SIGMOD Record 45(2), 2016 - https://dl.acm.org/doi/pdf/10.1145/3003665.3003674 hacomono 主要論文 (2/2) Amazon Aurora: On Avoiding Distributed Consensus for I/Os, Commits, and Membership Changes https://dl.acm.org/doi/abs/10.1145/3183713.3196937 Amazon Aurora: Design considerations for high throughput cloud-native relational databases https://www.amazon.science/publications/amazon-aurora-design-consider ations-for-high-throughput-cloud-native-relational-databases Dong, H. et al "Cloud-Native Databases: A Survey" IEEE TKDE 36(12), 2024 - https://dl.acm.org/doi/10.1109/TKDE.2024.3397508 Raft: Understandable Consensus (Ongaro 2014) https://www.usenix.org/conference/atc14/technical-sessions/presentation/ ongaro ● SNS / 連絡先: @bootjp 

Thank You & QA / 参考文献 hacomono ● SNS / 連絡先: @bootjp 書籍 / その他 (1/2) NewSQL 徹底入門 ミック・小林隆浩 - 分散 DB のアーキテクチャからユースケースまで https://www.kspub.co.jp/book/detail/5419526.html Aurora DSQL Vignette series Marc Brooker https://brooker.co.za/ Jepsen reports https://jepsen.io/ Spanner under the hood Understanding strict serializability and external consistency https://cloud.google.com/blog/products/databases/strict-serializability-and-external-consistency-in-spanner?hl=en 書籍 / その他 (2/2) AlloyDB for PostgreSQL の仕組み Google Cloud 公式ブログ - データベース対応のインテリジェントストレージ https://cloud.google.com/blog/ja/products/databases/alloydb-for-postgresql-intelligent-scalable-storage Aurora PostgreSQL Limitless Database Amazon Aurora 公式ドキュメント - アーキテクチャ解説 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/limitless-architecture.html Amazon Aurora の先進性解説 Qiita 記事 - 誰も解説してくれないから解説する https://qiita.com/kumagi/items/67f9ac0fb4e6f70c056d 

Thank You & QA ● SNS / 連絡先: @bootjp ご静聴いただきありがとうございました。 @bootjp 質問/お問い合わせはSNSでもお気軽にど うぞ！ 

既存サーベイ 既存サーベイ・書籍との位置づけ What's Really New with NewSQL? Pavlo & Aslett 2016 [対象: 〜2015] ▼ 分類軸 ・実装3分類: Novel / Sharding MW / DBaaS の分類 ・機能6軸: Main Memory / Sharding / Concurrency / Index / Replication / Recovery ▼ 本発表との共通点 NewSQL の文脈で、シャーディング・一貫性（ Concurrency Control / Replication）・リカバリを扱う点は共通 ▼ 本発表との違い 本発表は シャーディング / ストレージとコンピュートとイン テリジェントストレージ / 強い一貫性 で再構成 Cloud-Native Databases: A Survey Dong et al. 2024 [対象: 〜2024] ▼ 分類軸 軸: OLTP (3アーキ × 5技術) + OLAP (2アーキ × 5技術) の包括サーベイ OLTP 5技術 (Data Placement / Storage Consistency / Compute Consistency / Multi-Layer Recovery / HTAP Optimization) ▼ 本発表との共通点 OLTP系クラウドネイティブDBの文脈で、シャーディング （Data Placement）とログ適用型ストレージ（Coupled Page-Log / No-Redo Recovery）を扱う点は共通 ▼ 本発表との違い OLTP に絞る点は共通だが、Dong et al. の "Compute Consistency" は primary-secondary 同期を指す。本発表 は Spanner/CockroachDB/TiDB 系の分散時刻順序づけ まで踏み込み、シャーディング / ストレージとコンピュートと インテリジェントストレージ / 強い一貫性 で再構成 NewSQL徹底入門 ミック・小林 講談社 2025 [対象: 〜2025] ▼ 分類軸 ・要素技術別解説 ▼ 本発表との共通点 分散 DB の基本原理や主要なクラウドネイティブ DB の アーキテクチャを体系的に解説している点は共通 ▼ 本発表との違い 本発表はNewSQLが シャーディング / ストレージとコン ピュートとインテリジェントストレージ / 強い一貫性 の三軸 の組み合わせであるという立場