AWS Certified Developer Associate 자격증 준비 - RDS, Aurora, & ElasticCache편

1. RDS

• RDS: 관계형 데이터베이스 서비스(Relational Database Service)의 약자.
• SQL을 쿼리 언어로 사용하는 데이터베이스용 관리형 데이터베이스 서비스.
• AWS에서 관리되는 클라우드 상의 데이터베이스를 생성할 수 있도록 해줌.
  • Postgres
  • MySQL
  • MariaDB
  • Oracle
  • Microsoft SQL Server
  • Aurora (AWS Proprietary database)

Advantage over using RDS versus deploying DB on EC2

• RDS는 관리형 서비스이며, AWS는 데이터베이스 뿐만 아니라 다양한 서비스를 제공함.
  • 프로비저닝, 기본 운영체제 패치 자동화
  • 지속적인 백업과 특정 타임스탬프로의 복원 (특정 시점 복원)
  • 모니터링 대시보드
  • 읽기 성능 향상을 위한 읽기 전용 복제본
  • 재해 복구를 위한 다중 AZ 설정
  • 유지 관리 기간에 업그레이드 가능
  • 수직 및 수평 스케일링 기능
  • EBS(gp2 또는 io1)로 지원되는 스토리지
• 한 가지 단점은, RDS 인스턴스에 SSH로 접속할 수 없음.

RDS – Storage Auto Scaling

• Helps you increase storage on your RDS DB instance dynamically
• 데이터베이스 스토리지가 부족해지고, RDS 스토리지 Auto Scaling 기능이 활성화되어 있으면 RDS가 이를 감지하여 자동으로 스토리지를 확장해 줌.
• 데이터베이스 스토리지를 수동으로 스케일링하는 작업을 피할 수 있음.
• 최대 스토리지 임계값(스토리지의 최대 제한)을 설정해야 함.
• 다음의 경우에 자동으로 스토리지를 수정함.
  • 스토리지의 남은 공간이 10% 미만인 경우
  • 스토리지 부족 상태가 5분 이상 지속
  • 마지막 수정 이후 6시간이 지난 경우
• 워크로드를 예측할 수 없는 애플리케이션에서 유용함.
• 모든 RDS 데이터베이스 엔진 (MariaDB, MySQL, PostgreSQL, SQL Server, Oracle)을 지원.

RDS Read Replicas for read scalability

• 읽기 전용 복제본을 최대 15개까지 생성 가능.
• 동일한 가용 영역 또는 가용 영역이나 리전을 걸쳐 생성 가능.
• 복제는 비동기 방식으로 진행됨. 즉, 읽기가 일관적으로 유지됨.
• 복제본은 자체 데이터베이스로 승격될 수 있음.
• 읽기 전용 복제본을 사용하려는 경우에는 주요 애플리케이션은 모든 연결을 업데이트 해야하며 이를 통해 RDS 클러스터 상의 읽기 전용 복제본 전체 목록을 활용할 수 있음.

RDS Read Replicas – Use Case

정상적인 작업 부하를 처리하는 프로덕션 데이터베이스가 있다고 가정. 데이터를 기반으로 몇 가지 보고와 분석을 실시하고자 함. 새로운 작업 부하를 처리하기 위해 읽기 전용 복제본을 생성.

읽기 전용 복제본은 SELECT(=읽기) 명령문에만 사용. (INSERT, UPDATE, DELETE는 제외)

RDS Read Replicas – Network Cost

AWS에서는 데이터가 한 AZ에서 다른 AZ로 이동할 때 네트워크 비용이 발생한다. 하지만, 동일한 리전 내에서의 RDS 읽기 전용 복제본에 대해서는 해당 비용을 지불하지 않는다.

RDS Multi AZ (Disaster Recovery)

