Amazon Auora DSQLとは

Amazon Aurora DSQLとはre:Invent 2024で発表された、サーバーレス分散データベースです。
まだパブリックプレビュー中ですが、大きな特徴を整理すると以下のようになります。
うまく利用すると、RDBを求められることが多いエンタープライズシステムでも、サーバーレスアーキテクチャで構築できると考えております。

PostgreSQL互換であり、強い整合性を有している
マルチリージョンでアクティブ/アクティブ構成を取ることができる
シングルリージョンでマルチAZ構成をとることができる
マルチリージョン構成で99.999%、シングルリージョン構成で99.99%の可用性となっている
自動でワークロードに合わせてスケールアップ・ダウン
パッチ適用、アップグレード、メンテナンスダウンタイムなどの運用負荷が不要となっている

　(参考情報)

Aurora DSQL導入時の考慮事項

上記の通り、非常に期待度が高いサービスですが、同時にAurora DSQL特有の制限があります。
本稿では、2024年12月13日時点の以下のAWS公式ドキュメントを元に、
エンタープライズシステムでAurora DSQLを導入する際に考慮しなければいけない事項を整理しました。

総論

エンタープライズシステムに求められる可用性、拡張性、メンテナンス性、セキュリティは担保されていると判断している。
現状の仕様では、小さな更新が大量に入るような領域でAurora DSQLを適用すると想定しております。Aurora DSQLが持つメンテナンスフリー性や高可用性は、非常に魅力的であり、エンタープライズシステムの運用保守を一変させる可能性を持ちます。
ロックがOCC(楽観ロック)になっている点に関して、ビジネスロジックを確認し、再実行で問題ないのかを確認する必要があります。セキュリティや監査を考えると別途監査のための仕組みを設ける必要がありそうです。また、エンタープライズシステムでよくある大量データのバッチ処理を実行するためには、アプリケーションの作り込みが必要になります。
GA時のアップデートに期待しつつ、現状の仕様でも導入できるシステムを探ることが大切と思います。

考慮点1. ロックがOCC(楽観ロック)となっている

最も大きな考慮点は、ロックがOCC(楽観ロック)となっている点です。
「select for update」を２つのトランザクションで流しても、Aurora DSQLは両方とも待たずに結果を返します。commit発行時に競合の有無が評価され、先にcommitされた方が優先されます。
OCCによるエラーが出た場合、処理の再実行により対応できる場合がありますが、ビジネスロジックを確認した方が良いです。例えば、画面から発行されたupdate文でしたら、OCCでエラーが発生した場合、最新情報を画面に出し、人間が画面を確認したのちにもう一度画面操作を行なってもらう必要があるかもしれません。

以下の記事で詳細に説明されていますので、Aurora DSQLの導入を検討する際には読んでおきましょう。
https://aws.amazon.com/jp/blogs/news/concurrency-control-in-amazon-aurora-dsql/

考慮点2. エンドポイントがパブリックになっている

エンタープライズシステムでは社内規定によりインターネットを経由できない、もしくはパブリックIPを利用できないケースがあります。
前者のインターネットを経由できないという点に関しては、AWS内のパブリックIP同士の通信であればインターネットに出ることはないので、問題とならないかもしれません。
通信時の暗号化と保存時の暗号化は行われていますので、セキュリティ的には問題ないと考えていますが、企業ごとのセキュリティポリシーに拠るところではあります。

しかし、パブリックIPを利用できないような場合では、Aurora DSQLを利用できません。
また、データベースという非常に機密性の高いコンポーネントに対して、エンドポイントがインターネットに開示されていることに懸念を示すIT部門も存在するでしょう。
今後のアップデートで、パブリックエンドポイント有無の設定やVPCエンドポイント経由によるアクセスができるようになることを期待しております。

考慮点3. マルチリージョン構成の際に、第3のリージョンが必要となっている

マルチリージョン構成を取ろうとすると、データベースにアクセスするエンドポイントを持たない第3のリージョン(Witnessリージョン)を選択する必要があります。このリージョンは暗号化されたトランザクションログを保持します。
これは東京リージョンと大阪リージョンでAurora DSQLを利用できるようになったとしても、国内だけで閉じることができないことを意味しています。
シングルリージョン構成だとWitnessリージョンは必要ありません。
シングルリージョン構成でも99.99%のSLAが示されているため、国内で閉じるのであればシングルリージョン構成でも十分な場合が多いでしょう。

考慮点4. PL/pgSQLやpgAuditなど利用できない拡張機能がある

利用できない拡張機能があり、以下のページで確認できます。

特にPL/pgSQLやpgAuditが利用できない点に注意が必要です。
Oracle PL/SQLを利用している場合、PostgreSQLに移行するにはPL/pgSQLへの書き換えが必要となります。しかし、Aurora DSQLはPL/pgSQLに対応していないので、Oracleからの単純移行は難しいでしょう。

pgAuditも利用できないため、Aurora DSQLにアクセスできる踏み台サーバーよ用意し、そこでログを取るといった監査証跡の取り方を工夫する必要があるでしょう。

考慮点5. サポートされていないDDLがある

サポートされていないDDLで個人的によく利用するものを記載しました。

foreign key
view
materialized view
trigger
sequences
truncate

設計する際には以下のページでサポート対象か確認してください。

考慮点6. DDL・DMLの制限がある

create table、alter table add columnなど一般的なDDLは利用可能です。
同様にDMLでもselect、insert、update、deleteは利用可能です。
ただし、DDL・DMLともに制限があります。

まとめると、小さなトランザクションを大量に処理することに向いていると言えるでしょう。エンタープライズエンタープライズシステムでよく見るバッチ処理による大量データ更新を行うには、アプリケーション側で制御を入れないといけないようです。

最大の列数は255であり、1行に格納できるサイズは2 Mebibytes(おおよそ2MB)になっています。つまり、巨大なテーブルを作ることはできません
1つのトランザクションで更新できる行数は10,000行までになっています。インデックスの数が増えると更新できる行数がさらに減ります。以下のドキュメントのLimitationsを読む限りでは、インデックスが2つになると5,000行まで、4つなると2,500行までになるように見えます

行数による更新制限の他にもデータサイズによる制限もあり、1つの書き込みトランザクションでは、10 MiB(おおよそ10MB)までに制限されています
トランザクション時間は5分になっており、長時間の更新はできません
クラスタあたりの最大コネクション数は1,000です。大量のアプリケーションから接続することは避けた方がよさそうです
1秒あたりの新規で接続できるコネクション数が10、バーストして100になっています。1秒で10コネクション分の新規コネクションが張れるようになります。API Gatewayのスロットリングと同じ考え方でよさそうです

設計する際には以下のページで制約に引っかからないかを確認しましょう。

考慮点7. CloudWatchやPerformance Insightsのサポート

CloudWatchメトリクスに表示されている項目が「ApproximateClusterStorage」だけになっております
また、Performance Insightsも利用できないのでパフォーマンス管理にはAPMといった別の手段を考える必要があります

考慮点8. その他

他の分散データベースと同様に、主キーに単調増加する値を利用してはいけません。ホットパーティションができてしまい、パフォーマンスに影響があります

Aurora Limitless Databaseにあったようなテーブル配置(Standard、Sharded、Reference)の記載はありませんでした(2024年12月13日時点)

今後公開予定の機能

ドキュメントを読むと、プレビュー版には存在しないが、今後公開予定の機能の記載がありました。

AWS Backupによるバックアップ・リストア対応

マルチリージョンとシングルリージョンの両方で、AWS Backupによるバックアップとリストアに対応する予定と記載されております。GA時には利用できるのではないでしょうか。