LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Aurora DSQLとは何か

Amazon Aurora DSQLとは、サーバーレスで動作する分散SQLデータベースサービスであり、PostgreSQL互換のインターフェースでトランザクション処理向けのアプリケーションを構築できるサービスを指します^*1。インフラの管理を必要とせず、コンピューティング・I/O・ストレージをワークロードに応じて自動的に拡張する点が特徴です^*1。

Aurora DSQLはアクティブ-アクティブ構成の高可用性アーキテクチャを採用し、単一リージョンで99.99%、複数リージョンで99.999%の可用性を掲げています^*1。コンピューティング層はPostgreSQLの現行メジャーバージョン（バージョン16）をベースにしており、使い慣れたPostgreSQL用のドライバやツール（psqlなど）で接続できます^*1。

従来のリレーショナルデータベースは単一ノードでの整合性維持を前提としてきましたが、Aurora DSQLはクラスタを構成する複数のコンポーネント（リレー・コンピューティング・トランザクションログ・ストレージ）がそれぞれ3つのアベイラビリティゾーン（AZ、独立した施設を持つデータセンター群）にわたって冗長化される設計です^*1。マイクロサービスやサーバーレス、イベント駆動型のアプリケーションパターンとの親和性が高い点も特徴として挙げられています^*1。

分散SQLとアクティブ-アクティブが支える強整合

分散SQL（distributed SQL、複数の物理拠点にデータを分散しながら単一のSQLデータベースとして扱う方式）は、スケールと可用性を両立させる目的で採用される構成です。Aurora DSQLではこの分散SQL構成の中核に「アクティブ-アクティブ」という設計思想を据えています。

アクティブ-アクティブとは、クラスタを構成するすべてのデータベースリソースがピア（対等な立場）として読み取り・書き込みの両方を処理できる状態を指します^*2。リージョン内だけでなくリージョン間でも同様に機能し、マルチリージョンクラスタのエンドポイントに一時的に接続できない場合でも、強整合を保ったまま読み書きを継続できるよう設計されています^*2。

マルチリージョン構成では、ペアとなる2つのリージョンそれぞれにエンドポイントを持ちながら、両者は単一の論理データベースとして振る舞います^*1。書き込みトランザクションは同期的に複数リージョンへ複製され、さらに「witnessリージョン」と呼ばれる中立な第三の地点が、3拠点間の定足数（クォーラム、過半数による合意）維持のためにコミット判断に参加します^*2。この仕組みにより、どのリージョナルエンドポイントに対する読み書きも強整合（strong consistency、書き込み直後に全体で同じ最新データが参照できる整合性水準）であるとされています^*2。

トランザクションの分離レベルはPostgreSQLの「Repeatable Read（繰り返し読み取り）」に固定されており、スナップショット分離・アトミック性・AZ間およびリージョン間の永続性を伴うACID特性を備えます^*1*3。従来型の障害時フェイルオーバーのように、切り替えに伴う一時的なデータ不整合を心配する必要がない設計とされています^*1。

楽観的並行性制御とトランザクションの制約

Aurora DSQLは、行やテーブルに対する事前のロック取得を行わない、ロックフリーの並行性制御方式を採用しています^*3。この方式は楽観的並行性制御（optimistic concurrency control、OCC）と呼ばれ、他のトランザクションの状態を考慮せずに処理を進め、コミット時点でのみ競合をチェックする仕組みです^*4。

競合が検出された場合、PostgreSQLのシリアライゼーション失敗としてSQLSTATE 40001のエラーが返されます^*4。行データの競合には「OC000」、スキーマカタログの競合には「OC001」という識別コードが付与され、後から発生したトランザクションがエラーを受け取る仕組みです^*4。ロック待ちで処理が止まる従来方式とは異なり、デッドロックが発生しない一方で、アプリケーション側にリトライ処理の実装が求められます^*4。

公式ドキュメントでは、コンテンション（同一データへのアクセス集中）を避けるため、主キーにランダムな値を選ぶなど更新をキー範囲全体に分散させる設計を推奨しています^*4。単一キーや狭いキー範囲に更新が集中する設計は、競合エラーの頻発につながりやすい点に注意が必要です^*4。