• 동기식 복제
• 하나의 DNS 이름 - automatic app failover to stanby
• 가용성 향상
• AZ 손실, 네트워크 손실, 인스턴스 또는 스토리지 장애 발생 시 페일오버 - 스탠바이 데이터베이스가 새로운 마스터가 될 수 있도록 함.
• 애플리케이션에 수동으로 조치를 취할 필요가 없음.
• 스케일링에는 사용되지 않음.
  참고: 읽기 전용 복제본은 재해 복구(DR)을 위해 다중 AZ로 설정될 수 있음.

RDS – From Single-AZ to Multi-AZ

• 다운타임이 없는 운영 (DB를 중지할 필요 없음)
• 데이터베이스에 대해 "수정"을 클릭하고 활성화시키기만 하면 됨.
• 내부적으로는 다음이 수행됨.
  • 기본 데이터베이스의 RDS가 자동으로 스냅샷 생성
  • 이 스냅샷에서 새로운 DB가 새로운 가용 영역에 복원됨
  • 두 개의 데이터베이스 간에 동기화가 설정

Amazon Aurora

• Aurora는 AWS 고유 기술로 오픈 소스는 아님.
• Postgres와 MySQL이 호환됨.
• Aurora는 "AWS 클라우드 최적화"되었으며, RDS의 MySQL에 비해 5배 높은 성능이고, RDS의 - Postgres에 비해 3배 높은 성능.
• Aurora 스토리지는 자동으로 10GB 단위로 증가하며, 최대 128TB까지 확장할 수 있음.
• Aurora는 최대 15개의 복제본을 가질 수 있으며, 복제 과정은 MySQL보다 빠름 (10ms 미만의 복제 지연).
• 페일오버(Failover)는 즉시 이루어지고 가용성이 높음.
• 비용은 RDS에 비해 약 20% 정도 높지만 스케일링 측면에서 훨씬 효율적임.

Aurora High Availability and Read Scaling

• 3개의 가용영역에 걸쳐 6개의 데이터 복사본을 저장.
  • 쓰기 작업을 위해서는 6개의 사본 중 4개만 있으면 됨. (즉, AZ 하나가 작동하지 않아도 괜찮음.)
  • 읽기 작업을 위해서는 6개의 사본 중 3개만 있으면 됨. (즉, 읽기 가용성이 높음.)
  • 백엔드에서 P2P(peer-to-peer) 복제를 통한 자가 복구 진행.
  • 단일 볼륨에 의존하지 않고 수 백 개의 볼륨 사용함.
• 하나의 Aurora 인스턴스가 쓰기 작업을 수행함. (master)
• 마스터의 자동 장애 조치(failover)는 30초 이내에 이루어짐.
• 마스터 외에 읽기를 제공하는 읽기 전용 복제본을 15개까지 둘 수 있음.
• Cross Region 복제 지원
  마스터는 하나, 복제본은 여러 개, 스토리지 복제, 작은 블록 단위로 자가 복구 또는 확장이 일어남.

Aurora DB Cluster

• writer endpoint
• reader endpoint
• 자동 스케일링, 자동 확장되는 공유 스토리지 볼륨
• 로드 밸런싱이 statement level이 아니라 connection level에서 일어난다는 사실을 기억하기!

Features of Aurora

• 자동 장애 조치(failover)
• 백업 및 복구
• 격리 및 보안
• 산업 규정 준수
• 버튼 한 번으로 확장 가능 (push-button scaling)
• 제로 다운타임 자동 패치 설치
• 고급 모니터링
• 정기적인 유지 보수
• Backtrack(백트랙): 백업을 사용하지 않고 언제든 데이터 복원 가능

Aurora Replicas - Auto Scaling

• At-rest encryption
  • AWS KMS를 사용하여 데이터베이스 마스터 및 복제본 암호화 - 이는 데이터베이스를 처음 실행할 때 정의됨.
  • 마스터가 암호화되지 않은 경우 읽기 복제본을 암호화할 수 없음.
  • 암호화되지 않은 기존 데이터베이스를 암호화하려면 DB 스냅샷을 통해 암호화된 DB 형태로 데이터베이스 스냅샷을 복원해야 함.
