Redis 캐싱 전략

캐시(Cache)란?

캐시(Cache)란, 원본 저장소보다 빠르게 가져올 수 있는 임시 데이터 저장소를 의미한다.

 

캐싱(Caching)이란?

캐싱(Caching)이란 캐시(Cache, 임시 데이터 저장소)에 접근해서 데이터를 빠르게 가져오는 방식을 의미한다.

 

데이터를 캐싱할 때 사용하는 전략(Cache Aside, Write Around)

Cache Aside(= Look Aside, Lazy Loading)

데이터를 조회할 때 주로 사용하는 전략이다.

1. 캐시에 데이터가 있을 경우 (= Cache Hit) : 데이터를 요청했을 때 캐시에 데이터가 있는 경우를 보고 Cache Hit라고 한다.
2. 캐시에 데이터가 없을 경우 (= Cache Miss) : 데이터를 요청했을 때 캐시에 데이터가 없는 경우를 보고 Cache Miss라고 한다.

※ Cache Aside 전략은 캐시(Cache)에서 데이터를 확인하고, 없다면 DB를 통해 조회해오는 방식이다.

 

Write Around

데이터를 어떻게 쓸 지(저장, 수정, 삭제)에 대한 전략이다.

※ Write Around 전략은 쓰기 작업(저장, 수정, 삭제)을 캐시에는 반영하지 않고, DB에만 반영하는 방식이다.

Cache Aside, Write Around 전략의 한계점 / 해결 방법

Cache Aside, Write Around 전략의 한계점

• 캐시된 데이터와 DB 데이터가 일치하지 않을 수 있다.
  • 데이터의 일관성을 보장할 수 없다.
  • Write Around 전략에 따르면 데이터를 수정할 때 DB만 업데이트를 시키기 때문에 기존에 저장된 레디스의 데이터 값과 DB의 데이터 값은 다를 수 밖에 없다.
• 캐시에 저장할 수 있는 공간이 비교적 작다.
  • DB는 디스크(Disk)에 저장해서 많은 양을 저장하기 용이하지만, 캐시는 메모리(RAM)에 저장하기 때문에 DB에 비해 많은 양의 데이터를 저장할 수가 없다.

이 한계를 어떻게 극복하는 방법

• 캐시된 데이터와 DB데이터가 일치하지 않을 수 있다.
  • 캐시와 DB의 데이터를 일치시키기 위해, 데이터를 수정할 때마다 동시에 업데이트 시키면 성능적으로 느려진다. 그렇다고 성능 향상을 위해 DB의 데이터만 업데이트 시키면 캐시와 DB의 데이터가 일치하지 않게 된다.
  • 하지만 어쩔 수 없다. 어떤 선택을 하든 기회 비용(Trade Off)이 발생한다. 무언가를 얻으면 무언가를 포기해야 한다. 대부분의 개발 기술들이 장점이 있으면 단점이 있다. 따라서 데이터 조회 성능 개선 목적으로 레디스를 쓰는 경우에는 데이터의 일관성을 포기하고 성능 향상을 택한 것이다.
  • 이러한 이유로 인해 캐시를 적용시키기에 적절한 데이터는 다음과 같다.
    1. 자주 조회되는 데이터
    2. 잘 변하지 않는 데이터
    3. 실시간으로 정확하게 일치하지 않아도 되는 데이터
  • 하지만 장기간 데이터가 일치하지 않는 건 문제가 될 수 있다. 따라서 적절한 주기로 데이터를 동기화시켜주어야 한다. 이 때 활용하는 기능이 레디스의 TTL 기능(만료 시간 설정 기능)이다.
  • 일정 시간이 지나면 데이터가 캐시에서 삭제된다. 그럼 특정 사용자가 조회를 하는 순간 Cache Miss가 발생한다. DB의 데이터를 새로 조회해와서 캐시에 데이터를 넣게 된다. 즉, 데이터가 새롭게 갱신되는 효과가 있는 것이다.
• 캐시에 저장할 수 있는 공간이 비교적 작다.
  • 위에서 활용했던 TTL 기능(만료 시간 설정 기능)을 활용하면 캐시의 공간을 효율적으로 쓸 수 있다. 왜냐면 자주 조회하지 않는 데이터는 만료 시간에 의해 데이터가 삭제되기 때문이다.

※ Cache Aside, Write Around 전략을 사용할 때 주로 TTL을 같이 활용한다.

 

데이터 조회 성능을 개선하는 방법

• SQL 튜닝
• 캐싱 서버 활용 (Redis 등)
• 레플리케이션 (Master/Slave 구조)
• 샤딩
• DB 스케일업 (CPU, Memory, SSD 등 하드웨어 업그레이드)

많은 성능 개선 방법 중 'SQL 튜닝'을 먼저 고려해야 한다.

1. SQL 튜닝은 기존의 시스템 변경없이 성능을 개선할 수 있다.
2. 근본적인 문제를 해결하는 방법이다.
3. SQL 자체가 비효율적으로 작성됐다면 아무리 시스템적으로 성능을 개선한다고 하더라도 한계가 있다.