トランザクションには次の制約が明記されています^*3。DDL（データ定義言語）とDML（データ操作言語）の操作は別トランザクションで実行する必要があり、1トランザクションに含められるDDL文は1つまでです。また1トランザクションで変更できる行数は、セカンダリインデックスの数に関わらず3,000行までに制限されます^*3。データベース接続は1時間でタイムアウトする仕様です^*3。これらは通常のPostgreSQL運用と異なる制約であり、既存アプリケーションを移行する際は事前の設計見直しが欠かせません。

対応するPostgreSQL機能と非対応の機能

Aurora DSQLとは、コンピューティング層がPostgreSQL 16をベースにしているものの、分散アーキテクチャを実現するために機能面でいくつかの違いを持つデータベースです^*1。SELECT文の主要な句（FROM・GROUP BY・JOIN各種・WITH句によるCTEなど）や、INSERT・UPDATE・DELETEといった基本的なDML、GRANT・REVOKEなどのDCLは公式ドキュメント上で対応が明記されています^*5。

一方で、非対応の機能も複数あります。外部キー制約はサポートされておらず、参照整合性はアプリケーション層での検証に委ねる設計が案内されています^*6。データベーストリガーも非対応で、トリガー相当の処理はアプリケーションコードやAmazon EventBridge等を用いたイベント駆動アーキテクチャへの置き換えが推奨されています^*6。PL/pgSQLのような手続き型言語には対応せず、SQLベースの関数（CREATE FUNCTION、LANGUAGE SQL）のみサポートされます^*5*6。一時テーブル（テンポラリテーブル）も非対応で、CTEやサブクエリ、命名を工夫した通常テーブルでの代替が案内されています^*6。TRUNCATEコマンドも非対応であり、DELETE FROMまたはDROP TABLE後の再作成で代替します^*6。

そのほか、1クラスタにつき組み込みのデータベースは「postgres」という名称の1つに限られる点、文字エンコーディングはUTF-8・照合順序はCのみに固定される点も明記されています^*6。インデックス作成はCREATE INDEXではなく、テーブルをロックしない非同期方式のCREATE INDEX ASYNCを用いる設計です^*6。なお識別列（IDENTITY）やシーケンスオブジェクトは追加された機能として案内されており^*7、対応状況は今後変わる可能性があるため、導入検討時は最新の公式ドキュメントで確認することが欠かせないといえます。

従来のAurora・Aurora Serverlessとの違い

Aurora DSQLと従来のAurora（プロビジョンド構成またはAurora Serverless v2）は、いずれもAWSが提供するリレーショナルデータベースサービスですが、アーキテクチャの前提が異なります。従来のAuroraはプライマリインスタンスと複数のリードレプリカで構成され、書き込みは基本的にプライマリの1系統に集約される仕組みです。これに対しAurora DSQLは、複数のリージョナルノードがピアとして読み書きの両方を受け付けるアクティブ-アクティブ構成を採ります^*2。

Aurora Serverless（v2を含む）はコンピューティング容量（ACU）を需要に応じて自動調整する点でAurora DSQLと似ていますが、内部的には従来のAuroraと同じプライマリ/レプリカ構成を土台にしています。一方Aurora DSQLは、コンピューティング・コミット処理・ストレージの各コンポーネントが個別にスケールする分散アーキテクチャそのものが土台であり、サーバーレス性は後付けの機能ではなく設計の出発点になっている点が公式に説明されています^*8。課金もインスタンス起動時間やACUではなく、分散処理ユニット（DPU、クエリ処理・読み取り・書き込み等の要求ベースの活動を正規化した課金単位）とストレージ容量に基づきます^*8。

DynamoDBとの違いと使い分け

Amazon DynamoDBは、キーバリュー／ドキュメント型のNoSQLデータベースであり、Aurora DSQLとはデータモデルの前提が異なります。Aurora DSQLはPostgreSQL互換のリレーショナルモデルを採用し、SQLのJOINやトランザクション（ACID特性）を用いた設計が前提です^*1。公式ブログでは、リレーショナル構造を持つデータをNoSQLからAurora DSQLへ移行する事例も紹介されており、テーブル間の関係性を保ったままSQLで扱いたい場合の選択肢として位置づけられています^*9。

両者は排他的な選択肢ではなく、アクセスパターンによって使い分ける対象です。単純なキー参照が中心で極めて低いレイテンシが求められる部分はDynamoDBが強みを持つ領域であり、複数テーブルを結合した集計・レポーティングや、トランザクション整合性を要する更新処理はAurora DSQLが得意とする領域です。既存システムがDynamoDB中心の場合、Aurora DSQL導入はデータモデルの再設計を伴うため、移行範囲の見極めが最初の論点になります。

