[AWS, Certified Developer Associate] Aurora, RDS 프록시, ElastiCache

Aurora

• AWS의 독점 기술 (오픈소스 X)
• Postgre / MySQL과 호환 (드라이버 호환 O)
• 클라우드 최적화, 기능을 통해 RDS에서 MySQL 대비 5배 / Postgre 대비 3배 높은 성능
• 스토리지 자동 스케일링 (10GB up to 128TB)
• 15개 Read Replica 가능 및 복제 속도 빠름 (MySQL은 5개)
  • 리전 간 복제 지원
• 즉각적인 장애 복구 (MySQL의 다중 AZ 장애 조치보다 훨씬 빠름)
  • Master 장애 발생 시 평균 30초 이내 장애조치
• 클라우드 네이티브로 고가용성 제공
• 다른 RDS보다 20% 더 많은 비용 <-> 고효율

 

Aurora의 고가용성 및 읽기 확장성, DB 클러스터

• 데이터에 대해서 3개의 AZ에 6개의 사본이 저장됨
  • 쓰기에 대해서는 6개 중 4개 사본 필요 (하나의 AZ가 다운되어도 문제 X)
  • 읽기에 대해서는 6개 중 3개 사본 필요
  • 데이터 손상 시 자가 복구 프로세스를 통해 백엔드에서 P2P(Peer - to Peer) 복구
• 공유 스토리지는 100개의 Volume에 분산 (직접 관리 X 백엔드에서 이루어짐. 위험 감소)
  • 마스터만이 스토리지에 write
• 기본적으로 1개의 Master
• Writer EndPoint (DNS name)를 가지며, 항상 마스터를 가리킴
  • 클라이언트는 항상 Writer EndPoint를 통해 통신, 인스턴스에 리디렉션
• Reader EndPoint (DNS name)을 가지며, 모든 Read Replica에 로드밸런싱하여 자동으로 연결

 

 

RDS & Aurora 보안

• 미사용 데이터 암호화
  • AWS KMS를 통해 암호화 (DB 처음 실행 시 실행 타임에 정의되어야 함)
  • Master DB가 암호화되지 않은 경우, Read Replica도 암호화되지 않음
  • 암호화 되지 않은 DB를 암호화하기 위해서는 DB의 스냅샷을 가져와 암호화 된 상태로 복원
• 전송 중 암호화 (In-flight)
  • AWS 웹사이트에서 제공하는 AWS의 TLS 루트 인증서 사용
• IAM Role을 통해 username / pw 대신 DB 접근 가능
• 보안 그룹을 사용해 DB 네트워크 액세스 제어 가능
  • 특정 포트, IP, 보안그룹
• RDS, Aurora는 SSH 액세스를 가지고 있지 않음 (관리형 서비스이므로, AWS RDS Custom 제외)
• CloudWatch 로그 서비스를 통해 로그 저장 가능

 

 

RDS Proxy

• RDS Proxy 사용 시 애플리케이션이 DB로 설정된 연결을 풀링, 공유 받을 수 있음
• RDS 인스턴스에 대한 연결이 많은 경우 앞에 Proxy를 두어 CPU, RAM 등 DB 리소스에 대한 스트레스를 줄여 효율성 향상
• open connection, timeout 최소화
  • ex) 수백개로 증가하는 람다 함수를 풀링하여 적은 연결로 DB 인스턴스에 대한 open connection, timeout 최소화
• 완전한 서버리스, 오토스케일링 (용량관리 불필요)
• 다중 AZ로 고가용성
  • RDS 프록시는 장애 발생 시 장애조치를 직접 처리해 장애 조치 시간 최대 66% 감소
• MySQL, Postgre, MariaDB, Aurora에 대해 지원
• 애플리케이션 코드 수정 불필요 (DB 인스턴스 대신 프록시에 연결하면 끝)
• [보안 강화] DB의 IAM 인증 수행 (IAM을 통해서만 DB 접근 가능)
  • 해당 자격증명은 AWS Secrets Manager에 안전하게 저장됨
• VPC에서만 액세스 가능 (인터넷 등 공개적인 액세스 불가능)

 

 

ElastiCache

