読み取りのスケールと最新データの可視性
DSQLは reader への分散と比べて、性能・最新性・ルーティング作業がどう異なるか?
結果の要約
この実験では、書き込みがコミットされた直後に別の接続からその値をすぐ読めるかどうか、つまり最新データの可視性を DSQL と Aurora Serverless v2(A2)で比較しました。計画の全範囲ではなく最小範囲(MVP)に絞り、ある接続で行を挿入してコミット応答を受け取った直後から、別の接続が 10 ms 間隔でその行を照会する試験を200回繰り返しました。
DSQL(D1)では、200回すべてで最初の照会から新しい行が見えました。2つ目の接続が行を確認するまでの時間は p50 2.1 ms、p99 5.5 ms で、照会1回の往復時間程度でした。DSQL は接続先が1つだけで、コミット済みのデータはどの接続からもすぐに読めたため、アプリケーションが書き込み直後の読み取りを writer に送るルーティング規則を別途用意する必要はありませんでした。
A2 では、writer エンドポイントの別接続からは200回すべてですぐに見えましたが(p99 0.5 ms)、reader エンドポイントで照会すると200回中199回が最初の照会で行を見つけられませんでした。新しい行が reader で見えるまで p50 21.8 ms、p95 22.1 ms、p99 32.6 ms、最大 65.5 ms かかりました。reader に読み取りを分散する構成では、「書き込み直後に自分の書き込みを読む」必要があるリクエストを writer に送るか、数十 ms の遅延を許容する必要があります。今回は読み取りスループットのスケールや reader 数に応じた性能は測定していません。
本番利用の観点
最新性の面では DSQL が有利でした。コミット直後の別接続でも200回すべて新しい値を読めたため、従来の Aurora のように reader の複製遅延(今回の測定で p99 約 33 ms)を避けるために書き込み直後の読み取りを writer に送るルーティングコードは不要です。注文直後に注文内容を表示する画面のように、自分の書き込みをすぐ読む必要がある業務では実装が単純になります。ただし、読み取りスループットをどこまで増やせるかは今回測定しておらず、E002 で見たとおり DSQL の読み取り遅延そのものは Aurora writer の約4倍でした。読み取りの比率が非常に高いサービスは E002 の容量結果とあわせて判断する必要があります。
確認する問い
DSQLは reader への分散と比べて、性能・最新性・ルーティング作業がどう異なるか? 今回の MVP はこのうち最新性と、それに伴うルーティングの必要性だけに答えます。
実行条件
- リージョンと日時: ソウル(ap-northeast-2)、2026-09-29 08:38–08:40 UTC。
- 構成:
- D1: Aurora DSQL 単一リージョンクラスター。
- A2: Aurora PostgreSQL 16.15 Serverless v2、writer 1台 + 別 AZ の reader 1台(昇格優先度 1)、それぞれ 4–32 ACU、Aurora Standard。
- データ: E002 のデータ規模の2%(顧客2万、注文22万行、約 100 MB)。可視性試験用のテーブル
mvp_visibilityを別途作成し、試験後に削除しました。 - 方法: 書き込み接続が
INSERTを自動コミットで実行し、応答を受け取った時点から、観測接続が新しいトランザクションで 10 ms ごとにその行を照会しました。5秒以内に見えなければ打ち切り(censored)として数えました。各試験は200回です。 - 観測接続: D1 は同じエンドポイントの別接続。A2 は writer エンドポイントの別接続と reader エンドポイント(
pg_is_in_recovery() = trueでレプリカであることを確認)の2通り。 - 負荷発生器: 構成ごとに Spot ランナー1台(D1
c6g.4xlarge、A2m7g.4xlarge)。可視性試験は接続を2つしか使わないため、ランナーの仕様差は結果に影響しません。 - 計画から変わった点： 読み取り中心の負荷でのスループット・p99 の比較、reader 数の変更、R2 構成、エンジンの複製指標の収集は実行しませんでした。
性能結果
| 構成 | 観測経路 | 最初の照会で古い値 | 5秒超過 | 見えるまで p50 | p95 | p99 | 最大 |
|---|---|---|---|---|---|---|---|
| D1 | 同じエンドポイント、別接続 | 0/200 | 0 | 2.1 ms | 2.8 ms | 5.5 ms | 41.8 ms |
| A2 | writer エンドポイント、別接続 | 0/200 | 0 | 0.2 ms | 0.3 ms | 0.5 ms | 4.1 ms |
| A2 | reader エンドポイント | 199/200 | 0 | 21.8 ms | 22.1 ms | 32.6 ms | 65.5 ms |
- 見えるまでの時間には観測照会そのものの往復時間が含まれます。D1 の値が A2 writer より大きいのは複製遅延ではなく、DSQL の照会1回の遅延(E002 では読み取り約 2–10 ms)のためです。
- A2 reader の遅延は照会間隔 10 ms 単位で測定されるため、約 ±10 ms の誤差があります。
開発・運用のしやすさ
- DSQL は接続先が1つなので、読み取り・書き込みのルーティング設定は不要でした。A2 は reader エンドポイントがクラスターエンドポイントとは別にあり(
.cluster-ro-)、書き込み直後の読み取りをどちらに送るかをアプリケーションが決める必要があります。 - DSQL で試験テーブルを作成・削除する DDL は問題なく実行されました。
費用
この試験は E005・E006・E007・E009 をまとめて実行した実行 B(e002-20260929t082035z-afbe)の一部で、可視性試験そのものは約2分でした。実行 B 全体の費用は E009 レポートの費用の節にまとめています。
結論と限界
- DSQL はコミット直後に別接続からも新しい値を読めましたが、A2 reader はほぼ毎回数十 ms 遅れて見えました。この差が、書き込み直後の読み取りルーティングが必要かどうかを分けます。
- 限界: 各試験200回、1回の実行です。小規模データと無負荷状態での測定のため、負荷の大きい状況では複製遅延がさらに大きくなる可能性があります。読み取りスループットのスケールは測定していません。
後片付けの記録
- 実行 B で作成したリソース: BATCH(VPC、サブネット2つ、IGW、セキュリティグループ2つ、DB サブネットグループ、ランナーの IAM ロール・インスタンスプロファイル)、D1 DSQL クラスター、A2 クラスターと writer・reader、RDS 管理シークレット、Spot ランナー2台(D1
c6g.4xlarge、A2m7g.4xlarge)。E007 で AWS Backup ボールト、バックアップサービスロール、復旧ポイント2つ、復元した DSQL クラスター1つ、ポイントインタイム復元した A2 クラスターとインスタンスを追加で作成しました。 - 削除: バックアップボールトと復旧ポイント2つは 09:35 UTC に、復元した DSQL クラスターと A2 の復元先は 09:48 UTC から約 10:05 UTC にかけて、所有タグを確認したうえで削除しました。残りは
e002.py batch-downで 10:04–10:20 UTC に削除しました。削除に失敗したリソースはありません。 - 検証(10:20:27 UTC):
e002.py verifyの結果はremaining_count=0です。手動のクロスチェックで AWS Backup ボールト0個、この実行の接頭辞を持つ RDS クラスター・IAM ロール0個、未処理の Spot リクエスト0件を確認しました。この時点で残っていた DSQL クラスター1つは、同時に実行中だった実行 A(E002・E003・E008・E012)のものです。