Redis 캐싱 전략

지금 까지 Redis의 개념과 자료구조를 정리했습니다.

하지만 실무에서 Redis를 사용할 때 가장 중요한 것은 단순 사용법이 아니라 

어떤 캐싱 전략을 선택할 것인가입니다

 

같은 Redis라도 캐싱 전략에 따라 

• 성능
• 데이터 정합성
• 장애 대응
• 시스템 구조 

가 달라지게 됩니다.

이번 글에서는 실무에서 반드시 알아야 하는 캐싱 전략들을 정리해 보겠습니다 

---

Look Aside (Lazy Loading)

 

애플리케이션에서 데이터를 읽을 때 가장 많이 사용하는 캐싱 전략입니다

흐름은 다음과 같습니다.

1. Cache에서 데이터를 먼저 확인 
2. Cache 에 데이터가 있으면 Cache에서 가져온다
3. Cache 에 데이터가 없다면 DB에서 데이터를 읽어온다
4. DB에서 얻어온 데이터는 Cache에 저장하고 응답으로 내보낸다 

즉 Cache Miss 가 발생했을 때만 DB를 조회하는 방식입니다 

 

장점 

• 구현이 매우 간단합니다
• Cache가 다운되더라도 바로 장애로 이어지지 않고 db에서 가져올 수 있다
• 점진적 캐싱 가능

 

단점

• 최초 요청이 느림
• Cache에 connection 이 많이 붙어 있었는데 해당 Cache가 끊어지게 된다면
  그 connection이 DB로 몰려 갑자기 부하를 줄 수 있다

 

Cache Warming

Cache를 새로 투입했거나 DB 에만 새로운 데이터를 저장했다면 처음에 Cache Miss가 발생해서 성능이 저하가 발생할 수 있다

이럴 때는 Cache로 Data를 미리 밀어 넣어주는 작업이 필요할 수 있다 

---

Write Around

이 전략은 Write 시 Cache를 거치지 않고 DB 에만 저장하는 방식입니다 

흐름은 다음과 같습니다 

Write → DB 
Read → Cache Miss 시 DB 조회 후 Cache 저장

 

장점

• Cache 오염을 방지할 수 있다 
  Cache는 자주 사용해야 하는 Data 가 있어야 하는데 자주 사용하지 않는 Data가 Cache에 쌓이는 걸  오염이라고 한다 
• 자주 조회되지 않는 데이터에 유리

 

단점

• Cache와 DB 간 데이터 불일치
• Read시 Cache Miss 증가할 수 있다 

 

사용 사례

• 일회성 데이터
• 조회 가능성이 낮은 데이터

---

Write Through

DB에 데이터를 저장할 때 Cache에도 함께 데이터를 저장하는 방식이다

흐름은 다음과 같습니다 

Write → Cache + DB 
Read → Cache Hit

 

장점

• Cache는 항상 최신 정보를 가진다는 장점이 있다 
• Read 성능 매우 좋음

 

단점

• 저장할 때마다 두 단계 스탭을 거쳐야 한다
• 데이터를 무조건 캐시에 넣어버리기 때문에 재사용하지 않는 데이터도 캐시에 넣어버린다

---

Write Back (Write Behind)

이 전략은 먼저 Cache에 저장하고 이후 Batch로 DB에 반영하는 방식입니다.

흐름은 다음과 같습니다

Write → Cache 저장 
비동기 Batch → DB 저장

장점

• Write 성능 매우 빠름
• DB 부하 감소
• 대량 처리에 유리
• Log 처리 방식에 유리

 

단점

• 장애 시 데이터 유실 가능
• 정합성 관리 필요

 

---

Cache Stampede

이처럼 데이터를 저장할 때는 얼마나 데이터를 보관하겠다는 Expire Time을 설정하는 게 중요하다

하지만 이 ExpireTime을 너무 짧게 설정해서 발생하는 문제가 있다 

 

언제 발생하는가?

• TTL 이 너무 짧을 때
• 인기 데이터가 동시에 만료될 때

 

발생 원인

Look Aside 패턴 은 Redis의 데이터가 없다면 서버가 직접 DB로 데이터를 요청하고 다시 Redis에 저장하는 과정을 거칩니다

TTL을 작게 잡아 키가 만료되는 순간 많은 서버에서 이 키를 같이 보고 있었다면, 그 모든 애플리케이션 서버들이 db에 가서 같은 데이터를 찾게 되는 duplicate read 가 발생한다

또 읽어온 데이터를 Redis에 각각 write 하는 duplicate write 도 발생하게 된다

이는 굉장히 비효율적인 상황이고 한번 이런 상황이 발생하면 처리량뿐만 아니라 불필요한 과정이 너무 많이 늘어난다

 

해결 전략

TTL을 충분히 길게 설정

TTL = 5분 → 위험 
TTL = 30분 → 안정

 

Random TTL

TTL = 30분 + 랜덤값

 

Lock 기반 재생성

• 한 요청만 DB 조회
• 나머지는 대기

---

마무리

Redis를 사용하는 것 자체보다

어떤 캐싱 전략을 선택하느냐가
시스템 성능과 안정성을 결정합니다.

 

실무에서는

• Look Aside → 가장 많이 사용
• Write Through → 정합성 중요할 때
• Write Back → 대용량 처리
• Write Around → Cache 오염 방지

처럼 상황에 맞게 전략을 선택해야 합니다.

 

다음 글에서는 대규모 트래픽 대응 아키텍처를 정리해 보겠습니다

---