【AWS】Aurora DSQLについて調べてみた

紹介サイト

aws.amazon.com

Aurora DSQLとは

PostgreSQL 互換のサーバーレス分散 SQL データベースで、読み取りも書き込みもリージョンをまたいでアクティブ-アクティブに処理しながら、ほぼ無制限にスケールし、99.99 %（単一リージョン）／99.999 %（マルチリージョン）可用性を目指す新しい Aurora ファミリーのエンジン。運用者がインスタンス／シャードを意識する必要はなく、パッチ適用やスケールは完全に自動化されている。

従来のAuroraとの違い

1. アーキテクチャの違い

項目	Aurora 従来版	Aurora DSQL
エンジン設計	インスタンスベースマネージド RDS の一部として、マスターインスタンス（書き込み）＋リードレプリカ（読み取り）を AZ 内外に配置 Compute（インスタンス）とストレージを分離するものの、いずれもプロビジョニングされたインスタンス単位で動作	サーバーレス分散 SQL エンジンクエリ実行は Firecracker ベースのマイクロVM（Query Processor）がオンデマンドに起動／破棄され、トランザクションごとに並列実行分散ジャーナル層とストレージ層がシャード化・分散化されており、Compute／Storage／IO が独立スケール
スケール方法	インスタンスのスペック（vCPU・メモリ・IOPS）を手動または Serverless v2 で自動拡張リードレプリカを追加すれば読み取り性能向上（書き込みはマスター限定）	DPU（Distributed Processing Unit）単位の従量課金で、負荷に応じたマイクロVMが自動起動リージョンをまたいで複数の QP（Query Processor）ノードが並列実行シャーディング不要で水平分散が容易
障害時の耐障害性	マスターインスタンス障害時はフェイルオーバーでリードレプリカを昇格リードレプリカ障害時は冗長性低下（リードのみ影響）	QP やジャーナルが障害を起こしても別ノードが即座にトランザクションを再実行ストレージ層は 3 AZ 同期レプリケーション＋マルチリージョン時は Witness リージョンを含むクォーラム構成で高可用性を確保

2. SQL 互換性・機能の違い
Aurora 従来版（MySQL/Aurora PostgreSQL）
- MySQL 互換版あるいは PostgreSQL 互換版のどちらかを選択可能
- 既存の MySQL/PostgreSQL ドライバ・エコシステムと 100% 同等に動作
- ストアドプロシージャ、トリガー、外部キー、ビュー、拡張モジュール（PostGIS など）など、元版エンジンの機能は基本的にすべてサポート

Aurora DSQL
- 現時点で PostgreSQL サブセット互換 のみ（MySQL 互換はなし）
- 未サポート機能
- 外部キー
- ビュー
- トリガー
- マテリアライズドビュー
- 拡張モジュールも一部制限あり
- トランザクション中に楽観的排他制御（OCC）でコミット時に競合チェックを行うため、長時間の大規模バッチや大量一括更新時はリトライが発生しやすい

3. スケーリング・パフォーマンスの違い
Aurora 従来版
- 読み取りスケールはリードレプリカ追加で改善
- 書き込みはマスターインスタンス1台に依存
- Serverless v2（MySQL/Aurora PostgreSQL 両対応）ではインスタンスサイズ（ACU：Aurora Capacity Unit）がミリ秒単位で自動拡張可能
- 水平シャーディングは行わず、あくまで同一インスタンス内でのリソース増減
- 継続的に高負荷がかかる OLTP ワークロードやマルチリージョン書き込みには限界がある

Aurora DSQL
- リージョンをまたいだ複数の QP（クエリ実行ノード）がアクティブ‐アクティブで動作し、書き込みもあらゆるリージョンから同時に可能
- ストレージも自動でシャード化・スケールアウトされるため、極めて大規模なトランザクション処理が可能
- コミット時の OCC 検証を採用しており、読取レイテンシは低めだが、同一行を同時更新すると再試行コストが発生
- 小さく短いトランザクションを大量に捌く OLTP に最適化

4. 料金モデルの違い
Aurora 従来版
- インスタンス単位の課金（vCPU・メモリ・I/O）
- ストレージ使用量：月額 0.10～0.125 USD/GB・月（リージョンによる）
- IO 操作量課金：およそ 810 μUSD/1 万 IO リクエスト
- Serverless v2 は ACU（Aurora Capacity Unit）単位での従量課金
- 例：2 ACU × 使用時間＋ストレージ
- リードレプリカを多数使うとインスタンス費用が合算される

Aurora DSQL
- 完全サーバレス＆DPU（Distributed Processing Unit）単位の従量課金
- 例：米国東部リージョンで $8/100 万 DPU、ストレージ $0.33/GB-月
- 毎月最初の 100k DPU および 1 GB ストレージは Free Tier
- DPU 消費量はクエリの「重さ」や同時実行数に依存
- 低負荷時はほぼ課金ゼロ、負荷が上がるとリニアに増加
- インスタンス台数を意識せず、自動で柔軟に拡張・縮退

5. ユースケースの違い
Aurora 従来版が向いているケース
- 単一リージョン内での高パフォーマンスな OLTP／OLAP
- MySQL または PostgreSQL と 100% 互換性が必須、既存アプリからの移行コストを極力抑えたい
- 読み取りがメインで、書き込みはプライマリのみ、Global Database を使ったリードレプリカによるマルチリージョン読み取り
- 拡張機能（PostGIS、論理レプリケーション、ビュー、ストアドプロシージャ、トリガーなど）を多用する

Aurora DSQL が向いているケース
- グローバルに分散したアクティブ‐アクティブ書き込みが必要（例：グローバル SNS、オンラインゲーム、マルチリージョン決済システム）
- 小さいトランザクションを非常に高い同時実行でさばきたい OLTP ワークロード
- インフラ運用を極力省きつつ、秒〜分単位でスケールアウト・スケールイン要件がある
- シャーディング不要でマルチリージョン展開を検討しており、可用性 99.999%（マルチリージョン構成時）を求める

6. 構築・運用面の違い
Aurora 従来版
- コンソールまたは CloudFormation/Terraform でクラスタを作成し、インスタンス数やインスタンスタイプ（vCPU・メモリ）を選択
- メンテナンスウィンドウでのパッチ適用、リソース変更（インスタンスサイズ変更）はユーザーが設定・実施
- バックアップはストレージに自動的にスナップショットが取得され、復旧ポイントを保持
- リードレプリカや Global Database などのオプション構成は比較的簡単だが、各インスタンスの台数や種類を意識する必要がある

Aurora DSQL
- クラスタ作成時に「リージョン／PostgreSQL バージョン／シングル or マルチリージョン」を指定するだけで、DPU やシャード数などを意識せず自動プロビジョニング
- メンテナンスやスケーリングは AWS 側が完全にハンドリング
- アプリケーション接続は PostgreSQL ドライバ（libpq、psql、ORM など）を使い、エンドポイントに接続するだけ
- エラスティックかつアクティブ‐アクティブ：リージョン間フェイルオーバーを AWS が自動的に管理し、運用負担は非常に少ない

7. 制約・注意点の違い
Aurora 従来版
- フル互換エンジンのため、大抵の PostgreSQL/MySQL 機能はそのまま利用可能
- 書き込みスケールは単一マスターに依存するため、ワークロード急増時はインスタンススペックやレプリカ数の調整が必要
- マルチリージョン

Auroraとはコンソールを分けている模様