[SAA] Elasticache

Elasticahe

• Redis 또는 Memcached의 관리형 서비스
• in-memory DB
• 낮은 지연율
• 높은 성능
• DB 읽기 부하 감소
• 애플리케이션의 무상태성을 지원 (루즈, 로그인 세션)
• OS와 관련된 모든 요소 AWS에서 관리
• 다른 SDK를 사용하여 cache가 적용되지 않았던 서비스에 적용할 때 코드 변경 (많이) 필요

Elasticache - Redis

• 멀티 AZ
• 복구 자동화
• 읽기 복제본 사용 가능
• AOF(Append Only File) 영속성을 통해 데이터 관리 가능 (읽기 이벤트 저장 -> 복구 및 영속성, 복제본 생성에 사용)
• 백업 및 복구 기능
• Sorted Set / Set 기능 지원

Elasticache - Memcached

• 여러 노드간 데이터 샤딩 가능
• 읽기 복제본 사용 불가
• 영속성 관리 불가
• 복구, 백업 불가
• 멀티 스레드 아키텍처 지원

캐시 보안

• IAM 기반 인증 제공
• IAM 정책을 통한 보안은 AWS API 레벨에서만 동작
• Redis AUTH (자체적 보안)
  • 비밀번호 / 토큰 생성 시 설정
  • 필요할 때만 설정하면 됨
  • SSL 암호화 통신 지원
• Memcached
  • SASL 기반 인증 지원
• 최소한의 보안은 직접 지켜야 한다.

활용

• Lazy Loading 패턴 사용 가능
  • 업데이트 시 캐시에 저장
  • 리얼타임 데이터가 아닐 수 있음

• Session 관리 용도로 사용 (stateless를 위해)
• 캐시 사용시 네이밍과 캐시 정합성 검사(Lazy Loading 패턴 시)를 제외하면 어렵지 않음.
  • 중요하고 불변성이 유지되어야 한다면, 사용하지 않는 것이 좋다.
  • 혹은 메인 DB에만 적용하는 것도 괜찮다. (복잡성 때문인 듯)
  • 메인 DB에만 적용하는 경우, 영속성을 위해 Redis를 사용할 것.
• Redis의 경우, Sorted Set 사용 가능
  • 순서 보장
  • Unique 보장

Lazy Loading 동작 구조

• 캐시를 가져오려고 시도
• 없으면(캐시 미스) RDS를 통해
• 가져온 데이터를 캐시에 저장하고 반환
• 하는 모든 과정을 애플리케이션에서 해줘야 하기 때문에 기존 로직의 변경이 많이 요구됨

동작 예시 (stateless)

• 로그인 세션을 캐시에 저장
• 저장된 캐시를 기반으로 다른 서버에서도 확인 가능
• 로컬 캐시 대신 사용
• 여러 인스턴스가 있을 경우에는 필수

---

Lazy Loading 외의 데이터 저장 방식