RDS / Aurora / ElastiCache
RDS
Relational Database Service
Postgres, MySQL, MariaDB, Oracle, Microsoft SQL Server, IBM DB2, Aurora (AWS Proprietary database) 를 제공한다.
DB의 기능 뿐만 아니라 자동화된 데이터베이스 프로비저닝, 자동화된 운영체제 패치 등을 제공한다.
(PITR)Point in Time Restore를 통해 지속적으로 백업이 이루어져 특정 시점으로 복원할 수 있다.
데이터베이스 성능을 모니터링할 수 있는 대시보드를 제공한다.
Read Replicas 기능을 사용할 수 있다.
가용성을 높이고 재해 복구에 유용하도록 Multi-AZ를 구성할 수 있다.
업그레이드를 위한 Maintenance Windows를 제공한다.
인스턴스 타입을 변경해 수직 확장하거나 인스턴스 수를 늘려 수평 확장할 수 있다.
EBS 기반으로 구현되어 있다.
Managed Service이므로 Underlying EC2 인스턴스에는 SSH로 접근할 수 없다.
데이터베이스 서버 호스트와 운영체계에 액세스하고 맞춤화할 수 있게 하려면 RDS Custom을 사용해야 한다.
RDS Storage Auto Scaling
RDS Database를 생성할 때 필요한 스토리지 용량을 지정하는데, 사용 가능한 공간이 부족해지면 RDS Storage Auto Scaling이 스토리지를 자동으로 확장해 준다.
스토리지 용량을 늘리기 위해 데이터베이스를 중단할 필요가 없다.
최대 스토리지 임계값을 설정해야 스토리지가 무한정 늘어나지 않는다.
할당된 용량의 10% 미만으로 남으면 스토리지 설정을 자동으로 변경할 수 있다.
스토리지가 5분 이상 부족한 상태가 지속되고 마지막 수정 후 6시간이 지나면 스토리지가 자동으로 확장된다.
읽기 전용 복제본
메인 데이터베이스 인스턴스가 너무 많은 요청을 받아 충분히 스케일링할 수가 없을 때 읽기 전용 인스턴스를 통해 스케일링할 수 있다.
SELECT 문 외에는 사용할 수 없으며, 최대 다섯 개까지 생성할 수 있다.
동일한 가용 영역 또는 가용 영역이나 리전을 걸쳐서 생성할 수 있다.
메인 RDS 데이터베이스 인스턴스와 읽기 전용 복제본 사이에 복제는 비동기로 이뤄지므로 eventually consistent 한 상태가 된다.
복제본을 데이터베이스로 승격시켜 사용할 수도 있다.
읽기 전용 복제본을 사용하려는 경우에는 애플리케이션과의 연결을 업데이트해야 하며 이를 통해서 RDS 클러스터 상의 읽기 전용 복제본 전체 목록을 활용할 수 있다.
AWS에서는 기본적으로 서로 다른 AZ 간에 데이터가 이동할 때에 비용이 발생하지만, RDS는 관리형 서비스이므로 동일한 Region 내에 있는 서로 다른 AZ 간 복제 작업이 이뤄져도 비용이 발생하지 않는다. 단, Region 간 복제 작업이 이뤄지면 비용이 발생한다.
다중 AZ
AZ A에서 읽기와 쓰기를 수행하는 마스터 데이터베이스 인스턴스의 데이터를 동기 방식으로 AZ B의 스탠바이 인스턴스로 복제한다.
하나의 DNS 이름을 사용해 두 데이터베이스를 연결해두고, 마스터에 문제가 생기면 스탠바이 데이터베이스를 마스터로 승격시켜 automatic failover를 할 수 있다.
스탠바이 데이터베이스는 단지 대기 목적이므로 데이터를 직접 읽거나 쓸 수 없다.
재해 복구를 대비해서 읽기 전용 복제본 역시 다중 AZ로 설정할 수 있다. 읽기 전용 복제를 마스터로 한 또 다른 스탠바이 데이터베이스가 생성되는 것이다.
단일 AZ에서 다중 AZ로 전환할 때에 데이터베이스를 중지할 필요가 없다.
마스터 데이터베이스의 RDS가 스냅샷을 생성하면 새로운 스탠바이 데이터베이스에 스냅샷을 통해 데이터가 복원된다. 이후 두 데이터베이스 간 동기화가 설정된다.
프록시
애플리케이션이 데이터베이스로 설정된 데이터베이스 연결을 풀링하고 공유할 수 있도록 해준다.
RDS 데이터베이스 인스턴스에 대한 연결이 많은 경우, 연결을 풀링하면 CPU, RAM 등 데이터베이스 리소스에 대한 부하를 줄여 데이터베이스 효율성을 향상시킬 수 있다.
서버리스이며 오토 스케일링이므로 용량을 관리하지 않아도 된다.
다중 AZ를 사용하기 때문에 가용성이 높다.
RDS 데이터베이스 인스턴스에 failover가 발생하면 standby 였다가 master가 된 인스턴스로 연결을 이동시켜야 한다. 이 때 프록시를 사용하면 연결을 직접 다시 맺지 않아도 되며 자동으로 연결이 이동된다. 덕분에 failover 시간을 최소화하며, 최대 66%까지 줄여준다.
MySQL, PostgreSQL, MariaDB에 대해 RDS Proxy를 지원하며, Aurora도 지원한다.
IAM을 사용해야만 RDS 데이터베이스 인스턴스에 연결할 수 있다. 이러한 자격 증명은 AWS Secrets Manager라는 또 다른 서비스에 안전하게 저장할 수 있다.
VPC에서만 프록시에 접근 가능하다.
Lambda 함수에서 RDS 데이터베이스 인스턴스에 대한 연결을 사용하며, 수많은 Lambda 함수가 생겨났다가 제거될 가능성이 있다면, 데이터베이스에 연결 수가 증감하고 타임아웃이 날 가능성이 높아진다. 이 경우, RDS 프록시를 사용하여 Lambda 함수에 대한 연결을 풀링해야 한다.
RDS Custom
기저 운영 체제나 데이터베이스 사용자 지정 기능에 액세스할 수 있는 서비스
Oracle과 Microsoft SQL Server 만을 지원한다.
RDS를 통해 AWS에서의 데이터베이스 자동화 설정, 운영, 스케일링을 사용할 수 있도록 해준다.
내부 설정 구성, 패치 적용, 네이티브 기능 활성화, SSH 또는 SSM 세션 관리자를 사용해서 RDS 뒤에 있는 기저 EC2 인스턴스 액세스 등의 작업을 수행할 수 있다.
사용자 지정 설정을 사용 시 RDS에서 주기적으로 자동화, 유지 관리, 스케일링과 같은 작업을 수행하지 않도록 자동화 기능을 꺼두어야 한다.
기저 EC2 인스턴스에 액세스가 가능하므로 문제가 쉽게 발생할 수 있기 때문에, 복구를 위해 데이터베이스 스냅샷을 만들어 두는 것이 좋다.
Aurora
Postgres와 MySQL과 호환되며 드라이버를 제공한다.
많은 최적화와 기능을 통해 RDS의 MySQL보다 5배 뛰어난 성능과 Postgres보다 3배 뛰어난 성능을 보인다.
10GB로 시작하며, 데이터베이스에 데이터를 더 입력할수록 자동으로 128TB까지 확장된다. 덕분에 디스크 모니터링에 신경 쓰지 않아도 된다.
읽기 전용 복제본을 15개까지 가질 수 있다. (MySQL은 5개만 가능하다.)
failover가 즉시 이뤄진다. MySQL RDS의 다중 AZ failover보다 훨씬 더 빠르다.
RDS보다 약 20% 비싸다.
3개의 AZ(가용 영역)에 걸쳐 무엇이든 쓸 때마다 데이터의 6개 사본을 저장한다.
쓰기 시에는 4개의 사본이 필요하다.
읽기 시에는 3개의 사본이 필요하다.
자가 복구 프로세스 - 어떤 데이터가 손상되거나 상태가 좋지 않다면 백엔드에서 피어 투 피어(P2P) 복제를 한다.
수백 개의 볼륨에 저장되어 관리된다. 복제, 자가 복구, 자동 확장 기능을 갖고 있다.
Aurora는 RDS의 다중 AZ와 비슷하다. 하나의 마스터 인스턴스가 쓰기를 담당한다.
마스터가 작동하지 않으면 평균 30초 이내에 failover가 발생한다. 이 때 읽기 전용 복제본이 마스터가 될 수 있다.
마스터 외에도 최대 15개의 읽기 전용 복제본이 모두 읽기를 제공한다.
Region 간 복제를 지원한다. 복제는 1초 이내로 완료된다. 메인 리전에 문제가 발생하면 다른 리전을 메인 리전으로 승급시킬 수 있다.
자가 복구와 자동 확장이 작은 블록마다 차례로 이뤄진다.
DNS이름을 가진 Writer Endpoint를 제공하여 마스터가 변경되고 장애가 발생하면 다른 인스턴스에 자동 리다이렉트 되도록 한다.
읽기 전용 복제본을 오토 스케일링할 수 있다.
1-15개의 복제본을 가질 수 있으며, 오토 스케일링을 설정해서 적절한 개수의 읽기 전용 복제본을 가질 수 있다.
하지만, 이로 인해 애플리케이션이 복제본에 어떻게 연결하는지를 알 수 없으므로 Reader Endpoint를 지원한다.
Reader Endpoint를 통해 모든 읽기 전용 복제본들에 자동으로 연결하고, 연결 로드밸런싱을 지원한다. 즉, 트래픽을 분산하는 것이 아니라 연결을 분산시켜주는 것이다.
SageMaker, Comprehend과 같은 ML모듈을 사용할 수 있다.
보안
미사용 데이터 암호화
KMS를 사용하여 마스터와 복제본을 암호화해야 한다. (데이터베이스를 처음 실행할 때 정의되어야 한다)
마스터 데이터베이스를 암호화하지 못한 경우, 읽기 전용 복제본이 암호화될 수 없다.
암호화되지 않은 기존 데이터베이스를 암호화하려면 암호화되지 않은 데이터베이스의 스냅샷을 가져온 후, 해당 데이터베이스 스냅샷을 암호화된 데이터베이스로 복원하면 된다.
전송 중 암호화
클라이언트와 데이터베이스 간의 암호화
AWS의 TLS 루트 인증서를 사용해야 한다.
IAM 역할을 통한 데이터베이스 연결
만약 EC2 인스턴스에 IAM 역할이 있는 경우, IAM 역할을 직접 사용하여 데이터베이스에 인증할 수 있다. 따라서 IAM의 AWS 내에서 모든 보안을 관리할 수 있다.
보안 그룹을 통한 네트워크 액세스 제어
특정 포트나 IPS, 보안 그룹을 허용하거나 차단할 수 있다.
RDS Custom 서비스를 사용하지 않는다면 SSH 접근이 불가능하다.
RDS와 Aurora에서 만들어지는 쿼리와 데이터베이스 로깅을 위해 감사 로그를 활성화할 수 있다. 오랜 기간 동안 보관하고 싶다면 AWS의 CloudWatch 로그 서비스를 사용해야 한다.
복제본 Auto Scaling
여러 Aurora 인스턴스가 있고 writer endpoint, reader endpoint가 있을 때 읽기 요청이 많이 들어왔다면, 복제본 auto scaling을 설정할 수 있다.
Amazon Aurora 복제본들이 추가로 생성된다.
이를 통해 각 복제본이 받게 되는 CPU 사용량을 줄일 수 있다.
사용자 지정 엔드포인트
여러 읽기 전용 복제본의 부분 집합을 사용자 지정 엔드포인트로 정의해 사용할 수 있다.
특정 복제본들이 어떠한 작업에 특화된 용도의 장비에서 수행되고 있을 때, 복제본들을 묶어 특화된 용도로 사용하기 위해 필요하다.
각각의 다양한 업무마다 다양한 사용자 지정 엔드포인트를 만들어 복제본의 부분 집합에 쿼리하게 된다.
서버리스
자동화된 데이터베이스 예시화와 실제 사용량에 따른 Auto Scaling을 제공한다.
간헐적이고 예측 불가능한 업무량에 대응할 수 있다.
용량 산정을 하지 않아도 되므로, 현재 사용량을 기반으로 비용을 지불한다.
클라이언트는 Aurora가 관리하는 프록시 플릿에 연결하면 되고, 백엔드에는 알아서 Aurora 인스턴스들이 생성된다.
Global Aurora
Aurora 교차 리전 읽기 전용 복제본은 재해 복구에 도움이 많이 되고, 실행하기 쉽다.
모든 읽기와 쓰기가 일어나는 하나의 기본 리전이 있고 최대 5개의 보조 읽기 전용 리전을 만들 수 있다.
이 때 응답 지연이 1초 이하이다.
보조 리전 당 최대 16개의 읽기 전용 복제본을 사용할 수 있다.
한 리전에 데이터베이스 중단이 일어날 경우 재해 복구를 위해 다른 리전을 승급시키는데, 이 때 복구시키는 시간이 1분 이내이다.
평균적으로 Aurora 글로벌 데이터베이스에서 한 리전에서 다른 리전으로 데이터를 복제하는 데에는 1초 이하의 시간이 걸린다.
머신 러닝
SQL 인터페이스를 그대로 사용하면서 기계 학습 기반의 예측 기능을 함께 도입할 수 있다.
SageMaker, Amazon Comprehend와 간단하게 통합할 수 있다.
사용자가 SQL 문으로 쿼리하기만 하면 이상 행위 탐지, 광고 타겟팅, 감정 분석, 상품 추천 등이 백그라운드에서 수행되도록 한다. 그리고 수행 결과를 사용자에게 반환한다.
백업
RDS
자동 백업
RDS 서비스가 자동으로 매일 데이터베이스의 전체 백업을 수행한다.
가장 최신의 백업은 5분 전의 백업이다.
자동 백업 보존 기간은 1~35일 사이로 설정할 수 있다.
자동 백업 보존 기간을 0일로 두어 자동 백업 기능을 비활성화할 수 있다.
수동 데이터베이스 스냅샷
사용자가 수동으로 백업을 트리거한다.
백업을 원하는 기간 동안 유지할 수 있다.
항상 사용되는 것은 아닌 RDS를 운영할 때 비용 절감을 위해 백업해둔 뒤 데이터베이스를 중지하고, 필요 시 다시 스냅샷을 복원해 RDS를 시작하면 훨씬 저렴하다.
Aurora
자동화된 백업
1일에서 35일 사이로 백업 보존 기간을 설정할 수 있다.
비활성화할 수 없다.
시점 복구 기능을 통해 해당 기간의 어느 시점으로든 복구할 수 있다.
수동 DB 스냅샷은 사용자가 수동으로 트리거할 수 있으며, 원하는 기간 동안 유지할 수 있다.
스냅샷 복원 옵션
자동화된 백업이나 수동 스냅샷을 복원할 때마다 새 데이터베이스가 생성된다.
온프레미스 데이터베이스의 백업을 생성하고 Amazon S3에 저장한 뒤, RDS에서는 Amazon S3의 백업 파일을 복원하여 실행시킬 수 있다.
온프레미스 데이터베이스를 Percona XtraBackup 소프트웨어를 통해 백업하고 Amazon S3에 저장한 뒤 MySQL Aurora 클러스터로 복원할 수 있다.
Aurora 클러스터 복제
기존 Aurora 클러스터에서 새로운 Aurora 클러스터를 생성할 수 있다.
예를 들어 Aurora에 프로덕션 데이터베이스가 있고, 해당 데이터를 기반으로 테스트를 하고 싶은 경우 스테이징 Aurora 데이터베이스에 복제하면 된다.
copy-on-write 프로토콜을 사용하므로 백업을 통해 스냅샷을 생성하고 복원하는 것보다 빠르다.
처음 데이터베이스 복제본을 만들 때는, 원래 데이터베이스 클러스터와 동일한 데이터 볼륨을 사용한다. Aurora 데이터베이스 또는 스테이징 Aurora 데이터베이스에 업데이트가 이루어지면, 새로운 추가 스토리지가 할당되고 데이터가 복사 및 분리된다.
ElastiCache
관리형 캐시 서비스를 지원한다.
Redis
Multi AZ 간 자동 failover를 지원한다.
읽기 복제본을 생성하여 읽기 작업을 확장하고 높은 가용성을 제공한다.
AOF 지속성을 사용하여 데이터 내구성을 제공한다.
백업 및 복원 기능을 제공한다.
IAM 인증과 Redis AUTH 기능을 통해 보안을 제공한다.
Memcached
샤딩을 통해 여러 노드에 데이터를 파티셔닝한다.
복제를 지원하지 않으므로 고가용성이 지원되지 않는다.
Memcached의 서버리스 버전에는 백업 및 복원 기능이 있다.
멀티 스레드 아키텍처로 동작한다.
SASL 기반 승인을 지원한다.
IAM, 보안 그룹, KMS, Redis Auth를 통해 보안성을 보장한다.
백업, 스냅샷, Point in time restore 기능을 제공한다.
RDS와 연동된 캐싱 작업을 수행하려면 애플리케이션 코드를 수정해주어야 한다.
캐싱 전략
캐싱 대상 데이터
자주 바뀌지 않아야 한다.
데이터 구조가 캐싱에 적합해야 한다.
쿼리하기 쉬운 데이터여야 한다.
lazy loading / cache aside / lazy population
데이터 조회 시 캐시에서 먼저 데이터를 조회해보고, 데이터가 없으면 RDS에 조회 요청을 보낸다. 이후 해당 데이터를 캐시에 저장한다.
하나의 조회 쿼리에서 최대 3번의 요청을 수행하게 된다.
데이터가 RDS에는 업데이트되었지만 캐시에는 업데이트되지 않은 상황이면 데이터 불일치가 발생할 수 있다.
write through
DB에 데이터를 추가하거나 변경할 때 캐시에도 같이 데이터를 추가하거나 변경해준다.
이 방식은 항상 사용할 필요는 없다. 필요한 부분에서만 쓰면 된다.
데이터를 쓸 때 항상 2번의 요청을 수행하게 된다.
데이터 쓰기 요청이 없었던 데이터를 접근하기 위해서 lazy loading 전략을 함께 사용할 수 있다.
캐시에는 자주 접근되지 않는 데이터까지 넣어두는 것이 비효율적인데, 이 전략을 사용하면 모든 데이터를 넣어두게 되므로 캐시 이탈률이 높아진다.
MemoryDB for Redis
Redis와 호환되고 내구성이 뛰어난 인 메모리 데이터베이스 서비스
초당 1억 6천만 건의 요청을 처리하는 초고속 성능을 제공한다.
여러 AZ에 저장되어 원하는 경우 빠른 복구와 데이터 내구성에 대한 접근을 제공하는 다중 AZ 트랜잭션 로그를 가진다.
10기가바이트부터 100테라바이트 이상에 이르기까지 원활하게 크기를 조정할 수 있다.
Last updated