[AWS 스터디모임] ElasticCache

Amazon ElasticCache

1. 개요

Amazon Web Services에서 제공하는 완전 관리형 인메모리 데이터 캐시 서비스. ElastiCache는 관리형 Redis 또는 Memcached를 제공한다.

캐시란?
높은 성능과 짧은 대기 시간을 가진 인 메모리 데이터베이스.
높은 읽기 성능으로 읽기 집약적인 워크로드에 대한 데이터베이스의 부하를 줄인다.

인 메모리 데이터베이스?
기존에 사용하는 Mysql, Oracle 같은 데이터베이스들은 그 데이터가 Disk에 저장되는 형태이다.
인메모리 DB는 그 데이터를 메모리에 저장하여 기존 DB들보다 빠른 속도를 자랑한다. 다만 메모리에 저장되는 만큼 휘발성이 강하여 주 저장소로는 사용하기 힘든 오류가 있다.

 

2. 사용 예시 (아키텍쳐) 

일반적인 아키텍쳐는 DB와 함께 사용되는 것이 보통으로 동일한 쿼리가 수행될 때의 성능을 향상시킨다.

애플리케이션이나 인스턴스에서 쿼리를 수행할 때 일반 DB 전에 데이터가 저장되어 있는지 확인하고 있을 경우(캐시 적중) 인메모리 캐시에서 바로 반환하고 없을 경우(캐시 미스) 일반 DB에서 가져와 반환하는 형태이다.

다만 캐시 기술을 사용할 때의 어려움이 있는데 항상 최신 데이터만 사용하도록 캐시 무효화 전략을 가지고 있어야한다는 점이다.

 

또다른 아키텍쳐 형태로는 애플리케이션을 무상태로 만드는 형태이다. 사용자 세션을 저장하는 방식인데 애플리케이션에 사용자가 로그인을 하면 유저의 세션을 저장한다. 이후 유저가 애플리케이션의 다른 인스턴스로 리다이렉션되면 세션을 검색하여 반환받는다. 이 방식으로 사용자는 재 로그인을 하지 않아도된다.

 

3. Redis vs Memcached

Memcached란?

범용 분산 캐시 시스템. 데이터베이스의 부하를 완화하여 동적 웹 프로그램의 속도를 높이는데 사용하게 개발됨.

2003년 개발되었다. Key- Value 타입을 기반하여 데이터를 저장한다.

Redis란?

Remote Dictionary Server의 약자로 비정형 데이터 저장 비관계형 데이터베이스 관리 시스템. 2009년 개발되었다.

Key-Value 타입을 기반으로 하고 있으며 String말고도 set, sorted set, hashes, list 등의 자료 구조를 지원한다.

 

비교

Redis	MemCahed
자동 실패 복구를 위한 다중 가용 영역(Multi AZ)	• 데이터 파티셔닝(샤딩)을 위한 다중 노드
읽기 확장과 고가용성을 위한 읽기 복제본	고가용성(복제) 없음
AOF 지속성을 이용한 데이터 내구성	비영구적
백업 및 복원 기능	백업 및 복원 없음
Set와 Sorted Set를 지원 (시험 출제 가능성)	다중 스레드 아키텍처

 

표에서 볼 수 있 듯. Redis가 고가용성, 백업, 읽기 전용 복제 기능을 가지고 있다면 MemCached는 분산된 순수 캐시에 불과하다.

데이터 손실을 감수해야하며 고가용성, 백업, 복원 기능이 없다. 이것이 둘의 주요 차이점이다.

 

캐시 고려 사항

캐시 데이터를 사용하는 것이 좋은가? 캐시가 최신 버전이 아니라 순간적인 일관성이 깨질 순 있지만 최종적으로는 일관성을 유지한다. 그렇다면 모든 유형에서 사용해도 되나?

데이터가 자주 바귀지 않으며 자주 필요한 키가 적을 경우엔 캐싱이 효과적일 수 있다. 

그러나 데이터가 빠르게 바뀌고, 데이터셋의 모든 키가 필요한 경우 캐싱에 적합한지 한 번더 고려해봐야한다.

 

Lazy Loading / Cache-Aside / Lazy Population

셋은 같은 의미이다. 캐시 데이터를 예열한다고 생각하면되는 형태이다.

애플리케이션이 캐시에 요청한 데이터에 대해  캐시 미스 발생했을 때 RDS에 데이터를 요청해서 읽게되고 이렇게 읽은 데이터만 캐시 저장하는 형태이다. 즉 요청된 데이터만 캐싱된다.

요청된 데이터만 저장하기에 효율적이지만 캐시 미스가 발생할 경우 패널티로 인해 3번의 라운드 트립이 발생하며, 해당 요청에 대해 지연이 눈에 띄게 발생한다.

또한 한 번 적중된 데이터에 대해 데이터베이스에서 데이터가 업데이트되어도 캐시에서는 오래된 데이터가 사용될 수 있다.

(시험에서는 Cache Aside나 Lazy Loding 구조를 읽는 법이 나올 수 있다.)

Pseudocdoe

user_id 에 대한 유저 요청이 왔을 때 캐시를 확인하고 없으면 db에 쿼리를 보내고 적중이면 캐시에서 반환하는 수도 코드.

 

Write Througth

요청시에 캐시를 저장하지 않고 데이터베이스가 업데이트 될 때 캐시를 추가하거나 업데이트 하는 방식이다.

데이터 일관성 문제가 발생하지 않는다. 또한 읽기 작업시에 속도가 빠르다는 장점이 있다.

또한 해당 방식은 쓰기 작업 시에 두 번의 쓰기 작업을 해야한다는 점이 있는데, 사용자 입장에서는 쓰기 Write 작업에 시간이 더 걸리는 느낌을 받을 수 있다.( 사용자 입장에서는 좋을 것이다.)

단점으로는 데이터가 RDS에 기록되기 전까지는 데이터 누락이 발생할 수 있다. 이를 위해 Lazy Loding 전략과 결합하여 사용 할 수 있다.

또 다른 단점으로는 RDS에 많은 데이터가 추가될 경우 캐시에 읽히지 않는 데이터가 적재될 단점 또한 존재한다.

Pseudocdoe

 

user_id와 데이터를 RDS 저장할 때 캐시에도 저장하는 코드.

캐시 제거와 TTL(Time to Live)

캐시는 제한된 크기가 있다. 따라서 관리를 위해 데이터를 제거하는 경우가 있는데 이를 캐시제거 라고 한다.

방식은 크게 3가지가 있다.

• 캐시에서 항목을 명시적으로 삭제한다.
• 메모리가 가득 차 있을 때 최근에 사용되지 않은 항목을 삭제되도록 한다.(LRU, Least Recently Used).
• 항목의 생존 시간(TTL, Time-to-live)을 설정하여 자동 삭제처리되도록 한다.

메모리가 항상 꽉 차서 제거가 많이된다면 캐시 확장을 고려해야한다.

 

전략 조언

Lazy Loding 전략은 쉽게 구현할 수 있는 방식으로 많은 상황의 기초가된다.
Write Through 전략은 난이도가 조금 있으며 자체로 캐시 전략이라기보단 Lazy Loding의 후속 효과 최적화 문제라고 보는게 편하다.(Write Through를 첫 우선순위 전략으로 두지 말 것.)
TTL 방식은 나쁘지 않은 방식이지만 사용할 것이라면 Write Through 방식 사용은 지양해야한다.
캐시를 사용할 때는 의미 있는 데이터만 캐시할 것.

 

2024.03.04 - [AWS] - [AWS 스터디 모임] ElasticCache 생성해보기