想定されるユースケース

公式ドキュメントでは、マイクロサービス・サーバーレス・イベント駆動型アーキテクチャのアプリケーションパターンにAurora DSQLが適しているとされています^*1。ACIDトランザクションとリレーショナルデータモデルの恩恵を受けるトランザクション処理ワークロード全般が対象です^*1。

公式ブログでは、グローバル規模の金融トランザクションを例に、複数リージョンにまたがる強整合な読み書きが必要なワークロードでの活用が紹介されています^*10。地理的に離れた拠点からアクセスされるアプリケーションで、リージョンをまたいでも同一の最新データを参照する必要がある場合に、Aurora DSQLのアクティブ-アクティブ構成が候補になり得ます^*10。

一方で、1トランザクションあたり3,000行までという制約や、外部キー・トリガーが非対応である点を踏まえると、大量バッチ処理や複雑な参照整合性をデータベース側に持たせる既存システムをそのまま載せ替える用途には向きません^*3*6。新規開発でアプリケーション層に整合性ロジックを持たせる設計を採用できるプロジェクトの方が適合しやすいといえます。

外注と内製の判断軸

Aurora DSQLの導入を内製で進める場合、必要になる知識は一段階増えます。PostgreSQLの知識だけでなく、楽観的並行性制御を前提にしたリトライ設計、DDL・DML分離のトランザクション設計、外部キーやトリガーに依存しないスキーマ設計、マルチリージョン構成時のリージョンセット制約の理解が必要です^*3*6*1。これらを誤って設計すると、コミット時の競合エラー（OC000/OC001）が想定より頻発し、アプリケーションのスループットが低下する可能性があります^*4。

特に既存のPostgreSQLアプリケーションを移行する場合は、外部キー制約やトリガーに依存したロジックを全面的にアプリケーション層へ移し替える作業が発生します^*6。この移行作業を過小評価すると、リリース後に整合性エラーやデータ不整合の切り分けに想定以上の工数を要する事態になりかねません。設計段階での見積もりが甘いと、後工程での手戻りが大きくなりやすい領域です。

外部パートナーに依頼した場合と内製で対応した場合の差分は、主に設計レビューの速度に表れます。専門パートナーはOCC前提のスキーマ設計パターンや、マルチリージョンクラスタのリージョンセット制約といった固有の落とし穴を事前に把握しているため、設計段階での試行錯誤を減らせます。内製で対応する場合は、これらの制約を自社で検証しながら進める工数を確保する必要があります。LASSICへの相談は、こうした設計上のリスクを早期に洗い出し、移行計画の精度を高める目的で活用いただけます。

まとめ：Aurora DSQL導入判断の3つの軸

本稿ではAurora DSQLの分散SQL構成・アクティブ-アクティブ・強整合の仕組みと、楽観的並行性制御を前提としたトランザクション設計の違いを整理しました。要点を3つに集約すると、第一に整合性モデルとトランザクション制約（3,000行制限・DDL分離・1時間タイムアウト）を事前に把握すること、第二に外部キー・トリガー・PL/pgSQLといった非対応機能をアプリケーション層でどう代替するかを設計段階で決めること、第三に既存AuroraやAurora Serverlessからの移行かDynamoDBとの使い分けかで判断軸が変わることです。これらを踏まえたうえで、外注か内製かを選ぶことが導入の成否を左右します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「What is Amazon Aurora DSQL?」
2. *2　出典：Amazon Web Services「Amazon Aurora DSQL FAQs」
3. *3　出典：Amazon Web Services「Migrating from PostgreSQL to Aurora DSQL」
4. *4　出典：Amazon Web Services「Concurrency control in Aurora DSQL」
5. *5　出典：Amazon Web Services「Supported SQL for Aurora DSQL」
6. *6　出典：Amazon Web Services「Migrating from PostgreSQL to Aurora DSQL（アーキテクチャの違い）」
7. *7　出典：Amazon Web Services「Amazon Aurora DSQL adds support for identity columns and sequence objects」
8. *8　出典：Amazon Web Services「Amazon Aurora DSQL Pricing」
9. *9　出典：Amazon Web Services「Migrate relational-style data from NoSQL to Amazon Aurora DSQL」
10. *10　出典：Amazon Web Services「Amazon Aurora DSQL for global-scale financial transactions」

Tweet