AWS RDS Aurora Serverless

in Development on DevOps


AWS Aurora Serverless

Many services use DBMS using AWS RDS Instance or Aurora Cluster. Aurora Serverless was officially released in 2018. It’s been about five years, but many services haven’t used it yet. There are three main reasons for this.

  1. Connection is disconnected when Scale Up occurs.
  2. Due to the nature of AWS Serverless products, the usage price is more expensive than existing services.
  3. I’m not sure if the usage and function will be 100% the same as the existing RDS.

For the same reason, I didn’t think about Aurora Serverless until now, but there was an opportunity to consider introducing it.

  1. Aurora Serverless v2 has been resolved for connectivity disconnection issues.
  2. You can eliminate the trouble of writing logic while paying attention to Replica Lag.
  3. It can reduce the burden of server management.

Although there are these advantages, if the cost is too high, it will not be easy to introduce.

### Aurora Serverless Pricing

Aurora Serverless charges in ACU units, and the corresponding resource in RDS is 2Gb memory. Since the instance used in RDS has an average of 1vCPU : 8Gb ratio, 1 ACU can be considered 0.25 vCPU. ACU is about 6 times more expensive per unit hour than vCPU. Therefore, **ACU is about 1.6 times more expensive when calculating the vCPU metric of RDS currently in service as the maximum value every hour on weekdays. For reference, for stability, the service is currently operating with a peak of less than 40% of the RDS CPU as of the day when there is no special event. Furthermore, Aurora Serverless does not yet have discount policies such as Reserved Instance or Savings Plan.

For more information, visit the official website.

https://aws.amazon.com/rds/aurora/pricing

### Aurora Serverless Q&A

Therefore, before reviewing the introduction of this, I had a technical meeting with Special SA about Aurora Serverless through AWS partners, and I would like to briefly summarize the information obtained at that time. It’s a lot to write everything down, so I’ll mainly classify it as something that engineers would be interested in.

  1. Is Multi-Master supported?

Aurora Serverless is a concept that replaces one instance in the Aurora Cluster. Therefore, Aurora Cluster does not support Multi-Master, so Aurora Serverless makes no difference.

In other words, Writers and Readers can be configured separately in Aurora Serverless, and Multi-AZ or Multi-Region must be configured separately for high availability.

  1. Is there no Replica Lag?

It is less than the existing Aurora Cluster Instance, but it exists. It is not a method of using binlog, so it is much less than before. However, it is not absent, so when using functions such as GraphQL Subscription, you should read them in the Writer.

In my case, I don’t want to use Reader separately, but only Writers are used for the service, so that developers don’t care about Replica Lag. For high availability, the Reader Instance will be created but not used, or used only for data analysis internally. It’s Serverless anyway, so if you don’t use it, it’ll be kept at the minimum AAS, and you just have to bear this cost.

  1. Is the connection disconnected during rollout resolved?

It was resolved in Aurora Serverless v2.

  1. Under what conditions does rollout occur? Can it be free from the AAS problem?

Rollout occurs when CPU usage, memory usage, and the number of I/O requests are exceeded, and the unit occurs in units set to the minimum ACU.

In the existing RDS, RDS itself did not create additional connections overall in the AAS excess situation, but Serverless only affects the request because rollout occurs every second if CPU usage is exceeded, and it is much more stable because the newly rolled out instance processes the request from the next request.

  1. Do internal actions such as SQL and DB Function match?

It is safe to say that it is consistent within the range used by general developers. There is little difference. Therefore, Serverless and existing instances can be used in parallel in one Aurora Cluster. At the time of introduction, it is recommended to add a Serverless Instance within the Aurora Cluster as a Reader and test it first while using it together. If there is no problem, you can lower the existing Instance and operate it only with Serverless.

### Conclusion

Although it is about 1.6 times more expensive than the Aurora Cluster, it is expected to improve the product faster because it is much easier to develop because it does not take into account Replica Lag and all requests alone do not cause cost and reliability problems.

한글로 작성된 원문은 아래에 있으며, 먼저 파파고 번역기를 이용하여 영어로 번역한 내용이 있습니다. (The original text written in Korean is below, and first, there is a translation into English using Papago Translate.)

AWS Aurora Serverless

많은 서비스에서 AWS RDS Instance나 Aurora Cluster를 사용해서 DBMS를 사용하고 있다. Aurora Serverless는 출시된 2018년 정식출시되었다. 5년 정도가 지났지만 아직 많은 서비스에서 이걸 사용하고 있지 않다. 그 이유는 크게 3가지가 있을 것으로 추정된다.

  1. Scale Up이 일어날 때 Connection이 끊기는 현상이 발생한다.
  2. AWS Serverless 제품 특성상 기존 서비스보다 이용가격이 더 비싸다.
  3. 기존 RDS와 사용법, 기능이 100% 동일할지 확신이 없다.

필자도 같은 이유로 그 동안 Aurora Serverless를 생각하고 있지 않다가 도입을 검토하게 되는 계기가 있었다.

  1. Aurora Serverless v2에서 Connection이 끊기는 문제에 대해서는 해결되었다.
  2. Replica Lag을 신경써가면서 로직 작성을 하는 수고를 제거할 수 있다.
  3. 서버관리에 대한 부담을 줄일 수 있다.

