: '관계형 데이터베이스 서비스'
SQL을 쿼리 언어로 사용하는 데이터베이스용 관리형 데이터베이스 서비스이다.
SQL은 데이터베이스를 쿼리하는 구조화된 언어로 적합하고, 많은 엔진 실행에 사용된다.
클라우드의 RDS 서비스에 DB를 생성할 수 있고 AWS가 DB를 관리하므로 누릴 수 있는 혜택이 많다.
장점
: 데이터베이스 뿐만 아니라 다양한 서비스를 제공한다.
- 데이터베이스 프로비저닝과 기본 운영체제 패치가 자동화되어 있다.
- 지속적으로 백업이 생성되므로 특정 시점으로 복원할 수 있다.
- 데이터베이스의 성능을 대시보드에서 모니터링할 수 있다.
- 읽기 전용 복제본을 활용해 읽기 성능을 개선할 수 있다.
- 재해 복구 목적으로 다중 AZ를 설정할 수 있다.
- 수직확장, 수평확장이 가능하다.
- 파일 스토리지는 EBS에 구성된다.(gp2, io1)
단점
- RDS 인스턴스에 SSH로 접속할 수 없다.
데이터베이스를 많이 사용하면 공간이 부족해질 수 있다.
RDS 스토리지 오토 스케일링 기능이 활성화되어 있으면 RDS가 이를 감지해서 자동으로 스토리지를 확장
해 준다. 스토리지 용량을 늘리기 위해 DB를 다운시키는 등의 작업을 할 필요가 없다.
애플리케이션이 RDS 데이터베이스에서 읽기와 쓰기 작업을 많이 하면 임곗값에 도달하게 되고 RDS가 자동으로 스토리지를 오토 스케일링한다.
이를 위해 최대 스토리지 임곗값
을 설정해야 한다. 할당된 용량에서 남은 공간이 10% 미만이 되면 스토리지를 자동으로 수정한다.
워크로드를 예측할 수 없는 애플리케이션에서 굉장히 유용하다.
모든 RDS 데이터베이스 엔진에서 지원되는 기능이다.(MariaDB, MySQL PostgreSQL, SQL Server)
: 읽기를 스케일링
한다.
애플리케이션과 RDS 데이터베이스 인스턴스가 있다. 애플리케이션은 데이터베이스 인스턴스에 대해 읽기와 쓰기를 수행한다. 하지만 주된 데이터베이스 인스턴스가 너무 많은 요청을 받아서 충분히 스케일링할 수가 없어서 읽기를 스케일링하고자 한다.
평균적인 로드를 감당하고 있는 생산 데이터베이스가 있다. 생산 데이터베이스에서는 메인 RDS 데이터베이스 인스턴스에 대한 읽기 및 쓰기가 수행된다.
이때 새로운 팀 이 데이터를 기반으로 몇 가지 보고와 분석을 실시하고자 한다고 한다. 보고 애플리케이션을 메인 RDS 데이터베이스 인스턴스에 연결하면 오버로드가 발생하고 생산 애플리케이션의 속도가 느려진다.
➡️ 새로운 워크로드에 대한 읽기 전용 복제본을 생성
한다.
읽기 전용 복제본이 있는 경우에는 SELECT 명령문만 사용할 수 있다.
AWS에서는 하나의 가용 영역에서 다른 가용 영역으로 데이터가 이동할 때에 비용이 발생한다. 하지만 관리형 서비스에서는 예외가 존재한다.
다중 AZ는 주로 재해 복구에 사용
된다.
전체 AZ 또는 네트워크가 손실될 때에 대비한 장애 조치로, 마스터 데이터베이스의 인스턴스 또는 스토리지에 장애가 발생할 때 스탠바이 데이터베이스가 새로운 마스터가 될 수 있도록 한다.
스탠바이 데이터베이스는 단지 대기 목적 하나
만 수행한다. 그 누구도 이를 읽거나 쓸 수 없다.
: 다운타임이 전혀 없는지 확인해야 한다.
즉 단일 AZ에서 다중 AZ로 전환할 때에 데이터베이스를 중지할 필요가 없다.
RDS에서는 기저 운영 체제나 사용자 지정 기능에 액세스할 수 없다.
그러나
RDS Custom에서는 가능하다.
Aurora DB Cluster
아래 그림을 보면, 클라이언트가 있고 세 개의 Aurora 인스턴스가 있다. 하나는 라이터 엔드포인트를 통해 쓰고 있고 나머지 둘은 리더 엔드포인트를 통해 읽고 있다.
그런데,
리더 엔드포인트의 읽기 요청이 매우 많아서 CPU 사용량이 증가하고 있다.
➡️ 복제본 자동 스케일링을 설정하면 된다.
Amazon Aurora 복제본이 추가되고, 새로운 복제본을 처리하기 위해 자동으로 리더 엔드포인트가 연장된다. 새로운 복제본들이 트래픽을 받게 되고 읽기가 좀 더 분산된 형태로 이루어지게 된다.
이번에는 두 종류의 다른 복제본이 있다. 일부 복제본은 다른 복제본보다 크기가 크다.
이렇게 하는 이유는 Aurora 인스턴스의 서브셋을 사용자 지정 엔드포인트로 정의하기 위해서이다.
이 인스턴스들이 더 강력해서 이 특정 복제본에서 분석 쿼리를 실행하는 게 더 낫기 때문
이다.
사용자 지정 엔드포인트가 있으면 리더 엔드포인트는 사용하지 않는다. 사라지는 않지만 더 이상 사용하지 않게 된다.
실제 사용량에 기반한 자동 데이터베이스 인스턴스화와 자동 스케일
을 가능하게 해준다.
라이터 노드에 대한 즉각적 장애 조치로 라이터 노드에 높은 가용성
을 갖추고자 할 때 사용한다.
Aurora 리전 간 복제본은 재해 복구에 많은 도움이 되며 간단하게 생성이 가능하다.
최근에는 Aurora Global 데이터베이스를 만드는 것을 권장하고 있다.
복제 지연이 1초 미만
인 보조 읽기 전용 리전을 다섯 개까지 설정할 수 있고, 각 보조 지역마다 읽기 전용 복제본을 16개까지 생성 가능하다.Aurora는 AWS 내의 머신 러닝 서비스와의 통합을 지원한다.
Automated Backup(자동 백업)
자동으로 매일 데이터베이스가 유지 관리 시간에 데이터베이스 전체를 백업한다.
5분마다 트랜잭션 로그도 백업된다.
자동 백업 보유 기간은 1~35일까지 설정할 수 있다. 이 기능을 비활성화하려면 0으로 설정하면 된다.
Manual DB Snapshots(수동 DB 스냅샷 생성)
사용자가 수동으로 트리거해야 한다.
원하는 만큼 오랫동안 보유할 수 있다.
💡 비용 절감 방법
매달 2시간만 사용할 예정인 RDS 데이터베이스가 있다면, 2시간 사용 후에 스냅샷을 만들고 원본 데이터베이스는 삭제한다. 데이터베이스를 다시 사용할 대가 되면 스냅샷을 복원해서 사용하면 된다.
Automated Backup(자동 백업)
자동으로 매일 데이터베이스가 유지 관리 시간에 데이터베이스 전체를 백업한다.
자동 백업 보유 기간은 1~35일까지 설정할 수 있다. 비활성화 할 수 없다.
Manual DB Snapshots(수동 DB 스냅샷 생성)
사용자가 수동으로 트리거해야 한다.
원하는 만큼 오랫동안 보유할 수 있다.
RDS 및 Aurora 백업 또는 스냅샷을 새로운 데이터베이스로 복원한다.
자동 백업이나 수동 스냅샷을 복원할 때마다 새로운 데이터베이스가 생성된다.
S3로부터 MySQL RDS 데이터베이스를 복원한다.
S3로부터 MySQL Aurora 클러스터를 복원한다.
기존의 데이터베이스로부터 새로운 Aurora DB 클러스터를 만들 수 있다.
프로덕션 데이터베이스에 영향을 주지 않고 개발 또는 테스트를 수행할 수 있다.
매우 빠르고 비용 면에서 효율적이다.
RDS와 동일한 방식으로 관계형 데이터베이스를 관리할 수 있다.
레디스 또는 멤캐시트와 같은 캐시 기술을 관리할 수 있도록 한다.
애플리케이션의 상태를 Amazon 일래스틱 캐시에 저장해 애플리케이션을 무상태로 만들 수 있다.
Redis
레디스(Redis)는 자동 장애 조치로 다중 AZ를 수행하는 기술
읽기 전용 복제본은 읽기 스케일링에 사용되며 가용성이 높다.
백업과 기능 복원 기능도 있다.
Memcached
데이터 분할에 다중 노드를 사용한다.
가용성이 높지 않고 복제도 발생하지 않는다.
지속적인 캐시가 아니다.
백업과 복원 기능도 없다.