RDS + Aurora + ElastiCache

Amazon RDS

• Relational Database Service
• SQL을 쿼리 언어로 사용하는 관리형 데이터베이스 서비스
• SSH로 접근은 불가능 하다
  • Postgres
  • MySQL
  • MariaDB
  • Oracle
  • Microsoft SQL Server
  • Aurora

RDS를 사용하는 이유

• 관리형 서비스
• 데이터베이스 프로비저닝이나 이런 것들이 자동화 되어있음
• 지속적으로 백업이 생성
• 복원 가능
• 모니터링 가능
• 읽기 전용 복제본을 활용해 읽기 성능을 향상
• 다중 AZ 설정 가능
• Scaling 가능

RDS - Storage Auto Scaling

• RDS가 용량을 감지해서 scaling을 진행
• 임곗값을 기준으로 실행
• 데이터베이스를 수동으로 확장하는 것을 방지
• 남은 공간이 10%미만인 경우, 스토리지 부족 상태가 5분이상, 지난 수정으로부터 6시간이 지났을 때 자동으로 실행
• 워크로드를 예측할 수 없는 경우 사용하면 좋다

RDS 읽기 전용 복제본

• 최대 15개까지 생성 가능
• 비동기식 복제
  • 비동기는 동시에 일어나지 않는다는 의미
  • 요청한 결과는 동시에 일어나지 않는다
• 복제본을 데이터베이스로 사용할 수 도 있다
• 다른 AZ에 있는 데이터를 읽어 들이는 경우 보통 비용이 발생하지만 AWS에서는 관리형 서비스에 한해서는 비용이 들지 않는다 (같은 리전이여야 함)

RDS 읽기 전용 복제본 사용 사례

• 평균적인 로드를 감당하고 있는 생상 데이터베이스인 경우 만약 데이터베이스를 보고 보고서를 작성해야 하는 경우
  • 복제본을 만들어 읽기 전용으로 만들어 준다
• 생산 어플리케이션은 영향을 받지 않는다

RDS Multi AZ (Disaster Recovery)

• 재해 복구에 사용
• 동기식으로 다른 AZ에 복제 (DB를 중지할 필요가 없음)
  • 동기식은 요청을 하면 얼마나 걸리던지 요청한 자리에서 결과가 주어져야 한다
• 하나의 DNS 이름을 가짐
• 스탠바이 DB가 마스터 DB에 문제가 생길 경우 사용될 수 있다
• 스탠바이 DB는 단순히 스탠바이를 위해 대기 한다

RDS Custom

• OS 및 데이터베이스 사용자 지정 기능에 액세스할 수 있다
  • 내부 설정 구성
  • 패치 적용
  • 네이티브 기능 활성화
  • SSH
  • SSM Session Manager
• RDS에서는 기저 운영 체제나 사용자 지정 기능에 액세스할 수 없지만 RDS Custom에서는 가능하다
• RDS Custom에서는 두가지 데이터베이스를 다룬다
  • Oracle
  • Microsoft SQL Server

RDS vs RDS Custom

• RDS : 데이터베이스 전체를 관리하며 OS와 나머지는 AWS에서 관리
• RDS Custom : Oracle과 Microsoft SQL Server에서만 사용 가능하며 기저 운영 체제와 데이터베이스에 대한 관리자 권한을 가진다

Amazon Aurora

• AWS의 고유 기술
• Postgres와 MySQL 데이터베이스에 연결하면 작동한다
• 클라우드에 최적화되어 있으며 최적화를 통해 성능을 높였다
• 자동으로 확장한다 (10GB up to 128 TB)
• 저장 디스크를 신경 쓰지 않아도 된다
• 읽기 전용 복제본의 경우 15개 까지 가능하며 복제 속도도 빠르다
• 클라우드 네이티브이므로 가용성이 높다
• 마스터는 하나이고 복제본은 여럿이며 스토리지가 복제된다

Aurora High Availability and Read Scaling

• 기록을 할 때마다 6개의 사본을 3개의 AZ에 저장한다
• 6개의 복사본중 4개에서 쓰기가 가능하며 읽기는 3개만 있어도 된다
• 일부 데이터가 손상되거나 문제가 있으면 백엔드에서 P2P 복제가 진행된다
• 마스터 데이터베이스가 작동하지않으면 평균 30초 이내로 장애 조치가 시작된다

Aurora DB Cluster

