Amazon Auora DSQLとは
Amazon Aurora DSQLとはre:Invent 2024で発表された、サーバーレス分散データベースです。
まだパブリックプレビュー中ですが、大きな特徴を整理すると以下のようになります。
- PostgreSQL互換であり、強い整合性を有している
- マルチリージョンでアクティブ/アクティブ構成を取ることができる
- シングルリージョンでマルチAZ構成をとることができる
- マルチリージョン構成で99.999%、シングルリージョン構成で99.99%の可用性となっている
- パッチ適用、アップグレード、メンテナンスダウンタイムなどの運用負荷が不要となっている
(参考情報)
Aurora DSQL導入時の考慮事項
上記の通り、非常に期待度が高いサービスですが、同時にAurora DSQL特有の制限があります。
本稿では、2024年12月13日時点の以下のAWS公式ドキュメントを元に、
エンタープライズシステムでAurora DSQLを導入する際に考慮しなければいけない事項を整理しました。
総論
エンタープライズシステムに導入するには、現状の機能では難しい部分が多い。特に楽観ロックしか利用できない点に関しては、利用できるシーンが限られてしまいます。セキュリティや監査を考えると、IT部門から使用許諾をもらうことにハードルがありそうです。また、エンタープライズシステムでよくある大量データのバッチ処理を、データベースの機能だけで実現することは難しく、アプリケーションの作り込みが必要になります。
現状の仕様では、いわゆるSoEと呼ばれるような領域にAurora DSQLを適用すると想定しております。
しかし、Aurora DSQLが持つメンテナンスフリー性や高可用性は、非常に魅力的であり、エンタープライズシステムの運用保守を一変させる可能性を持ちます。GA時のアップデートに期待しつつ、現状の仕様でも導入できるシステムを探ることが大切と思います。
考慮点1. ロックが楽観ロックとなっている
最も大きな考慮点は、ロックが楽観ロックとなっている点です。
「select for update」を２つのトランザクションで流しても、Aurora DSQLは両方とも待たずに結果を返します。commit発行時に競合の有無が評価され、先にcommitされた方が優先されます。
以下の記事で詳細に説明されていますので、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リージョンは必要ありません。
考慮点4. PL/pgSQLやpgAuditなど利用できない拡張機能がある
利用できない拡張機能があり、以下のページで確認できます。
特にPL/pgSQLやpgAuditが利用できない点に注意が必要です。
Oracle PL/SQLを利用している場合、PostgreSQLに移行するにはPL/pgSQLへの書き換えが必要となります。しかし、Aurora DSQLはPL/pgSQLに対応していないので、Oracleからの単純移行は難しいでしょう。
pgAuditも利用できないため、監査証跡の取り方を工夫しなければなりません。
考慮点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も利用できないのでパフォーマンス管理には別の手段を考える必要があります
考慮点8. その他
- 他の分散データベースと同様に、主キーに単調増加する値を利用してはいけません。ホットパーティションができてしまい、パフォーマンスに影響があります
- Aurora Limitless Databaseにあったようなテーブル配置(Standard、Sharded、Reference)の記載はありませんでした(2024年12月13日時点)
今後公開予定の機能
ドキュメントを読むと、プレビュー版には存在しないが、今後公開予定の機能の記載がありました。
AWS Backupによるバックアップ・リストア対応
マルチリージョンとシングルリージョンの両方で、AWS Backupによるバックアップとリストアに対応する予定と記載されております。GA時には利用できるのではないでしょうか。