AWS RDS, Aurora 가용성을 위한 설정

RDS 개요

EC2에 DB를 설치하고 사용할 수 있지만, RDS 서비스를 사용하는 이유는 자동 프로비저닝, 주기적인 백업, 대쉬보드를 통한 모니터링 등등이 있지만, 주요한 이유는 다음과 같다.

Point in Time Restore : 특정 시점 복원은 자동 백업과 연계된 기능인데 백업본이 저장된 동안 DB를 복원할 수 있다.
수직 & 수평 자동 스케일링
EBS 스토리지 지원 (gp2, io1)
RDS Read Replicas : 읽기 부하를 나누기위한 읽기 전용 DB 인스턴스 자동 생성
다중 AZ for Disaster Recovery : 자동으로 다른 AZ의 인스턴스를 메인 DB로 승격

RDS 스토리지 Auto Scaling

RDS 사용량이 일정 수준 이상일 때 이를 감지해서 자동으로 스토리지 크기를 조절한다. 하지만, 무한으로 증가하는 것을 막기위해 최대 스토리지 값을 정해야한다. 그리고 모든 RDS DB 엔진에 스토리지 Auto Scaling은 적용된다.

스토리지를 스케일링하는 조건

남은 영역이 10% 이하일 때
낮은 스토리지가 5분 이상 지속될 때
마지막 수정 후 6시간이 지났을 때

RDS 읽기 전용 복제본

DB가 너무 많은 Read/Write 요청이 있을 때 부하를 분산할 때 사용하거나 서비스 애플리케이션에 연결된 DB 데이터를 분석할 때 메인 DB에 부하를 주지 않기 위해 읽기 전용 복제본을 만들어서 사용할 수 있다.

최대 5개의 복제본을 만들 수 있다
비동기식 복제
AZ 설정
- 메인과 동일한 AZ에 복제본 생성
- 동일 Region, 다른 AZ에 생성
- 다른 Region에 생성 : 이 경우 RDS는 과금이 붙는다. 나머지는 무과금
메인 RDS DB와 읽기 전용 DB는 비동기식 복제가 이뤄진다.
복제본 중 하나를 메인 DB로 승격시킬 수 있다. (가용성을 위함)

다중 AZ for Disaster Recovery

메인 DB나 그 AZ 전체의 문제가 발생했을 때를 대비해서 다른 AZ에 스탠바이 DB를 준비해 놓은 것이다. 읽기 전용 복제본과 달리 재난 복구용이기 때문에 누구도 접근하지 못한다. 메인 DB와 One DNS 이름을 사용하기 때문에 자동으로 메인 DB에 문제가 생겨도 스탠바이 DB가 메인으로 승격되고 애플리케이션과 연결될 수 있다.

다만, 주의할 점은 읽기 본제본을 다중 AZ에 위치 시켜서 Disaster Recovery로 쓸 수 있다!!

다중 AZ DB를 생성할 때 메인 DB는 downtime이 발생하지 않느다. 그 이유는 메인 DB의 스냅샷을 생성하고 다른 AZ에 스탠바이 DB를 생성하기 때문이다. 그리고 한번 스탠바이 DB를 생성하면 메인 DB와 동기식 복제가 이뤄진다.

Aurora 개요

Aurora는 AWS에서 개발한 RDS이며 PostGre와 MySQL과 호환된다. 주요한 특징은 다음과 같다.

자동으로 늘어나는 스토리지 (10GB(기본) ~ 128TB)
최대 15개 읽기 복제본 생성
Failover 자동화
Auto Scaling
다중 AZ에서 Auto Scaling 공유 스토리지 볼륨 사용 (가용성 보장)
읽기 복사본끼리 P2P 복제

고가용성과 Read Scaling

Aurora는 3개 AZ에 걸쳐서 6개의 복제본 볼륨을 생성한다. 쓰기에는 4개의 사본을 사용하고 읽기에는 3개의 사본만 사용한다. (한 AZ가 down해도 나머지가 있어서 ok) 이러한 볼륨들이 모여서 하나의 복제본 DB가 된다. 만약 어느 복제본 DB에 문제가 생기면 다른 복제본을 복사해서 복구할 수 있는 기능도 있다.

Aurora의 구성과 동작 방법

Aurora에는 하나의 마스터 DB가 있고 최대 15개의 읽기 전용 복사본이 있다. 마스터 DB에 이상이 생기면 복사본 DB중 하나가 마스터 DB가 되고 클라이언트는 이 마스터 DB로만 쓰기 작업을 할 수 있다. 만약 계속 마스터 DB가 바뀐다면 매번 클라이언트는 다른 DNS 이름에 요청해야할까? 아니다. Writer Endpoint라는 DNS 이름이 항상 클라이언트를 마스터 DB로 리다이렉트시켜준다.