• 스토리지에 쓰는 것은 마스터만 가능하다
• Writer Endpoint
  • DNS 이름으로 항상 마스터를 가리킨다
• 항상 적절한 수의 읽기 전용 복제본을 둔다
• Reader Endpoint
  • 모든 읽기 전용 복제본의 로드 밸런싱

Aurora의 특징

• 자동 장애 조치
• 백업 및 복구
• 격리 및 보안
• 산업 규정 준수
• 자동 스케일링을 통한 버튼식 스케일링
• 제로 다운타임 자동 패치 설치
• 고급 모니터링
• 통상 유지 관리
• Backtrack
  • 과거 어느 특정 시점으로 복구 가능

Aurora Replicas - Auto Scaling

Aurora Replicas - Custom Endpoints

• 크기가 큰 Custom Endpoint에서 분석 쿼리를 실행하는 것이 더 좋을 수 있기 때문
• 일반적으로 Custom Endpoint를 정의하면 Reader Endpoint를 사용하지 않는다

Aurora Serverless

• 실제 사용량에 기반한 자동 데이터베이스 인스턴스화와 자동 스케일을 가능하게 한다
• 비정기적, 예측 불허한 워크로드에 유용하다
• 용량을 정할 필요가 없다

Aurora Multi - Master

• Writer node에 대한 즉각적 장애 조치로 높은 가용성을 가진다
• 이 경우 Aurora 클러스터의 모든 노드에서 읽기 및 쓰기가 가능하다

Global Aurora

• 모든 쓰기 및 읽기가 진행되는 하나의 기본 리전이 존재
• 복제 지연이 1초 미만인 보조 읽기 전용 리전을 다섯 개까지 설정할 수 있고 각 보조 지역마다 읽기 전용 복제본을 16개까지 생성 가능하다
• 리전에 걸쳐 데이터를 복제하는데 걸리는 시간은 평균 1초 미만이다

Aurora Machine Learning

• AWS 내의 머신 러닝 서비스와의 통합을 지원
• ML 기반 예측을 SQL 인터페이스로 애플리케이션에 적용하는 것
• 지원하는 서비스는 두가지이다
  • Amazon SageMaker
    • 백엔드에서 어떤 머신 러닝 모델이라도 사용할 수 있게 해준다
  • Amazon Comprehend
    • Sentiment analysis

RDS Backups

• Automated backups
  • RDS가 매일 데이터베이스 유지 관리 시간에 데이터베이스 전체를 백업
  • 5분마다 트랜젝션 로그도 백업된다
  • 5분 전 어떤 시점이라도 복구 가능하다
  • 1일 35일 사이 정해진 기간이 지나면 사라진다
  • 0일로 설정시 비활성화
• Manual DB Snapshots
  • 사용자가 수동으로 트리거해야 한다
  • 원하는 기간동안 보유할 수 있다는 장점이 있다

기본적으로 비용을 아끼려면 데이터베이스 스냅샷을 이용해서 사용하는 날 스냅샷을 이용해 데이터베이스를 복구 하는 것이 비용을 아낄 수 있다

Aurora Backups

• Automated backups
  • 정해진 시간 범위 내의 어느 시점으로도 복구가 가능하다
  • 1일 35일 사이 정해진 기간이 지나면 사라진다
  • 비활성화는 불가능하다
• Manual DB Snapshots
  • 사용자가 수동으로 트리거해야 한다
  • 원하는 기간동안 보유할 수 있다는 장점이 있다

RDS & Aurora Restore options

• RDS, Aurora 백업 또는 스냅샷을 통해 새로운 데이터베이스로 복원 가능하다
• S3를 통해서 복구가 가능하다
  • S3는 AWS 클라우드에 객체를 저장하는 서비스
  • RDS MySQL을 복구 하려면 데이터베이스 백업만 있으면 된다
  • Aurora MySQL로 북구 하려면 Percona XtraBackup을 사용해서 백업한 다음 S3로부터 Aurora DB 클러스터로 복원해야 한다

Aurora Database Cloning

• 기존의 데이터베이스로부터 새로운 데이터베이스를 만들어낸다
• 개발 또는 테스트가 가능하다
• 스냅샷보다 빠를 수 있다
• 시간의 흐름에 따라 새 데이터베이스로 사용할 수 도 있다
• 프로덕션 데이터베이스를 복제해 사용하므로 프로덕션 데이터베이스엔 영향을 주지 않는다

RDS & Aurora Security

