オンプレミスSQL ServerからAWS移行後にDisk I/O性能が低下する原因と対策

この文書の適用条件

そのまま実行できるコマンド

-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: 対象テーブルへの参照権限（sp_estimate_data_compression_savings の実行権限）
-- 変更作業: なし（見積もりのみ、実際の圧縮は行わない）
-- Production 実行: 可能
USE [SampleDB];
GO
EXEC sys.sp_estimate_data_compression_savings
    @schema_name = 'dbo',
    @object_name = 'Orders',
    @index_id = NULL,
    @partition_number = NULL,
    @data_compression = 'PAGE';

-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: sys.databases のメタデータ可視性
-- 変更作業: なし（参照のみ）
-- Production 実行: 可能
SELECT name, log_reuse_wait_desc
FROM sys.databases
WHERE name = 'SampleDB';
-- 結果が 'REPLICATION' の場合、CDC またはトランザクションレプリケーションが未読ログを保持している

-- 対象: SQL Server 2008 以降（CDC 対応エディション） / Amazon RDS for SQL Server
-- 権限: db_owner（cdc.sp_cdc_cleanup_job の実行権限）
-- 変更作業: あり（保持期間を超えたCDC変更テーブルのデータを削除）
-- Production 実行: 実行可能。ただし削除対象データを下流の連携がまだ消費していないかを事前に確認する
USE [SampleDB];
GO
EXEC sys.sp_cdc_cleanup_job;

-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server
-- 権限: sysadmin または db_owner
-- 変更作業: あり（ログファイルの末尾を切り捨ててファイルサイズを縮小）
-- Production 実行: 原則実行可能。ただし log_reuse_wait_desc が NOTHING であることを確認してから
USE [SampleDB];
GO
-- 目標サイズ（MB）を指定して縮小する
DBCC SHRINKFILE (N'SampleDB_log', 1024);

結果の読み方

こういう状況で使います

• オンプレミス移行前と同等以上のスペックのAWSインスタンスを選んだのに、夜間バッチやインデックス再構築の所要時間が2倍以上に伸びた
• 大規模なデータロードやインデックス再構築の途中でデータベース全体が一時的に応答しなくなる
• CPU使用率には余裕があるのに、バッチ処理だけが終わらない
• 移行後しばらくしてストレージ容量が急激に逼迫し、RDSの自動ストレージスケーリングが頻発する
• Provisioned IOPS（io2など）を増強してもストレージ費用ばかり増え、根本的な改善に至らない

考えられる原因（可能性の高い順）

1. 01

   ネットワーク接続型ストレージ（EBS）特有のレイテンシ

   オンプレミスの物理NVMe/SSDはPCIeバスに直結されマイクロ秒単位のレイテンシで動作しますが、AWSのRDS/EC2で標準的なAmazon EBSはインスタンスと専用の内部ネットワークリンクで接続される仮想ブロックストレージです。物理的な遅延（数ミリ秒単位）が構造上必ず発生します。

2. 02

   IOPSとスループットのスロットリング（帯域制限）

   インスタンスサイズおよびボリュームの種類・割り当て容量に応じて、1秒間に処理できるIOPSとスループット（MB/s）の上限が厳格に定義されています。gp2/gp3などの汎用ボリュームはベースライン性能を超えるとバースト残量を消費し、大規模なデータロードやインデックス再構築で上限に達すると激しいスロットリングが発生してDB全体が応答不能になります。ボリューム側のIOPSをio2等で引き上げても、インスタンス側のEBS専用帯域幅（EBS-Optimized）がボトルネックになる場合もあります。

3. 03

   Provisioned IOPSの過大設定によるコスト肥大化

   I/O性能不足を安易に解決しようとして高額なio2/io2 Block Expressなどのプロビジョンド IOPSを大量に確保すると、ストレージ費用だけで月数十万〜数百万円規模に跳ね上がり、クラウド移行によるコスト削減効果が失われます。

