ElastiCache는 분산 인메모리 데이터 스토어를 클라우드에서 쉽게 설정하고 관리할 수 있게 해주는 서비스이다. 데이터가 디스크가 아닌 RAM(메모리)에 저장되므로 응답 속도가 압도적으로 빠르다.

1. Redis vs Memcached: 무엇을 선택해야할까?

대부분의 현대적인 백엔드 개발 환경에서는 Redis를 사용한다.

비교 항목	Memcached	Redis
데이터 타입	단순 Key-Value (String만 가능)	List, Set, Hash, Sorted Set 등 다양함
영속성	없음 (재시작 시 데이터 소멸)	스냅샷/AOF를 통한 데이터 복구 가능
복제(Replica)	지원 안 함	읽기 복제본, 다중 AZ(Failover) 지원
주 용도	단순한 객체 캐싱	세션 관리, 랭킹 시스템, 메시지 큐

---

2. 백엔드 개발자의 주요 활용

2.1. DB 부하 감소 (Caching)

• 전략: Look-aside (Lazy Loading)
  • 애플리케이션이 데이터를 찾을 때 먼저 Redis를 확인한다
  • 데이터가 있으면(Cache Hit) 즉지 반환하고 없으면(Cache Miss) DB에서 가져와 Redis에 저장한 후 반환한다.
• 효과: 반복적인 무거운 쿼리를 줄여 DB CPU 사용량을 획기적으로 낮출 수 있다.

2.2. 세션 저장소 (Session Store)

• 상황: 서버가 여러 대(Auto-Scaling)일 때, 사용자가 1번 서버에서 로그인했는데 다음 요청이 2번 서버로 가면 로그인이 풀리는 문제가 생긴다.
• 해결: 세션 정보를 서버 메모리가 아닌 중앙 Redis에 저장하여 모든 서버가 공유하게 한다. (Stateless 아키텍처의 핵심)

2.3. 실시간 랭킹 시스템 (Stored Sets)

• 기능: Redis의 ZSET(Stored Sets)자료구조를 사용하면 수백만 명의 점수를 실시간으로 정렬하여 순위를 매길 수 있다.
• 속도: DB에서 ORDER BY를 사용하는 것보다 수천배 빠르다.

2.4. 분산 락 (Distributed Lock)

• 여러 서버가 동시에 같은 데이터를 수정하려고 할 때, 데이터 정합성을 맞추기 위해 Redis를 공유 잠금 장치로 사용할 수 있다.

---

3. ElastiCache 운영 시 필수 체크리스트

3.1. TTL 설정

• 캐시 데이터는 반드시 유효 기간을 설정해야 한다. 메모리는 비싸고 한정되어있기 때문이다.
• TTL이 없으면 메무리 부족으로 서비스가 멈출 수 있다.

3.2. Eviction Policy (데이터 축출 정책)

• 메모리가 꽉 찼을 때 어떤 데이터를 먼저 지울지 정해야 한다.
• 보통 가장 오래 사용되지 않는 데이터를 지우는 allkeys-lru를 많이 사용한다.

3.3. 복제 및 고가용성 (Multi-AZ)

• Primary-Replica: 읽기 전용 복제본을 두어 읽기 성능을 높일 수 있다.
• Multi-AZ With Auto-Failover: 기본 노드에 문제가 생기면 자동으로 복제본을 승격시켜 장애를 방지한다.

---

4. 백엔드 개발자 실무 팁

• 보안: Redis는 기본적으로 인증 기능이 약할 수 있으므로 반드시 VPC 내부에 위치시키고 보안 그룹에서 6379 포트를 철저히 관리해야 한다.

• 모니터링: CloudWatch에서 FreeableMemory 와 CPUUtilization을 주시해야 한다. 특히 Redis는 싱글 스레드 기반이므로 특정 명렁어가 CPU를 점유하지 않도록 주의해야 한다.

• Serialization: Java 객체를 저장할 때 JSON으로 직렬화할지, 바이너리로 할지 결정해야 한다. 가독성은 JSON이 좋으나 성능과 용량은 바이너리가 유리하다.

  ---