그럼 클라이언트가 읽기 요청을 보낼때는 어떻게할까? Reader Endpoint라는 로드밸런서에 DNS 이름을 가지고 클라이언트가 요청하면 로드밸런서가 각 읽기 전용 복사본에 연결 요청을 분배해서 보낸다. 이때 로드 밸런싱은 연결 수준에서 발생한다.

또 다른 Aurora의 기능으로 Back track이라는 기능이 있다. 백업하는 것과는 다른 방법으로 DB의 과거 기록을 저장해두고 언제든지 이전 포인트로 데이터를 복원할 수 있다. (cmd z 같은 느낌!) 이 기능은 다른 RDS에는 없는 기능이라 외워둘 필요가 있을 것이다.

이처럼 Aurora는 다른 RDS에 비해 20% 가격이 비싸지만 클라우드 스토리지를 적극적으로 이용해서 가용성과 Scaling 가능성을 극대화한 RDS라고 할 수 있다.

RDS와 Aurora의 보안

KMS를 이용해서 마스터와 복제본 DB 볼륨 내용 암호화, 시작할 때 설정해야한다.
- 마스터가 암호화가 안되면 복사본도 암호화가 안된다.
- 이미 실행 중인 DB를 암호화하려면 스냅샷을 찍고, 다시 복구하는 과정에서 암호화 설정을 추가하면된다.
AWS TLS 루트 인증서를 이용해서 TLS 보안 연결 가능하다.
- HTTPS 연결 같이 네트워크 상에서 데이터 암호화 가능!
- 비대칭 키를 이용한 연결!
DB 로그인할 때 username/pwd 대신에 IAM role을 이용할 수 있다.
- 예를 들어 EC2에 IAM 역할을 부여해서 DB 접근을 설정할 수 있다.
Security Group을 이용해서 DB의 네트워크 연결을 관리할 수 있다.
관리형 서비스기 때문에 SSH 연결을 불가능한다.
감사 로그를 찍을 때 Audit Log를 이용할 수 있다.
- Auit Log는 짧은 기간 동안 저장되기 때문에 더 길게 저장하고 싶으면 Cloud Watch Log를 사용할 수 있다.

RDS Proxy

DB Proxy는 DB를 연결하기 전에 거쳐가는 곳이다. 그럼 왜 DB Proxy가 필요할까?

connection pooling

마치 JDBC의 Data Source와 비슷한 역할을 RDS Proxy가 해줄 수 있다.

Data Source는 이미 connection pool을 만들어 놓고 외부 연결이 요청되면 남는 connection을 제공해주면서 DB에 connection 생성으로 인한 리소스를 줄일 수 있다. 비슷하게 RDS Proxy는 VPC 내부에 RDS와 함께 위치하면서 RDS의 connection을 미리 생성해서 저장하는 connection pool 역할을 할 수 있다.

위오 같은 특징 덕분에 JDBC의 connection pool의 장점을 그대로 RDS Proxy가 가질 수 있다. connection을 만들기 위한 시간을 줄일 수 있어 timeout 시간을 줄이고, DB의 리소스를 아낄 수 있다.

이러한 특징을 가지고 Lambda와 더 큰 시너지를 얻을 수 있다. Lambda는 한번에 100~1000개가 생성되고 제거되는데 그때마다 DB connection을 생성하면 DB의 메모리나 CPU가 버티지 못할 수 있다. 그렇기 때문에 connection pooling하는 RDS Proxy를 사용해서 더 적은 연결 시간, 더 적은 리소스로 Lambda와 RDS를 연결할 수 있다.

Multi-AZ 장애조치

RDS Proxy는 Multi-AZ를 지원하기 때문에 RDS나 Aurora의 장애조치를 지원할 수 있는데. 프라이머리 DB에서 대기 인스턴스로 이동하는 시간을 66% 감소할 수 있고, 자동화 할 수 있다고 한다.

보안 연결

RDS Proxy 덕분에 사용자가 RDS에 연결할 때 IAM 인증을 받아야만 RDS에 연결할 수 있도록 설정할 수 있다. 그리고 AWS Secrets Manager에 이런 자격증명을 저장한다.

RDS Proxy는 VPC 내부에 위치하고 인터넷으로 RDS Proxy를 연결할 수 없다. VPC 내부 인스턴스만 연결할 수 있다. Lambda나 EC2!

목차