Amazon RDS 비용 최적화를 위한 단계 및 고려 사항

AWS의 주요 이점 중 하나는 애플리케이션에 필요한 리소스 수를 프로비저닝하고 요구 사항 변경에 따라 확장하거나 축소할 수 있는 유연성입니다. 이를 위해서는 현재 리소스 사용률을 모니터링하고 필요한 경우 조치를 취할 수 있는 정책이 있어야 합니다. 이러한 사전 조치가 마련되지 않으면 리소스를 적게 프로비저닝하거나 과도하게 프로비저닝 할 수 있습니다. 리소스를 부족하게 프로비저닝하면 성능에 직접적인 영향을 미치므로 에스컬레이션되고 수정됩니다.

그러나 과도하게 프로비저닝 된 리소스는 애플리케이션 중단을 초래하는 직접적인 기능적 영향을 미치지 않으므로 종종 놓치는 경우가 많습니다. 결과적으로 리소스가 과도하게 할당되어 크기를 줄이고 최적화해야 할 수 있습니다.

이 글은 모범 사례를 사용하여 Amazon Relational Database Service(Amazon RDS) 비용을 최적화하기 위한 권장 사항을 제공합니다.

접근 방식

이 Amazon RDS 비용 최적화 접근 방식은 다음과 같은 주요 단계로 구성됩니다:

1. 리소스 활용도 태그 및 추적
2. Amazon RDS 리소스에 대한 사용 정책 정의
3. 운영자 교육 및 정책 실행
4. 정책 및 프로세스 학습 및 최적화

다음 다이어그램은이 워크 플로를 보여줍니다.

다음 섹션에서는 각 단계에 대한 자세한 내용을 제공합니다.

1. 리소스 활용도 태그 및 추적

비용 최적화를 위한 첫 번째 단계는 리소스에 올바르게 태그를 지정하고 사용률 추적을 시작하는 것입니다. AWS는 RDS 인스턴스에 쉽게 태그를 지정할 수있는 기능을 제공합니다. 이렇게 하려면 Amazon RDS 콘솔에서 인스턴스를 찾습니다. 태그 탭에서 RDS 인스턴스의 운영자를 명확하게 식별하는데 필요한 태그를 추가합니다. 태그 지정에 대한 자세한 내용은 Amazon RDS 리소스 태그 지정을 참조하십시오.

애플리케이션 이름 및 조직 그룹과 같이 Amazon RDS 리소스를 식별하는데 도움이 되는 모든 태그를 추가 할 수 있지만 다음 두 태그를 권장합니다:

• 데이터베이스 운영자
• 애플리케이션 운영자

이 정보는 운영자를 신속하게 식별하고 비용 최적화 기회에 대해 경고하는데 도움이 됩니다.

Amazon RDS는 각 활성 데이터베이스 인스턴스에 대해 1 분마다 Amazon CloudWatch에 지표를 자동으로 전송하기 때문에 리소스 사용률을 추적하기 위해 아무것도 할 필요가 없습니다. CloudWatch의 Amazon RDS 지표에 대한 추가 요금은 없습니다. 이러한 지표에 대한 자세한 내용은 Amazon RDS 모니터링 개요를 참조하십시오.

Amazon RDS를 CloudWatch와 통합하면 리소스 사용률을 쉽게 추적 할 수 있습니다. 다음 단계는 비용 최적화 기회를 식별하는데 도움이 되는 정책을 개발하는 것입니다. 다음 섹션에서는 정책에 중점을 둡니다.

2. Amazon RDS 리소스에 대한 사용 정책 정의

이 단계에서 이해 관계자는 활용도가 낮은 RDS 인스턴스를 식별하는 정책을 정의하고 이러한 인스턴스가 식별 될 때 취할 조치를 정의합니다. 이러한 정책은 세 가지 주요 Amazon RDS 측면을 다룹니다:

2.1 읽기 전용 복제본 정책
Amazon RDS 읽기 전용 복제본은 RDS DB 인스턴스에 향상된 확장성과 내구성을 제공합니다. 이러한 읽기 전용 복제본은 읽기 트래픽을 수평으로 확장하는 기능을 제공합니다. 이는 읽기가 많은 데이터베이스 워크로드에 특히 유용합니다.

Amazon RDS에서 Multi-AZ 및 읽기 전용 복제본은 두 가지 유형의 인스턴스입니다. Multi-AZ 배포를 위해 생성 된 대기 인스턴스는 액세스 할 수 없으며 고가용성을 위해서만 사용됩니다. 반면 Amazon Aurora에서 Multi-AZ standby는 액세스 가능한 또 다른 읽기 전용 복제본입니다. 따라서 Aurora 클러스터의 고가용성을 위해 사용되지 않는 경우에도 읽기 전용 복제본이 하나 필요합니다. 다른 모든 Amazon RDS 및 Aurora 읽기 전용 복제본의 경우 CPU 및 I/O 사용률을 평가하여 실제로 필요한지 확인해야 합니다. 읽기 전용 복제본 결정을 내릴 때 다음 기준을 고려하십시오:

