[Redis] 캐싱 전략

이 글은 인프런의 지식 공유자 박재성님의 강의를 듣고 개인적으로 정리하는 글임을 알립니다.

---

조회 전략

데이터를 조회할 때 주로 사용하는 전략이 Cache Aside 전략이다. Look Aside 전략 또는 Lazy Loading 전략이라고 부른다.

 

캐시에 데이터가 있을 경우 (= Cache Hit)

 

 

캐시에 데이터가 없을 경우 (= Cache Miss)

 

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

 

쓰기 전략

Write Around 전략

Cache Aside 전략이 데이터를 어떻게 조회할 지에 대한 전략이었다면, Write Around 전략은 데이터를 어떻게 쓸지(저장, 수정, 삭제)에 대한 전략이다. 

Write Around 전략은 Cache Aside 전략과 같이 자주 활용되는 전략이다.

Write Around 전략은 데이터를 저장할 때는 레디스에 저장하지 않고 데이터베이스에만 저장하는 방식이다.

그러다 데이터를 조회할 때 레디스에 데이터가 없으면 데이터베이스로부터 데이터를 조회해와서 레디스에 저장시켜주는 방식이다. 

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

 

Cache Aside, Write Around 전략의 한계점

• 캐시 미스(cache miss) 발생: 데이터가 처음 요청될 때 캐시에 저장되지 않기 때문에, 데이터가 자주 사용되지 않는다면 캐시가 활용되지 않고, 그로 인해 캐시 미스가 자주 발생할 수 있다. 이는 캐시의 효율성을 떨어뜨릴 수 있다.
  
  
• 데이터 일관성 문제: 데이터베이스에 업데이트가 일어나면, 캐시에 있는 데이터를 직접적으로 갱신하지 않기 때문에 캐시와 데이터베이스 간에 일관성 문제가 생길 수 있다. 데이터베이스가 변경된 후 캐시가 갱신되지 않으면 오래된 데이터를 참조하게 될 수 있다.
  
  
• 저장 공간 문제: DB는 디스크(Disk)에 저장해서 많은 양을 저장하기 용이하지만, 캐시는 메모리(RAM)에 저장하기 때문에 DB에 비해 많은 양의 데이터를 저장할 수가 없다.

 

이러한 한계점 때문에 캐시를 적용시키기에 적절한 데이터는 아래와 같다.

• 자주 조회되는 데이터
• 잘 변하지 않는 데이터
• 실시간으로 정확하게 일치하지 않아도 되는 데이터

 

장기간동안 데이터가 일치하지 않는 것은 큰 문제가 될 수 있기 때문에 적절한 주기로 데이터를 동기화시켜서 싱크를 맞추어줘야 한다.

이때 활용하는 기능이 레디스의 TTL(만료시간 설정) 기능이다.

 

일정 시간이 지나면 데이터가 캐시에서 삭제된다. 그럼 특정 사용자가 조회를 하는 순간 Cache Miss가 발생한다. DB의 데이터를 새로 조회해와서 캐시에 데이터를 넣게 된다. 즉, 데이터가 새롭게 갱신되는 효과가 있는 것이다. 

 

 

캐싱보단 SQL 튜닝이 우선

캐싱으로 조회 성능을 하기전에 SQL 튜닝을 먼저 최우선적으로 고려해야 한다.

SQL 튜닝을 제외한 나머지 방법은 추가적인 시스템을 구축해야 한다. 따라서 금전적, 시간적 비용이 추가적으로 발생한다.

조금 더 복잡해진 시스템 구조로 인해 관리 비용이 늘어난다. 그에 비해 SQL 튜닝은 기존의 시스템 변경 없이 성능을 개선할 수 있다.

 

또한 근본적인 문제를 해결하는 방법이 SQL 튜닝일 가능성이 높다.

SQL 자체가 비효율적으로 작성됐다면 아무리 시스템적으로 성능을 개선한다고 하더라도 한계가 있다.

하지만 SQL 튜닝을 통해 기본적으로 성능을 향상시킨다면, 시스템적인 성능 개선이 필요없거나 훨씬 간단한 개선으로 큰 성능 개선 효과를 얻을 수 있다.