【セッションレポート】 Amazon Aurora DSQL アーキテクチャー詳細（AWS-43） #AWSSummit

こんにちは。サービス開発室の武田です。

2025年6月25日〜26日、AWS Summit Japanが開催されました。7月11日まではオンデマンド配信が行われているため、気になるセッションなどがあればぜひ忘れずに視聴することをお勧めします。

今回は「Amazon Aurora DSQL アーキテクチャー詳細」を視聴しましたのでレポートをお届けします。

スピーカー

• 新久保 浩二
  • アマゾン ウェブ サービス ジャパン合同会社 データ事業本部スペシャリストソリューション本部 シニア PostgreSQL スペシャリストソリューションアーキテクト

セッション概要

Amazon Aurora DSQL は、何十年にもわたる Amazon の革新と優れた運用性を生かした、新しいサーバーレスの分散型 SQL データベースです。新しいアプリケーションや高い耐障害性を必要とするアプリケーションにとって Aurora DSQL が理想的な選択肢となっている設計と主要な革新的テクノロジーについて詳しく説明します。Aurora DSQL のアクティブ - アクティブアーキテクチャーが、シングルリージョンとマルチリージョンのレジリエンシーと事実上無制限のスケーリングを実現する方法を学んでいただけます。

引用元：Amazon Aurora DSQL アーキテクチャー詳細

レポート

• セッションのターゲット
  • Aurora DSQLの概要をある程度知っている
  • 何らかのRDBを使ったことがある
  • RDSやトランザクションの原理、原則に理解がある
• ポイント
  • Aurora DSQLの特徴の理解
  • Aurora DSQLがどのようなコンポーネントで構成され、スケーラビリティに貢献しているかの理解
  • マルチリージョンで展開する分散DBでは、リージョン間の調整を最適化することが重要な点の理解

アジェンダ

• 簡単なリマインド：Amazon Aurora DSQLとは何か？
• 書き込みと同時実行制御
• 読み込みとSQLの実行
• マルチリージョンとスケーラビリティ

簡単なリマインド：Amazon Aurora DSQLとは何か？

• トランザクション処理に最適化されたSQLデータベース
  • 分析系などかなり重いSQLに対しては最適化されていない
• 拡張性に優れている
  • 従来のDBはひとつの筐体でさまざまなコンポーネントを持っていたが、DSQLはマイクロサービスのような形で分けている
• サーバーレス
  • ユーザーからはエンドポイントしか見えない
  • インスタンスやバージョン管理など煩わしさがない
• アクティブ・アクティブ、マルチリージョン
  • シングルリージョンでも使用可能で、その場合はマルチAZということになる
  • スケーラビリティも高いしアベイラビリティも高い
  • 強い一貫性を持っている
• PostgreSQLとの互換性
  • PostgreSQLに慣れていれば、比較的簡単に使える
• AWSの経験をもとに構築
  • AWSは同期、非同期などさまざまなサービスを開発しナレッジを持っている
  • そういった知見をもとに作られたもので、完全にフルスクラッチで作ったというものではない

書き込みと同時実行制御

トランザクショナルデータベースを再考してみる。

• トランザクションルーター
  • データベースに接続すると最初に接続されるレイヤー
• Query processor
  • トランザクションを開始（BEGIN）すると処理が引き継がれるレイヤー
• Adjudicator
  • 書き込み（INSERT）した際、トランザクション間の競合チェックをするレイヤー
• Journal
  • 競合がなければコミットが成功しジャーナル（トランザクションログ）に書き込まれる
• Storage
  • 最終的に非同期でジャーナルからストレージに書き込まれる

これらは通常のRDBではひとつの筐体に入っているが、DSQLはこれらを独立したコンポーネントとし、水平スケーリングできるようにしている。

• マルチリージョンの構成
• リージョンAとCがプライマリ（アクティブ-アクティブ）で動く
• リージョンBはトランザクションログだけを持っている（Witnessと呼ばれる）
  • プライマリリージョンで障害が起きた時、どちらを生き残らせるのかという判断も行う

書き込みのトランザクションを確認する。ACID特性を誰が満たすのかを見ていく。

• Journal
  • Atomicity（原子性） と Durability（耐久性）
  • DynamoDBやKinesisなど、AWSサービスのバックエンドとして長く使われているコンポーネント
  • Journalの律速を検知すると自動的にスケーリングする
    • Scalability（拡張性）
• Adjudicator
  • Isolation（分離性）
  • 書き込みトランザクション間に矛盾がないか確認
  • トランザクションが大きい場合、Adjudicatorをスケーリングしそれぞれが特定のキーを担当する
    • Scalability（拡張性）
  • 独自の分散コミットプロトコルを使用して協調している
  • セッションで明言はされていませんが、 Consistency（一貫性） もここ？