• I/O 및 CPU 사용량에 대한 기본 인스턴스 사용률이 지속적으로 30 % 미만인 경우 읽기 전용 복제본을 가동하지 마십시오.
• 읽기 전용 복제본의 CPU 및 I/O 용량이 지속적으로 30 % 미만인 경우 더 작은 인스턴스 크기를 사용할 가능성을 고려합니다. 기본 인스턴스에 용량이 있는 경우 부하를 기본 인스턴스로 전송하고 읽기 전용 복제본을 종료 할 수도 있습니다.

예를 들어 사용률이 30 % 인 db.r4.4xlarge (vCPU 16 개) 유형의 읽기 전용 복제본을 사용하는 경우 db.r4.2xlarge (vCPU 8 개)로 크기를 줄이는 것을 고려해야 합니다. 이제 vCPU 수가 절반이므로 CPU 사용률이 약 60 ~ 70 %로 증가 할 것으로 예상됩니다. 이로 인해 예상치 못한 급증 및 향후 트래픽 증가에 대비하여 약 30 %의 버퍼가 남습니다.

각 인스턴스 유형이 최대 I/O 대역폭을 지원하기 때문에 I/O 처리량도 매우 중요합니다. 축소하면 지원되는 I/O 대역폭도 떨어지므로 현재 요구 사항이 감소된 대역폭으로 충족되는지 확인하는 것이 중요합니다. 예를 들어 db.r4.4xlarge에서 db.r4.2xlarge로 크기를 줄이면 사용 가능한 최대 대역폭이 7000Mbps에서 3500Mbps로 떨어집니다. 자세한 내용은 DB 인스턴스 클래스의 하드웨어 사양을 참조하십시오.

프로덕션 환경의 읽기 전용 복제본의 경우 30 % 임계값이 권장됩니다. 기능 테스트에만 사용되는 비 프로덕션 환경의 경우 사용률 임계값을 50 % 로 더 엄격하게 설정할 수 있습니다. 즉, CPU 사용률이 50 % 미만인 읽기 전용 복제본은 더 작은 인스턴스 유형에 적합한 크기로 조정할 수 있습니다.

2.2 사용하지 않는 인스턴스 정책
사용하지 않는 RDS 인스턴스는 전체 비용은 증가시키나 가치를 추가하지 않습니다. 사용하지 않는 모든 인스턴스는 조직에서 정의한 정책에 따라 확인하고 종료하는 것이 좋습니다. 인스턴스는 때때로 빠른 테스트를 위해 비 프로덕션 환경에서 생성되며 작업이 완료된 후에는 정리되지 않습니다. 이러한 사용되지 않은 인스턴스는 사용되지 않은 상태로 유지되며 불필요하게 비용이 추가됩니다. 사용하지 않는 인스턴스를 식별하려면 다음 기준을 고려하십시오:

• 1 개월 동안 데이터베이스 연결 없음 (요구 사항에 따라 그 이하)
• CPU 사용률 및 I/O가 지속적으로 5 % 미만

사용량이 적은 RDS 인스턴스를 식별 한 후 운영자에게 알려야 합니다. 조치를 취하지 않으면 문제를 에스컬레이션해야합니다. 다음 단계를 고려할 수 있습니다:

1. 데이터베이스 및 애플리케이션 운영자에게 이메일을 보내 인스턴스를 종료합니다.
2. 이메일에 기한을 포함하여 인스턴스를 종료하거나 예외를 받을 수 있습니다.
3. 기한이 만료되면 알림을 보내고 관리자에게 이관합니다.

RDS 인스턴스를 삭제하기 전에 DB 스냅샷을 생성하는 것이 좋습니다. 이렇게하면 RDS 인스턴스를 복원해야하는 경우 마지막 스냅샷을 사용하여 복원 할 수 있습니다.

2.3 기본 RDS 인스턴스 정책

기본 RDS 인스턴스는 애플리케이션에 대한 읽기 및 쓰기 트래픽을 처리합니다. 따라서 애플리케이션 요구 사항을 충족하기 위해 올바른 크기를 조정하는 것이 중요합니다. 동시에 활용도가 낮은 상태로 두는 것도 좋지 않습니다. 활용도가 낮은 기본 인스턴스를 식별하려면 CPU 사용률이 30 % 미만이고 I/O가 30 % 미만인 인스턴스를 지속적으로 찾습니다.

활용도가 낮은 인스턴스를 식별 한 후 다음 단계를 완료하십시오:

