온프레미스 SQL Server에서 AWS 이전 후 디스크 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 등의 Provisioned 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 등)의 Provisioned 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の対応範囲

‘디스크 I/O 90% 초과’와 같은 리소스 임계값의 알림만으로는, 어떤 쿼리나 처리가 I/O를 압박하고 있는지, 월당 실제로 얼마만큼의 불필요한 비용이 발생하는지는 알 수 없습니다. GIIP에서는 스토리지 I/O·IOPS 소비량·CDC 정리 잡의 실행 상황·로그 파일의 증감을 동일 시계열로 보유하여, 원인을 비용($) 기반으로 특정할 수 있도록 하고 있습니다. Provisioned IOPS의 증강과 같은 비가역적이며 고비용인 판단은, 실행 전의 SQL과 롤백 절차를 명시한 뒤 실시 가능 여부를 인간이 확인하는 운용으로 하고 있습니다.

関連サービス

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