Aurora Serverless
- Aurora의 온디맨드 Auto Scaling 구성
- 애플리케이션 요구사항을 기반으로 자동으로 시작 및 종료하고 용량을 확장 또는 축소 함
- 데이터베이스 용량을 관리하지 않고도 클라우드에서 데이터베이스를 실행할 수 O
- 인스턴스를 미리 프로비전 하거나 관리할 필요X
- T2.micro / T2.midium 등의 인스턴스 타입 역시 선택 불필요
- V1과 V2가 존재하는데 이 강의를 할 때는 V2는 아직 Preview 상태라서 V1기준으로 서술 하겠음
Aurora Serverless 특징
1. OnDemand
- 사용한 리소스를 1초 단위로 과금
2. Single-AZ
- 하나의 AZ에서만 동작 함
- 단, Multi-AZ Failover를 지원 함
: 하나의 AZ에서 장애 발생 시, 다른 AZ로 바로 복구를 해줌 - 기존의 Provisioned(Aurora) 보다 느림 - 용량은 10Gb ~ 128Tb로 자동 스케일링
- DB Cluster Parameter Group만 지원 함
--> DB Cluster Parameter Group: 클러스터 전체에 적용
--> DB Instance Parameter Group: 개별 인스턴스에 적용
3. ACU(Aurora Capacity Unit) 단위로 컴퓨팅 조절
(1) 약 2gb RAM, CPU, 네트워크
(2) 최대/최소 ACU 설정 가능
- 부하에 따라, 정해놓은 변동폭 안에서 자유롭게 변함
- 부하가 많다 --> 높은 ACU
(3) AWS에서 Warm Instance pool에서 인스턴스를 준비하고 스케일링에 따라 인스턴스를 할당/회수
(4) 최소 0ACU까지 스케일 다운 가능 == 스토리지 비용만 지불
- 단, 0ACU에서 1이상의 ACU로 전환하는데 시간 소요(25~40초)
- 선택적 기능이기 때문에 최소 1ACU이상 유지 가능
- 디폴트 5분, 최대 24시간 까지
- 7일동안 이용내역이 없으면 스냅샷으로 저장, 요청 발생시 자동 복구
Aurora Serverless 아키텍쳐
- 외부에서 직접 액세스X, Public IP 없음
- Bastion Host 등을 이용하여 VPC를 통해서 액세스 해야함
Requester Router
- Connection을 계속 유지시켜줌
- 계속 연결을 받아주고 Instance Layer가 바뀜에도 불구하고 계속 Connection을 유지하고 라우트를 해줌
- Instance Layer에서 계속 구성이 바뀌는데, 바뀔때마다 Connection이 끊어지면 지속적으로 동작을 못하기 때문
Instance Layer
- Requester Router에서 받은 요청들을 처리, 연산
- Storage Layer와 연동
- Instance는 Stateless, 아무데나 왔다갔다 함
Storage Layer
- 저장 담당
Work Flow
- 요청이 들어왔을 때 Warm Instance pool에서 Instance 하나를 할당
- Requester Router를 통해서 인스턴스가 요청을 받고 Storage에 접속해서 쿼리, 트랜잭션 등을 처리
- 요청이 많아지게 되면 Warm Instance pool에서 더 많은 인스턴스들을 할당(ACU 최대에 따라 하겠쥬?)
- 많은 요청들을 처리
- 그림에서 인스턴스 사이즈는 같게 그렸지만 사실은 수시로 변함
- 변함에도 불구하고 Requester Router 덕분에 Connection을 유지O
- 요청이 줄어들어서 인스턴스가 많이 필요가 없다고 하면 Aurora Serverless에서 인스턴스를 회수 함
- 적정한 ACU을 유지하여 비용 최적화 함
- 아무런 요청이 없다면 마지막 인스턴스도 회수를 하여 0ACU 상태로 유지 함
(0ACU 설정 하였을 때) - Aurora Serverless에서 커넥션 없을 때를 계속 찾음
--> 이것을 Scaling Point라고 함
Aurora Serverless의 보안과 복구
1. Multi-AZ Failover
- 장애 발생시 자동으로 다른 AZ에 복구
2. 기본적으로 암호화 되어있음 : 비활성 불가
3. 패치/업데이트 시 스케일링 포인트를 찾아 업데이트
- 스케일링 포인트: 쿼리 처리가 없는 상태
- 하루이상 찾지못하면 클러스터 이벤트로 알려줌
- 이후 TimeoutAction 설정에 따라 롤백 혹은 자동업데이트
Aurora Serverless의 제약사항
1. VPC 밖에서 액세스 불가능
- 직접 밖에서 로그인 불가능
- Public IP 할당 불가능
- Data API 또는 Bastion Host 등의 방법으로 접근
2. Replica / 클로닝 / Backtrack / Multi-Master 불가능
3. 포트는 3306(MySQL) / 5432(PostgreSQL) 고정
4. Inter Region VPC Peering 불가능
5. 엔진 버전 고정
Data API
- Aurora Serverless용 Data API를 사용하면 Aurora Serverless DB 클러스터에 대한 웹 서비스 인터페이스로 작업할 수 있다.
- Data API에서 DB 클러스터에 지속적으로 연결하지 않아도 됨
- 대신 AWS SDK와의 통합과 보안 HTTP 엔드포인트를 제공한다.
- 연결을 관리하지 않고 엔드포인트를 사용하여 SQL문을 실행 할 수 있다.
cf) 기존, 전통적인 rdbms
- 전통적인 rdbms는 커넥션 유지가 어렵다.
- DB에는 커넥션의 제한숫자가 있다
- 근데 람다는 순식간에 100-200개도 줄었다 늘었다 하기 때문에 제한된 수가 넘어서 bottleneck이 발생 할 수 있다.
- 그것을 해결하기 위해서 AWS에서 출시 한 것이 Amazon RDS Proxy 임
- 또 한가지가 Data API 이다.
참고
쿄쿄쿄