• In-flight encryption: 기본적으로 TLS 사용 가능. 클라이언트는 AWS TLS 루트 인증서 사용해야 함.
• IAM 인증:사용자 이름/암호 대신 IAM Role을 사용하여 DB에 연결 가능.
• 보안 그룹:RDS/AUrora DB에 대한 네트워크 액세스 제어
• SSH 액세스 불가능 (RDS Custom 제외)
• 감사 로그 활성화 - CloudWatch Logs로 전송하여 장기간 보관 가능.

Amazon RDS Proxy

• Fully managed database proxy for RDS
• 애플리케이션이 데이터베이스 내에서 데이터베이스 연결 풀을 형성하고 공유할 수 있음. (애플리케이션을 RDS DB 인스턴스에 일일이 연결하는 대신 프록시에 연결하면 프록시가 하나의 풀에 연결을 모아서 RDS DB 인스턴스로 연결함)
• 데이터베이스 리소스에 가해지는 부하를 줄이고 (ex. CPU, RAM), 데이터베이스에 개방된 연결과 타임아웃을 최소화하여 데이터베이스의 효율성을 향상
  = RDS 프록시는 완전한 서버리스로 오토 스케일링이 가능해 용량을 관리할 필요가 없고 가용성이 높음. 다중 AZ도 지원.
• RDS와 Aurora의 장애 조치 시간을 66%까지 줄일 수 있음
• RDS (MySQL, PostgreSQL, MariaDB, MS SQL Server) 및 Aurora (MySQL, PostgreSQL)를 지원
• 애플리케이션의 코드를 변경하지 않아도 됨
• DB에 대한 IAM 인증을 강제함으로써 IAM 인증을 통해서만 RDS DB 인스턴스에 연결할 수 있음. 이때 자격 증명은 AWS Secrets Manager에 안전하게 저장됨.
• RDS 프록시는 퍼블릭 액세스가 절대 불가능함. (VPC에서만 접근 가능)

3. ElastiCache

• RDS와 동일한 방식으로 관계형 데이터베이스를 관리할 수 있음
• ElastiCache는 Redis 또는 Memcached와 같은 캐시 기술을 관리할 수 있도록 함.
• Cache: 매우 높은 성능과 낮은 지연 시간을 가진 인메모리 데이터베이스
• 읽기 집약적인 워크로드에서 데이터베이스의 부하를 줄이는데 도움
• 애플리케이션을 stateless로 만드는데 도움이 됨
• AWS는 OS 유지 관리/패치, 최적화, 설정, 구성, 모니터링, 장애 복구 및 백업을 처리
• ElastiCache를 사용하는 것은 애플리케이션 코드 변경이 많이 필요

ElastiCache Solution Architecture

DB Cache

• 애플리케이션은 ElastiCache에 쿼리를 보내고, ElastiCache에 데이터가 없는 경우 RDS에서 가져와 ElastiCache에 저장.
• RDS의 부하를 완화하는 데 도움
• 캐시는 가장 최신 데이터만 사용되도록 만료 전략(invalidation strategy)을 가져야 함

User Session Store

사용자가 애플리케이션 중 하나에 로그인하면 애플리케이션은 세션 데이터를 ElastiCache에 기록한다. 사용자가 이후 애플리케이션의 다른 인스턴스로 리디렉션 되면 애플리케이션은 ElastiCache에서 직접 세션 캐시를 검색하고 사용자는 계속 로그인한 상태로 한번 더 로그인할 필요가 없음.

Redis vs Memcached

Redis

• 자동 장애 조치(Auto-Failover)를 위한 Multi AZ
• 읽기 스케일링에 사용되며 가용성이 높은 읽기 전용 복제본
• AOF 지속성을 통한 데이터 내구성
• 백업 및 복원 기능
• 세트(Sets)와 정렬 세트(Sorted Sets)를 지원함

