RDS(Relational Database Service)
: 관계형 데이터베이스 서비스
- Postgres, MySQL, MariaDB, Oracle, Microsoft SQL Server, Amazon Aurora
Storage Auto Scaling
: 데이터베이스의 스토리지 크기를 자동으로 조정
RDS Read Replicas for read scalability
: 읽기 전용 복제본(읽기 스케일링)
- 복제는 비동기식(ASYNC)이므로 읽기가 일관된다.
- 복제본을 자신의 DB로 승격하여 이용할 수 있다.
- 애플리케이션은 복제본을 활용하기 위해 모든 연결을 업데이트해야 한다.
- 읽기 전용 복제본이 있는 경우, SELECT 명령문에만 사용해야 한다.
- 암호화되지 않은 RDS DB 인스턴스에서는 암호화된 읽기 전용 복제본을 생성할 수 없다.
RDS Multi AZ(Disaster Recovery)
: 마스터 데이터베이스의 모든 변화를 동기적(SYNC)으로 복제
- 하나의 DNS 이름을 갖음으로써 가용성을 높이기 때문에 다중 AZ라 불린다.
- 다중 AZ는 다운되는 전체 AZ에 대한 재해 복구를 계획할 때 도움이 된다. 전체 AWS 지역이 다운될 것을 계획하는 경우 AWS 지역에 걸쳐 백업 및 복제를 사용해야 한다.
- 다중 AZ는 어떤 데이터베이스가 작동 중인지에 관계없이 동일한 연결 문자열을 유지한다.
단일 AZ에서 다중 AZ로 전활할 때는 데이터베이스를 중지할 필요가 없다. 이를 통해 RDS 데이터베이스 인스턴스는 마스터를 갖고 동기식 복제본인 스탠바이 데이터베이스를 확보한다.
tip: 읽기 전용 복제본과 다중 AZ의 차이
RDS Proxy
: RDS 데이터베이스 인스턴스에서 연결을 최소화하고 풀링하기 위해 사용
- CPU, RAM 등 데이터베이스 리소스에 대한 스트레스를 줄여서 데이터베이스 효율성 향상
- 열린 연결과 데이터베이스에 대한 시간 초과를 최소화
- 서버리스, 오토 스케일링으로 용량 관리 필요 없음, 다중 AZ 사용으로 가용성 높음
- MySQL, PostgreSQL, MariaDB에 대해 RDS Proxy를 지원한다.
- IAM을 사용해야만 RDS 데이터베이스 인스턴스에 연결할 수 있다. 자격 증명을 Secrets Manager 서비스에 안전하게 저장한다.
- VPC에서만 액세스 가능(공개적으로 액세스 불가)
Amazon Aurora
: Postgres, MySQL과 호환 가능한 amazon 데이터베이스
- 데이터베이스 스토리지 자동 확장 기능
- 읽기 전용 복제본 최대 15개 생성, 빠른 복제
- 즉각적인 장애 조치
오토 스케일링, 공유 스토리지 볼륨, 자동 확장
High Availability and Read Scaling
- 3개의 AZ에 걸쳐 무엇이든 쓸 때마다 데이터의 6개 사본을 저장(읽기에 대한 가용성이 높다)
- P2P(peer-to-peer)를 이용한 자가 복구 프로세스
- 수백개의 볼륨(위험 감소)
- 1개의 마스터, 다수의 사본, 스토리지 복제
DB Cluster
- Writer Endpoint: 마스터 가르키기
- Reader Endpoint: 로드 밸런싱 연결
RDS & Aurora Security
- At-rest encryption
- In-flight encryption
- IAM Authentication
- Security Groups
- No SSH availavle
- Audit Logs can be enabled
Amazon ElastiCache
: 캐시 기술인 관리현 Redis 또는 Memcached를 얻을 수 있도록 도와줌
Solution Architecture
- DB Cache
- User Session Store: 사용자 세션을 저장하여 애플리케이션을 무상태로 만든다.
Redis vs Memcached
- Redis: 고가용성, 백업, 읽기 전용 복제본 기능, 데이터 내구성과 캐시 기능, 세트와 정렬 세트 지원
고가용성을 보장하려는 ElastiCache Redis 클러스터를 실행 중인 경우 다중 AZ를 활성화 한다.
클러스터 모드가 비활성화된 ElastiCache Redis 클러스터에 추가할 수 있는 읽기 전용 복제본은 최대 5개이다. - Memcached: 분산된 순수 캐시, 데이터 손실, 고가용성, 백업, 복원 기능 없음
Caching Implementation Considerations
- 캐시 데이터가 안전한가?
- 캐싱이 데이터에 효과적인가?
- 데이터 구조가 캐싱에 적합한가?
- 어떤 캐싱 설계 패턴이 가장 적합한가?
Lazy Loading/Cache-Aside/Lazy Population
: 쉽게 구현 가능하며 많은 상황에서 기초로 사용된다.(특히 읽기 성능을 개선할 때)
- 필요할 때만 캐시에 데이터를 로드(데이터베이스에서 능동적으로 데이터를 요청한 경우)
tip: 캐시 어사이드나 레이지 로딩 구조를 읽는 법
Write Through
: 데이터베이스가 업데이트될 떄 캐시를 추가하거나 업데이트하는 것(필요한 경우만 구현)
Cache Evictions and Time-to-live(TTL)
:캐시 데이터를 제거(Cache Eviction), 데이터를 캐시에 보관하는 것과 제거되는 것 사이에서 균형 유지(TTL)
ElastiCache 및 RDS 읽기 전용 복제본은 실제로 읽기 확장에 도움이 된다.
Amazon MemoryDB for Redis
:Redis와 호환되고 내구성이 뛰어난 인메모리 데이터베이스 서비스
- Redis는 약간의 내구성을 갖춘 캐시로 사용, MemotyDB는 Redis와 호환되는 API가 있는 데이터베이스로 굉장히 높은 성능을 자랑한다.
