> [!abstract] 概要(arXiv abstract の日本語訳) > Aurora DSQL は、マルチリージョンのアクティブ・アクティブ機能を備えたクラウド規模のトランザクション処理向けに設計されたサーバーレス SQL データベースである。disaggregated アーキテクチャに基づき、DSQL は compute・storage・トランザクション調整を、独立して水平スケール可能なサービスへ分離する。クエリプロセッサはローカル状態を持たずに PostgreSQL 互換 SQL を実行する Firecracker MicroVM 上で動作する。システムは、座標不要な読み取りのための精密タイムスタンプによるマルチバージョン並行制御(MVCC)と、書き込みのための楽観的並行制御(OCC)を使用し、分散アジュディケータと Journal レプリケーションシステムを通じて座標をコミット時まで遅延させる。これにより、個々のステートメントごとではなくコミット時にのみ座標を要求することで、クロスリージョンレイテンシを最小化する。DSQL は、可用ゾーンまたはリージョン障害時にも強い一貫性・ACID トランザクション・継続的な可用性を提供しながら、ゼロから毎秒数百万トランザクションへの弾力的なスケーリングを可能にする。 ## 論文情報 - タイトル: Aurora DSQL: Scalable, Multi-Region OLTP - 著者: Marc Brooker, Marc Bowes, Mike Hershey, Zak van der Merwe, James Morle, Matthys Strydom(全員 Amazon Web Services) - 媒体: arXiv プレプリント(cs.DB) - 投稿日: v1 2026-07-14、v2 2026-07-16(本 ingest は v2 を参照) - arXiv ID: 2607.13276 ## 概要 Aurora DSQL は、Query Processor・Adjudicator・Journal・Crossbar・Storage という 5 種の独立サービスに分離された disaggregated アーキテクチャを持つサーバーレス SQL データベースである。読み取りは MVCC による座標不要パス、書き込みは OCC によりコミット時にのみ座標するパスを採用し、マルチリージョンでも 1 回のクロスリージョン通信でコンシステンシと耐久性の両方を達成する。PostgreSQL のクエリエンジン・オプティマイザ・プロトコル実装を利用しつつ、ストレージ・トランザクション処理層は独自実装に置き換えている。 ## 問題設定 - 入力: PostgreSQL 互換クライアントからの SQL 接続(BEGIN/SELECT/UPDATE/COMMIT 等)。 - 出力: strong snapshot isolation(snapshot isolation + linearizability)を満たすトランザクション結果。 - 前提条件: AWS EC2 の精密時刻同期インフラ(マイクロ秒精度・強い誤差限界)がリージョン間で利用可能であること。 - 目標(製品要求): サーバーレス(インフラ管理不要)・familiar(PostgreSQL 互換の API/型/isolation semantics)・スケーラブル(ゼロから数百万 TPS)・マルチリージョンアクティブ・アクティブ(強一貫性・高速フェイルオーバー・データ損失なし)の 4 点。 ## 提案手法 ### アーキテクチャ DSQL のアーキテクチャは disaggregated であり、単一障害点を持たない 5 種のコンポーネントに分解される(Figure 3)。 - **Query Processor(QP)**: Firecracker MicroVM 内で動作し、PostgreSQL エンジンで SQL をパース・実行する。読み取りはストレージへ問い合わせ、書き込みはローカルにバッファしてコミット時にまとめて Adjudicator へ送る。QP は接続ごとに水平・垂直にスケールし、耐久状態を一切持たないため障害時はトランザクションを中断して別 MicroVM で透過的にリトライできる。 - **Storage**: シャードキーに基づくレンジパーティショニングでデータを保持し、行・インデックスエントリ単位の論理ストレージ(古典的 Aurora の物理ページストレージとは対照的)を提供する。クエリプッシュダウン(フィルタリング・集約・射影のストレージ側実行)が可能。 - **Adjudicator**: write-write 競合を検知してコミット可否を判定し、コミット時刻 τ_commit を決定する。シャーディングは各キーが常に単一 Adjudicator に属する方式で、ストレージシャーディングとは独立に設計できる(読み書きヒートが異なるワークロードに対応)。 - **Journal**: AWS 社内で S3・DynamoDB・MemoryDB にも使われてきた耐久・順序付き・アトミックなデータストリームサービス。トランザクションのコミットは Journal への書き込みで確定する。 - **Crossbar**: Journal のトータルオーダーをストレージのシャード境界に合わせて分割し、各 Storage シャードへ配信する。 マルチリージョン構成(Figure 4)では、読み取りパスはシングルリージョンとほぼ同一(ストレージが全リージョンの Journal 前進を確認してから応答する点のみ異なる)だが、書き込みパスは Journal がリージョン間で複製し、Adjudicator の配置はワークロードに応じたコントロールプレーンの最適化問題となる。DSQL は Abadi の PACELC 分類で PCEC(一貫性を可用性より優先)を選ぶが、多数派側のリージョンには一貫性と可用性の両方を提供し続ける。 **Figure 3: Aurora DSQL のシングルリージョンアーキテクチャ概要** ![[_attachments/arxiv-2607.13276/fig03-architecture-overview.png]] (Figure 3. Query Processor が Adjudicator と Journal を経由してコミットし、Crossbar がストレージシャードへ配信する読み取り/コミットパスの全体像。破線が読み取りパス、実線がコミットパス。Source: 論文 Figure 3。) **Figure 4: マルチリージョン構成でのアーキテクチャ** ![[_attachments/arxiv-2607.13276/fig04-multiregion-architecture.png]] (Figure 4. 各リージョンに Frontend・Query Processor・Adjudicator・Crossbar・Storage が配置され、Journal がリージョンをまたいで複製する。Region B(中央)はクォーラム確保のための witness リージョンとして機能しうる。Source: 論文 Figure 4。) シングルリージョン・マルチリージョンいずれでも、アプリケーション層は単純化される。単一リージョンではロードバランサとリージョン DNS のヘルスチェックのみで AZ 障害を吸収し(Figure 1)、マルチリージョンでは Global DNS を介した 2 リージョン以上のアクティブ・アクティブ構成でリージョン障害を無停止で吸収できる(Figure 2、本文参照。図は attachment 未収録)。 **Figure 1: シングルリージョンのアプリケーションアーキテクチャ** ![[_attachments/arxiv-2607.13276/fig01-single-region-architecture.png]] (Figure 1. ステートレスなアプリケーションスタックがロードバランサ経由でリージョナル DSQL エンドポイントに接続する、AWS における既定的なサービスアーキテクチャ。Source: 論文 Figure 1。) ### アルゴリズム/手法の詳細 **読み取りパス(MVCC)**: 各トランザクションは開始時に EC2 の精密時刻インフラから τ_start を取得する。以降の全読み取りは τ_start 時点のスナップショットとして処理され、MVCC によりストレージが「τ_start 以前にコミットされた最新版」を返す。読み取りはロック状態を一切持たないため、任意のリードレプリカから並列に処理でき、リーダーやロックサーバとの通信を必要としない。 **書き込みパス(OCC)**: UPDATE/INSERT はコミットまでローカルの QP にバッファされ、COMMIT 時に (1) 分離規則の充足確認、(2) 結果のアトミックな永続化、(3) 必要な AZ/リージョンへの複製、の 3 点を実施する。単一 Adjudicator が関与する場合、以下の手順で write-write 競合を検出する: 1. 𝑊_A: トランザクション A が書き込むキー集合を計算。 2. 𝑊_C: τ_start(A) < τ_commit(t) < τ_commit(A) を満たす全コミット済みトランザクション t の書き込み集合の和集合。 3. 𝑊_A ∩ 𝑊_C = ∅ ならば A はコミット可能。 4. 以降、𝑊_A と交差する書き込みを持ち τ_commit ≤ τ_commit(A) となるトランザクション B のコミットを禁止する約束をする。 複数 Adjudicator にまたがる場合は Warp に着想を得た 2 段階の投票プロトコルを用いる: 代表 Adjudicator a_l を選び、全 Adjudicator が投票と現在時刻 τ_a を a_l に転送、a_l が τ_commit = max(τ_a) を計算してタイムアウト閾値 τ_max 以内なら a_l の Journal のみに書き込む。これは「アトミックなコミット」ではなく「コミット候補としてのアトミックな投票」であり、実際のアトミック性は単一 Journal への単一の書き込みが担保する。クロス Journal 調整やフォールトトレラントなコーディネータが不要になる。 **Journal と Crossbar**: Journal はコミット済みトランザクションを決定論的に(ストレージ側での読み取り変更ロジックなしに)適用できるコミットログである。Crossbar が Journal のトータルオーダーをストレージパーティション境界に合わせて再分割・配信する。DSQL のこの部分は決定論的データベース(Calvin・SLOG)に類似するが、任意のインタラクティブ SQL トランザクションを実行できる点で異なる。 **インデックスとブラインドライト最適化**: セカンダリインデックスへの変更は Journal への post-image に含めて主キー更新と同一 τ_commit でアトミックにコミットされる。非ユニークインデックスは主キーの集合操作として扱えるため、主キーの write-write 競合検出が済んでいれば追加のコンフリクトチェックを省略できる(ユニークインデックスは対象外)。 **ガベージコレクション**: DSQL のどの部品もアクティブなトランザクションの全体リストを把握していないため、時間ベースの単純な GC(τ_expiry、現行運用で 5 分)を採用する。τ_start が τ_expiry より古い読み取りは拒否され、QP がトランザクションを中断・リトライする。 **クロックスキューへの耐性**: τ_start・τ_commit は物理クロックから直接導出されるため、クロックスキューが起きると τ_start が真の物理時刻から大きくずれる場合に読み取り遅延(≫ の場合)または線形化可能性の喪失(≪ の場合)が生じうる。ただし isolation・durability・atomicity は維持される。DSQL はクロックスキューを障害として扱い、冗長なクロック同期ハードウェアで監視する。 **カタログとロック節の例外**: 学術的な snapshot isolation の定義は DDL(ALTER TABLE 等)や FOR UPDATE のような明示ロック節を扱わない。DSQL はカタログテーブルへの read-write 競合を検出して常に serializable にし、FOR UPDATE でも同様に read-write 競合検出を追加することで、既存の OCC フレームワーク内でこれらの例外を処理する。 ### 実装上の工夫 - **Firecracker MicroVM とスナップショット再利用**: 新規 MicroVM 起動時に OS・DB エンジンを毎回ブートするのではなく、メモリ・レジスタ・デバイス状態のスナップショットをクローン・リストアすることで起動時間を短縮し、カーネル等の不変ページをコピーオンライトで QP 間共有する。 - **PostgreSQL の Access Method 層への直接プラグイン**: PostgreSQL のバッファプール・ロックマネージャは使わず、AM インターフェイスに直接ストレージプラグインを実装することでバッファプール競合とロックマネージャオーバーヘッドを排除する。 - **erasure coding によるレイテンシ・可用性最適化**: Journal に直接依存する代わりに複数 Journal 間で 2-of-3 のイレイジャーコード(単純な XOR)を適用し、任意の 2 つから復元可能にする。これによりレイテンシ分散を抑えつつ、1 つの Journal が不可用でも他 2 つから継続してコミット・読み取りができるため可用性が大幅に向上する。 - **コミットサイズ上限**: Little's Law に基づき、テールレイテンシの安定性を優先して 1 トランザクションあたり最大 3,000 行・10MiB に制限している(大規模データロード用途とはトレードオフ)。 - **soft allocation によるマルチテナンシー**: 1 物理マシンで数千顧客ワークロードを扱うマルチテナント設計とし、CPU/メモリのオンデマンド割り当てでピーク対平均比を圧縮する。プロセス分離(メモリ安全な自社コード)と Firecracker による VM 分離(PostgreSQL エンジン等の安全でないコード)を使い分ける。 ## 新規性 - **OCC のよくある欠点を MVCC と snapshot isolation の組み合わせで回避**: 従来批判される OCC の欠点(read-write 競合による中断)を、MVCC による一貫スナップショット読み取りと serializability ではなく snapshot isolation を選ぶことで回避し、write-write 競合のみで中断させる。これにより Spanner・CockroachDB のような悲観的ロックベース設計と異なり、トランザクション実行中の継続的な座標(ステートメントごとのロック状態管理)が不要になる。 - **座標をコミット時のみに限定**: 個々のステートメントではなくコミット時のみクロスリージョン通信を要求する設計により、リージョン間 RTT(us-east-1⇔us-west-2 で p50 62.4ms)であっても、実際のコミットレイテンシは最も近い第 2 リージョンとの RTT(us-east-1⇔us-east-2 で p50 11.5ms)に抑えられる。 - **Adjudicator シャーディングとストレージシャーディングの独立性**: 読み取りヒートと書き込みヒートが異なるワークロードに対し、それぞれ独立にシャード数を最適化できる(例: 読み取り多・書き込み少なら Adjudicator シャード 1 つで多数のストレージレプリカ)。DynamoDB から得た教訓として、レプリケーションファクタとシャーディングを独立制御できることの重要性を挙げている。 - **既存分散 SQL との比較(論文 §2.6)**: DSQL は FoundationDB にアーキテクチャ的に最も近いが、ロギング・アトミックコミット・複製方式が大きく異なる。Aurora・Neon・AlloyDB は分散ストレージを使うが単一書き込みリーダーを持つ。Vitess・Citus はシングルリーダーシステムをキー空間分割でスケールさせるがアトミック性・分離性を犠牲にすることが多い。CockroachDB・Spanner は同様の分散 SQL アプローチだが悲観的並行制御・単一リーダー per write shard・Paxos グループによる複製を用いる。DynamoDB はタイムスタンプ順序に基づくトランザクションを持つ NoSQL である。 ## 実験設定 - **マイクロベンチマーク**: プライマリキートランザクションを用いたベンチマークで、us-east-1・us-east-2 の 2 リージョン構成(us-west-2 を witness として含む)と、単一リージョン構成を比較。 - **競合比較**: 悲観的ロックベース設計を持つ「Competitor A」と、クライアント 2 リージョン(r1, r2)・UPDATE ステートメント数を増加させたトランザクションで正規化レイテンシを比較(Figure 5、本文参照。図は attachment 未収録)。 - **TPC-C 風シミュレーション**: 決定論的シミュレーションフレームワーク turmoil(Rust 製)を用いたイベントベースの数値シミュレーションで、単一リージョン・us-east-1/us-east-2・us-east-1/us-west-2 の 3 構成の期待 goodput(コミット済みトランザクションのスループット)を比較。 - **正当性検証**: TLA+/P によるプロトコルの形式検証、決定論的シミュレーションテスト(deterministic simulation testing、FoundationDB に着想)、本番環境での fault injection testing(AWS Fault Injection Service 経由で顧客にも一部提供)、SQLancer に着想したファジングによる PostgreSQL との結果比較。 ## 実験結果 - **p99 レイテンシ(Figure 6)**: 2 リージョン構成で SELECT ≈ 2ms、UPDATE ≈ 3ms(いずれも同一 AZ 内のリードレイテンシに近い水準)。COMMIT ≈ 30ms(マルチリージョン)/ 7.4ms(単一リージョン)。30ms はリージョン間クォーラムコミットの効果により us-west-2 への RTT(63ms p99)より高速。 - **読み取り専用トランザクション(Figure 7)**: 読み取り専用の COMMIT は no-op として扱われ、明示的 COMMIT でも p99 1.5ms 未満。マルチリージョンでも読み取りは同一リージョン・同一 AZ 内で完結する。 - **競合比較(Figure 5)**: 悲観的ロックベースの Competitor A は UPDATE ステートメント数に応じてレイテンシが線形増加(追加ラウンドトリップのため)するのに対し、DSQL はいずれのリージョンでも同一レイテンシを維持する。 - **可用性への erasure coding の効果(Figure 8、本文参照)**: base availability 99.99% に対し、2-of-3 コード(k=2, M=3)で 7.5 桁を超える可用性(nines)へ改善。 - **TPC-C 風シミュレーション(Figure 9)**: 限定的な同時実行数(w1)ではクロスリージョンコミットの追加レイテンシがスループットを顕著に低下させるが(usw2_w1 が最も高いが低水準)、同時実行数を増やす(w100)と全体としてスケールし、シミュレーションは本番テストと整合した。 **Figure 6: 2リージョン構成・単一リージョン構成でのp99レイテンシ比較** ![[_attachments/arxiv-2607.13276/fig06-p99-latency-commit-select-update.png]] (Figure 6. COMMIT・SELECT・UPDATE の p99 レイテンシ(ms)を us-east-1、us-east-2、us-east-2(単一リージョン)で比較。COMMIT のみリージョン構成に応じて大きく変化する。Source: 論文 Figure 6。) **Figure 9: TPC-C風シミュレーションのgoodput比較** ![[_attachments/arxiv-2607.13276/fig09-simulation-goodput.png]] (Figure 9. 単一リージョン(usw2)・us-east-1/us-west-2・us-east-1/us-east-2 の3構成で、同時実行数 w1/w100 ごとに正規化 goodput を比較。同時実行数を上げるほどクロスリージョンコミットの影響が緩和される。Source: 論文 Figure 9。) ## 考察 - **snapshot isolation を唯一のサポートレベルとする判断**: 顧客の大半が SERIALIZABLE を選ばず REPEATABLE READ/READ COMMITTED を使う実運用の傾向を踏まえ、DSQL は PostgreSQL の REPEATABLE READ と等価な strong snapshot isolation のみを提供する(READ COMMITTED は現状非サポート)。この選択により PostgreSQL の EvalPlanQual のような複雑な再評価機構が不要になり、DB とアプリケーション双方の並行性バグの表面積を削減する。 - **書き込みスキュー(write skew)の許容とその緩和策**: snapshot isolation の代償として write skew 異常が発生しうるが、顧客とのやりとりから、スキーマ設計(write-write 競合を強制するテーブル設計)や FOR UPDATE のようなツールを提供することで実用上のアプリケーション設計を可能にしてきた。 - **クロック品質への強い依存**: linearizability の保証はクロックスキューが誤差限界内であることに依存しており、DSQL チームはこれを障害として扱い冗長なクロック同期ハードウェアで対処する設計判断をしている。 - **一貫性への一貫した優先(2007年 Dynamo との対比)**: Amazon 自身の 2007 年 Dynamo 論文が結果整合性を選んだ歴史的経緯と対比し、20 年間のクロック・ネットワーク・分散プロトコルの進歩により、強一貫性を選びながら 2007 年比で読み取り約 10 倍・書き込み約 4 倍低いレイテンシを達成したと主張する。 ## 強み / 弱点・課題 **Strengths** - disaggregated アーキテクチャによりコンポーネントごとの独立スケーリング・障害隔離・セキュリティ境界の個別設計が可能。 - コミット時のみの座標により、マルチリージョン構成でも読み取り・書き込みともに低レイテンシを実現。 - TLA+/P による形式検証と決定論的シミュレーションテストを組み合わせた体系的な正当性保証プロセス。 **Weaknesses/Limitations(論文が明示する課題)** - 現行実装はトランザクションあたり最大 3,000 行・10MiB の commit size 制限があり、大規模データロードでは不便との顧客フィードバックが想定より多く、緩和策を開発中。 - 外部キー制約(FKC)が未サポート(JOIN・FK 付き schema は可能)。当初は市場投入優先度のトレードオフとして意図的に外したが、想定より高い需要があり実装を進めている。 - レンジベースのパーティショニングは、シリアルキー(AUTO_INCREMENT 等)・書き込み局所性を持つセカンダリインデックス(タイムスタンプ列への insert)・低カーディナリティインデックス(boolean 列)のスケーリングを困難にする。これらの高局所性ケースをスケールさせつつ読み取り局所性を維持するのは一般には不可能かもしれないと述べており、レンジ+ハッシュのハイブリッド方式を計画している。 - 複数 Adjudicator にまたがるコミットではデッドロックが理論上発生しうる(実運用では極めて稀と報告)。