DevOps

Aurora Serverless 알아보기

2025년 1월 6일

안녕하세요, SRE팀에 DBA로 새로 합류한 브라우니입니다.

AWS Service에 여러 서비스가 있지만 그 중에서도 여러 서비스에 활용할 수 있는 주제를 다뤄보고자 합니다. 그래서 선택한 주제는 AWS에서 제공하는 Aurora Serverless v2입니다. Aurora Serverless v2는 Aurora MySQL 호환 버전 및 PostgreSQL 호환 버전에 사용할 수 있습니다. 본 포스팅에서는 명칭의 혼선을 없애기 위해 Aurora Serverless(Aurora Serverless Mysql v2)와 Aurora MySQL(기존 Aurora MySQL)로 지칭하겠습니다. Aurora Serverless 에 대한 간략한 소개와 더불어 Aurora MySQL과 대조를 해 보고, 그 중 주목할만한 점에 대해 성능 위주로 공유하고자 합니다.

참조 : Aurora Serverless v2 사용하기 — Amazon Aurora

Amazon Aurora

Aurora Serverless의 개요 및 주요 특징

Aurora Serverless란?

Aurora Serverless는 Aurora MySQL에 대한 온디맨드 방식의 자동 크기 구성을 할 수 있게 해주는 AWS 서비스입니다. 기존에는 Aurora MySQL을 관리하려면 새로운 부하 상황을 미리 예상하여 증설해야만 했었습니다. 하지만, Aurora Serverless 는 애플리케이션 요구 사항에 따라 데이터베이스가 자동으로 확장/축소됩니다. 또한, 사용하지 않는 리소스에 대해서는 요금을 지불하지 않고 Aurora의 고가용성, 확장성을 그대로 활용할 수 있으며, 빠른 속도로 이용할 수 있습니다. 즉, 트래픽을 예측할 수 없을 때 적절한 구성으로 볼 수 있습니다

Aurora Serverless는 v1, v2로 버전이 나뉘어져 있습니다. 그리고 Aurora MySQL은 v1,v2,v3가 있는데, 현재는 Aurora MySQL v3에서 Aurora Serverless v1 사용은 불가합니다.

참조 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.html#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.amy

Aurora Serverless에선 ACU(Aurora Capacity Unit)라는 단위를 이용하여 Resource를 정하게 됩니다. 0.5 ~ 128 ACU까지 범위를 정할 수 있으며 최소단위 ACU로 초당 과금됩니다. 1 ACU= 대략 적으로 2GB Memory + CPU + Network 의 조합으로 이루어집니다. ACU는 ServerlessDatabaseCapacity와 ACUUtilization, 두 가지 지표를 통해 손쉽게 확인할 수 있습니다.

참조 : Aurora Serverless v2의 성능 및 크기 조정 — Amazon Aurora

Scale Up / Down에 따라 자동 조정되는 파라미터는 다음과 같습니다.(수동 조정 불가)

innodb_buffer_pool_size
innodb_purge_threads
table_definition_cache
table_open_cache
참조 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.parameters-based-on-scaling

그리고, 조정 가능한 파라미터는 다음과 같습니다.

max_connections

max_connections도 최대 ACU 기준 자동 조정이 되나 파라미터 그룹에서 수정할 수 있습니다. 자동 조정 connection 수는 다음과 같습니다.

하지만 max_connections을 수정하는 경우 Static 파라미터 이므로 그룹이 펜딩(Pending) 상태가 되어 DB 재기동이 필요합니다.

다음으로 Aurora Serverless v1 , v2 의 특징을 알아보겠습니다.

Aurora Serverless v1 특징

Mysql v5.6.10a만 지원(버전이 낮으므로 엔진적 이점이 적음) -> ex) max_connections 값 조정이 불가합니다.
다중 AZ , 읽기 복제본 지원 X(즉, Failover 불가)
장기 실행 쿼리 또는 진행중인 Tx, 임시 테이블 또는 테이블 잠금이 존재하는 경우 Auto Scaling 지연 발생( 서비스 이슈 발생 가능성)할 수 있으며, Auto Scaling 이후 용량 감소시 Buffer Pool 축소로 인한 서비스 이슈 우려
Max Connection 이 줄어든 상태에서 한꺼번에 여러 세션이 붙을 경우 Too many connection error 발생 (즉, 한번에 많은 세션으로 인한 쓰레드 생성시 이슈 발생 가능성 있음)

Aurora Serverless v2 특징

Aurora v3.02.0 (Compatible with Mysql v8.0.23) 이상만 가능
다중 AZ 지원
RI 지원 불가
Pricing이 Provisioned보다 비싸기 때문에 트래픽이 일정 이상 유지된다면 비용 절감 불가

테스트 케이스 1)

Aurora Serverless 성능 및 Spec Up & Down 성능 확인 Test

테스트 주제: Aurora Serverless의 Spec Up & Down 속도 측정 테스트
테스트 시나리오: Sysbench를 이용하여 약 1GB 테이블 10개를 생성 후 1분 동안 Select 시도하였습니다.

실시간 Innodb_buffer_pool 변화를 확인하기 위하여 Table의 버퍼 사이즈를 실시간으로 수집하여 Scale up ~ Scale Down 시간을 파악하였습니다. Innodb_buffer_pool Size가 변화되는 시점을 중점적으로 확인하여 소요되는 시간을 확인하였습니다. 특정 시점의 정확한 값을 확인하시려면 하기 이미지 중 DB 내 Innodb Buffer Pool 사이즈 확인하시면 되겠습니다.

