DSQLの開発・運用のしやすさと導入負担
DSQLは初期導入・繰り返し運用の作業時間と修正量をどれだけ減らすか、または増やすか？
結果の要約
この実験では、DSQLを導入するとインフラ運用の作業がどれだけ減り、その代わりにアプリケーションと運用手順にどのような負担が加わるかを整理しました。最小範囲（MVP）として、新たなAWS実行なしに、E001からE012までで4つのサービス（DSQL、RDS Multi-AZ、Aurora Provisioned、Aurora Serverless v2）を実際に作成し、データを投入し、負荷をかけ、復旧し、削除する中で経験した作業を集めました。計画にあった作業ごとの時間測定と3回の再実行は行っていないため、作業時間の削減率は計算していません。
インフラ側の作業はDSQLのほうが明確に少なくなりました。DSQLクラスターは作成リクエストから32秒で使用可能になり、削除は約2分でした。Aurora Serverless v2（writer+reader）は作成に約11分、削除に約15分かかりました。DSQLにはインスタンスサイズや最小・最大容量を選ぶ手順、保存するパスワード、vacuumのようなメンテナンス設定、読み取り・書き込みのルーティングがなく、2万4千TPSまで負荷が増えても容量を調整する必要がありませんでした。
一方、アプリケーション側の負担はDSQLで増えました。業務SQL 35個のうち16個を修正する必要があり（E001）、コミット時の競合をリトライするコードが必須でした（E004）。トランザクションは3,000行と300秒を超えられないため、データ投入・削除・バッチのコードを分割する必要があり（E002、E008）、非同期インデックスは完了を別途確認する必要があり、外部キー側のインデックスを手動で作成する必要がありました。接続は1時間ごとに入れ替えてIAMトークンに署名する必要があり（E003）、ポイントインタイム復元がないため、誤操作からの復旧はバックアップ周期に縛られました（E007）。
本番利用の観点
DSQLは「DBサーバーを運用する作業」を大きく減らします。容量計画、インスタンスの入れ替え、パスワードのローテーション、vacuum、readerルーティングを気にする必要がなく、クラスターの作成も30秒余りでした。その代わり、その負担のかなりの部分がアプリケーションに移ります。既存のPostgreSQLコードはSQL修正、リトライ、トランザクション分割、接続入れ替えを設計し直す必要があり、ポイントインタイム復元がない分、バックアップ周期と復旧手順を別途決める必要があります。新しく作るサービスが最初からこの制約に合わせて設計するなら利点は大きく、ストアドプロシージャや大量バッチが多い既存サービスを移行すると負担が大きくなります。作業時間は測定していません。
確認する問い
DSQLは初期導入・繰り返し運用の作業時間と修正量をどれだけ減らすか、または増やすか？
実行条件
- 追加のAWS実行: なし。E001–E012の実行記録、ツールコードの変更履歴、公開レポートを根拠に整理しました。
- 対象: D1 Aurora DSQL、R1 RDS PostgreSQL 16 Multi-AZ、A1 Aurora PostgreSQL 16 Provisioned、A2 Aurora PostgreSQL 16 Serverless v2（ソウル）。
- 計画から変わった点： 作業ごとの実作業時間・待ち時間の測定、最初の実装と独立した3回の再実行、権限エラーの診断試験、基準となるPostgreSQLアプリのサービスごとのdiff管理は行っていません。下表の時間は自動化ツールのログから読み取ったサービスの待ち時間です。
性能結果
インフラ作業（自動化ログ基準）
| 作業 | DSQL | Aurora Serverless v2（writer+reader） | 根拠 |
|---|---|---|---|
| 作成リクエスト → 使用可能 | 32秒 | 約11分 | E005–E009 実行B、2026-09-29 |
| 削除リクエスト → 削除完了 | 約2分 | 約15分 | E002 2回目・実行B |
| 容量の選択 | なし | ACUの最小・最大、readerの昇格優先順位 | E002 |
| 認証の準備 | IAM権限（dsql:DbConnectAdmin） |
マネージドパスワード（Secrets Manager） | E002 |
| 読み取りルーティング | なし（単一エンドポイント、即時に最新） | readerエンドポイント、書き込み直後の読み取りはwriter | E005 |
| 負荷増加への対応 | なし（24,541 TPSまで） | 最大ACUの範囲内で自動、上限32 ACU | E002、E009 |
| 誤操作からの復旧 | バックアップボールト・ロールの準備、フルバックアップ → 新クラスター（129秒） | ポイントインタイム復元 → 新クラスター + インスタンス（587秒） | E007 |
アプリケーションと手順に加わった作業（DSQL）
| 項目 | 必要な変更 | 根拠 |
|---|---|---|
| SQL互換性 | 35個中16個を修正: sequence・identity、serial、インデックス作成、一時テーブル・パーティション、PL/pgSQL・トリガー、分離レベル、statement_timeout、サーバー側のキャンセル |
E001 |
| 同時実行 | コミット時の競合（40001）のリトライと、業務IDによるコミット有無の確認が必須。READ COMMITTEDなし |
E004 |
| トランザクションのサイズ・時間 | 3,000行、300秒の上限に合わせてデータ投入・削除・バッチを分割 | E002、E008 |
| インデックス | CREATE INDEX ASYNC の後に indisvalid を確認。外部キー側のインデックスを手動で作成 |
E002、E008 |
| 接続 | 1時間の接続寿命に合わせた入れ替え、IAMトークンの署名・キャッシュ、同時に最初の接続をするときの署名の競合防止 | E002、E003 |
| 一時的なエラー | データ投入中の XX000 server unavailable のリトライ |
E002 |
| 大量削除 | 遅いため、測定ツールの初期化方法を変える必要があった | E002 |
| 復旧 | ポイントインタイム復元なし。バックアップ周期でRPOが決まり、復元後は新しいエンドポイント・権限に切り替え | E007 |
| 診断 | SHOW max_connections が20を返す（実際のクォータは1万） |
E004 |
開発・運用のしやすさ
- インフラ運用の面でDSQLが減らした作業は、作成・削除の待ち時間、容量計画、パスワード管理、メンテナンス設定、読み取りルーティングです。これらは繰り返し運用で毎回発生する作業なので、サービスの数が多いほど効果が大きくなります。
- アプリケーションの面で増えた作業の大部分は、一度実装すれば再利用できるコード（リトライ、トランザクション分割、トークン署名、接続入れ替え）ですが、既存のコードベースでは全領域にわたる修正が必要です。
- 今回の研究の負荷ツールも、DSQLに対応するために何度も修正しました:
server unavailableのリトライ、チャンク単位でのデータ投入の再開、非同期インデックスの完了待ち、外部キーインデックスの追加、トランザクション分割、トークン署名のロック、初期化方法の変更。
費用
このレポート自体はAWSリソースを作成していません。引用した実行の費用は各レポートと E010 にまとめています。
結論と限界
- DSQLはインフラ運用の作業を減らし、アプリケーション設計の負担を増やします。新しく設計するサービスは利点が大きく、既存のPostgreSQLの機能に依存するサービスは移行コストが大きくなります。
- 限界: 作業時間は測定しておらず、人が実際に費やした時間と学習コストを金額で比較していません。対照群側の繰り返し運用作業（パッチ適用、インスタンスの入れ替え、ストレージの増設）は実行していません。観察は今回の研究で経験した事例であり、すべてのワークロードに一般化できるものではありません。
後片付けの記録
- このレポートは新しいAWSリソースを作成していません。引用した3つの測定実行は、それぞれのレポートで残存リソース0を確認しています（2026-09-28 12:07:44、2026-09-29 11:10:30、10:20:27 UTC）。