【技術検証】Amazon Aurora DSQLで遊んでみた

Last updated at 2025-01-12Posted at 2025-01-12

いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！

AWS reinvent:2024のアップデートで注目を浴びたAmazon Aurora DSQLをまだ触っていなかったため、何ができるのかをキャッチアップするために触ってみました。

データベース初学者でもすっと読めるように、平易な表現で執筆しておりますので、お気軽に読んでいただければ幸いです。

Amazon Aurora DSQLは現在プレビューサービスとなります

本日、私たちは常時利用可能なアプリケーションに最適な、最速のサーバーレス分散 SQL データベース「Amazon Aurora DSQL」をご紹介します。Aurora DSQL は、事実上無限のスケーラビリティ、最高の可用性、そしてインフラストラクチャ管理ゼロを提供します。ワークロードの需要に合わせて、データベースのシャーディングやインスタンスのアップグレードなしにスケーリングできます。革新的なアクティブ・アクティブの分散アーキテクチャにより、シングルリージョン構成で 99.99%、マルチリージョン構成で 99.999% の可用性を実現し、高可用性アプリケーションの構築に最適です。サーバーレスの設計により、パッチ適用、アップグレード、メンテナンスダウンタイムなどの運用負荷が不要になります。Aurora DSQL は PostgreSQL 互換であり、開発者は既知のリレーショナルデータベースの概念、ドライバー、ツール、フレームワークを使ってアプリケーションを迅速に構築・デプロイできます。

すごくざっくりいうと、高可用性とスケーラビリティを最大まで追求したPostgreSQL対応のSQLデータベースサービスかと思います。

Aurora DSQL は、3 つの AZ にまたがるアクティブ/アクティブの単一リージョンクラスターを提供し、レプリケーションラグと従来のデータベースフェイルオーバー操作を最小限に抑えます。ハードウェアまたはインフラストラクチャに障害が発生した場合、手動介入なしでリクエストを正常なインフラストラクチャに自動的にルーティングします。

アーキテクチャ構成を見る限り、3つのアベイラビリティゾーンに所属しているストレージ間でデータを分散管理しているような構成のように見えますね。

マルチリージョン対応の場合の構成として以下のようなアーキテクチャ構成になるようです。

楽観的同時実行制御

そのうえで、Amazon Aurora DSQLを利用するうえで注意が必要な要素として楽観的同時実行制御があります。

楽観的同時実行制御に関して、公式ブログでも説明がなされていました。

公式ブログ

Aurora DSQL は楽観的同時実行制御を採用しています。これは、リレーショナルデータベースよりも非リレーショナルデータベースでよく使われる手法です。楽観的同時実行制御では、同じ行を更新しようとする他のトランザクションについてあまり考慮せずにトランザクションロジックを実行します。トランザクション完了時に、データベースへの変更をコミットしようとします。その際、Aurora DSQL は他の同時実行トランザクションからの書き込みが干渉していないかを確認します。干渉がなければトランザクションは正常にコミットされますが、干渉があった場合はデータベースがエラーを返します。このような場合、ユーザーは悲観的同時実行制御を使うデータベースと同様に、どのように処理を進めるかを決める必要があります。ほとんどのユースケースでは、トランザクションをリトライするのが最善のアプローチです。

すごくざっくりいえば、データベースの変更確定（=コミット）時に競合が発生したら、エラーを返す仕様にしているといったニュアンスかと思います。

開発業務でGitを利用している方であれば、コミット時のコンフリクトをイメージすればわかりやすいかと思います。

そのうえで、注意が必要なところとして、競合が発生したらエラーが返されるため、エラー時の挙動を定義する必要があるといったことがあります。

今までのデータベースであれば、Aさん・Bさんが同じ行への更新を行おうとしたときに、ロック機能を利用することで、処理の待機時間がかかるが処理競合を防ぐことができるといった考え方でデータ更新を行えます。

データベースのロックに関しては以下ブログが分かりやすいです

https://zenn.dev/gibjapan/articles/1d8dfb7520dabc

Amazon Aurora DSQLの場合は、処理競合が発生したら、即座にエラーを返してしまい、ユーザ側でアクションを行わないといつまでたってもデータが反映されないといった状況が発生します。

そのため、Amazon Aurora DSQLを導入する場合、処理競合が発生した場合の処理方針（リトライ実行など）を考える必要があるといったことを重視する必要があります。

利用可能リージョン

本サービスは、現在プレビュー期間のため以下リージョンでしか利用できません。

米国東部 (バージニア北部)
米国東部 (オハイオ)

ユーザ向けドキュメント

ユーザ向けドキュメントに関してもある程度そろっているので、何から始めればいいのかよくわからないといった状況にはなりにくいかと思います。

スタートガイド

開発者向けガイド

APIリファレンス

APIリファレンスがそろっているのでCDKでの構築も可能な印象を持ちました。

コンソールでの設定画面

実際にコンソール上で触ってみないとわからないので触ってみたいと思います。

検索ボックスにDSQLと入力し、検索結果内のAmazon Aurora DSQLを押下

米国東部 (バージニア北部)および米国東部 (オハイオ)以外のリージョンの場合、利用不可画面が表示されます。

クリック後、Amazon Aurora DSQLトップ画面が表示されるためcreate Clusterボタンを押下

クリック後、Amazon Aurora DSQL設定画面が表示されます
マルチリージョン構成で設定する場合は、Multi-Regionのチェックボックスを押下（今回はマルチリージョンを試してみるのでチェックを入れておく）

Multi-Regionにチェックを入れた場合、Linked cluster Region（レプリケーション用リージョン）とWitness Region（書き込み用リージョン）を設定することができます。
ただし、Linked cluster RegionはOhioのみ**、Witness RegionはOregonしか選択できません。

Linked cluster Region設定画面

Witness Region設定画面

Tagに関してはデフォルトで値が入っているため、Create Clusterボタンを押下

設定できるタグに関しては50個までのようですね。

作成したDSQL用のクラスターが表示されています
StatusがCreateなのでしばらく待機します

補足ですが、クラスターに設定されたエンドポイント宛にpingを実行したら、ipv6アドレスが紐づいているようですね

C:\>ping taabtygyqp4nfpj5r63ieo4z54.dsql.us-east-1.on.aws

taabtygyqp4nfpj5r63ieo4z54.dsql.us-east-1.on.aws [2600:1f18:692c:303:31c4:3b43:ed6d:d04d]に ping を送信しています 32 バイトのデータ:
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。

2600:1f18:692c:303:31c4:3b43:ed6d:d04d の ping 統計:
    パケット数: 送信 = 4、受信 = 0、損失 = 4 (100% の損失)、

C:\>