はじめに

re:Invent 2025の一発目のセッションで、DSQLの並列実効性についてのライブコーディングセッションに参加しました。

セッション概要

このセッションはCode talkという形式のセッションで、話者はライブコーディングを行いながら、DSQLの並列実効性についての説明をしていました。
話者がライブコーディングにつまずいているところに聴講者から修正点について指摘があったりと、Code talkの醍醐味と言えるインタラクティブなシーンが多くありました。
セッション中は聴講者から様々な質問が行われ、DSQLに関する様々な特性が深堀りされていました。

ライブコーディングデモ

ライブコーディングは以下のリポジトリをベースに行われたため、試してみたい方はこちらを参照してみてください。

https://github.com/marcbowes/riv25-codetalk

セットアップ（クラスター作成 ~ デモ実行）

マネジメントコンソールからDSQLクラスターを作成するデモが行われました。
設定項目は非常に少なく、スクロールバーが不要なほどシンプルであることが強調され、10秒程度でSingle-Regionのクラスターが作成されました（実際にカウントしていたw）
デモ用のlambdaコードにはトランザクションの中で2種の書き込みを行う簡単なDB操作がコーディングされました。

並列書き込みテスト（小規模）

1000アカウントに対して1000リクエストを並列実行するテストでは、多数のserialization errorが発生しました。
これはリクエスト数に対してアカウント数が少なく、競合率が高いためです。
リトライロジックの実装により、エラーが発生してもトランザクションが成功することが確認されました。

スケールアウトテスト

100万アカウントにデータを投入し、複数マシンから4000 TPSで並列実行するテストが行われました。
アカウント数を十分に増やしたことで競合確率が低下し、serialization errorがほぼ発生しなくなりました。
このデモから、競合を減らすスキーマ設計の重要性が示されました。

コストの確認

DSQLの課金モデルは使用量ベースで、Reads、Writes、Storage、Computeの4つのメトリクスで課金されます。
デモでは、負荷テスト中に$2、20-30分間100万TPSで実行して$10という実測値が紹介されました。
負荷がない時間帯はストレージ分のみの課金となり、アイドル時のコストが最小化されることが強調されました。

聴講者からの質問と回答

Q1: VPCの外からの接続は可能か

質問内容:
DSQLはVPCの外から接続できるのか？

回答:
はい、可能です。DSQLはパブリックエンドポイントを提供しており、VPC内に配置する必要はありません。
これはS3のような一般的なAWSサービスと同様の動作です。

Q2: 楽観的ロックアプローチのトレードオフ

質問内容:
楽観的ロック方式は開発者に負担をかけるのではないか？リトライロジックの実装が必要で、パフォーマンスにも影響する。PostgreSQLの標準的なRead Committedモードと比較すると妥協（compromise）なのでは？

回答:
その通り、トレードオフです。
DSQLはPostgreSQLのRepeatable Read相当よりも強力な分離レベルを提供しており、アノマリー（異常）がほとんど発生しません。
この強力な分離レベルを分散環境で実現するために、楽観的同時実行制御が採用されています。
確かにリトライロジックは開発者の負担ですが、より強い一貫性保証とのトレードオフであることを理解してください。

議論のポイント:
聴講者からは「straight out better（完全に優れている）とは言えない」という指摘があり、話者も「それはトレードオフだ」と同意していました。
この率直なやり取りは、DSQLの特性を理解する上で重要な議論でした。

Q3: 分散データベースでの一貫性管理

質問内容:
分散データベースでトランザクションが別々の場所で実行されている場合、どうやって競合を検出するのか？ストレージは共有されているが、セッションはどこかで待機する必要があるのでは？

回答:
楽観的同時実行制御では、トランザクション実行中にロックを取得しません。
各トランザクションは完全に独立して動作し、コミット時に単一の場所で競合がチェックされます。
コミット時に、他のトランザクションが同じレコードを変更していた場合、serialization errorが返されます。
ストレージレベルでの競合チェックは行わず、すべてコミット時に判定されます。

Q4: 接続数と課金の関係

質問内容:
例えば1000接続を開いた場合、課金はどうなるのか？

回答:
接続自体は無料です。
接続を開く際に権限チェックなどの小さな処理が発生しますが、課金されるのは実際の使用量（Reads、Writes、Compute）のみです。
接続を開いたままにしておいても、使用していなければ課金されません。
これにより、接続プールを維持してもコストを気にする必要がありません。

Q5: AuroraとDSQLの使い分け

質問内容:
これらの優れた機能がある中で、AuroraやRDSとDSQLをどう使い分けるべきか？

回答:
以下のガイドラインが示されました：

DSQLを推奨するケース:

• 新規アプリケーション開発で、インフラ管理を最小化したい場合
• スケール要件が不明で、柔軟なスケーリングが必要な場合
• サーバーレスアーキテクチャを採用している場合

Auroraを推奨するケース:

• マルチリージョン、アクティブ-アクティブ構成が必要な場合
• 極めて高いスループット要件がある場合

既存アプリケーションの場合:

• 必要な機能がDSQLでサポートされているか確認
• アプリケーション変更（特にリトライロジック実装）の価値があるか評価
• 機能が追加されるのを待つという選択肢も

「AWS社員として特定のサービスを推すつもりはない。重要なのは、あなたのユースケースに最適なツールを選ぶこと」というメッセージも示されました。

Q6: 高負荷時のコスト制御

質問内容:
サーバーレスは低負荷時は良いが、高負荷のプロダクション環境ではコストが高くなりがちだ。Lambdaのように実行時間の上限を設定してコストを制御できないか？

回答:
以下の点が説明されました：

• DSQLはまだ若いサーバーレスサービスで、価格プランは今後成熟していく予定
• DynamoDBなどの他のサーバーレスサービスから学んだ教訓を活かしている
• 例：DynamoDBは4KB単位の切り上げ課金だが、DSQLはバイト単位で正確に課金
• 実際にペタバイト級の負荷を実行している顧客でもコストは問題になっていない

コスト最適化のヒント：

• クエリの実行計画を確認（EXPLAIN）
• 適切なインデックスを作成
• AI（ChatGPTなど）を活用してクエリ最適化の提案を受ける
• CloudWatchでメトリクスを監視

Q7: パフォーマンス制御

質問内容:
スループット制限のような方法でパフォーマンスを制御できるか？遅いクエリが他のクエリのパフォーマンスを破壊する問題をどう防ぐか？

回答:
アーキテクチャの観点から、パフォーマンスのボトルネックは主に書き込み側にあります。
読み取り側は境界なく実行可能で、強い一貫性が保証されます。

パフォーマンス最適化のポイント：

• クエリの実行計画を確認（EXPLAIN ANALYZE）
• 非効率なクエリを特定
• AIツールを活用してスキーマとクエリ最適化の提案を受ける
• CloudWatchでCompute時間やReads/Writesを監視
• 可能な限り効率的なクエリを実行することが重要

まとめ

かなり多くの質問があったため、質問の回答を多く含めた形でブログにまとめました。
少しでもCode talkの雰囲気が伝わり、コードを書くエンジニアに「re:Invent行ってみたい！」と思ってもらえたら幸いです！

以上でした！