rds 다운그레이드를 위한 지표 모니터링

목적

Aurora MySQL 클러스터의 리더 및 라이터 인스턴스를 다운그레이드하여 비용 절감 및 리소스 최적화

대상 인스턴스:

• 라이터 인스턴스: r6g.large (현재 USD 0.51/h)
• 리더 인스턴스: t4g.large (현재 USD 0.406/h)

---

라이터 인스턴스 다운그레이드 계획

• 현재 인스턴스 타입: r6g.large (2 vCPU, 16 GiB RAM, 시간당 약 USD 0.51/h)
• 다운그레이드 후 인스턴스 타입: t4g.medium (1 vCPU, 4 GiB RAM, 시간당 약 USD 0.203/h)

1)다운그레이드 근거

• 성능 모니터링 결과 (최근 6일 동안의 지표)

6일치 지표 대시보드 (3/15~)

CPU 사용률 (퍼센트)

• 평균 사용률: 약 10% 이하
• 피크 사용률: 최대 30% 정도
• 평가:
  • CPU 사용량이 매우 여유로움
  • 현재 r6g.large 인스턴스(2 vCPU) 대비 1 vCPU로 줄여도 성능 저하 문제 없을것으로 예상

---

여유 메모리 (FreeableMemory)

• 평균 여유 메모리: 약 4.9 GiB (전체 메모리의 약 30% 이상)
• 메모리 부족 종료: 없음
• 평가:
  • 메모리 사용률이 안정적이며, 메모리 부족으로 인한 문제 없음

---

IO 디스크 대기열 길이 (요청)

• 평균 대기열 길이: 0.0 ~ 0.001
• 피크: 4.6 ~ 9.3 (일부 구간)
• 평가:
  • 디스크 I/O 병목 현상 거의 없음
  • 간헐적인 피크가 있지만, 전체 성능에 미치는 영향은 미미

---

네트워크 처리량 (초당 바이트)

• RX/TX 피크 처리량: 약 180 KB/s
• 평균: 90 KB/s 이하
• 평가:
  • 네트워크 부하가 낮음

---

IO 지연 시간 (밀리초)

• Read/Write Latency: 10~20 ms, 간헐적으로 25 ms까지 상승
• 평가:
  • 디스크 읽기/쓰기 지연이 일부 존재하나, 전체 성능에 영향 없음
  • DiskQueueDepth와 IOPS를 고려할 때, 성능 제로 이어지지 않음
  • 일반적인 데이터베이스 성능 기준:
    • 1~5 ms: 이상적
    • 5~20 ms: 양호, 약간의 지연은 있지만 문제 없음
    • 20~50 ms: 주의, 성능 저하 가능성 있음
    • 50 ms 이상: 문제 발생 가능성 높음

---

IO 처리량 (초당 바이트)

• 평균 처리량: 3~7 MB/s
• 평가:
  • 디스크 처리량이 적정 수준으로, 다운그레이드 시에도 무리 없음

---

세션 수

• 평균 세션 수: 1.5 ~ 2.9 (낮음)
• 평가:
  • 활성 세션이 적음으로, 다운그레이드 후에도 성능 저하 가능성 낮음

---

DML (초당 행 수)

• 삽입, 삭제, 업데이트 처리량: 주로 삽입 작업이 많음 (최대 9,385건/s)
• 평가:
  • DML 성능이 안정적으로 처리되고 있는 편

---

버퍼 풀 적중률

• 적중률: 100%
• 평가:
  • InnoDB 버퍼 풀 사용률이 매우 우수하여, 메모리 절감에도 성능 저하가 발생하지 않음

---

트랜잭션 처리 상태

• 활성 트랜잭션 수: 0.7 이하 (낮음)
• 평가:
  • 트랜잭션 처리 병목 없음

비용 절감 예상 효과

https://aws.amazon.com/ko/rds/mysql/pricing/

(다중 AZ배포 기준으로 계산 )

• 한 달 기준 비용 절감액: 약 220.44 USD -alpha(크레딧 추가사용시)
• 연간 기준 비용 절감액: 약 2,645.28 USD -alpha(크레딧 추가사용시)