[Spec Up & Down 비교]

[DB 내 Innodb Buffer Pool Size 실시간 변경 Log]

결과적으로 ,

Query 수행 대략 10초 후 Spec Up이 진행되었으며 이후 2초에서 15초 내 계속해서 Spec Up이 된 것을 확인 하였습니다.
Query 종료 대략 5분 후 Spec Down이 진행되었으며 이후 15분 간격으로 Spec Down이 된 것을 확인 하였습니다.

테스트 케이스 2)

테스트 주제 : Aurora MySQL vs Aurora Serverless의 메모리 Spec을 동일하게 구성 했을 때 양쪽 서버의 성능 테스트
테스트 시나리오:Aurora Serverless 에서 말하는 ACU라는 단위의 정확한 Computing Power를 알 수가 없기 때문에 카탈로그 상 동일한 지표인 Memory를 같게 맞추고 Sysbench를 사용하여 부하를 주었을 때 양쪽 서버의 성능 지표를 비교
#참고 : TPS와 QPS는 Sysbench를 통해 측정된 값으로, 실제 워크로드와는 차이가 있으므로 단순 참고만 함.

결과적으로,

Spec을 동일하게 맞췄을 경우 미세한 차이가 있으나 거의 동일한 Resource가 사용되었습니다.

Serverless 비용 알아보기

Aurora MySQL vs Aurora Serverless 비용 비교

Aurora Serverless 같은 경우 초단위로 과금 되나 도큐먼트상에는 시간단위로 계산이 되어있어 가시성을 위해 시간단위로 비교하였습니다. 새로 출시된 I/O Optimized 같은 경우 시간당 비용이 다르니 참조 부탁드립니다. 비용 참조 : (MySQL PostgreSQL 관계형 데이터베이스 — Amazon Aurora Pricing — AWS )

1. 동일 기준 Spec 비교

해당 케이스에서는 , 동일한 스펙으로 한 달을 사용하였을 때 비용이 얼마나 발생하는지 비교하였습니다.

2. 사용 시간별 비교

해당 케이스에서는 Aurora MySQL이 r6.large 인스턴스를 유지하는 동안, Aurora Serverless가 하루에 1시간 동안 2 ACU를 사용하고, 이후 매일 2 ACU를 사용하는 시간이 1시간씩 증가한다고 가정해보겠습니다 . 이 조건으로 Aurora Serverless가 기존 Aurora MySQL보다 비용을 초과하는 시점을 그래프로 확인하였습니다.

이 글에서는 간략하게 테스트 한 내용을 소개 드렸지만, 결론은

첫 번째 , 동일 스펙(동일 기준 Spec)으로 24시간 가정할 경우, 비용은 약 4.25배 차이가 납니다.

두 번째 , Aurora Serverless가 2 ACU 성능으로 일정 시간 이상 유지될 경우, 기존 Aurora MySQL보다 더 높은 비용을 초과하게 되며, 이로 인해 장기적으로 비용 효율성이 떨어지게 됩니다. 따라서 Aurora Serverless는 짧은 시간 동안의 유동적인 트래픽을 처리하는 데는 유리하지만, 일정 시간 이상 고정적인 성능을 요구하는 경우 기존 Aurora MySQL이 더 효율적입니다.

따라서, Aurora Serverless를 사용하실 때 비용적 관점으로 본다면 일시적인 트래픽이 얼마나 들어오는지 추이 확인이 필요하다고 생각됩니다.

또한, 위에서도 언급드렸던 Aurora Serverless는 RI가 적용되지 않기 때문에 이 부분도 주의해 주셔야합니다.

Aurora Serverless에서 Aurora MySQL로 복구 및 원복 절차

Aurora Serverless 구성 후 서버로 변경 시 원복 방법

Serverless는 Writer , Reader 둘 다 적용이 가능하며 문제가 될 시 즉시 원복이 가능합니다.

Rollback)

DMS(Database Migration Service, AWS에서 제공하는 복원력을 갖춘 데이터 이관 서비스) & Dump를 이용한 마이그레이션 시간이 다소 소요되며 , 예외 케이스(새 클러스터를 생성하여 복원)를 제외하고는 실용적인 방안이라고 볼 수 없음.
Failover를 사용한 변경 Master ) Aurora Mysql Serverless — Slave ) Aurora Mysql Server Master ) Aurora Mysql Server — Slave ) Aurora Mysql Serverless Failover를 통하여 Writer 전환 후 리더 인스턴스 부분 제거시 변경 완료 되며 5초 내외 순단이 발생합니다.

Scale up , Down시 Serverless 내부 IP는 변경되지 않습니다.

마치며,

이렇게 하여 , 성능 테스트가 완료되었으며 간략하게 나마 Serverless에 대한 궁금증에 대해 알아보는 시간을 가졌습니다. 하지만, Performance Test만 진행했을 시에는 각 회사에 맞는 요구사항이 다르기 때문에 이 글만 참조해서는 실제 서비스에 적용하긴 어려운 점이 있습니다. 따라서, 서비스에 적용하기 위해서는 좀 더 적합한 POC를 진행해야 한다고 생각됩니다.

이 글이 Aurora Serverless를 도입하시기 전 조그마한 도움이 되었으면 하는 바램입니다.

감사합니다.