<div id="readability-page-1" class="page"><div> <h3 id="aws-aurora-serverless">AWS Aurora Serverless</h3>Many web and mobile services use DBMS using AWS RDS Instance or Aurora Cluster. Aurora Serverless was officially released in 2018. It’s been about 5 years, but not many services are using it yet. It is presumed that there are three main reasons for this.<ol><li>Connection disconnection occurs when Scale Up occurs.</li><li>Due to the nature of AWS Serverless products, the usage price is higher than that of existing services.</li><li>It’s not sure if the usage and functions are 100% the same as the existing RDS.</li></ol>For the same reason, I had not been thinking about Aurora Serverless in the meantime, but there was an opportunity to consider introducing it.<ol><li>Aurora Serverless v2 has resolved the problem of disconnection.</li><li>You can eliminate the trouble of writing logic while paying attention to Replica Lag.</li><li>It can reduce the burden of server management.</li></ol>Despite these advantages, if the cost is too high, it will not be easy to introduce.<h3 id="aurora-serverless-pricing">Aurora Serverless Pricing</h3>In Aurora Serverless, billing is in units of ACU, and in RDS, you can think of the resource corresponding to this as vCPU. (2Gb memory is also included, but CPU was the more important metric for RDS mainly.) The price per unit hour of ACU is 6 times more expensive than vCPU. So, when I roughly calculated the vCPU metric of the currently serviced RDS with the maximum value per hour on a weekday basis, ACU was calculated approximately 2.5 times cheaper. For reference, the current service is operated at a scale where the peak does not exceed 40% of the RDS CPU based on days without special events for stability.Unless it is a global service, there is almost no usage at night or early in the morning, and since it is high for a specific few hours rather than always high during the daytime, ACU was calculated cheaper when calculated with average usage. Instead, Aurora Serverless does not yet have a discount policy such as Reserved Instance or Savings Plan. Even so, 2.5 times is much cheaper.For more details, please refer to the official website.<a href="https://aws.amazon.com/rds/aurora/pricing">https://aws.amazon.com/rds/aurora/pricing</a><h3 id="aurora-serverless-qa">Aurora Serverless Q&amp;A</h3>So, before reviewing the introduction of this, we had a technical meeting with Special SA about Aurora Serverless through AWS partners, and we would like to briefly summarize the information obtained at that time. It’s too long to cover everything, so I’ll try to narrow it down to something that will be of interest to engineers.<ol><li>Is Multi-Master supported?</li></ol>Aurora Serverless is a concept that replaces one instance in Aurora Cluster. Therefore, since Aurora Cluster does not support Multi-Master, Aurora Serverless is no different.That is, in Aurora Serverless, writers and readers can be configured separately, and for high availability, Multi-AZ or Multi-Region must be configured separately.<ol><li>Is there no replica lag?</li></ol>It exists. Since it is not a way to use binlog, it has been greatly reduced compared to before. However, it is not something that is not there, so when using functions such as GraphQL Subscription, you must read from the writer.In my case, I want to configure it in such a way that I do not use Reader separately and only use Writer in service so that developers do not care about Replica Lag. For high availability, Reader Instance will be created but not used, or used only for internal data analysis. Since it is Serverless anyway, if you do not use it, it will be maintained at minimum AAS, and you only have to pay this cost.<ol><li>Has the problem of disconnection during rollout been resolved?</li></ol>Fixed in Aurora Serverless v2.<ol><li>Under what conditions does a rollout occur? Can you be free from AAS problems?</li></ol>The rollout occurs when the CPU usage rate, memory usage, and number of I/O requests are exceeded, and the unit is the unit set as the minimum ACU.In the existing RDS, RDS itself failed to create an additional connection as a whole in the case of AAS overflow. In the case of Serverless, if the CPU usage is exceeded, rollout occurs in 1 second increments, so it affects only the request, and from the next request, the newly rolled-out instance handles the request, so it’s much more reliable.<ol><li>Are the internal operations such as SQL and DB functions consistent?</li></ol>It is safe to say that they are consistent within the scope of use by general developers. Almost no difference. Therefore, Serverless and existing instances can be used in parallel in one Aurora Cluster. When introducing it, it is recommended to test it first by adding a Serverless Instance in the Aurora Cluster as a reader and using it together. If there is no problem by doing so, you can take down the existing instance and operate only Serverless.<h3 id="conclusion">Conclusion</h3>Aurora Serverless is expected to be cheaper in terms of cost, except for cases where it is almost always not being used as highly as Global Service. In addition, even if all requests are made only by writers without considering Replica Lag, it is expected that the product can be improved more quickly because it is much easier to develop because there is no greater problem in cost and stability. There seems to be no reason not to use Aurora Serverless.한글로 작성된 원문은 아래에 있으며, 먼저 구글 번역기를 이용하여 영어로 번역한 내용이 있습니다. (The original text written in Korean is below, and first, there is a translation into English using Google Translate.)<h3 id="aws-aurora-serverless-1">AWS Aurora Serverless</h3>많은 서비스에서 AWS RDS Instance나 Aurora Cluster를 사용해서 DBMS를 사용하고 있다. Aurora Serverless는 출시된 2018년 정식출시되었다. 5년 정도가 지났지만 아직 많은 서비스에서 이걸 사용하고 있지 않다. 그 이유는 크게 3가지가 있을 것으로 추정된다.<ol><li>Scale Up이 일어날 때 Connection이 끊기는 현상이 발생한다.</li><li>AWS Serverless 제품 특성상 기존 서비스보다 이용가격이 더 비싸다.</li><li>기존 RDS와 사용법, 기능이 100% 동일할지 확신이 없다.</li></ol>필자도 같은 이유로 그 동안 Aurora Serverless를 생각하고 있지 않다가 도입을 검토하게 되는 계기가 있었다.<ol><li>Aurora Serverless v2에서 Connection이 끊기는 문제에 대해서는 해결되었다.</li><li>Replica Lag을 신경써가면서 로직 작성을 하는 수고를 제거할 수 있다.</li><li>서버관리에 대한 부담을 줄일 수 있다.</li></ol>이러한 장점이 있지만 비용이 너무 비싸면 도입을 하기가 쉽지 않아진다.<h3 id="aurora-serverless-pricing-1">Aurora Serverless Pricing</h3>Aurora Serverless에서는 ACU단위로 과금이 되는데, RDS에서 이것과 대응되는 자원은 vCPU라고 생각하면 된다. (2Gb 메모리도 포함되기는 하는데, 주로 RDS에서는 CPU가 더 중요한 메트릭이었다.) ACU의 단위 시간당 가격이 vCPU에 비해 6배 가량 더 비싸다. 그래서 현재 서비스 중인 RDS의 vCPU 메트릭을 평일 기준 1시간 단위로 Maximum값으로 대략적으로 계산을 해보니 ACU가 대략 2.5배 더 저렴하게 계산되었다. 참고로 현재 서비스는 안정성을 위해서 특별한 이벤트가 없는 날 기준 peak가 RDS CPU의 40%를 넘지 않는 규모로 운영중이다.글로벌 서비스가 아닌 이상 야간,새벽 시간대의 사용량이 거의 없으며 주간 시간에도 항상 높다기 보다 특정 몇시간 동안 높기 때문에 평균 사용량으로 계산을 하면 ACU가 더 저렴하게 계산되었다. 대신 Aurora Serverless는 아직 Reserved Instance나 Savings Plan 같은 할인 정책이 없다. 그렇더라도 2.5배면 훨씬 더 저렴하다.자세한 내용은 공식 홈페이지를 참조하면 된다.<a href="https://aws.amazon.com/rds/aurora/pricing">https://aws.amazon.com/rds/aurora/pricing</a><h3 id="aurora-serverless-qa-1">Aurora Serverless Q&amp;A</h3>그래서 이것의 도입을 검토하기 이전에 AWS 협력사를 통해서 Aurora Serverless에 대해서 Special SA와의 기술미팅 시간을 가졌으며 그때 얻은 정보에 대해서 간략하게 정리해보고자 한다. 모든 내용을 다 적기에는 분량이 많으므로 주로 엔지니어들이 관심있을 만한 것으로 추려보겠다.<ol><li>Multi-Master가 지원되는가?</li></ol>Aurora Serverless는 Aurora Cluster에서의 하나의 Instance를 대체하는 개념이다. 그러므로 Aurora Cluster는 Multi-Master를 지원하지 않으므로, Aurora Serverless라고해서 다른 점은 없다.즉, Aurora Serverless에서도 Writer, Reader를 따로 구성할 수 있으며, 고가용성을 위해서는 Multi-AZ나 Multi-Region을 따로 구성해야 한다.<ol><li>Replica Lag은 없는가?</li></ol>기존 Aurora Cluster의 Instance보다는 줄었지만, 존재한다. binlog를 사용하는 방식이 아니므로 기존보다는 많이 줄어들었다. 하지만 아에 없는 것이 아니므로 GraphQL Subscription 같은 기능 사용시 Writer에서 Read하도록 해야 한다.나의 경우에는 Reader를 따로 사용하지 않고 서비스에서는 Writer만을 사용하는 식으로 구성해서 개발자들이 Replica Lag을 신경쓰지 않도록 하고 싶다. 고가용성을 위해서 Reader Instance를 생성은 하되 사용하지 않거나, 내부적으로 데이터 분석하는 용도등으로만 사용할 것이다. 어차피 Serverless라서 사용하지 않으면 최소 AAS로 유지가되며 이 비용만 부담하면 된다.<ol><li>Rollout시 Connection이 끊기는 문제는 해결되었는가?</li></ol>Aurora Serverless v2에서 해결되었다.<ol><li>Rollout은 어떤 조건에서 일어나는가? AAS 문제로부터 자유로울 수 있는가?</li></ol>Rollout이 일어나는 조건은 CPU 사용률, 메모리 사용량, I/O 요청 수 등이 초과하는 경우 Rollout이 발생하며, 그 단위는 최소 ACU로 설정한 단위로 발생한다.기존 RDS에서는 AAS 초과 상황에서 RDS 자체가 전체적으로 추가적인 Connection을 생성하지 못했는데, Serverless의 경우 CPU 사용을 초과하는 경우 1초 단위로 Rollout이 발생하므로 해당 요청에 대해서만 영향을 미치며, 다음 요청부터는 새로 Rollout된 Instance가 요청을 처리하므로 훨씬 안정적이다.<ol><li>SQL, DB Function등 내부 동작이 일치하는가?</li></ol>일반 개발자들이 사용하는 범위안에서는 일치한다고 봐도 무방하다. 거의 차이가 없다. 그러므로 하나의 Aurora Cluster에서 Serverless와 기존 Instance를 병행해서 사용할 수 있다. 도입시 Aurora Cluster내의 Serverless Instance를 Reader로 추가해서 함께 사용하면서 먼저 테스트를 해보기를 권장한다. 그렇게해서 문제가 없으면 기존 Instance를 내리고 Serverless로만 운영을 하면 된다.<h3 id="conclusion-1">Conclusion</h3>Global Service처럼 거의 항상 높게 사용하고 있지 않은 경우를 제외하고는 Aurora Serverless가 비용면에서도 더 저렴할 것으로 예상된다. 그리고 Replica Lag을 고려하지 않고, 모든 요청을 Writer로만 하더라도 비용 및 안정성에 문제가 더 커지지 않으므로 훨씬 더 개발을 쉽게하므로 제품을 더 빠르게 개선할 수 있을 것으로 예상된다. Aurora Serverless를 사용 안 할 이유가 없는것 같다.<h3 id="tags">Tags</h3>#AWS #RDS #Aurora #Serverless #DevOps <div>이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :) </div></div></div>

