[AWS] RDS & Aurora & ElastiCache

RDS : 관계형 데이터베이스

AWS에서 관리되는 클라우드 상의 데이터베이스를 생성할 수 있도록 도와줌

종류 : PostgreSQL, MySQL, MariaDB, Oracle, Aurora 등

 

(+) 자동 프로비저닝 및 OS 패치 → AWS가 적절한 EC2 인스턴스를 준비하고 OS를 설치하고 선택한 DB 엔진 설치 등의 과정을 해

(+) 지속적인 백업과 특정 시점 복구

(+) 모니터링 대시보드

(+) 읽기 성능 향상을 위한 읽기 전용 복제본

(+) 다중 AZ 설정으로 재해 복구 가능

(+) 수직, 수평 확장 가능

 

(-) RDS는 관리형 서비스이기에 SSH 접근 불가

 

 

1) RDS - Storage Auto Scaling

• 데이터베이스 사용량 증가 시 RDS 스토리지를 자동으로 확장할 수 있음
• 예측 불가능한 워크로드를 가진 애플리케이션에 유용
• 최대 스토리지의 임계값을 설정해놓음
  • 여유 공간이 할당된 스토리지의 10% 미만이 되면 확장
  • 스토리지 부족 상태가 5분 이상 지속 시 확장
  • 마지막 수정 이후 6시간이 지난 경우 확장

 

2) Read Replicas(읽기 전용 복제본)

• 읽기 성능 향상을 위해 최대 15개의 Read Replicas 생성 가능
• 동일 AZ, 다른 AZ, 다른 리전에 생성 가능
• 비동기 방식으로 진행 → 읽기가 일관적으로 유지됨
• 복제본은 자체 데이터베이스로 승격 가능
• SELECT 명령문만 사용
• 같은 리전 내에 다른 AZ간 이동은 무료지만 다른 리전으로 이동 시 비용 발생
• ex) 분석 어플리케이션이 prod 데이터베이스에 부하를 주고 있다면, Read Replica를 생성해 분석 작업을 복제본에서 수행

 

3) Multi AZ(재해복구용)

• 높은 가용성을 위한 설정
• 다른 AZ에 동기로 복제
• 하나의 DNS 이름 사용 → 자동 장애 조치
• 읽기 전용 복제본은 재해 복구를 위해 다중 AZ로 설정될 수도 있음

 

4) Single AZ → Multi AZ

• 다운타임 없는 운영
• 데이터베이스에 대해 ‘수정’을 클릭하고 활성화시키기만 하면 됨
• 내부적으로는 다음과 같이 수행됨
  1. 기본 DB의 RDS가 자동으로 스냅샷 생성
  2. 새 AZ에 새 DB 복원
  3. 두 DB간 동기화 설정

 

5) RDS Proxy

• 애플리케이션이 데이터베이스 내에서 데이터베이스 연결 풀을 형성하고 공유할 수 있음
• 프록시가 하나의 풀에 연결을 모아 RDS DB 인스턴스로 연결
• DB 리소스에 가해지는 부하를 줄이고, DB에 개방된 연결과 타임아웃을 최소화하여 DB 효율성 향상
• DB에 대한 IAM 인증을 강제함으로 IAM 인증을 통해서만 RDS DB 인스턴스에 연결할 수 있음
• RDS 프록시는 퍼블릭 액세스 절대 불가능(VPC에서만 접근 가능)
• RDS와 Aurora의 장애 조치 시간을 66%까지 줄일 수 있음

---

Aurora

Aurora는 AWS의 고유 기술로 오픈 소스는 아님

1) 특징

• MySQL 대비 5배 성능 향상, PostgreSQL 대비 3배 성능 향상
• 스토리지가 10GB에서 시작해 128TB까지 자동 증가
• 최대 15개의 Read Replica
• 즉각적 장애 조치(Multi AZ보다 빠름)
• 비용은 RDS보다 20% 비싸지만 효율성이 뛰어남

 

2) High Availability

• 3개의 AZ에 걸쳐 6개의 데이터 복사본 유지
• 쓰기에는 6개의 사본 중 4개만 있으면 됨(AZ 하나가 작동하지 않아도 괜찮음)
• 읽기에는 6개의 사본 중 3개만 있으면 됨
• 자가 복구 기능 : 손상된 데이터를 peer-to-peer 복제로 복구
• 마스터 외에 읽기를 제공하는 읽기 전용 복제본을 15개까지 둘 수 있음

-> 마스터는 하나, 복제본은 여러 개, 스토리지 복제, 작은 블록 단위로 자가 복구 또는 확장이 일어남

 

 

Writer Endpoint

• 항상 마스터를 가리킴
• 장애 조치 시 자동으로 새 마스터를 가리킴

Reader Endpoint

• 모든 Read Replica에 대한 연결 로드 밸런싱
• Read Replica가 추가되면 자동으로 연결됨

 

3) Aurora 주요 기능

Aurora Custom Endpoints

• 일부 오로라 인스턴스를 사용자 지정 엔드포인트로 정의할 수 있음
• ex) 특정 복사본에서 분석 쿼리 실행
• 사용자 지정 엔드포인트 정의 후에는 일반적으로 Reader 엔드포인트는 사용되지 않음

Aurora Serverless

• 실제 사용량에 기반해 자동으로 데이터베이스 인스턴스화 및 자동 스케일링이 이루어짐
• 비정기적, 간헐적이고 예측 불가능한 워크로드에 적합
• 용량 계획이 필요하지 않음
• 초 단위 과금로 더 경제적일 수 있음

Aurora Mult-Master

• 쓰기 노드의 즉각적 장애 조치(페일오버)가 필요한 경우
• Auroa 클러스터의 모든 노드에서 읽기 및 쓰기 수행

