이 글은 <Amazon Aurora Serverless v2 정식 출시 블로그>를 읽고 정리한 것입니다.
Aurora Serverless v2
Aurora Serverless는 낮은 빈도/ 예측 불가한 워크 로드에 대응하기 적합한 데이터베이스로, 사용량이 많은 경우 리소스를 확장해야 하며 반대로 사용량이 적은 경우 리소스를 축소해야 하는데 Aurora Serverless는 이러한 크기 조정이 가능하다.
참고로, Aurora Serverless는 2018년에 첫 번째 버전이 출시되었다.
Aurora Serverless가 필요한 이유는 뭘까?
프로비저닝 된 데이터베이스를 사용하는 쇼핑 서비스가 있다고 가정해 보자.
- 이 때 예상보다 판매량이 많은 경우가 생길 수 있다. 그런데 만약 데이터베이스가 수요를 따라잡을 수 없는 경우(인스턴스 성능이 낮은 경우) 서비스 저하가 발생할 수 있다.
- 반대로 마케팅 캠페인이 예상된 판매량을 창출하지 못하는 경우에는 필요하지 않은 용량에 대해 불필요한 비용을 지불하게 될 것이다.
특징
크기 조정
- Aurora Serverless v2는 CPU 및 메모리 리소스를 추가하는 방법을 통해 기본 인스턴스의 용량을 늘리기 때문에 운영 중단 없이 즉시 크기를 조정할 수 있다.
- Aurora Serverless v2를 통해 기본 인스턴스가 크기 조정을 위해 새 인스턴스로 장애 조치(failover)를 하지 않고 적절한 용량을 늘리거나 줄일 수 있다.
- 워크로드에 필요한 용량에 도달할 때까지 용량은 단계적으로 축소 된다.
- 왜냐하면, 너무 빨리 축소하면 캐시된 페이지가 조기에 제거되고 버퍼 풀이 줄어들어 성능에 영향을 줄 수 있기 때문이다.
비용
- 데이터베이스가 활성 상태일 때 사용하는 용량을 초당 요금으로 지불 한다.
- 따라서, 프로비저닝 용량의 비용에 비해 최대 90%까지 절약이 가능하다고 한다.
용량
- 용량은 ACU(Aurora 용량 단위)로 측정 된다.
- ACU는 약 2GiB(기비바이트)의 메모리, 해당 CPU, 네트워킹의 조합이다.
- Aurora Serverless v2를 사용하면 최소 용량은 0.5ACU, 최대 용량은 128ACU이다.
- 데이터베이스 용량이 워크로드 요구 사항에 거의 부합할 수 있도록 0.5ACU 단위로 용량을 증분할 수 있다.
- 데이터베이스 용량은 밀리초 단위로 증가하여 로드에 정확하게 맞춰 조정 된다.
- 용량 증가에는 정확하게 맞춰 조정 되지만 트래픽 감소에는 정확히 맞춰 조정되지 않는다.
- 위에서도 언급했듯이, 5ACU에 도달할 때까지 단계적으로 감소 한다.
- 이는 캐시된 페이지가 조기 제거 되어 성능에 영향을 미치지 않도록 용량 축소를 보다 보수적으로 수행하기 때문이다.
- 이를 통해, 급증하는 워크로드에 대한 불필요한 대기 시간을 방지하고 캐시 및 버퍼 풀이 빠르게 제거되는 것을 막을 수 있다.
사용 방법
기존 Aurora 클러스터에 serverless 추가하기
- 기존 Amazon Aurora 클러스터가 있는 경우 동일한 클러스터 내에 Aurora Serverless v2 인스턴스를 생성할 수 있다.
- 이 방법을 이용하면 프로비저닝된 인스턴스와 Aurora Serverless v2 인스턴스가 모두 동일한 클러스터 내에 공존하는 혼합 구성 클러스터를 갖게 된다.
- 이 때, 기존 클러스터의 리더 인스턴스를 serverless v2 유형으로 구성하면 된다.
- 만약 잘 작동하면 기존의 provisioned 인스턴스의 failover로 serverless 인스턴스를 선택하면 된다.
새롭게 Serverless v2 데이터베이스 생성하기
- 기존에 Aurora 데이터베이스를 생성하는 방식과 기본적으로는 같다.
- 달라지는 점은 용량(Capacity range)을 선택해야 한다는 것이다.