알아보자 Aurora Serverless 배워보자 Aurora Serverless (AKA. 알A배A)

모 프로젝트에서 메인 저장소로 Amazon Aurora를 통해 사용하고 있었다.

어느 날과 다를 거 없이 관련 문서를 찾아보던 중 아래 같은 글을 찾게 된다.

 

Amazon Aurora Serverless 정식 출시 | Amazon Web Services

오늘은 Amazon Aurora Serverless에서 대한 이야기를 해보려고 한다.

 

 

Amazon Aurora Serverless란?

기본적으로 Aurora Serverless의 목적은 'lamda'의 콘셉트와 같다고 생각하면 된다. (흠 당연한 이야기인가..) 

로켓처럼 들어오는 트래픽에 대해, DB에 대한 부하도를 Aurora Serverless가 관리하고 운영할 테니, 쓴 만큼 비용 만 내라는 거다.

 

Amazon은 Aurora Serverless가 필요한 이유를 이렇게 이야기하고 있다.

간헐적인 판매 이벤트를 진행하는 소매 웹 사이트, 필요한 경우 보고서를 생성하는 보고 데이터베이스, 개발 및 테스트 환경, 필요량이 불확실한 새 애플리케이션 등을 예로 들 수 있습니다. 이러한 경우와 기타 많은 경우 정확한 시점에 정확한 용량을 구성하기가 어려울 수 있습니다. 또한 사용하지 않는 용량에 대해 지불하는 경우에는 비용이 불필요하게 증가할 수 있습니다.

 

 

Amazon Aurora Serverless 그러면 Auto Scaling인데, 연결 끊기고 난리 나는 거 아님?

그럼 이런 의문이 들것이다

"엥 이거 완전 EC2 Auto Scaling인데, 중간에 연결 끊겨서, Application도 수정해야 하는 거 아니에요?" 

답을 먼저 이야기해주자고 하면 "아니다 Application을 수정하지 않아도 되고, 연결도 끊기지 않는다."

이것이 "Aurora Serverless"가 주장하는 장점이다.

 

그럼 일반적인 개발자라면, "우와 아마존 대단하다"라고 생각하겠지만, 난 "엥 그걸 어떻게 구현했지?"라는 생각이 든다.

 

Aurora Serverless 아키텍처

그 매직 같은 방법의 중심엔  "Proxy fleet"이 있다.

기본적으로 애플리케이션은 DB 서버에 바로 연결되는 것이 아닌, Proxy Layer에 있는 서버와 연결을 유지하게 된다.

 

이를 통해, Aurora Serverless에 DB 인스턴스에 대해 자유로운 Auto Scale이 가능하게 되는 것이다.

 

Amazon Aurora Serverless의 Auto Scale은?

Aurora Serverless DB 클러스터에 할당된 용량은 클라이언트 애플리케이션에서 생성된 부하(CPU 사용률 및 연결 수)에 따라 원활하게 확장 및 축소됩니다. (마치 EC2 Auto Scale 같은 개념)

 

Amazon Auto Scaling과 같이 최소 용량과 최대 용량을 지정하게 된다.

이때의 단위는 ACU (Aurora 용량 단위)로 지정한다.

 

Amazon은 기본적으로 각 Region별로,  Aurora Serverless의 Warm Pool을 운영하게 된다.

이를 통해 Aurora Serverless가 판단하기에, 현재 컴퓨팅 파워가 부족하다고 판단되면 Warm Pool에 있는

더 좋은 리소스의 인스턴스로 변경하고, "Proxy Fleet"에서 기존의 연결을  신규 인스턴스로 넘겨주기 때문에 애플리케이션 수정 없이, 빠른 시간 안에 로켓 같은 DB Event를  처리할 수 있는 것 이다.

 

단 세상에 매직은 없고, 디비는 중요하다.

아래와 같은 상황에는 Auto Scale Event가 잠시 보류된다.

 

- 장기간 쿼리 또는 트랜잭션이 진행 중인 경우

- 임시 테이블 또는 테이블 잠금이 사용 중인 경우

 

Amazon Aurora Serverless라  가능한, 미사용시 일시정지, 다시 시작 

Aurora Serverless의 특징이라고 하면  계속 언급되지만 유연한 인스턴스 활용이다. 

이벤트가 적은 시간대 혹은 없는 시간 (5분 이하 연결이 없는 경우) 용량이 0으로 지정되고,

이벤트가 넘치는 시간대에는 자동으로 필요한 만큼 확장이 되니,  어느 정도 수준에서는 비용도 아끼고,

높은 서비스 품질을 제공하고 이 얼마나 좋은가?

 

Aurora Serverless의 기본 일시정지 시간은 최소 5분에서 최대 1440분이며, 기본 값은 5분으로 설정된다.

물론, 일시정지는 사용하지 않을 수도 있다.

 

일시정지가 되었을때 컴퓨팅 자원 (Cpu, Memory)에 대해서는 지불하지 않고, 스토리지 사용 비용만 측정되게 된다.

 