Dev Note

AWS Aurora Serverless
Many web and mobile services use DBMS using AWS RDS Instance or Aurora Cluster. Aurora Serverless was officially released in 2018. It’s been about 5 years, but not many services are using it yet. It is presumed that there are three main reasons for this.
Connection disconnection occurs when Scale Up occurs.
Due to the nature of AWS Serverless products, the usage price is higher than that of existing services.
It’s not sure if the usage and functions are 100% the same as the existing RDS.
For the same reason, I had not been thinking about Aurora Serverless in the meantime, but there was an opportunity to consider introducing it.
Aurora Serverless v2 has resolved the problem of disconnection.
You can eliminate the trouble of writing logic while paying attention to Replica Lag.
It can reduce the burden of server management.
Despite these advantages, if the cost is too high, it will not be easy to introduce.
Aurora Serverless Pricing
In Aurora Serverless, billing is in units of ACU, and in RDS, you can think of the resource corresponding to this as vCPU. (2Gb memory is also included, but CPU was the more important metric for RDS mainly.) The price per unit hour of ACU is 6 times more expensive than vCPU. So, when I roughly calculated the vCPU metric of the currently serviced RDS with the maximum value per hour on a weekday basis, ACU was calculated approximately 2.5 times cheaper. For reference, the current service is operated at a scale where the peak does not exceed 40% of the RDS CPU based on days without special events for stability.
Unless it is a global service, there is almost no usage at night or early in the morning, and since it is high for a specific few hours rather than always high during the daytime, ACU was calculated cheaper when calculated with average usage. Instead, Aurora Serverless does not yet have a discount policy such as Reserved Instance or Savings Plan. Even so, 2.5 times is much cheaper.
For more details, please refer to the official website.
https://aws.amazon.com/rds/aurora/pricing
Aurora Serverless Q&A
So, before reviewing the introduction of this, we had a technical meeting with Special SA about Aurora Serverless through AWS partners, and we would like to briefly summarize the information obtained at that time. It’s too long to cover everything, so I’ll try to narrow it down to something that will be of interest to engineers.
Is Multi-Master supported?
Aurora Serverless is a concept that replaces one instance in Aurora Cluster. Therefore, since Aurora Cluster does not support Multi-Master, Aurora Serverless is no different.
That is, in Aurora Serverless, writers and readers can be configured separately, and for high availability, Multi-AZ or Multi-Region must be configured separately.
Is there no replica lag?
It exists. Since it is not a way to use binlog, it has been greatly reduced compared to before. However, it is not something that is not there, so when using functions such as GraphQL Subscription, you must read from the writer.
In my case, I want to configure it in such a way that I do not use Reader separately and only use Writer in service so that developers do not care about Replica Lag. For high availability, Reader Instance will be created but not used, or used only for internal data analysis. Since it is Serverless anyway, if you do not use it, it will be maintained at minimum AAS, and you only have to pay this cost.
Has the problem of disconnection during rollout been resolved?
Fixed in Aurora Serverless v2.
Under what conditions does a rollout occur? Can you be free from AAS problems?
The rollout occurs when the CPU usage rate, memory usage, and number of I/O requests are exceeded, and the unit is the unit set as the minimum ACU.
In the existing RDS, RDS itself failed to create an additional connection as a whole in the case of AAS overflow. In the case of Serverless, if the CPU usage is exceeded, rollout occurs in 1 second increments, so it affects only the request, and from the next request, the newly rolled-out instance handles the request, so it’s much more reliable.
Are the internal operations such as SQL and DB functions consistent?
It is safe to say that they are consistent within the scope of use by general developers. Almost no difference. Therefore, Serverless and existing instances can be used in parallel in one Aurora Cluster. When introducing it, it is recommended to test it first by adding a Serverless Instance in the Aurora Cluster as a reader and using it together. If there is no problem by doing so, you can take down the existing instance and operate only Serverless.
Conclusion
Aurora Serverless is expected to be cheaper in terms of cost, except for cases where it is almost always not being used as highly as Global Service. In addition, even if all requests are made only by writers without considering Replica Lag, it is expected that the product can be improved more quickly because it is much easier to develop because there is no greater problem in cost and stability. There seems to be no reason not to use Aurora Serverless.
한글로 작성된 원문은 아래에 있으며, 먼저 구글 번역기를 이용하여 영어로 번역한 내용이 있습니다.
(The original text written in Korean is below, and first, there is a translation into English using Google Translate.)
AWS Aurora Serverless
많은 서비스에서 AWS RDS Instance나 Aurora Cluster를 사용해서 DBMS를 사용하고 있다. Aurora Serverless는 출시된 2018년 정식출시되었다. 5년 정도가 지났지만 아직 많은 서비스에서 이걸 사용하고 있지 않다. 그 이유는 크게 3가지가 있을 것으로 추정된다.
Scale Up이 일어날 때 Connection이 끊기는 현상이 발생한다.
AWS Serverless 제품 특성상 기존 서비스보다 이용가격이 더 비싸다.
기존 RDS와 사용법, 기능이 100% 동일할지 확신이 없다.
필자도 같은 이유로 그 동안 Aurora Serverless를 생각하고 있지 않다가 도입을 검토하게 되는 계기가 있었다.
Aurora Serverless v2에서 Connection이 끊기는 문제에 대해서는 해결되었다.
Replica Lag을 신경써가면서 로직 작성을 하는 수고를 제거할 수 있다.
서버관리에 대한 부담을 줄일 수 있다.
이러한 장점이 있지만 비용이 너무 비싸면 도입을 하기가 쉽지 않아진다.
Aurora Serverless Pricing
Aurora Serverless에서는 ACU단위로 과금이 되는데, RDS에서 이것과 대응되는 자원은 vCPU라고 생각하면 된다. (2Gb 메모리도 포함되기는 하는데, 주로 RDS에서는 CPU가 더 중요한 메트릭이었다.) ACU의 단위 시간당 가격이 vCPU에 비해 6배 가량 더 비싸다. 그래서 현재 서비스 중인 RDS의 vCPU 메트릭을 평일 기준 1시간 단위로 Maximum값으로 대략적으로 계산을 해보니 ACU가 대략 2.5배 더 저렴하게 계산되었다. 참고로 현재 서비스는 안정성을 위해서 특별한 이벤트가 없는 날 기준 peak가 RDS CPU의 40%를 넘지 않는 규모로 운영중이다.
글로벌 서비스가 아닌 이상 야간,새벽 시간대의 사용량이 거의 없으며 주간 시간에도 항상 높다기 보다 특정 몇시간 동안 높기 때문에 평균 사용량으로 계산을 하면 ACU가 더 저렴하게 계산되었다. 대신 Aurora Serverless는 아직 Reserved Instance나 Savings Plan 같은 할인 정책이 없다. 그렇더라도 2.5배면 훨씬 더 저렴하다.
자세한 내용은 공식 홈페이지를 참조하면 된다.
https://aws.amazon.com/rds/aurora/pricing
Aurora Serverless Q&A
그래서 이것의 도입을 검토하기 이전에 AWS 협력사를 통해서 Aurora Serverless에 대해서 Special SA와의 기술미팅 시간을 가졌으며 그때 얻은 정보에 대해서 간략하게 정리해보고자 한다. 모든 내용을 다 적기에는 분량이 많으므로 주로 엔지니어들이 관심있을 만한 것으로 추려보겠다.
Multi-Master가 지원되는가?
Aurora Serverless는 Aurora Cluster에서의 하나의 Instance를 대체하는 개념이다. 그러므로 Aurora Cluster는 Multi-Master를 지원하지 않으므로, Aurora Serverless라고해서 다른 점은 없다.
즉, Aurora Serverless에서도 Writer, Reader를 따로 구성할 수 있으며, 고가용성을 위해서는 Multi-AZ나 Multi-Region을 따로 구성해야 한다.
Replica Lag은 없는가?
기존 Aurora Cluster의 Instance보다는 줄었지만, 존재한다. binlog를 사용하는 방식이 아니므로 기존보다는 많이 줄어들었다. 하지만 아에 없는 것이 아니므로 GraphQL Subscription 같은 기능 사용시 Writer에서 Read하도록 해야 한다.
나의 경우에는 Reader를 따로 사용하지 않고 서비스에서는 Writer만을 사용하는 식으로 구성해서 개발자들이 Replica Lag을 신경쓰지 않도록 하고 싶다. 고가용성을 위해서 Reader Instance를 생성은 하되 사용하지 않거나, 내부적으로 데이터 분석하는 용도등으로만 사용할 것이다. 어차피 Serverless라서 사용하지 않으면 최소 AAS로 유지가되며 이 비용만 부담하면 된다.
Rollout시 Connection이 끊기는 문제는 해결되었는가?
Aurora Serverless v2에서 해결되었다.
Rollout은 어떤 조건에서 일어나는가? AAS 문제로부터 자유로울 수 있는가?
Rollout이 일어나는 조건은 CPU 사용률, 메모리 사용량, I/O 요청 수 등이 초과하는 경우 Rollout이 발생하며, 그 단위는 최소 ACU로 설정한 단위로 발생한다.
기존 RDS에서는 AAS 초과 상황에서 RDS 자체가 전체적으로 추가적인 Connection을 생성하지 못했는데, Serverless의 경우 CPU 사용을 초과하는 경우 1초 단위로 Rollout이 발생하므로 해당 요청에 대해서만 영향을 미치며, 다음 요청부터는 새로 Rollout된 Instance가 요청을 처리하므로 훨씬 안정적이다.
SQL, DB Function등 내부 동작이 일치하는가?
일반 개발자들이 사용하는 범위안에서는 일치한다고 봐도 무방하다. 거의 차이가 없다. 그러므로 하나의 Aurora Cluster에서 Serverless와 기존 Instance를 병행해서 사용할 수 있다. 도입시 Aurora Cluster내의 Serverless Instance를 Reader로 추가해서 함께 사용하면서 먼저 테스트를 해보기를 권장한다. 그렇게해서 문제가 없으면 기존 Instance를 내리고 Serverless로만 운영을 하면 된다.
Conclusion
Global Service처럼 거의 항상 높게 사용하고 있지 않은 경우를 제외하고는 Aurora Serverless가 비용면에서도 더 저렴할 것으로 예상된다. 그리고 Replica Lag을 고려하지 않고, 모든 요청을 Writer로만 하더라도 비용 및 안정성에 문제가 더 커지지 않으므로 훨씬 더 개발을 쉽게하므로 제품을 더 빠르게 개선할 수 있을 것으로 예상된다. Aurora Serverless를 사용 안 할 이유가 없는것 같다.
Tags
#AWS #RDS #Aurora #Serverless #DevOps

AWS RDS Aurora Serverless

댓글