Memcached

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

Caching Implementation Considerations

• 데이터를 캐싱하는 것은 안전한가?
  • 데이터가 최신 정보가 아닐 수 있으나, 최종적으로는 일관성을 유지한다.
• 캐싱이 데이터에 효과적인가?
  • 패턴: 데이터 변경이 느리고 필요한 키가 적은 경우
  • 안티 패턴: 데이터가 빠르게 바뀌고 데이터셋의 모든 키가 필요한 경우
• 데이터의 구조가 캐싱에 적합한가?
  • 예시: 키-값 캐싱 또는 집계 결과의 캐싱
• 그렇다면 어떤 캐싱 설계 패턴이 가장 적합할까?

Lazy Loading / Cache-Aside / Lazy Population

• 장점
  요청된 데이터만 캐시됨 (요청되지 않은 데이터는 캐시되지 않음)
  노드 실패가 발생해도 치명적이지 않음 (캐시를 워밍하기 위한 대기 시간이 증가할 뿐)

• 단점
  캐시 미스일 경우 3번의 네트워크 호출이 이뤄지며, 해당 요청에 대한 지연이 발생할 수 있음
  오래된 데이터: 데이터는 데이터베이스에서 업데이트 되었지만 캐시에서는 오래된 상태일 수 있음

Lazy Loading / Cache-Aside / Lazy Population Python Pseudocode

Write Through – Add or Update cache when database is updated

• 장점
  캐시된 데이터는 절대로 오래된 상태가 아니며, 읽기가 빠르다
  쓰기 패널티 vs 읽기 패널티

• 단점
  데이터가 데이터베이스에 추가/업데이트 되기 전까지는 데이터가 없다. 이를 완화하기 위해 Lazy Loading 전략을 결합하여 구현할 수 있다.
  캐시 이탈률(churn): 많은 데이터를 추가할 경우 많은 데이터가 읽히지 않을 수 있다.

Write-Through Python Pseudocode

Cache Evictions and Time-to-live (TTL)

• 캐시 제거는 세 가지 방식으로 발생할 수 있다.
  • 캐시에서 명시적으로 항목을 삭제한다.
  • 메모리가 가득 찼을 때 가장 최근에 사용되지 않은 항목이 제거된다. (LRU, Least Recently Used)
  • 타임 투 리브 (TTL)로 설정한다.
• TTL은 다양한 종류의 데이터에 유용하다
  • 리더보드
  • 댓글
  • 활동 스트림
• TTL은 몇 초부터 몇 시간 또는 며칠까지 다양하다.
• 메모리가 항상 꽉 차서 너무 많은 제거가 발생하는 경우, 스케일 업 또는 스케일 아웃을 해야 한다.

Final words of wisdom

• Lazy Loading / Cache aside는 구현하기 쉽고 다양한 상황에서 기본으로 사용되며, 특히 읽기 측면에서 작동한다.
• Write-through는 일반적으로 Lazy Loading과 결합되어 이 최적화를 적용하는 쿼리나 워크로드를 대상으로 한다.
• TTL(Time-to-live) 설정은 일반적으로 좋은 아이디어다. Write-through를 사용하지 않을 때를 제외하고는 응용 프로그램에 적합한 값을 설정해야 한다.
• 필요한 데이터에만 캐싱을 적용해야 한다. (사용자 프로필, 블로그 등)

Amazon MemoryDB for Redis

• Redis와 호환되고, 내구성이 뛰어난 인메모리 데이터베이스 서비스
• 초당 1억 6천만 건 이상의 초고속 성능
• 다중 AZ 트랜잭션 로그를 사용한 내구성 있는 인메모리 데이터 스토리지
• 10GB에서 100TB까지의 스토리지로 원활하게 확장 가능
• 사용 사례: 웹 및 모바일 앱, 온라인 게임, 미디어 스트리밍 등