データ増加と運用作業の影響

結果の要約

この実験では、サービスの運用中にスキーマを変更したりインデックスを作成したりする作業が DSQL でどれほど簡単で、業務にどのような影響を与えるか、そして DSQL のトランザクション制約が実際にどのように現れるかを確認しました。最小範囲(MVP)として、E002 規模のデータがある DSQL クラスターに毎秒1,000件の注文業務を送りながらインデックス作成と列の追加・削除を実行し、同じ負荷だけを送ったセルと比較しました。対照群は今回測定していません。

注文1,100万行の status 列に CREATE INDEX ASYNC でインデックスを作成すると、コマンドは0.1秒で戻り、インデックスが実際に使える状態(indisvalid)になるまで736秒(約12分)かかりました。ビルドが進行した5分間の測定区間で、注文作成の p95 は 27.5 ms から 52.0 ms に、p99 は 30.7 ms から 79.8 ms に増え、注文履歴照会の p99 も 9.8 ms から 45.7 ms に増えました。それでもすべての業務が SLO 内にあり、失敗は0件、業務の不変条件違反も0件でした。続けて実行した列の追加・列の削除・インデックスの削除は、それぞれ0.1秒以内に終わりました。

DSQL の制約ははっきりと現れました。5,000行を1つのトランザクションで変更しようとすると「transaction row limit exceeded」(54000)で拒否され、トランザクションを310秒間開いたままにすると「transaction age limit of 300s exceeded」で拒否されました。大量の変更は3,000行以下に分け、5分を超える作業はトランザクションを分ける必要があります。E002 でもこの制約のためにロード・後片付けのコードを分割して書き、大量削除が遅いため測定方法を変える必要がありました。

本番利用の観点

運用中のインデックス追加と列の変更は、DSQL ではサービスを止めずに行えました。1,100万行のインデックスビルド中に書き込み遅延が2–3倍に増えましたが目標内で、失敗もありませんでした。ただしインデックスはコマンド終了後も約12分間使えないため、デプロイ手順で indisvalid を確認してから新しいインデックスに依存するコードを有効にする必要があります。3,000行と300秒のトランザクション上限は、大量の更新・削除や長いバッチ処理を複数のトランザクションに分けることを強いるため、既存のバッチやデータ移行スクリプトは書き直す必要があります。vacuum のような保守作業はユーザーが行う必要はありませんが、対照群との運用負担の比較はしていません。

確認する問い

DSQLの DDL・診断・成長への対応はどれほど簡単で、制約は何か?

実行条件

リージョンと日時: ソウル(ap-northeast-2)、2026-09-29 10:27–10:53 UTC。
構成: D1 Aurora DSQL 単一リージョン、E002 規模のデータ(注文1,100万、注文明細2,750万行、約 5 GiB)。E002 の2回目の測定と同じクラスターで、その測定で蓄積された行を含みます。
負荷: E002 と同じ業務構成、固定到着率 1,000 TPS、ウォームアップ60秒 + 測定300秒。負荷だけを送る基準セルと、DDL を同時に実行するセルを順に実行しました。
DDL の順序: 測定開始と同時に CREATE INDEX ASYNC orders_status_mvp ON orders (status) → indisvalid が真になるまで5秒ごとに確認 → ALTER TABLE customers ADD COLUMN → DROP COLUMN → DROP INDEX。インデックスのビルドが測定区間より長かったため、列の変更とインデックスの削除は測定区間の終了後に実行されました。
上限の試験: 商品5,000行を1つのトランザクションで更新、トランザクションを開いたまま310秒待ってから照会。
負荷発生器: m7g.4xlarge Spot ランナー1台。
計画から変わった点： 共通の Q の60%の代わりに 1,000 TPS を使い、4時間の更新・削除負荷、3回の繰り返し、容量増設・アップグレードの分岐、対照群との比較、診断指標の収集は実行しませんでした。

性能結果

p95 / p99、単位 ms。両セルとも成功約 927 TPS、失敗0、不変条件違反0件、SLO 合格。

業務	負荷のみ	インデックスビルド中
商品照会	6.0 / 6.9	5.9 / 6.7
注文履歴	8.7 / 9.8	9.4 / 45.7
注文作成	27.5 / 30.7	52.0 / 79.8
注文取消	27.0 / 29.2	29.8 / 66.1

DDL・上限の試験	結果
`CREATE INDEX ASYNC`(1,100万行)	コマンド0.1秒、使用可能まで735.8秒
`ALTER TABLE ... ADD COLUMN` / `DROP COLUMN`	0.04秒 / 0.12秒
`DROP INDEX`	0.05秒
5,000行更新のトランザクション	拒否: `54000` transaction row limit exceeded
310秒間開いたトランザクション	拒否: `54000` transaction age limit of 300s exceeded

成功スループット(約 927 TPS)が到着率(1,000 TPS)より低いのは、取消リクエストの一部が「すでに取消済みの注文」として拒否され成功に数えられなかったためと考えます(先行する測定が同じデータで取消を累積)。

開発・運用のしやすさ

非同期インデックス: コマンドはすぐに終わり、ビルドはサービスがバックグラウンドで行います。インデックスは pg_indexes にはすぐ表示されますが、indisvalid が真になるまでは使えません。E002 ではこの違いを見落とし、初期化が全件スキャンを行う問題が起きました。
外部キーの参照側インデックス: DSQL は外部キーを参照する側の列のインデックスを自動では作成しません。E002 では元帳の order_id インデックスがなかったため、注文の削除が元帳全体を走査して300秒の上限に達しました。
上限に合わせたコード: ロード・削除・バッチ作業を3,000行以下、300秒以下のトランザクションに分ける必要がありました。
保守: vacuum・統計更新のような作業をユーザーが設定したり実行したりする必要はありませんでした。実行計画と診断指標へのアクセスのしやすさは今回評価していません。

費用

同じクラスターを使った E002 の2回目の測定の一部として、この試験区間(10:28–10:54 UTC)の DSQL 使用量は 142,954 DPU(約 $1.43)でした。このうち2つの負荷セル(各6分、1,000 TPS)は約2万 DPU と推定されるため、大部分は1,100万行のインデックスビルドが使ったものとみています(約12万 DPU、約 $1.2、分単位の合計から切り分けた推定)。クラスターとランナーの費用は E002 レポートの費用の節に含めています。

結論と限界

DSQL は負荷中のインデックス追加と列の変更をサービスを止めずに処理し、インデックスビルド中も SLO を守りました。その代わり、トランザクションの行数・時間の上限が大量作業の構造を変えることを求めます。
限界: 1回の実行、1,000 TPS の1水準、DSQL 単独の測定です。対照群でのインデックス作成の影響とは比較しておらず、長期的な成長と運用作業の時間は測定していません。

後片付けの記録

この試験は E002 の2回目の測定の実行(e002-20260929t081139z-4dce)のクラスターとランナーを使いました。試験用のインデックスと列は試験内で削除しました。リソースは 11:08–11:10 UTC に削除し、e002.py verify の remaining_count=0(11:10:30 UTC)と手動のクロスチェック(DSQL クラスター・実験 VPC・実験 IAM ロール・未処理の Spot リクエスト0個)を完了しました。