[RDS] AWS Aurora Auto Scaling 정책 - Deep Dive

 

AWS Aurora 서비스를 이용할 시  Auto Scaling Policy를 적용하는데 있어 알아야 할 필수 지식에 대하여 기재하였다. Aurora 에서의 Auto Scaling이 기준값 도달시 Replica가 확장되고 축소되는 개념이라고 생각하면 오산이다.

 

이번 글에서 Aurora의 특징 그리고, Auto Scaling 정책을 적용 시 Scale-In, Scale-Out 메커니즘이 어떻게 구현되는지에 대하여 말하고자 한다.

 

---

AWS Aurora란

AWS Aurora는 고성능 + 오픈소스의 간편성과 비용 효율성 + MySQL / PostgreSQL 과 호환 + 고가용성(HA)이 결합되어 MySQL, PostgreSQL 기반으로 설계된 완전 관리형의 관계형 데이터베이스이다.

 

Aurora 특징

 

특징1. 독립적인 자원 구성
AWS에서 제공하는 EC2 서비스는 OS(EC2) + Volume(EBS)의 독립적인 자원 구성으로 이루어져 있다. RDS Aurora 역시 인스턴스와 스토리지가 분리되어 있다.

 

특징 2. 고가용성 (HA, High Availability)
1개의 가용영역에 2개의 스토리지가 생성되며, 총 3개의 가용영역에 도합 6개의 스토리지가 생성된다. 이를 바탕으로 한 가용영역에 있는 스토리지가 사용할 수 없는 상태가 되었을 때 다른 가용영역에 있는 스토리지 데이터를 참조하여 가용성을 보장한다. 이뿐만 아니라 스토리지에 있는 데이터는 S3에 자동으로 백업이 된다.

 

특징 3. 자동 스토리지 확장
RDS Aurora는 일반적인 RDS와는 다르게 스토리지를 자동으로 10GB씩 최대 128TB까지 늘려준다. 

AWS Aurora 구성

 

 

Aurora Auto Scaling

Aurora Auto Scaling 메커니즘

 

Auto Scaling 정책에서 [1] Aurora Read Replica의 평균 CPU 사용률 [2] Aurora Read Replica 평균 연결 수 기준으로 Scaling 메커니즘 기준을 설정할 수 있다.

💡 Aurora Auto Scaling Metric
[1] 평균 CPU 사용률 (RDSReaderAverageCPUUtilization)
전체 Read Replica들의 CPU 사용률의 평균값이다.

[2] 평균 연결 수 (RDSReaderAverageDatabaseConnections)
전체 Read Replica들의 DatabaseConnections 의 평균값이다.

 

Auto Scaling을 적용하게 되면 대상 측정치(CPU 사용률, DB연결 수)를 실시간으로 CloudWatch 에서 감시한다. CloudWatch는 리소스 대상으로 CPU 사용률(CPU Utilization) 혹은 DB 연결 수(Database Connections) 항목에 대하여 실시간 모니터링을 진행하게 되며, Scale Up/Down 기준 값 충족 시 해당 메커니즘을 실현시킨다.

 

Aurora Scale-In vs Scale-Out

선요약

• AWS Auto Scaling 은 보수적으로 동작하도록 설계되었다. (Scale-Out = 빠른 확장, Scale-In = 느린 축소)
• Scale-Out(확장) 메커니즘은 Target Value 값을 기준으로 발현된다.
• Scale-In(축소) 메커니즘은 Target Value 값의 90% 혹은 Scale Up의 근접한 값의 기준으로 결정되며, 이는 Aurora 내부 설정값이기에 설정 및 변경이 불가능하다.

---

Aurora Scale-Out 메커니즘

(1) CloudWatch는 실시간으로 CPU 사용률을 추적하며 Scale-Out 기준값(=Target Value)에 도달시 알림을 발생시킨다.

알림 양식: TargetTracking-cluster:<<cluster name>>-AlarmHigh-<<고유 식별자>>

CloudWatch > Aurora TargetTracking

 

(2) Cloudwatch로부터 발생한 알림(Scale-Out 기준값 도달)을 전달받은 Aurora는 Scale-Out 메커니즘을 발현시킨다.

 

(3) Scale-Out 되는 기준은 Target Value를 기준으로 발현되며, 가용성을 보장하기 위해 Metric에 비례하게 빠르게 증가한다.

 

만약, 여러 정책이 적용되어 있는 경우 여러 정책 중 한개의 정책이라도 충족시 Scale-Out 메커니즘이 발현된다. 이는, 가용성을 최대한 보장하기 위함이다.

---

Aurora Scale-In 메커니즘

Scale-In 메커니즘은 어플리케이션 가용성을 보장하기 위해 메트릭에 비례하여 느리게 감소되도록 설계되었다.

 

(1) CloudWatch는 실시간으로 CPU 사용률을 추적하며 Scale-In 기준 충족 시 알림을 발생시킨다.

알림 양식: TargetTracking-cluster:<<cluster name>>-AlarmLow-<<고유 식별자>>

아래에 설명할 예정이지만 Threshold 항목값에 60이 아닌 54로 되어 있고 15min 이라는 항목이 보인다. 이는 리더 인스턴스 전체 CPU 사용률이 54% 이하로 15분 이상 유지시 해당 알림이 발생한다.

CloudWatch > Aurora TargetTracking

 

(2) CloudWatch로부터 발생한 알림(Scale-In 기준값)을 전달받은 Auroa는 Scale-In 메커니즘을 발현시킨다.

 

(3) 가용성을 보장하기 위해 Scale-In 정책은 보수적으로 동작하게 된다. Scale-In이 되는 기준은 Target Value보다 낮은 값으로 설정되며 일반적으로 Target Value보다 10% 낮은 값으로 설정된다. 이 기준을 15분 동안 유지되었을 때 Scale-In 메커니즘이 발현된다. 

💡  Aurora Scale-In Policy
Target Value 의 90% 값, 15 분의 속성값은 Aurora 내부적으로 설계된 값이며, 이는 사용자 설정이 불가능한 속성들이다. Scale-In 정책이 (Target Value 90% + 15분 유지)로 설정된 이유는 가용성을 보장하기 위해 보수적으로 설계되었기 때문이다. 어플리케이션에서 더 이상 예상되는 Scale-Out 의 요인들이 없어졌다고 판단되었을 때 Scale-In 메커니즘을 발현시킨다.

 

만약, 여러 정책이 적용되어 있는 경우 여러 정책 중 모두 충족시 Scale-In 메커니즘이 발현된다. 이는, 가용성을 최대한 보장하기 위함이다.

 

---

참조

Target tracking scaling policies for Application Auto Scaling

https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html#target-tracking-considerations

Target tracking scaling policies for Application Auto Scaling - Application Auto Scaling