Global Database

• 1개의 Primary Region → 읽기/쓰기
• 최대 5개의 Secondar Region → 읽기 전용, 복제 지연 1초 미만
• 각 보조 리전당 최대 16개의 읽기 전용 복사본 생성 가능
• 지연 시간을 줄이는 데 도움됨
• 리전에 걸쳐 데이터 복제 시 걸리는 시간은 평균 1초 미만

Aurora Machine Learning

• ML 기반 예측을 SQL 인터페이스로 애플리케이션에 적용하는 것
• ex) 사기 탐지, 광고 타게팅, 감정 분석, 제품 추천 등

 

4) Aurora Database Cloning

• 기존 데이터베이스로부터 새로운 Aurora DB 클러스터를 생성하는 것
• 스냅샷 및 복원보다 빠름
• Copy-on-Write 작동 방식 : 클론이 원본과 동일한 데이터 블록을 공유하며, 실제로 데이터를 복사하지 않는다. 원본에서 데이터가 변경되면 변경된 블록만 새로 생성한다.
• 프로덕션 데이터베이스에 영향을 주지 않고 스테이징 데이터베이스를 생성하는데 유용함

---

Backups

1. RDS Backups

자동 백업

• 매일 자동으로 데이터베이스 유지 관리 시간에 데이터베이스 전체 백업
• 매 5분마다 트랜잭션 로그 백업
• 자동 백업 보유 기간은 1~35일 지정 가능(비활성화 가능)

수동 백업

• 사용자가 수동으로 트리거해야 함
• 원하는 기간 동안 백업 보존

→ 중지된 RDS 데이터베이스에서도 여전히 스토리지 비용이 발생하므로 오랜 기간 중지할 계획이 있다면 스냅샷을 생성하고 원본 DB는 삭제한 뒤 DB가 필요할 때 스냅샷을 복원하는 것이 좋다.

 

2. Aurora Backups

자동 백업

• 1~ 35일(비활성화 불가능)
• 지정시간 복구 기능 : 정해진 시간 범위 내의 어느 시점으로도 복구 가능

수동 백업

• 사용자가 수동으로 트리거해야 함
• 원하는 기간 동안 백업 보유 가능

---

RDS & Aurora Security

1. At-Rest Encryption : 저장 데이터 암호화

• AWS KMS를 사용해 DB 마스터 및 복제본 암호화 - DB 처음 실행 시 정의됨
• 마스터가 암호화되지 않은 경우 읽기 복제본을 암호화할 수 없음
• 암호화되지 않은 기존 DB를 암호화하려면 DB 스냅샷을 통해 암호화된 DB를 생성해 전환해야 함

2. In-Flight Encryption : 전송 중 암호화

• TLS/SSL 사용
• 클라이언트와 DB 간 통신 암호화

3. IAM

• 사용자 이름/암호 대신 IAM Role을 사용해 DB 연결 가능
• 비밀번호를 애플리케이션에 하드코딩하지 않을 수 있음

---

ElastiCache

• 관리형 인메모리 데이터베이스 서비스로 RDS와 동일한 방식으로 관계형 데이터베이스를 관리할 수 있음
• Redis 또는 Memcached와 같은 캐시 기술을 관리할 수 있도록 함
• 일반 RDS는 디스크에 데이터를 저장하지만 ElastiCache는 메모리에 저장
• 애플리케이션을 stateless로 만드는데 도움이 됨
• ex) 세션 저장소로도 사용 가능 → 사용자가 애플리케이션의 다른 인스턴스로 리디렉션 되면 애플리케이션은 ElastiCache에서 직접 세션 캐시를 검색하고 사용자는 계속 로그인할 상태로 유지
• 애플리케이션 코드 변경이 많이 필요

(+) 데이터베이스 부하 감소

(+) 응답 속도가 훨씬 빠름

(+) 비용 절감 : RDS IOPS 감소

 

ElastiCache 패턴

ElastiCache를 어떤 방식으로 사용할 것인가에 대한 전략

→ 언제 캐시에 데이터를 넣을 것인가? 언제 캐시를 업데이트 할 것인가?

 

Lazy Loading

• 모든 읽기 데이터를 캐시에 저장
• 실제 사용되는 데이터만 캐시됨
• 캐시 데이터가 오래된 상태가 될 수 있음
• 첫번째 요청을 느림

Write Through

• 데이터를 데이터베이스에 쓸 때 캐시에도 데이터를 추가하거나 업데이트
• 캐시 데이터에 오래된 데이터가 없음

Sessionn Store

• 임시 세션 데이터를 캐시에 저장
• TTL(Time To Live : TTL이 3600초일 경우 시간 지나면 자동 삭제)로 자동 만료

---

Redis vs Memcached

Redis

• 자동 장애 조치를 위한 Multi AZ
• 읽기 스케일링에 사용되며 가용성이 높은 읽기 전용 복제본
• 백업 및 복원 기능

Memcached

• 데이터 파티셔닝을 위한 다중 노드 사용
• 가용성이 높지 않고 복제도 발생하지 않음
• 지속적 캐시가 아님
• 백업 및 복원 기능이 없음

---

Cache Security

• ElastiCache : IAM 인증을 지원하지 않음 → IAM 정책으로 ElastiCache 클러스터 생성, 삭제, 수정 권한만 제어
• Redis AUTH : Redis 클러스터 생성 시 비밀번호나 토큰을 생성할 수 있음 → 캐시에 사용할 수 있는 보안 그룹에 대한 추가적인 수준의 보안
• Memcached : 좀 더 높은 수준인 SASL 기반 인증 지원

 

 

 

 

 

출처 : https://velog.io/@gagaeun/AWS-RDS-Aurora-ElasticCache