[RDS] (적은 트래픽에서) t3.micro ~ t3.xlarge 성능 직접 업그레이드하며 비교해보기

우리는 트래픽이 몰릴 때, DB의 처리 능력 발휘를 위해 CPU를 올리고 데이터를 많이 관리하기 위해 Memory를 올린다.

실제로 트래픽이 많을 때 스펙업을 하면 CPU Utilization, Memory 점유율이 안정되는 것을 종종 확인할 수 있다.

그러다 문득 이런 생각이 들었다.

 

트래픽이 적을 때, 오래 걸리는 메서드를 수행하면 RDS 스펙마다 어느 정도 성능이 차이가 날까?

 

트래픽이 많다면 동시에 들어오는 요청이 많을테니 vCPU, Memory가 높은 것이 확실히 유리하긴 할 것이다.

 

그런데 트래픽이 적을 때 + 단순 반복이 많아서 좀 오래 걸리는 로직에도 유의미하게 차이가 있을까?

 

공식 문서(https://aws.amazon.com/ko/rds/instance-types/)에는 아래와 같이 안내돼있긴 하다.

모델	코어	vCPU	Memory	비고
t3.micro	1	2	1	프리티어
t3.small	1	2	2
t3.medium	1	2	4
t3.large	1	2	8
t3.xlarge	2	4	16	xlarge부터 cpu 증가
t3.2xlarge	4	8	32

 

하지만 체감 상 어느 정도로 차이가 날지 알아차리기란 쉽지 않다.

그래서 직접 한번 실험해보기로 했다.

---

실험 방법

환경

• EC2: t2.xlarge
• RDS: t3.micro ~ t3.xlarge

RDS t3.micro 부터 시작하여, t3.xlarge 까지 수정 작업을 거친다.

scale-up 작업을 진행한다고 하여 DB 데이터 값이 사라지진 않으므로 실험 전 truncate를 진행해준다.

환경 세팅이 완료되면 Swagger 상에서 아래 두 메서드를 수행한다.

 

1. 특정 엔티티 100,000개 save 메서드 (JPA)

  - @GeneratedValue 전략은 IDENTITY로 bulk insert를 진행할 수 없다. 

 

2. 300,000개 엔티티 findAll

  - 페이지네이션이 아닌 300,000개 전체 조회이다.

 

두 메서드를 각각 3번 수행하여, 응답시간 평균값을 기록한다.

 

(사실 Swagger 상에서 수행되는 것이므로 EC2 영향도 어느 정도 받을 것이라 생각한다.

그렇기 때문에 EC2 성능은 매 실험마다 고정한다. 절대적 수치보단 상대적 수치로 비교하면 좋을 듯하다.)

---

결과

save 메서드

모델	1회	2회	3회	평균	CPU Utilization	Write Throughput (bytes/seconds)
t3.micro	76,594 ms	75,020 ms	75,060 ms	75,558 ms	19.591 %	6,575,298
t3.small	72,717 ms	74,783 ms	71,699 ms	73,066 ms	20.983 %	6,419,558
t3.medium	70,486 ms	71,011 ms	72,196 ms	71,231 ms	18.826 %	6,624,107
t3.large	65,384 ms	63,580 ms	71,823 ms	66,929 ms	20.958 %	6,132,592
t3.xlarge	72,546 ms	70,604 ms	66,562 ms	69,904 ms	10.937 %	5,682,816

• CPU Utilization, Write Throughput은 aws console의 RDS Cloudwatch 에서 확인
• 별도의 메모리 설정은 진행하지 않음.

 

findAll 메서드

모델	1회	2회	3회	평균
t3.micro	3,914 ms	3,159 ms	3,202 ms	3,425 ms
t3.small	2,926 ms	2,757 ms	2,805 ms	2,829 ms
t3.medium	2,751 ms	2,906 ms	3,268 ms	2,975 ms
t3.large	2,770 ms	2,928 ms	3,055 ms	2,918 ms
t3.xlarge	2,611 ms	2,947 ms	3,096 ms	2,885 ms

---

어느정도 예상은 했지만, 생각보다 더 변화가 없다.

트래픽이 많아서 CPU가 감당 못할 정도가 아닌, 단순히 save 메서드를 여러 번 하는 것이므로 spec에 따른 유의미한 차이는 보이지 않았다.

 

그나마 xlarge 부터 cpu가 2배로 좋아져서 CPU Utilization 이 1/2 로 더 좋아지긴 했다.

그 외에는 단순한 오차 정도만 존재하는 듯하다.

 

cloudwatch 모니터링

각각 CPU Utilization, Freeable Memory 그래프이다.

맨 처음 t3.micro ~ 맨 마지막 t3.xlarge RDS일 때의 상황이다. 

Freeable Memory는 스펙업할 때마다 2배씩 늘어나니 당연히 위 그래프처럼 나올 것이다.

CPU Utilization 역시 성능이 두배 좋아진 xlarge를 제외하곤 별 차이가 없다.

 

EC2 CPU Utilization

EC2 부하조차 걸리지 않는 아주 적은 트래픽이다.

쿼리 자체가 단순함에도 불구하고 반복이 많으면 시간복잡도에 따라 로직이 오래 걸릴 수 있는 셈.

 

따라서 트래픽이 몰리는지 여부가 가장 중요할 것 같다. 

트래픽이 적은 상황에서 단순한 쿼리가 여러 번 발생하여 오래 걸리는 문제점이 있다면 scale-up으론 해결하기 어려울수도?

 

 

아무튼 이번 실험은 별 의미없는 뻘짓같지만...

그래도 일단 재밌었으니 포스팅을 올려본다 ㅎㅎ