• 저장된 데이터를 암호화 할 수 있다
• KMS를 사용해 모든 마스터와 복제본에 암호화가 가능하다
• 마스터 주 데이터베이스에 암호화를 하지 않으면 읽기 전용 데이터베이스도 암호화 할 수 없다
• 뒤 늦은 암호화는 불가능 하므로 스냅샷 생성 및 복원 과정을 거쳐서 암호화 설정을 해야 한다
• In - flight encryption
• IAM Authentication : 데이터베이스 접속 시
• Security Groups : 특정 포드, IP 차단 가능
• NO SSH
• Audit Logs (감시 로그) : 시간에 따라 RDS 및 Aurora 에서 어떤 쿼리가 생성되고 있고 데이터베이스를 확인 할 수 있다 (장기간 보관 하기 위해선 CloudWatch를 사용해야 한다)

RDS Proxy

• 완전 관리형 RDS 데이터베이스 프록시도 배포할 수 있다
• 애플리케이션이 데이터베이스 내에서 데이터베이스 연결 풀을 형성하고 공유 할 수 있다
• RDS 데이터베이스 인스턴스에 연결을 줄여 준다
  • CPU, RAM등 사용을 줄여 준다
• RDS 프록시는 완전한 서버리스로 오토 스케일링이 가능해 용량을 관리할 필요가 없고 가용성이 높으며 다중 AZ도 지원한다
• RDS 프록시가 장애 조치가 발생한 RDS 데이터베이스 인스턴스를 처리하므로 장애 조치 시간이 개선된다
• IAM 인증을 통해서만 RDS에 접근 할 수 있게 한다
• RDS 프록시는 퍼블릭 액세스가 불가능 하므로 보안이 좋다

Cache

• 높은 성능과 낮은 지연시간을 가진 인메모리 데이터베이스

ElastiCache Overview

• Redis, Memcached와 같은 캐시 기술을 관리 할 수 있도록 한다
• 읽기 집약적인 워크로드의 부하를 줄이는데 도움이 된다
• Cache hit
  • 쿼리가 이미 생성됐는지 이미 생성되어 ElastiCache에 저장됐는지 확인
• Cache miss
  • ElastiCache에 존재하지 않으므로 데이터베이스에서 데이터를 가져온다
• User Session Store
  • 사용자가 애플리케이션의 모든 계정에 로그인하면 애플리케이션이 ElastiCache에 Session data를 기록
  • 사용자가 애플리케이션의 다른 인스턴스로 리다이렉션이 되면 애플리케이션은 ElastiCache에서 직접 Session Cache를 검색할 수 있다

ElastiCache - Redis vs Memcached

• Redis
  • 고가용성과 백업 읽기 전용 복제본
  • 자동 장애 조치로 다중 AZ를 수행하는 기술
  • 읽기 전용 복제본은 읽기 스케일링에 사용되며 가용성이 높다
  • 지속성으로 인해 데이터 내구성이 있음
  • 백업과 기능 복원 기능도 있음
• Memcached
  • 데이터를 손실할 수 없는 단순한 분산 캐시
  • 데이터 분할에 다중 노드를 사용 (Sharding)
  • 가용성이 높지 않다
  • 복제도 발생하지 않는다
  • 지속적인 캐시가 아니다
  • 백업과 복원 기능도 없다

ElastiCache - Cache Security

• ElastiCache의 모든 캐시는 IAM 인증을 지원하지 않는다
• ElastiCache에서 정의할 IAM 정책은 AWS API 수준 보안에만 사용된다
  • 캐시 생성, 캐시 삭제
• 그러나 캐시 내의 모든 작업은 IAM을 사용하지 않는다
• Redis AUTH
  • Redis AUTH를 사용하여 레디스 클러스터를 생성할 때 비밀번호나 토큰을 설정 할 수 있다 (캐시에 들어갈 때 비밀번호를 사용)
  • 전송 중 암호화를 위해 SSL 보안을 지원할 수 있다
• Memcached
  • 좀 더 높은 수준인 SASL 기반 인증을 지원한다

ElastiCache에서 데이터를 불러오는 세가지 패턴

• Lazy Loading
  • 모든 읽기 데이터가 캐시되고 데이터가 캐시에서 부실해질 수 있다
• Write Through
  • 데이터를 오래된 데이터가 없는 데이터베이스에 기록될 때마다 캐시에 데이터를 추가하거나 업데이트
• Session Store
  • Time to live 속성으로 세션을 만료시킬 수 있다