최종정리

CPU 사용량과 메모리 사용량이 인스턴스 스펙에 비교했을때 미미하고,

IOPS 지연이 간헐적으로 발생하긴 하지만 일관되게 높은 값으로 유지되지 않으므로 다운그레이드 하더라도

크게 성능 이슈가 있을것이라 예상되진 않음

하지만 ,

r모델 인스턴스의 크기 중 가장 작은게 large이므로 같은 r모델로 다운그레이드는 더이상 불가능.

r 모델에서 t모델로 변경시 발생 가능한 이슈들이 존재함

• cpu크레딧 관리 ,
• cpu 사용량 증가시 추가 사용량에 대한 추가 비용 발생 할 수 있음
• 추후 리소스 사용량 증가시 다시 r로 변경해야할수도 있음,

위처럼 r모델에서 t모델로 변경하는것에 리스크가 있지만

t모델은 버스팅 모드를 지원 (cpu 20% 이하로 사용할때 크레딧 원기옥처럼 모았다가 cpu사용량 20% 이상되면 모아뒀던 크레딧 소진)

t모델 중에서도 t4g나 t3 사용하면 크레딧 소진되어도 성능저하되지않고 크레딧을 추가로 만들어서 사용(추가 과금 가능성있으나 비싸지 않을것으로 보임 시간당 약 0.05USD)

https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode-concepts.html

---

리더 인스턴스 다운그레이드 계획

• 현재 인스턴스 타입: t4g.large (2 vCPU, 8 GiB RAM, 시간당 약 USD 0.406)
• 다운그레이드 후 인스턴스 타입: t4g.medium (1 vCPU, 4 GiB RAM, 시간당 약 USD 0.203/h)

1.다운그레이드 근거

• 성능 모니터링 결과

CPU 사용률 (퍼센트)

• 평균 사용률: 10% 미만 (일부 피크 구간 20~30%)

여유 메모리 (FreeableMemory)

• 평균 여유 메모리: 약 2.9 GiB

디스크 대기열 길이 (IO 디스크 대기열 길이)

• 평균 대기열 길이: 0.0005~0.001 정도
• 디스크 IOPS 대기열이 거의 없는 상태로, I/O 병목 문제는 거의 없음.

네트워크 처리량 (초당 바이트)

• RX/TX 처리량:
  • 피크 시 100KB/s 정도
• 네트워크 부하가 적은 편

세션 수와 DB Load

• DB Load: 평균 0.7 ~ 1.3 (적정 수준)
• Aborted Connections: 거의 없음
• 평가:
  • 세션 처리 성능도 안정적이며, DB 부하도 낮은 편

IO 지연 시간 (밀리초)

• Read/Write Latency: 1~2ms (일부 피크 4ms)
• 디스크 성능이 안정적이며, 지연 시간도 문제 없음
• I/O 병목은 없는 것으로 판단됨

버퍼 풀 적중률

• 적중률: 거의 100% 유지
• 메모리 활용이 매우 효율적이며, 버퍼 풀 캐시 적중률이 높아 성능 저하 위험이 없음

비용절감 예상 효과

• 한 달 기준 비용 절감액: 약 146.16 USD
• 연간 기준 비용 절감액: 약 1,753.92 USD

최종정리

라이터 인스턴스는 기존에도 t모델 n개월간 운영했을떄 이슈 없었음

전체적인 리소스 사용량이 기존 인스턴스의 평균 10~20% 정도이므로 사이즈 줄여도 큰 이슈 없을것으로 예상

---

인스턴스 변경 관련 예상 작업

1. aws 콘솔에서 다운그레이드 실행 (실행 시간 결정 필요, 리더, 라이터 순차적으로 실행해야함 )
2. 인스턴스 변경 중 오류 발생시 db 자동복구 해야할 가능성 있음
3. 다운그레이드 후 성능 모니터링 주기적으로 시행(rds 지표 대시보드 모니터링 )
   • cpu사용량
   • cpu 크레딧 추가 사용량 (r→t변경 인스턴스에 대해)
   • 메모리 관련 지표
   • 네트워크
   • IOPS latency …등등