• Storage
  • データを効率的に検索する方法を提供
  • DSQLがおもしろいのはD（耐久性）の担当はStorageではないので、極論なくてもいい
  • 読み込みの最適化を提供している
    • Queryable（検索可能）
  • Storageの律速を検知すると特定のキーのレンジで自動的にスプリットする
    • Scalability（拡張性）

読み込みとSQLの実行

読み込みの場合を確認。

• 読み込みはQuery processorからStorageへ直接アクセスする
• WHERE句などの絞り込み戦略において、どちらで絞り込みをするかという選択肢がある
  • DSQLの場合、Storageにオフロードするという戦略を取っている
  • ネットワークトラフィックを小さくする目的
  • プッシュダウン と呼んでいる
• Query processorは数万という単位で起動できる
  • 同時アクセスクライアントが増えてもスケール可能
• 読み取りのIsolation（分離性）
  • Query processorはスケールするので一般的なRDBのようにローカルのトランザクションIDを見ても新旧の判別ができない
  • DSQLはグローバルに同期している時計を使って判別する
  • その時間を使って、Storageに対してクエリする
  • MVCC（MultiVersion Concurrency Control）を制御するのもStorage

分離性について。BEGIN、SELECT、INSERT、UPDATE、COMMITが行われる一連のトランザクションについておさらい。

• BEGIN
  • トランザクション開始
  • グローバルな時間取得
• SELECT
  • 取得した時間をベースにStorageへ問い合わせ
• INSERT
  • Write Onlyなのでどこともコミュニケーションしない
  • COMMIT前なので書き込みはQuery processorのローカルストレージ
• UPDATE
  • Read Modify Writeなので最初にSELECTと同じ動きをする
  • 次にINSERTと同様にQuery processorのローカルストレージへ書き込む
• COMMIT
  • 変更内容がAdjudicatorに渡され、矛盾がないかチェックをし、なければJournalに書き込まれる
  • Journalに書かれた段階で、コミットの結果ACKが返ってくる

以上のことから、次の特徴が見られる。

• コミット前の調整は不要
• 楽観的同時実行制御（OCC）
• Strong Snapshot Isolation（PostgreSQLのREPEATABLE READと同一）
  • アーキテクチャ上はREAD COMMITTEDも可能
  • しかし性能的なメリットは何もないのがDSQLの特徴
  • メリットがないのであればDBでトランザクション検知ができるREPEATABLE READの方が開発者へよい体験が提供できると考えた

マルチリージョンとスケーラビリティ

• ラウンドトリップ最適化
  • データは1ms200kmで移動（物理限界）
  • 無邪気に隣のリージョンとはお話しできない
  • そのため（前述の例で言うと） リージョン間の調整が必要なのはCOMMITだけ
• コミット時に一度だけ調整
  • Read Onlyなトランザクションは調整が不要
• 高速フェイルオーバーの最適化
  • リーダーの交代に、データの移動は必要ない
  • 唯一必要なのは、 エンドポイントが切り替わるため接続先の切り替え
    • 各リージョンごとにエンドポイントができるため、障害のあったリージョンは別のエンドポイントへ切り替える
  • DBレベルで何かが起こるということはない
• 裏側では一部コンポーネントはフェイルオーバーしている
  • ユーザーからは見えない部分
  • Adjudicatorは特定のキーを担当しているので、あるリージョンが障害になると担当者がいなくなる
  • そのためAdjudicatorはフェイルオーバーして生きているリージョンが引き継ぐ

まとめ

• 分散アーキテクチャー
  • DSQLはルーティング、Query processor、Adjudicator、Journal、Storageなど独立した機能を水平分散して柔軟なスケーリングを実施
• 強い一貫性
  • マルチリージョン、シングルリージョンともに強い一貫性を提供
  • 開発者はデータの一貫性に悩むことなく高い可用性を得られる
• クロスリージョン
  • マルチリージョン間の調整を最小限に抑え、コミット以外の操作はローカルで完結
  • リージョン障害時でも高速かつシームレスに状態の回復が可能

最後に

今年5月にGAとなったAmazon Aurora DSQLのアーキテクチャーに関するセッションでした。これまでのAuroraと異なり書き込みも分散処理されることで、高いスケーラビリティと可用性を提供するDBとなっています。

またPostgreSQL互換ということですが、将来的にMySQL互換も登場するのでしょうか？今後どのように進化していくのか楽しみですね。