본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
강의 요약
오늘은 Redis 캐싱 전략과 패턴에 대해 학습했다. Redis는 단순한 메모리 저장소가 아니라, 캐시 운영에 필요한 일관성과 안정성을 제공하는 핵심 요소다. TTL, eviction, persistence 등 전략 구현 기능을 모두 제공하며, 어떤 전략을 선택하느냐에 따라 캐시 데이터의 신뢰성, 복구 가능성, 응답 지연이 결정된다.
Application 캐시 전략
다양한 캐시 전략 중 대표적인 3가지를 알아보자
Cache-Aside (Lazy Loading)
- 필요할 때만 DB에서 데이터를 불러와 캐시에 저장하는 가장 일반적인 캐시 전략이다.
- 기본 흐름은 캐시 조회 → 없으면 DB 조회 → 조회 결과를 캐시에 저장 후 반환이다.
- 1차 캐시(Local) 조회 -> 2차 캐시 조회 -> DB 이런식으로 다단계 레벨 캐시 구현도 가능할 것이다.
- 자주 접근하는 데이터만 캐시되므로 메모리 효율이 높지만, 첫 조회 시 지연이 발생하고 데이터 변경 시 캐시 삭제가 필요하다.
- 사용자 프로필, 게시글, 상세정보 캐시 등에 활용된다.
Write-Through
- 쓰기 요청이 들어올 때 캐시와 DB를 동시에 업데이트하는 전략이다.
- 항상 최신 데이터가 유지되어 캐시 일관성이 보장되지만, 쓰기 지연이 발생하고 장애 시 롤백/재시도 로직이 필요하다.
- 환경 설정, 계정 설정, 상태값 등에 활용된다.
Write-Behind (Write-Back)
- 캐시에 먼저 쓰고 나중에 비동기로 DB에 반영하는 전략이다.
- 클라이언트는 Redis에만 쓰고, Redis가 비동기로 DB를 갱신한다.
- 응답 속도가 빠르고 대량 쓰기 처리에 유리하지만, Redis 장애 시 DB 누락이 발생할 수 있다.
- 로그 수집, 임시 통계, 비동기 큐 등에 활용된다.
Application Cache의 종류
캐시를 적용하는 범위에 따라 크게 세 가지로 구분할 수 있다.
| 종류 | 위치 | 장점 | 단점 |
| Local Cache | Application 내부 (In-Memory) | 네트워크 비용 없이 빠른 접근 | Scale-out 시 정합성 문제 |
| Global Cache | 별도 캐시 서버 (Redis, Memcached) | 서버 간 데이터 공유 가능 | 네트워크 지연, SPoF 위험 |
| Distributed Cache | 여러 서버를 클러스터로 구성 | 높은 확장성과 처리량 | 높은 운영 비용, 일부 데이터 유실 가능 |
Local Cache
- Caffeine, EhCache 등을 활용하며 Application에서 바로 접근 가능하기 때문에 성능이 뛰어나다.
- 하지만 동일 Application이 Scale-out 된 경우에는 각 Local Cache가 동기화되지 않기 때문에 데이터의 정합성 문제가 발생하게 된다.
Global Cache
- 네트워크로 접근 가능한 캐시 서버를 구성하고 Application들이 이를 접근하도록 하는 방식이다.
- Local Cache에서 발생하는 데이터 정합성 문제를 해결하지만, 네트워크를 경유하여 데이터에 접근하기 때문에 Local Cache보다 성능이 낮다.
- 또한 Global Cache는 SPoF(Single Point of Failure)가 되기 때문에 장애 발생 시 모든 Application에 장애가 전파될 수 있어 기본적으로 이중화 구성이 필요하다.
Distributed Cache
- 여러 서버를 클러스터로 묶어 데이터를 분산 저장시키고 Hash와 같은 특정 Key를 통해 접근할 서버를 지정하는 방식이다.
- Redis Cluster, Hazelcast 등이 대표적이다.
- 새로운 캐시 서버를 쉽게 추가할 수 있어 확장성이 높지만, 특정 서버의 장애로 인한 일부 데이터 유실이 발생할 수 있고 Consistent Hashing을 사용하는 경우 서버의 요청 부하가 다음 서버로 전달되어 연쇄적인 장애가 발생할 수 있다.
분산 환경에서 로컬 캐시 정합성 보장
분산 환경에서 로컬 캐시를 사용할 때 가장 큰 문제는 한 서버에서 원본 데이터가 수정되면 다른 서버들의 캐시 데이터에도 이를 반영해야 한다는 점이다. 보통 최종적 일관성(Eventual Consistency)을 채택하여, 일시적 불일치를 허용하지만 최종적으로는 모든 서버의 데이터 일관성이 맞춰진다. 이를 해결하는 방법은 크게 두 가지가 있다.
TTL 설정
- 캐싱된 데이터에 유효 시간을 지정하여, TTL이 지난 데이터는 자동으로 제거되고 이후 조회 시 최신 데이터를 다시 캐싱하는 방식이다.
- 데이터 변경 주기가 예측 가능하고 주기적으로 바뀌는 경우에 효과적이다.
- 꼭 정합성 문제 뿐만 아니라 가용성 측면에서도 사용하면 좋을 것이다.
Invalidation Message Propagation
- 캐시 데이터에 수정이 발생할 경우 기존 캐시 데이터가 더 이상 유효하지 않다는 것을 다른 서버에 전파하여 무효화하는 방식이다.
- Redis Pub/Sub을 활용하면 효과적으로 구현할 수 있다.
- 데이터 수정이 발생한 서버가 변경된 캐시의 키가 이제 유효하지 않다는 메시지를 발행하고, 다른 서버들이 이를 구독하여 자신의 로컬 캐시를 무효화한다. 사용자 액션에 의해 변경 주기가 일정하지 않은 경우에 적합하다.
참고 출처
- https://lob-dev.tistory.com/87
- https://00h0.tistory.com/112
- https://tech.kakaopay.com/post/local-caching-in-distributed-systems/
