[AWS RDS SQL Server] 데이터 업데이트 작업

여러 테이블들의 데이터를 업데이트 해야하는 작업이 있었습니다.

작업을 위해 테스트한 내용과 주요 모니터링으로 보았던 지표들 그리고 특이사항에 대하여 기록합니다.

 

작업 요구 내용

서버 스펙  최대 IOPS : 6,120

최대 처리량 : 약 170MB  평소 IOPS 평균 100 이하 (스파크성으로 1000까지 증가) 처리량 평균 5MB 이하 (백업 시간 제외, 스파크성으로 20MB까지 증가)

CPU : 평균 5% 이내 (백업 시간 30%)

 

목표 

IOPS : 최대 4천 이하 유지

처리량 : 100MB 이하 유지

처리시간 : 최대 하루 이내 처리 이슈 없는 성능으로 최대한 빠르게 처리

 

주요 확인 항목 

CPU

IO 관련 : READ, WRITE Latecny IOPS, Throughput

지연 관련 : DiskQueueDepth, Lock Waits/sec

미러링 관련 : Transaction/sec, SQL SERVER:Database Mirroring

etc) Cache Hit Ratio, PLE, Log Flushs/sec, Latch Waits/sec

 

SQL 서버의 락 에스컬레이션은 5000건 이상(문서의 내용이지만 명확하진 않음) 의 락이 걸릴 경우 에스컬레이션 하는 경우가 많습니다. 해당 서버의 메모리가 여유있는 점을 고려하여 Trace 1224 를 ON으로 설정하는 테스트를 진행해보았습니다. 작업간 Lock Manager의 메모리 변화량을 추적하였을 때 성능에 영향이 없을 것으로 판단되어 해당 옵션을 ON으로 변경하였습니다.

https://learn.microsoft.com/ko-kr/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql?view=sql-server-ver16#tf1224

해당 표를 통해 1224 설정을 킨 경우 락 에스컬레이션이 발생하지 않은 것을 볼 수 있습니다.

 

아래 표는 작업 간의 적절한 IOPS와 시간을 계산하기 위한 업데이트 건수를 조정하는 테스트의 기록입니다.

 

여러 테스트를 바탕으로 아래의 순서로 작업을 처리하고 예상 시간을 산출하였습니다.

소규모 테이블 일괄 처리, 게임유저 1500건씩, TABLEA 10000건씩, TABLEB 5000건씩, 일반유저 500건씩, 일반유저 뒷번호 400건씩

테스트 별 소요 시간 (2회 실시)
일괄처리 1분내외
게임유저 1500건 40분 ,50분
TABLEA 1만건 40분, 40분
TABLEB 5천건 1시간35분, 1시간 25분
일반유저 500건 5시간 10분, 5시간 10분
일반유저 400건 2시간, 1시간40분

 

실제 작업

테스트와 비슷한 시간이 소요되었으며 서비스 운영에 이슈는 없었습니다.

 

특이사항

테스트 환경은 AG 환경이었고 실제 운영 환경은 미러링으로 구성되어 있었습니다.

 

1 미러링 트랜잭션 딜레이 현상 발생 (처리량에 따른 증가가 아닌 일시적인 증가)

 

2 순간적인 Latency 증가

 

스냅샷 생성 + 로그백업을 진행할 때 DB 미러링이 지연되는 것 확인