이러한 장점이 있지만 비용이 너무 비싸면 도입을 하기가 쉽지 않아진다.

Aurora Serverless Pricing

Aurora Serverless에서는 ACU단위로 과금이 되는데, RDS에서 이것과 대응되는 자원은 2Gb 메모리이다. RDS에서 사용하는 instance가 평균 1vCPU : 8Gb 비율을 가지니깐, 1 ACU는 0.25 vCPU라고 생각하면 된다. ACU의 단위 시간당 가격이 vCPU에 비해 6배 가량 더 비싸다. 그래서 현재 서비스 중인 RDS의 vCPU 메트릭을 평일 기준 1시간 단위로 Maximum값으로 대략적으로 계산을 해보니 ACU가 대략 1.6배 정도 더 비싸다. 참고로 현재 서비스는 안정성을 위해서 특별한 이벤트가 없는 날 기준 peak가 RDS CPU의 40%를 넘지 않는 규모로 운영중이다. 더군다나 Aurora Serverless는 아직 Reserved Instance나 Savings Plan 같은 할인 정책이 없다.

자세한 내용은 공식 홈페이지를 참조하면 된다.

https://aws.amazon.com/rds/aurora/pricing

Aurora Serverless Q&A

그래서 이것의 도입을 검토하기 이전에 AWS 협력사를 통해서 Aurora Serverless에 대해서 Special SA와의 기술미팅 시간을 가졌으며 그때 얻은 정보에 대해서 간략하게 정리해보고자 한다. 모든 내용을 다 적기에는 분량이 많으므로 주로 엔지니어들이 관심있을 만한 것으로 추려보겠다.

  1. Multi-Master가 지원되는가?

Aurora Serverless는 Aurora Cluster에서의 하나의 Instance를 대체하는 개념이다. 그러므로 Aurora Cluster는 Multi-Master를 지원하지 않으므로, Aurora Serverless라고해서 다른 점은 없다.

즉, Aurora Serverless에서도 Writer, Reader를 따로 구성할 수 있으며, 고가용성을 위해서는 Multi-AZ나 Multi-Region을 따로 구성해야 한다.

  1. Replica Lag은 없는가?

기존 Aurora Cluster의 Instance보다는 줄었지만, 존재한다. binlog를 사용하는 방식이 아니므로 기존보다는 많이 줄어들었다. 하지만 아에 없는 것이 아니므로 GraphQL Subscription 같은 기능 사용시 Writer에서 Read하도록 해야 한다.

나의 경우에는 Reader를 따로 사용하지 않고 서비스에서는 Writer만을 사용하는 식으로 구성해서 개발자들이 Replica Lag을 신경쓰지 않도록 하고 싶다. 고가용성을 위해서 Reader Instance를 생성은 하되 사용하지 않거나, 내부적으로 데이터 분석하는 용도등으로만 사용할 것이다. 어차피 Serverless라서 사용하지 않으면 최소 AAS로 유지가되며 이 비용만 부담하면 된다.

  1. Rollout시 Connection이 끊기는 문제는 해결되었는가?

Aurora Serverless v2에서 해결되었다.

  1. Rollout은 어떤 조건에서 일어나는가? AAS 문제로부터 자유로울 수 있는가?

Rollout이 일어나는 조건은 CPU 사용률, 메모리 사용량, I/O 요청 수 등이 초과하는 경우 Rollout이 발생하며, 그 단위는 최소 ACU로 설정한 단위로 발생한다.

기존 RDS에서는 AAS 초과 상황에서 RDS 자체가 전체적으로 추가적인 Connection을 생성하지 못했는데, Serverless의 경우 CPU 사용을 초과하는 경우 1초 단위로 Rollout이 발생하므로 해당 요청에 대해서만 영향을 미치며, 다음 요청부터는 새로 Rollout된 Instance가 요청을 처리하므로 훨씬 안정적이다.

  1. SQL, DB Function등 내부 동작이 일치하는가?

일반 개발자들이 사용하는 범위안에서는 일치한다고 봐도 무방하다. 거의 차이가 없다. 그러므로 하나의 Aurora Cluster에서 Serverless와 기존 Instance를 병행해서 사용할 수 있다. 도입시 Aurora Cluster내의 Serverless Instance를 Reader로 추가해서 함께 사용하면서 먼저 테스트를 해보기를 권장한다. 그렇게해서 문제가 없으면 기존 Instance를 내리고 Serverless로만 운영을 하면 된다.

Conclusion

Aurora Cluster보다 1.6배 정도 더 비싸긴 하지만, Replica Lag을 고려하지 않고, 모든 요청을 Writer로만 하더라도 비용 및 안정성에 문제가 더 커지지 않으므로 훨씬 더 개발을 쉽게하므로 제품을 더 빠르게 개선할 수 있을 것으로 예상된다.

Tags

#AWS #RDS #Aurora #Serverless #DevOps

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)