4. 04

   CDCクリーンアップジョブの遅延によるログ未解放

   大量のバッチ更新が発生した際にCDCのクリーンアップジョブが追いつかなくなると、トランザクションログが「CDCによってまだ読み取られていない」とマークされ、CHECKPOINTやログバックアップを実行してもログ領域が解放されなくなります。ログファイルが自動拡張を続け、ストレージ容量を枯渇させてRDSの自動ストレージスケーリングを強制発動させます。

確認手順

1. 1

   既存テーブルの圧縮削減効果を見積もる

   参照のみ

   `sys.sp_estimate_data_compression_savings` で、ディスクI/O削減とストレージ費用削減の余地がどれだけあるかを確認します。

2. 2

   log_reuse_wait_desc でログ未解放の要因を特定する

   参照のみ

   `sys.databases.log_reuse_wait_desc` が `REPLICATION` で固定されていないかを確認します。固定されている場合はCDCまたはトランザクションレプリケーションの遅延が疑われます。

3. 3

   CDCが有効かどうかとキャプチャの遅延を確認する

   参照のみ

   `sys.databases.is_cdc_enabled` でCDCの有効化状況を確認し、有効な場合は `sys.dm_cdc_log_scan_sessions` でキャプチャの遅延を確認します（詳細は関連記事を参照）。

4. 4

   EBSボリュームとインスタンスのIOPS/スループット契約値を確認する

   参照のみ

   ボリュームタイプ（gp3/io2等）のプロビジョンドIOPS・スループットと、インスタンス側のEBS帯域幅上限をAWSコンソールまたはCLIで確認します。

5. 5

   手動でCDCクリーンアップを実行する

   中

   下流の連携が保持期間内のデータを消費済みであることを確認したうえで `sys.sp_cdc_cleanup_job` を実行し、ログの解放可能状態を復元します。

6. 6

   ログファイルを縮小する

   高

   `log_reuse_wait_desc` が `NOTHING` になったことを確認してから `DBCC SHRINKFILE` でログファイルを目標サイズまで縮小します。

対応方法

これで解決しない場合に確認すること

• EBSボリュームのIOPS/スループットのバーストが枯渇していないか確認したか

  gp2/gp3のバースト残量を消費し尽くしていないかをCloudWatchメトリクスで確認します。

• インスタンス側のEBS帯域幅（EBS-Optimized）がボトルネックになっていないか確認したか

  ボリューム側のIOPSを引き上げても、インスタンスのEBS専用帯域幅の上限に達していれば期待した性能は出ません。

• CDCクリーンアップジョブの実行履歴とエラーを確認したか

  クリーンアップジョブが定期的に成功しているか、失敗やスキップが続いていないかをジョブ履歴から確認します。

• AWS Direct Connectの要否を含むネットワーク遅延を計測したか

  オンプレミスの残存アプリケーションとAWS上のDB間の通信遅延が別のボトルネックになっていないかを確認します。

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• オンプレミスSQL ServerをAWSに移行したら遅くなった原因を知りたい
• AWS移行後のストレージコストが急増する理由が知りたい
• CDCが原因でログファイルが増え続ける場合の対処法を知りたい

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

「Disk I/O 90%超過」のようなリソース閾値のアラートだけでは、どのクエリや処理が原因でI/Oを圧迫しているのか、月あたり実際にいくらの無駄なコストを生んでいるのかは分かりません。GIIPではストレージI/O・IOPS消費量・CDCクリーンアップジョブの実行状況・ログファイルの増減を同じ時系列で保持し、原因をコスト（$）ベースで特定できるようにしています。Provisioned IOPSの増強のような不可逆かつ高コストな判断は、実行前のSQLとロールバック手順を明示したうえで実施可否を人間が確認する運用としています。

関連サービス

• データベース性能チューニング
• 障害対応・火消し支援
• クラウドコスト最適化