Amazon Aurora Serverless 사용 사례를 생각해보자

이렇게 이야기만 하다 보니, 아무래도 와 닿지 않을 것 같다는 생각이 드는데 예를 들어보자.

 

(1) 데일리 배치를 사용해야 합니다.

내가 쇼핑몰 서비스를 하고 있고, 하루에 한 번 데일리 정산을 진행하는데 약 30분간 CPU를 10개 사용해야 한다.

하지만, 실제 서비스 운영 중에는 2개의 CPU를 사용하는 상황입니다.

 

그래서 개발자 Y 씨는 하루에 한 번 AWS API를 통해 작업을 시작할 때, 서버 티어를 높이고, 낮추 고를 진행하게 하였다.

하지만 이 모든 것이 관리적인 포인트로 들어가고, 개발을 해야 한다.

 

하지만 서버리스를 사용하여 최대 ACU만 지정해둔다면,

개발자는 인프라를 위한 로직을 고민하지 않고, Application만 개발하면 되는 것이다. 

 

(2) 우리 서비스는 특정 시간에 튑니다.

요즘 "코로나 19" 때문에, 관련된 서비스들이 많아지는데 아무래도 요청량이 불규칙하게 튀는 경우가 많다.

그래서 서비스 중단이 생기면 안 되기 때문에 미리 큰 인스턴스로 올려뒀는데, 

이런 실제 사용은 10%도 안 했지만 비용은 다 지불해야 한다. 이 얼마나 억울한가? 

 

하지만, Serverless를 사용한다면, 특정 이벤트가 발생했을 때 짧은 시간으로 스케일이 조정되어 서비스에 대한 품질은 높여주고 비용적인 부분도 이용한 만큼만 지불 하면 되는 것 이다.

 

 

Amazon Aurora Serverless의 제약사항

계속 이야기 하지만, 이 세상에 매직은 없고, 디비는 중요하기도 하니, 아래와 같은 제약사항들이 있다.

 

- PUBLIC IP를 할당 할 수 없습니다.

Aurora DB 자체의 PUBLIC IP를 할당 할 수 없습니다. 

 

- DB 인스턴스 별 파라미터를 지정할 수 없고, 클러스터 파라미터만 적용할 수 있다.

(READ 인스턴스에선 특정 값을 조정한다 던 지 등의 액션은 불가능합니다.) 

 

- Multi AZ를 지원하지 않는다.

특정 Zone에서 DB 클러스터가 생성되게 된다.

이는 해당 Zone 장애 발생 시, 자동으로 다른 Zone에 failover는 되지만,

그 시간이 오래 걸리고 서비스 중단의 문제가 있다는 뜻이다. 

단, Aurora는 아키텍처상 스토리지와 컴퓨팅을 분리하여 운영하고 있기 때문에 데이터는 문제없이 사용할 수 있다.

 

- Aurora MySQL Cluster에는 아래와 같은 파라미터 제약 사항이 있다.

character_set_server.
collation_server.
general_log. 
innodb_file_format. 
innodb_file_per_table.
innodb_large_prefix. 
innodb_lock_wait_timeout.
innodb_monitor_disable. 
innodb_monitor_enable. 
innodb_monitor_reset. 
innodb_monitor_reset_all. 
innodb_print_all_deadlocks. 
lc_time_names.
log_output.
log_queries_not_using_indexes
log_warnings
long_query_time
lower_case_table_names
net_read_timeout
net_retry_count
net_write_timeout
server_audit_logging
server_audit_events
server_audit_excl_users
server_audit_incl_users
slow_query_log
sql_mode
time_zone
tx_isolation

 

해당 값들만 수정이 가능하고, 그 외에는 기본값으로만 사용이 가능하다.

 

 

결론

우리는 항상 서비스 품질과, 비용이라는 갈림길에 서있다.

 

발생할 이벤트에 대해 잘 예측하여, 리소스를 잘 사용한다면, 아무런 문제가 없다. 

하지만, 특정 이벤트에 대응하기 위해 예측을 하였으나, 예측이 빗나가는 경우  비싼 비용은 사용했지만 제대로 된 뽕을 뽑지 못하게 된 것이다.

 

Amazon은 이러한 니즈를 충족하기 위하여,  Aurora Serverless라는 서비스를 출시하였고,

Application 개발자는 인프라에 대한 고민 없이 개발을 할 수 있고,  운영과 비용 관점에서 필요한 비용을 적절하게 사용하는 부분에 대해서도 큰 이점을 줄 수 있다.

 

또한 요청이 특정 시간에만 있는 혹은 적은 서비스를 효율적으로 운영하기 위하여 Lamda + Api Gateway를 통해 구성을 했고,

RDBMS 요구사항이 있다면, Aurora로 Flex 하는 것보다는 Aurora Serverless를 통해, 비용을 절감하는 것을 추천한다.