AWS Serverless v2
Aurora Serverless v2는 여러 유형의 데이터베이스 워크로드를 지원합니다. 아마 가장 잘 알려진 장점은 사용할 때만 비용을 지불하고, 사용하지 않을 때는 비용을 청구되지 않는다는 점입니다. 이런 특성을 이용하여 원하는 만큼 사용하고, 사용하지 않을 때는 사용량을 제어하여 비용을 최소화할 수 있을 것입니다. 즉, 가변 워크로드로써 활용했을 때 비용을 절약할 수 있게 됩니다.
이번 포스트에서는 가변 워크로드를 활용하여 비용을 절약할 수 있다는 장점에 대해 나열해보고자 합니다.
가변 워크로드란?
ACU는 Aurora 사용 용량 단위를 의미합니다. 만약 db.r6g.xlarge DB(vCPU 4, 32GiB)와 같은 성능을 위해서는 max ACU를 16으로 설정합니다. 따라서 0.5ACU당 1GiB 수준으로 성능을 비교해볼 수 있습니다.
최소, 최대 워크로드를 설정하여 필요한 만큼 사용할 수 있도록 변경할 수 있습니다. 예를 들어 사용량이 적을 때는 ACU(Aurora 용량 단위, 0.5 단위)를 최소화 하여 사용 용량 단위 비용을 최소화 할 수 있습니다. 예를 들어 사용하지 않을 때는 0.5(가장 작은 단위)를 유지하고, 사용량이 많을 때는 최대 ACU만큼 이용하게 됩니다.
{"min" : 0.5, "max" : 4.0}로 설정하여 워크로드 사용량이 적을 때는 최소 0.5만큼 사용하고, 사용량이 많을 때는 4.0만큼 사용됨
현재는 최소 ACU 단위가 0.5로 돼 있어 최소값은 0.5로 유지됩니다. 서버 비용 책정 정책은 아래 이미지와 같습니다. 아래의 비용을 바탕으로 계산을 해보았을 때, 일반적인 Amazon Aurora와 비교해보도록 하겠습니다.
서버 비용 비교(Serverless)
데이터베이스 사용량에 따른 비용 계산을 비교해보면 다음과 같습니다. 설명을 위해 조건을 나열하여 구체적으로 설명해보도록 하겠습니다.
•
vCPU 4, Memory : 32GiB 중 최소 비용 db.r6g.xlarge(0.627USD/hour)와 비교함
•
Aurora Serverless v2 성능도 위와 동일한 성능을 위해 {"min" : 0.5, "max" : 16.0} 으로 설정함
•
DB 사용량이 특정 시간에만 사용량이 높아지는 서버라고 가정함
Time | ACU | Aurora MySQL(db.r6g.xlarge) | Aurora Serverless v2 |
0:00 | 0.5 | 0.627$ | 0.1$ |
1:00 | 0.5 | 0.627$ | 0.1$ |
2:00 | 0.5 | 0.627$ | 0.1$ |
3:00 | 0.5 | 0.627$ | 0.1$ |
4:00 | 0.5 | 0.627$ | 0.1$ |
5:00 | 0.5 | 0.627$ | 0.1$ |
6:00 | 0.5 | 0.627$ | 0.1$ |
7:00 | 0.5 | 0.627$ | 0.1$ |
8:00 | 1 | 0.627$ | 0.2$ |
9:00 | 2 | 0.627$ | 0.4$ |
10:00 | 4 | 0.627$ | 0.8$ |
11:00 | 4 | 0.627$ | 0.8$ |
12:00 | 8 | 0.627$ | 1.6$ |
13:00 | 16 | 0.627$ | 3.2$ |
14:00 | 4 | 0.627$ | 0.8$ |
15:00 | 1 | 0.627$ | 0.2$ |
16:00 | 0.5 | 0.627$ | 0.1$ |
17:00 | 0.5 | 0.627$ | 0.1$ |
18:00 | 2 | 0.627$ | 0.4$ |
19:00 | 4 | 0.627$ | 0.8$ |
20:00 | 1 | 0.627$ | 0.2$ |
21:00 | 1 | 0.627$ | 0.2$ |
22:00 | 0.5 | 0.627$ | 0.1$ |
23:00 | 0.5 | 0.627$ | 0.1$ |
합계 | 15.048$ | 10.8$ |
위와 같이 가정하게 되면 Aurora MySQL은 성능을 유지하여 사용하지만, 비용은 고정적으로 시간당 0.627$를 지불하게 됩니다. 사용량이 없는 시점에 해당 서버를 유지했을 때, 월 451$/month 정도 지출이 발생합니다.
Aurora Serverless v2 를 사용하게 되면, 필요한 시간에 필요한 만큼 서버를 사용하게 되어 비용을 절감할 수 있습니다. 위와 같은 패턴이 1개월간 지속됐다고 가정하게 되면 324$/month 정도 지출이 발생합니다. 단순 계산식으로 비교했을 때 월 127$의 비용을 절감하는 효과가 있습니다.
서버 비용 비교(Aurora MySQL)
만약 서버의 사용량이 많다고 가정하였을 때, 비용을 비교해보도록 하겠습니다. 성능은 위의 조건과 동일하게 하나, 사용량 가정을 변경해보도록 하겠습니다.
•
서버 이용량이 지속적으로 높으며, 아침, 점심, 저녁 시간에 사용량이 높아지는 특징이 있음
Time | ACU | Aurora MySQL(db.r6g.xlarge) | Aurora Serverless v2 |
0:00 | 2 | 0.627$ | 0.4$ |
1:00 | 2 | 0.627$ | 0.4$ |
2:00 | 2 | 0.627$ | 0.4$ |
3:00 | 1 | 0.627$ | 0.2$ |
4:00 | 1 | 0.627$ | 0.2$ |
5:00 | 1 | 0.627$ | 0.2$ |
6:00 | 1 | 0.627$ | 0.2$ |
7:00 | 2 | 0.627$ | 0.4$ |
8:00 | 2 | 0.627$ | 0.4$ |
9:00 | 4 | 0.627$ | 0.8$ |
10:00 | 8 | 0.627$ | 1.6$ |
11:00 | 8 | 0.627$ | 1.6$ |
12:00 | 16 | 0.627$ | 3.2$ |
13:00 | 16 | 0.627$ | 3.2$ |
14:00 | 16 | 0.627$ | 3.2$ |
15:00 | 8 | 0.627$ | 1.6$ |
16:00 | 4 | 0.627$ | 0.8$ |
17:00 | 8 | 0.627$ | 1.6$ |
18:00 | 16 | 0.627$ | 3.2$ |
19:00 | 16 | 0.627$ | 3.2$ |
20:00 | 8 | 0.627$ | 1.6$ |
21:00 | 4 | 0.627$ | 0.8$ |
22:00 | 2 | 0.627$ | 0.4$ |
23:00 | 2 | 0.627$ | 0.4$ |
합계 | 15.048$ | 30$ |
단순히 비교했을 때 위와 같이 Serverless 비용이 훨씬 가중되는 것을 확인할 수 있습니다. 만약 서버의 사용량이 위와 같은 패턴을 보일 경우 비용을 오히려 Aurora MySQL 이 유리하게 됩니다.
Conclusion
서버의 사용량과 비용을 계산하는 것은 예측과 누적된 데이터, 두 가지를 활용할 수 있습니다. 서비스 초기에는 예측된 데이터를 통해 유저가 얼마나 접속하고 DB 사용이 발생할지 예상하여 서버 스펙을 결정하게 됩니다. 그리고 서비스 과정에서 누적된 데이터(서비스 이용률, 서버 사용량 등)를 통해 서버의 스펙을 변경할 수 있을 것입니다. 이번 포스트에서는 Serverless를 사용하면 유리한 경우와 Aurora를 사용할 경우의 유리한 경우를 살펴보았습니다.
이 포스트를 쓰게 된 계기는 조금 웃기지만, Serverless 스펙을 잘못 설정했던 경험 때문이었습니다. 최소 ACU와 최대 ACU를 설정할 때 ‘최소는 2, 최대는 4정도로 하면 충분하겠지?’ 라고 생각했으며, ACU == CPU라고 착각하고 있었습니다. 이 내용은 WS 공식 문서를 읽어보고 착각이었음을 알 수 있었습니다. 또한 ACU는 0.5당 1GiB로 매핑시킬 수 있다고 나와있습니다. 그리고 결정적으로 최소 사양 설정 부분이 다음과 같이 나타나 있었습니다. 이번 포스트와 경험을 계기로 공식 문서의 중요성을 다시 한 번 깨닫게 되었습니다.
References