1. 데이터베이스 및 애플리케이션 운영자에게 인스턴스 크기 조정을 알립니다.
2. 인스턴스 크기를 적절하게 조정하거나 예외를 받기위한 기한 포함.
3. 기한이 만료되면 알림을 보내고 에스컬레이션합니다.

성능 검증과 관련되지 않고 기능 테스트에 사용되는 비 프로덕션 기본 인스턴스의 경우 적절한 크기 조정을 위한 I/O 및 CPU 사용률 임계값을 30 % 미만에서 50 % 미만으로 늘릴 수 있습니다. 이를 통해 적절한 크기 조정 후보인 더 많은 인스턴스를 식별 할 수 있습니다.

3. 운영자 교육 및 정책 실행

정책을 정의한 후에는 데이터베이스 및 애플리케이션 운영자에게 이러한 비용 최적화 권장 사항에 대해 교육하는 것이 중요합니다. 그들은 이러한 정책의 중요성과 이것이 포트폴리오 비용에 미치는 영향을 인식해야 합니다.

모든 이해 관계자가 참여한 상태에서 조직 전체에 정책 구현을 시작해야 합니다. 소규모 Amazon RDS 데이터베이스 집합의 경우 월 1 회 수동 점검일 수 있습니다. 대규모 조직의 경우 메트릭을 확인하고 운영자에게 경고하는 이메일 알림을 생성하는 자동화된 일일 또는 주간 프로세스가 될 수 있습니다.

4. 정책 및 프로세스 학습 및 최적화

이 프로세스를 구현 한 후에는 계속해서 개선할 영역을 모니터링하고 식별하는 것이 중요합니다. 이를 통해 워크로드와 조직의 요구 사항에 맞게 정책과 프로세스를 지속적으로 발전시킬 수 있습니다. 이 단계에서는 워크로드 변경에 따라 플릿의 인스턴스를 자동 확장하고 적절한 크기를 조정하는 자동화 구현을 고려할 수 있습니다. 인스턴스 유형을 변경하면 다운타임이 발생하므로 워크로드에 영향을 주지 않거나 최소한으로 영향을 미치지 않도록 계획하는 것이 중요합니다.

추가 – Amazon RDS 비용 고려 사항

RDS 인스턴스 사용 정책 외에도 여러 다른 영역에서 비용을 최적화 할 수 있습니다. 이 섹션에서는 애플리케이션 요구 사항에 따라 고려할 수 있는 몇 가지 추가 권장 사항에 대해 설명합니다.

백업
Amazon RDS 백업 수명주기 정책을 검토하고 조직의 규정 준수 및 보존 정책에 따라 수동 및 자동 생성된 데이터베이스 백업 스냅샷을 제거하는 것을 고려하십시오. 자동 백업은 정의한 보존 정책에 따라 삭제되지만 수동 백업은 자동으로 삭제되지 않습니다. 자세한 내용은 백업 작업을 참조하십시오.

스토리지
Aurora에서는 스토리지 유형을 제어하지 않지만 나머지 RDS 인스턴스의 경우 인스턴스와 함께 사용할 Amazon Elastic Block Store (Amazon EBS) 볼륨 유형을 선택해야 합니다. 다양한 고객과 협력하면서 대부분의 개발 및 스테이징 워크로드가 범용 SSD 스토리지에서 잘 수행되는 것을 확인했습니다. I/O 집약적 워크로드의 경우 프로비저닝된 IOPS SSD 스토리지는 확실히 좋은 옵션이지만 다른 워크로드의 경우 범용 SSD가 더 적합할 수 있습니다. 범용 EBS 볼륨 크기가 1TB 미만인 경우 EBS 버스트 모드의 개념을 이해하는 것이 중요합니다. 버스트 모드를 사용하면 I/O 크레딧을 사용할 수 있는 한 최대 3000 IOPS에 도달 할 수 있습니다. I/O 크레딧이 소비되는 즉시 IOPS가 실제 사용 가능한 IOPS 한도로 떨어집니다. 자세한 내용은 Amazon RDS 및 GP2를 사용한 버스트 대 기준 성능 이해를 참조하십시오. 최적의 성능을 보장하려면 정기적으로 IOPS 사용률을 모니터링해야합니다.

메모리
사용 가능한 RDS 인스턴스 메모리는 데이터베이스 성능에 필수적이지만 크기를 줄이는 결정은 메모리 사용률을 기반으로 할 수 없습니다. 이는 인스턴스 메모리의 상당 부분이 내부 데이터베이스 버퍼 (Oracle의 SGA, Auroa PostgreSQL의 공유 버퍼)에 할당되기 때문입니다. 이로 인해 유휴 RDS Oracle 인스턴스의 연결이 없는 경우에도 메모리의 70 % 가 사용되는 것으로 표시 할 수 있습니다. 마찬가지로 Aurora PostgreSQL에서 shared_buffers는 기본적으로 사용 가능한 메모리의 약 75 % 를 사용하도록 구성되므로 유휴 인스턴스에서도 사용된 메모리가 표시됩니다.

