[AWS Developer Associate] ElastiCache 정리

ElastiCache

RDS와 동일한 방식으로 관계형 데이터베이스를 관리

Redis, Memcached와 같은 캐시 기술을 관리

 

캐시 : 높은 성능과 낮은 지연 시간을 가진 인 메모리 데이터베이스

 

ElastiCache 사용이점

읽기 집약적인 워크로드의 부하를 줄이는데 도움이 된다.

RDS와 같은 장점을 갖기 대문에 동일한 유지 보수를 수행한다.

운영체제, 패치, 최적화와 설정, 구성, 모니터링, 장애 회복, 백업 수행

 

Redis VS Memcached

 

Redis 

- 자동 장애 조치로 다중 AZ를 수행하는 기술

- 읽기 전용 복제본은 읽기 스케일링에 사용되며 가용성이 높다.

- 지속성으로 인해 데이터 내구성이 있다.

- 백업과 기능 복원 기능이 있다.

->고가용성, 백업, 읽기전용 복제본

 

Memcached

- 데이터 분할에 다중 노드를 사용(sharding)

- 가용성이 높지 않다.

- 복제가 발생하지 않는다.

- 지속적인 캐시가 아니다.

- 백업과 복원 기능이 없다.

->데이터를 손실할 수 없는 단순한 분산 캐시

 

 

ElastiCache 캐싱 전략

 

캐싱은 언제나 좋은가? No!!

데이터가 천천히 바뀌고 자주 필요한 키가 적을 경우에는 캐싱이 유리하다.

하지만 데이터가 빠르게 바뀌고 데이터셋의 모든 키가 필요한 경우 캐싱은 효과적이지 못하다.

 

즉, 데이터의 변동성과 데이터 구조에 따라 캐싱 사용여부를 결정해야 한다.

 

[캐싱 설계패턴]

 

1. Lazy Loading

(Cache-Aside/Laze Population)

- 데이터 요청이 있을 때만 캐싱된다. RDS에서 요청받은 데이터가 없는 경우 캐신되지 않아 효율적이다.

- 만약 캐시가 삭제되거나 노드 실패가 발생해도 치명적이지 않다.

- 캐시를 한 번 예열해야 하므로 대기 시간이 늘어난다. (최초 요청 시 데이터베이스에 직접 쿼리해야 한다.)

- 캐시 미스인 경우 지연이 발생한다.

- 캐시에 오래된 데이터가 남아 있을 수 있다.

- 데이터가 갱신되었을 때 기존에 캐싱된 데이터만 무효화 시키면 된다.

 

2. Write Through

- 데이터베이스가 업데이트될 때 캐시를 추가하거나 업데이트하는 것을 의미(데이터 갱신시 느리다.)

- 데이터 갱신 후에는 데이터가 캐싱되어 있으므로 빠르게 캐시를 읽어올 수 있다.

(읽기에는 유리, 쓰기에는 불리)

- 항상 최신의 데이터를 가져오고, 캐시 히트가 발생할 확률이 높다.

- RDS에 기록되기 전에는 캐시에서는 데이터 누락이 발생할 수 있다.

 

3. 캐시제거(Cache Eviction)&TTL

 

캐시에는 제한된 크기가 있기 때문에, Write Through 방식에서도 캐시 이탈(캐시 용량이 부족한 경우)이 발생할 수 있다.

따라서 캐시 제거 방법을 사용한다.

LRU 방식으로 가장 최근에 사용하지 않은 항목을 제거할 수 있고, 캐시 데이터 항목을 TTL하여 사용시간을 정할 수 있습니다.