[Architecting on AWS] Database

• AWS 목적 별 데이터베이스

Relational Database

RDS

• Mysql, Postresql 같이 클라우드 서비스가 등장하기 전에 만들어진 DBMS 서빙.

• standalone workload 를 상정하고 서비스하다보니 Aurora 에 비해 분산처리에 최적화 되어있지는 않다.
• 예) multi-AZ 환경에 primary stand-by DB 인스턴스를 둘 수 있지만 stand-by DB 가 read-only 리플리카 역할을 병행할 수는 없다. (read-only 리플리카 전용 인스턴스를 따로 만들어야 함.)

Aurora

• AWS 에서 직접 개발한 DBMS 엔진. (cloud-native)

• 클러스터 볼륨으로 RDS 에 비해 효율적인 분산처리/failover 가능. https://docs.aws.amazon.com/en_en/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html
• 클러스터 볼륨 : multi-AZ 단위로 레플리카들을 관리하기 위해 여러 AZ 에 있는 볼륨들을 논리적으로 하나로 묶음. 물리적으로 각 AZ 에서는 클러스터에 대한 메타 정보를 복사하여 소유한다.

• pre-cloud DBMS(Mysql, Postgresql) 와 호환.

Non-Relational Database

• DynamoDB

• DocumentDB

• ElasticCache

DynamoDB

• 완전관리형 Serverless NoSQL database service

• 무제한 용량.

• 아래 3개를 지정하면 테이블이 만들어진다.
• table name
• partition key
• sort key

• primary key = (partition key, sort key)

• 데이터 용량과 상관없이 빠른 조회 가능.
• partition key 해싱

• 최종 일관성 (eventually consistent)

• 강력 일관성 (strongly consistent)

• WCU

• RCU

ElasticCache

• Redis, Memcached 호환.

• lazy loading caching strategy
1. 캐싱된 데이터 요청
2. 캐싱 미스되면 (캐싱된 데이터가 없으면) 디비에서 조회
3. 조회한 결과를 캐싱
4. 요청한 데이터 응답

• lazy loading caching strategy 는 캐싱된 데이터에 대해 TTL을 설정해줘야 outdated 데이터가 캐싱에 오래 남는 것을 방지한다.

• 캐싱 메모리 자원을 효율적으로 쓰려면 캐싱 메모리 데이터 제거 정책이 필요하다.
1. 액세스 한 지 가장 오래된 데이터 (Least Recently Used)
2. 액세스 빈도가 가장 낮은 데이터 (Least Frequently Used)