[レポート] Amazon Aurora DSQLの始め方 #DAT424 #AWSreInvent

ウィスキー、シガー、パイプをこよなく愛する大栗です。

AWS re:Invent 2024 の Keynote にラスベガス現地で参加しています。今回の新発表の目玉の一つである Amazon Aurora DSQL に関するセッションに参加してきたのでレポートします。

Get started with Amazon Aurora DSQL

AWSのバイスプレジデント兼ディスティングイッシュトエンジニアであるマーク・ブローカー氏が、Aurora DSQL の基本について説明するセッションです。

登壇者

Marc BrookerVP and Distinguished Engineer, Amazon Web Services

Amazon Aurora DSQL とは？

2020年当時に Lambda チームで働いており、お客様から RDBMS を使いたいと言われたが既存のデータベースサービスはあまりサーバーレス環境に適していませんでした。データベースチームに移り、最終的に欲しかったものは Active-Active なデータベースだった事が分かったので DSQL を作成しました。

Aurora DSQL はトランザクションに最適化されたリレーショナルデータベースで、分析ワークロードには適していませんが、小規模な読み書きに最適化されています。巨大なワークロードを持っている方は限定的なので、最初から組み込まれている機能としてスケールダウンがあります。また、目に見えるインフラストラクチャが存在せず、監視やパッチ適用、コンプライアンスなどが組み込まれています。エンドポイントを作成すればインフラストラクチャを意識する必要がありません。

複数のリージョンで同時にアクティブにワークロードを実行でき、ACID 特性を損なわず、PostgreSQL クライアントで接続できます。

小さい単一リージョンのアプリケーション

小規模な単一リージョンのアプリケーションを構築します。ALB、単一のマシン、DSQL という素朴な構成だとオートスケーリングを￥使用すれば 99.9% 以上の可用性を実現できます。

更にシンプルに Lambda とその URL を DSQL と組み合わせると秒間1000件以上のリクエストを処理できます。インフラストラクチャの面倒を見ることなく 99.95％ の可用性を実現できます。

巨大な単一リージョンのアプリケーション

巨大なアプリケーションではアプリケーションを複数デプロイするような環境で毎秒数千リクエストかそれ以上あり、99.95％ の可用性で、AZ が障害が発生したり切断されても影響がありません。DSQL を使用するとAZ やフォルトトレランス、障害の検出と対応などについて心配する必要はありません。

トレードオフとして、同時に同じキーを更新しようとすると楽観的同時実行制御エラーが発生してコミットが失敗します。そのためホットキーを避ける必要があります。従来のデータベースはデータの局所性を好みます。DSQL は分散を好みます。

マルチリージョンの Active-Active なアプリケーション

マルチリージョンで Active-Active なアプリケーションですが、2つの検討事項があります。1つはレイテンシで、もう一つはクライアント体験の最適化です。例えば東海岸と西海岸のクライアントにはそれぞれローカルの読み取りレイテンシを提供したいです。AZ の障害が発生しても数ミリ秒から数秒で切り替わり、データの損失や耐久性の損失はありません。自然災害などでリージョン全体に障害が発生した場合に備える場合でも、Active-Active で待機する必要がなく、数ミリ秒から数分で切り替えを行い、コミット済みのトランザクションが消えることはありません。

リージョンを超えたコミットではリージョン設定次第で 15〜100ms 程度時間がかかります。DSQL のトランザクションはレイテンシを改善していて、そのトランザクションのコミットで償却します。可能であれば読み取り専用で、必要な場合に書き込みを行います。アボートかロールバックしたトランザクションは決して見えず、実行中（コミット前）のトランザクションも決して見えません。

独立性と一貫性

DSQL はスナップショット分離を提供します。アトミックにコミットして、コミット時刻以降に開始するトランザクションに表示して、コミット時刻より前に開始するトランザクションには表示されません。DSQL は強い一貫性です。リージョン間であっても、スケールアウトした読み取りでも強い一貫性です。DSQL は強いスナップショット分離（スナップショット分離 ＋ 強い一貫性）を提供しています。Aurora DSQL の強いスナップショット分離は PostgreSQL の Repeatable Read と同等のものです。

まとめ

• シンプルなアーキテクチャも十分にスケールする
• Active-Active が望ましい
• ホットなキー書き込みを避ける
• トランザクションを使用する。

さいごに

Aurora DSQL は今回の re:Invent の発表の中で最も興味深いものでした。このセッションを見ると、マルチリージョンの巨大なアプリケーションだけでなく、小規模なアプリケーションから利用できるものであることが分かりました。

ただしトランザクションでロックを取れないことに注意が必要になると思います。カジュアルにリージョン間で Active-Active なアプリケーションを構築可能であるので、アプリケーションが大規模になったり複雑化することに備えトランザクションの検討が必要ですね。