개요
AWS에는 수많은 데이터베이스가 존재하며 RDB로는 RDS와 RDS for Arurora가 존재합니다. 공식 문서와 성공 사례를 보면 RDS for Aurora가 많은 장점을 가지고 있는 것은 분명합니다.
하지만 현실적인 이유들로 RDS를 사용하고 있다면 어떻게 비용을 절감할 수 있을까요?
어떻게 해야 가용성, 확장성을 유지한 상태로 RDS Instance를 다양한 운영환경에서 최적화할 수 있을까요?
본 문서는 RDS Instance를 수십개 쓰고 있으며 매달 수천만원의 비용이 나오는 기업에서 “최소 인풋으로 최대 절감”을 하기 위한 가이드라인을 제시합니다.
신규 생성시
RDS Instance 비용 최적화를 달성하기 위해서 다음의 6-Step을 따라가겠습니다.
이 과정을 통해서 요구사항을 정의하고 RDS 비용 정책 및 아키텍처에 대한 이해도를 기르고자 합니다. 최종적으로는 각 운영환경의 특성에 맞게 RDS 옵션을 수정하여 비용 최적화를 할 수 있는 길을 제시합니다.
요구사항 정의
RDS 생성 시점의 비용 분석하기
RDS 생성 시점의 Multi-AZ와 가용성 이해하기
RDS 생성 시점의 Storage Type과 프로비저닝 IOPS 이애하기
운영 환경 별로 탬플릿 선택하기
요구사항 정의
회사와 서비스의 경쟁력을 위해 비용 절감은 단연코 필요한 일입니다.
하지만 그를 위해서 서비스 장애를 유발시키면 안되기에 트레이드 오프를 하겠습니다.
[운영 환경 예시]
prod/live : 실제 서비스를 공급하고 있는 운영 환경
dev/stg/qa/rc : 서비스를 개발 및 테스트하기 위한 운영 환경
위와 같은 [운영 환경 예시]에 따라서 아래와 같은 요구사항 정의를 하겠습니다.
prod/live 에서는 최적화로 인한 장애가 발생하면 안되며, 일부 비용은 포기한다.
dev/stg/qa/rc 등에서는 비용 절감을 최우선으로 하며, 최적화로 인한 일부 장애를 감수한다.
RDS 생성 시점의 비용 분석하기
RDS 생성 시점에 탬플릿 3개를 제공해줍니다.
저희는 PoC*를 위한 RDS가 필요한 것이 아니므로 프로덕션 및 개발/테스트 환경의 비용을 비교해보겠습니다.
PoC*(Proof of Conecpt, 개념 증명)
두 탬플릿 모두 기본적으로 RDS Instance Type으로 db.m6gd.large를 사용합니다.
하지만 무려 5.6배에 달하는 비용 차이가 발생합니다.
개발/테스트 $216.73 (₩1,685,062.8, 기준환율 1380)
프로덕션 $1221.06 (₩1,685,062.8, 기준환율 1380)
위 그림을 보고 생긴 2가지 질문에 대한 차이점을 해답으로 제시합니다.
질문 :
DB 인스턴스와 같은 컴퓨팅 비용이 왜 차이가 날까?답변 : 프로덕션에서는 Multi-AZ 활성화가 되어 있어 대기 인스턴스가 생성됩니다.
스토리지와프로비저닝된 IOPS와 같은 스토리지 비용이 왜 차이가 날까?답변 : 개발/테스트와 프로덕션의 스토리지는 각각 gp3, io2 타입이라 비용이 다릅니다.
그렇다면 왜 프로덕션에서는 Multi-AZ를 활성화하도록 가이드하는 것일까요?
RDS 생성 시점의 Multi-AZ와 가용성 이해하기
결론부터 말하면 Multi-AZ가 활성화되어 있으면 인스턴스 타입 변경 시에도 장애가 발생하지 않습니다. 인스턴스 타입 변경으로 인한 수직적 확장 및 축소 동안 가용성이 보장된다는 소리입니다.
db.m6gd.large → db.mg.6gd.xlarge 로 타입을 변경하는 경우에도 DB Connection이 끊기지 않습니다.
따라서 prod/live에서는 Multi-AZ를 활성화하고 그 외에서는 Multi-AZ를 활성화하지 않는 것으로 DB 인스턴스 항목에서 50%의 비용 절감을 달성할 수 있습니다.
[ RDS DeepDive 설명 포함 필요 ]
RDS 생성 시점의 Storage Type과 프로비저닝 IOPS 이애하기
결론부터 EBS 400 GiB / 3000 IOPS / No Snapshot 기준으로만 봐도 gp3보다 io2가 훨씬 비쌉니다. 더하여 RDS EBS의 경우 순순한 EBS와 비용 정책이 다르기 때문에 훨씬 비싼 요금을 지불해야 합니다.
따라서 prod/live에서는 io2를 사용하고 그 외에는 gp3를 사용하는 것이 비용 합리적입니다.
다음은 2024-08-07 / gp3, io2 비용 차이 계산 에 따라서 계산한 EBS gp3 vs io2 비용 차이를 통해서 나온 금액과 실제 RDS EBS 비용 차이에 대한 비교입니다.
다만 EBS Volume Price와 RDS Volume Price에는 다소간의 비용 차이가 존재합니다.
[gp3 200/400 GiB 기준 비용 차이 : EBS vs RDS EBS]
예를 들어 200 GiB 3000 IOPS 125 Throughtput은 다음과 같이 차이가 발생합니다.
EBS : $18.24
RDS EBS : $26.20
더하여 RSD 400 GiB 초과 구간에서 gp3 최소 IOPS가 3000에서 12000, 최소 Throughput이 125에서 500으로 증가하기 때문에 비용도 비례하여 증가합니다.
EBS : $36.48
RDS EBS : $52.40
재밌는 부분은 초과분인 9000 IOPS에 대한 비용은 스토리지 항목에 추가된다는 점입니다.
이는 RDS 스토리지 비용의 가격 정책이 EBS와 독립적으로 존재하기 때문입니다.
[io2 400 GiB 비용 비용 차이 : EBS vs RDS EBS]
추가 예시로 io2 400GiB 3000IOPS의 경우 스토리지 $51.12, IOPS $199.80으로 총계 $250.92가 지불됩니다. 하지만 RDS EBS에서는 무려 $840가 청구됩니다.
EBS : $250.92 ( = $51.12 * 1 + $199.80)
RDS EBS : $840.00 ( = $120.00 * 1 + $720.00)
역시나 RDS 스토리지 비용의 가격 정책이 달라서 발생하는 문제입니다.
단, 유의할점은 $250.92 중 $51.12가 스토리지 자체 비용이며,
[ EBS Volume Type Deep Dive 설명 포함 필요 ]
운영 환경 별로 탬플릿 선택하기
사전 정의 한 요구사항과 RDS 탬플릿 딥다이브를 기준으로 아래와 같은 결론을 내렸습니다.
prod/live 망 : 프로덕션 탬플릿으로 데이터베이스 생성
dev/stg/qa/rc 망 : 개발/테스트 탬플릿으로 데이터베이스 생성
기존 데이터베이스
지속적인 최적화
마이그레이션 요구사항
Single-AZ to Multi-AZ 마이그레이션
Multi-AZ to Single-AZ 마이그레이션
gp3 to io2 마이그레이션
io2 to gp3 마이그레이션
지속적인 최적화
데이터 베이스 생성 시점에 올바른 탬플릿을 골라서 생성하셨나요?
그렇다면 RDS CPU Utilization Metrics와 Connection을 보면서 RDS Instance Type을 변경하면서 최적화를 진행하면 됩니다.
인스턴스 타입 별 특징 및 최적화는 본 문서의 범위를 벗어나므로 포함하지 않았습니다.
추가적으로 IOPS, Throughput 등이 설정 가능할 경우 해당 Metric을 포함하여 최적화가 필요할 것입니다.
역시나 IOPS, Throughput 최적화는 본 문서의 범위를 벗어나므로 포함하지 않았습니다.
하지만 데이터베이스 생성 시점에 부적합한 탬플릿을 선택하였다면 마이그레이션이 필요합니다.
마이그레이션 시 가용성 보존
Multi-AZ 설정 및 EBS Volume Type이 잘못 설정하면 마이그레이션이 필요합니다.
이 경우, 마이그레이션 간 장애가 발생하여 가용성이 보장되지 않는지 확인해야 합니다.
Single-AZ to Multi-AZ 마이그레이션 : 가용성 보존
Multi-AZ to Single-AZ 마이그레이션 : 검토 필요
Single-AZ, gp3 ← (변경) → io2 마이그레이션 : 검토 필요
Multi-AZ, gp3 ←(변경)→ io2 마이그레이션 : 가용성 보존
단, 마이그레이션 순간에 데이터 정합성 보존 여부는 별도로 확인해야 합니다.
