ElasticCache

RDS가 관리하는 방식과 동일하게 ElasticCache도 Redis나 Memcached를 관리하기 위해 사용됩니다. Read Intensive Workload, Stateless한 상황에 대해서 유용합니다.

하지만 ElasticCache를 적용하면 기존 코드의 수정량이 RDS에 비해 많습니다.(쿼리 캐시 등)

ElasticCache는 Redis나 MemCached를 이용하여 구현이 됩니다.

ElasticCache 적용 사례

DB Cache

RDS에 직접 접근하는 것이 아닌, ElasticCache를 거친다면, 캐싱이 되는 일부 데이터는 빠른 속도로 가져올 수 있습니다.

User Session Store

사용자가 이미 특정 application에 접속되어 있고, 또다른 application에 접근하고 싶을 때, ElasticCache를 사용한다면 user 데이터를 해당 application에 전달함으로써 새로운 로그인 중복을 해결할 수 있습니다.

Redis vs Memcached

Redis	MemCached
Multi AZ 가능	Multi-node(sharding)
고가용성(Replica 가능)	고가용성 불가능
Data Durability	Data가 Persistent하지 않음
Backup과 Restore 존재	Backup과 Restore 불가
Set, Sorted Set 저장 가능
	Multi-Thread 아키텍처 채택

Caching시 고려사항

1. Data를 Caching하기에 안전한가?
   • 데이터가 최신을 유지해야 하는 환경이라면 고려(Stale Data)
2. Caching하는 것이 효율적인가?
   • Data가 자주 바뀌지 않고, 몇 개의 내용만 자주 필요할 때
3. Well-Structured인가?
   • Key-Value(Redis와 같이) 등
4. 어떤 캐싱 패턴을 사용해야 하는가?
   • Lazy Loading, Cache Aside, Lazy Population...

Caching Pattern

Lazy Loading

데이터를 읽으려고 할 때, 캐시에 존재하는 데이터라면 바로 반환하고, 없는 데이터라면 DB에서 찾은 후 캐시에 저장하는 방식입니다.

장점

• 요청된 데이터만 캐싱되므로 불필요한 공간 낭비가 없습니다.
• Node Failure가 치명적이지 않습니다.

단점

• Miss 발생 시 3번의 Round Trip이 필요합니다.
• Stale Data가 캐시에 존재할 수 있습니다.(DB 업데이트 미반영)

Write Through

Write를 할 때, DB에만 Write하는 것이 아닌 캐시에도 Write를 진행하는 방식입니다.

장점

• Data가 항상 최신 상태이고, 읽는 속도도 빠릅니다.
• Write가 자주 발생하는 어플리케이션이라면 Round Trip이 2번인 이 방식을 택하는 것이 이득입니다.

단점

• Data가 Write될 때까지 캐시에 저장되지 않습니다.
• 한번 써진 데이터가 평생 읽히지 않을 수도 있습니다.

따라서 Lazy Loading과 Write Through를 섞어 쓰는 것이 이상적입니다.

Cache Evictions & Time To Live

캐싱된 데이터를 제거하는데 TTL을 기반으로 제거하는 방식입니다.

하지만 TTL은 Write Through와 같이 쓰기에는 효율적이지 않습니다.

Amazon MemoryDB

MemoryDB는 Redis와 치환가능한 인메모리 데이터베이스입니다. Durability와 빠른 성능을 보장하고, multi AZ 환경도 지원합니다. 또한 확장성도 매우 좋습니다.