• Redis, Memcached에 대한 관리형 서비스
• 캐시는 높은 성능과 짧은 대기시간을 가진 인메모리 DB
• 읽기 집약적인 워크로드에 대한 DB 부하를 줄일 수 있도록 함
• App 상태를 ElastiCache에 저장해 App을 Stateless로 만들 수 있음
• AWS는 OS 관리 / 패칭, 최적화, 셋업, 구성, 모니터링, 장애복구, 백업 지원
• DB 쿼리 전후 애플리케이션 변경을 통한 캐시 쿼리를 해야하므로 애플리케이션 코드 변경이 많이 요구됨
• 아키텍처 1) ElastiCache에서 Cache Hit 시 바로 데이터 반환 / Miss 시 RDS에서 데이터 반환
  • RDS 부하 감소
  • 최신 데이터를 위한 캐시 무효화 전략이 필요
• 아키텍처 2) ElastiCache에서 사용자 세션 저장을 통한 애플리케이션 무상태 유지
  • 어떤 인스턴스에서 접근하든 ElastiCache에서 사용자 세션을 얻어옴

 

Redis vs Memcached

• Redis (고가용성, 백업, 데이터 내구성, 캐시기능)
  • Multi AZ를 통한 자동 장애복구 지원
  • Read Replica 스케일링을 통한 고가용성 지원
  • AOF 지속성을 통한 데이터 내구성
    • Append Only File
    • 데이터 변경에 대한 커맨드를 AOF 파일에 기록하고 해당 파일을 기반으로 복원
  • 백업, 복원 기능 존재
  • Set, Sorted Set 타입 지원
• Memcached (분산된 순수 캐시, 데이터 손실 가능성 있음)
  • 데이터 파티셔닝에 다중 노드 사용 (샤딩)
  • 복제 X (고가용성 X)
  • 지속적인 캐시 X
  • 백업, 복원 기능 X
  • 멀티 스레드 아키텍처로, 샤딩을 통한 여러 인스턴스 보유

 

 

ElastiCache 캐시 전략

• Lazy Loading / Cache-Aside / Lazy Population (구현 쉬움, 많은 상황에서 기본적으로 사용, 읽기성능 개선)
  
  • 캐시 히트 시 ElastiCache에서 데이터 바로 반환
  • 캐시 미스 시 DB에서 데이터 반환 / 애플리케이션은 데이터를 ElastiCache에 Write
  • 장점
    • 오직 요청된 데이터만 캐싱
    • 캐싱 실패, 노드 실패 시 치명적이지 않음 (캐시에 write 하기 위한 예열시간만 존재)
  • 단점
    • [읽기 페널티] 캐시 미스 시 3번의 네트워크 호출 (RDS Read, DB Read, 캐시 Write)
    • 데이터가 RDS에서 업데이트 되어도 ElastiCache에는 오래된 데이터 존재할 수 있음
• Write Through (구현 어려움, 레이지 로딩의 단점을 보완한 것이므로 첫번째 우선순위로는 X, 오래된 캐시 개선을 위함)
  • DB가 업데이트 될 때 캐시도 함께 업데이트
  • 장점
    • 오래된 데이터가 존재할 수 없음
    • [쓰기 페널티] 캐시 미스 시 2번의 네트워크 호출 (RDS, 캐시 Write) (vs 읽기 페널티 3번 호출)
  • 단점
    • RDS에 쓰기 전까지 데이터 누락될 수 있음 (Lazy Loading과 결합 가능, Cache에 데이터 없을 시 RDS에서 Lazy Loading)
    • 캐시 이탈률 - RDS에 많은 데이터가 쓰일 때 캐시에도 같이 쓰이지만 캐시에서 읽히지 않을 가능성 (캐시가 작을 경우 문제)
• Cache Evictions and Time-to-Live (TTL)
  • 제한된 캐시 크기를 위해 캐시를 제거하기 위한 전략 Cache Evictions
  • 최근에 사용되지 않은 항목 제거 (LRU, Least Recently Used)
  • 또는 TTL 설정하여 제거 (리더보드, 코멘트, 활동 스트림 등에 유용)
  • TTL은 초, 시간, 일 단위로 가능
  • 너무 많이 제거된다면 캐시 크기 늘리는 것을 고려
• 캐싱은 자주 변하는 데이터에 적합하지 않음

 

---

Reference

Udemy - AWS Certified Developer Associate 시험 합격을 위한 모든 것!