데이터베이스 엔진은 사용 가능한 메모리를 사용하여 데이터 블록을 캐시합니다. 이 캐시 된 데이터는 쿼리 속도를 높이는데 도움이 됩니다. 애플리케이션이 쿼리에 대해 지연 시간이 짧은 특정 SLA를 충족해야하는 경우 인스턴스 유형을 다운그레이드하면 영향을 미칠 수 있습니다. 예를 들어 db.r4.4xlarge에서 db.r4.2xlarge로 크기를 줄이면 사용 가능한 메모리가 122GB에서 61GB로 떨어집니다. 이로 인해 데이터베이스 캐시가 작아 지므로 데이터베이스 엔진은 저장소에서 더 많은 페이지를 읽어야 합니다. 저장소에서 가져 오는 것이 캐시에서 가져 오기보다 느리기 때문에 쿼리 시간이 늘어날 수 있습니다.

또한 더 작은 캐시를 사용하면 애플리케이션에 더 많은 IOPS가 필요할 수 있으므로 스토리지 I/O가 증가합니다. 애플리케이션 운영자가 프로덕션 인스턴스의 크기를 줄이기 전에 지연 시간에 민감한 애플리케이션에 미치는 영향을 평가하는 것이 중요합니다. Amazon Aurora에서는 데이터베이스가 소비하는 IO에 대한 비용을 지불하므로 인스턴스 유형을 다운 그레이드하기로 결정하기 전에 IO 비용 영향도 분석해야 합니다.

인스턴스 타입
Amazon RDS는 데이터베이스 워크로드에 필요한 인스턴스 유형을 선택할 수 있는 유연성을 제공합니다. 각 인스턴스 유형은 특정 수의 CPU, 메모리, EBS 대역폭 및 네트워크 성능을 지원합니다. 애플리케이션 운영자는 워크로드 요구 사항에 따라 인스턴스 유형을 선택해야 합니다. 예를 들어 CPU 집약적 워크로드의 경우 M * 제품군 인스턴스가 더 적합하고 메모리 집약적 워크로드의 경우 R * 제품군이 더 좋습니다. 이전 섹션에서 설명한 것처럼 요구 사항을 주의 깊게 살펴본 후에만 ​​인스턴스 유형을 변경해야 합니다.

대부분의 데이터베이스 워크로드는 메모리 집약적이므로 R * 및 X * 제품군 인스턴스에서 최신 제품을 사용하여 평가해야 합니다. 자세한 내용은 Amazon RDS 인스턴스 유형을 참조하십시오.

RDS 인스턴스 정책 요약

다음 표는이 블로그에서 논의 된 샘플 정책의 요약을 제공합니다.

CPU 사용률 및 I/O 처리량 지표는 CloudWatch에서 사용할 수 있습니다. CPU 사용률 메트릭 (CPUUtilization)은 모니터링하는 기간 동안의 최대 CPU 사용률이어야 합니다. I/O 처리량은 허용되는 최대 인스턴스 I/O 처리량과 비교하여 읽기 처리량 (ReadThroughput)과 쓰기 처리량 (WriteThroughput)의 합계입니다. 허용되는 최대 처리량에 대한 자세한 내용은 DB 인스턴스 클래스의 하드웨어 사양을 참조하십시오.

이 글에서 제공하는 권장 사항의 목표는 RDS 인스턴스 비용을 최적화하는데 도움이 되는 것입니다. 모든 애플리케이션은 고유한 아키텍처와 서로 다른 사용 패턴 및 SLA가 있다는 점을 기억하는 것이 중요합니다. 따라서 프로덕션 환경에 배포하기 전에 항상 변경 사항을 확인하고 검토하는 것이 중요합니다.

비 프로덕션 데이터베이스 인스턴스의 경우 자동화를 적용하여 종료하거나 적절한 크기를 조정할 수 있습니다. 그러나 프로덕션 인스턴스의 경우 인스턴스 크기를 조정하거나 중지하기 전에 애플리케이션 운영자와 협력하여 사용 패턴을 이해하는 것이 좋습니다.

– Samujjwal Roy, AWS Principal Consultant
– Yaser Raja, AWS Senior Consultant
– Li Liu, AWS Database Cloud Architect

이 글은 AWS Database 블로그의 Optimizing costs in Amazon RDS 한국어 번역본으로 장동훈 AWS DB  솔루션 아키텍트가 번역 및 검수하였습니다.