RDS / Aurora / ElastiCache

RDS

• Relational Database Service

• Postgres, MySQL, MariaDB, Oracle, Microsoft SQL Server, IBM DB2, Aurora (AWS Proprietary database) 를 제공한다.

• DB의 기능 뿐만 아니라 자동화된 데이터베이스 프로비저닝, 자동화된 운영체제 패치 등을 제공한다.

• Point in Time Restore를 통해 지속적으로 백업이 이루어져 특정 시점으로 복원할 수 있다.

• 데이터베이스 성능을 모니터링할 수 있는 대시보드를 제공한다.

• Read Replicas 기능을 사용할 수 있다.

• 가용성을 높이고 재해 복구에 유용하도록 Multi-AZ를 구성할 수 있다.

• 업그레이드를 위한 Maintenance Windows를 제공한다.

• 인스턴스 타입을 변경해 수직 확장하거나 인스턴스 수를 늘려 수평 확장할 수 있다.

• EBS 기반으로 구현되어 있다.

• Managed Service이므로 Underlying EC2 인스턴스에는 SSH로 접근할 수 없다.

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 함수에 대한 연결을 풀링해야 한다.

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 간 복제를 지원한다.

• 자가 복구와 자동 확장이 작은 블록마다 차례로 이뤄진다.

• DNS이름을 가진 Writer Endpoint를 제공하여 마스터가 변경되고 장애가 발생하면 다른 인스턴스에 자동 리다이렉트 되도록 한다.

• 읽기 전용 복제본을 오토 스케일링할 수 있다.

  • 1-15개의 복제본을 가질 수 있으며, 오토 스케일링을 설정해서 적절한 개수의 읽기 전용 복제본을 가질 수 있다.

  • 하지만, 이로 인해 애플리케이션이 복제본에 어떻게 연결하는지를 알 수 없으므로 Reader Endpoint를 지원한다.

• Reader Endpoint를 통해 모든 읽기 전용 복제본들에 자동으로 연결하고, 연결 로드밸런싱을 지원한다. 즉, 트래픽을 분산하는 것이 아니라 연결을 분산시켜주는 것이다.

보안

• 미사용 데이터 암호화

  • KMS를 사용하여 마스터와 복제본을 암호화해야 한다. (데이터베이스를 처음 실행할 때 정의되어야 한다)

  • 마스터 데이터베이스를 암호화하지 못한 경우, 읽기 전용 복제본이 암호화될 수 없다.

  • 암호화되지 않은 기존 데이터베이스를 암호화하려면 암호화되지 않은 데이터베이스의 스냅샷을 가져온 후, 해당 데이터베이스 스냅샷을 암호화된 데이터베이스로 복원하면 된다.

• 전송 중 암호화

  • 클라이언트와 데이터베이스 간의 암호화

  • AWS의 TLS 루트 인증서를 사용해야 한다.

• IAM 역할을 통한 데이터베이스 연결

  • 만약 EC2 인스턴스에 IAM 역할이 있는 경우, IAM 역할을 직접 사용하여 데이터베이스에 인증할 수 있다. 따라서 IAM의 AWS 내에서 모든 보안을 관리할 수 있다.

• 보안 그룹을 통한 네트워크 액세스 제어

  • 특정 포트나 IPS, 보안 그룹을 허용하거나 차단할 수 있다.

• RDS Custom 서비스를 사용하지 않는다면 SSH 접근이 불가능하다.

• RDS와 Aurora에서 만들어지는 쿼리와 데이터베이스 로깅을 위해 감사 로그를 활성화할 수 있다. 오랜 기간 동안 보관하고 싶다면 AWS의 CloudWatch 로그 서비스를 사용해야 한다.

ElastiCache

• Redis

  • Multi AZ 간 자동 failover를 지원한다.

  • 읽기 복제본을 생성하여 읽기 작업을 확장하고 높은 가용성을 제공한다.

  • AOF 지속성을 사용하여 데이터 내구성을 제공한다.

  • 백업 및 복원 기능을 제공한다.

• Memcached

  • 샤딩을 통해 여러 노드에 데이터를 파티셔닝한다.

  • 복제를 지원하지 않으므로 고가용성이 지원되지 않는다.

  • Memcached의 서버리스 버전에는 백업 및 복원 기능이 있다.

  • 멀티 스레드 아키텍처로 동작한다.

캐싱 전략

• 캐싱 대상 데이터

  • 자주 바뀌지 않아야 한다.

  • 데이터 구조가 캐싱에 적합해야 한다.

  • 쿼리하기 쉬운 데이터여야 한다.

• 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테라바이트 이상에 이르기까지 원활하게 크기를 조정할 수 있다.