[redis] 캐싱, 활용할 데이터 선정, 고려할 점

이전엔 캐싱을 사용할 수 있는 redis가 무엇인지 정리해봤습니다.

그런데, 모든 데이터를 캐싱 적용 하면, 성능이 올라갈까?

redis는 메모리에 값을 저장해 db에 저장하는 것 보다 값을 빠르게 불러오도록 해주지만, 저장장치에 저장된 데이터를 메모리에도 모두 저장시킨다면 자원이 많이 필요하게 될 것이라 생각합니다.
수정이 자주 일어나는 작업이라면 캐싱을 쓰지 않는 부분이 더 나을수도 있으며,
사용 빈도가 높지 않은 데이터라면 캐싱을 안쓰더라도 별 영향이 없을 수도 있습니다.
또한 메모리에 지속적으로 보관할 지, 아니면 수명 정책을 걸어 일정 시간이 지나면 삭제하고 메모리 여유를 둘지 고민해야 합니다.
이런 부분들을 고려하여 캐싱을 적용할 정책, 기준을 정하는 것이 필요합니다.

1. <저장 정책> 데이터에 만료 정책 적용하기

• 캐시 데이터는 영구 저장소(e.g., 데이터베이스)의 데이터와 반드시 동기화 되어야 함 → 캐시 구성시 만료 정책 필요
• 기간이 만료되면 캐시 삭제 되도록 수명 주기를 설정
• 만료 주기가 너무 짧으면 성능 저하, 너무 길면 데이터 정합성 문제 또는 메모리 부족 문제가 발생할 수 있다.
• 대규모 트래픽 환경에서 TTL이 너무 짧으면 cache stampede 현상이 일어날 수 있다.
  (캐시가 만료되어 순간적으로 많은 요청이 동시에 DB로 몰리는 현상)
  여러 환경에서 특정 키를 조회하려는 순간 key의 만료시간이 지났다면 영구 저장소에 한꺼번에 데이터 조회 요청을 하며 duplicated read가 발생하게 되고, 조회한 데이터를 또 캐싱하는 duplicated write이 발생 → 성능 저하 및 요청 병목이 생길 수도 있다.

2. <공유 정책> 캐싱된 데이터를 여러 인스턴스에서 읽어간다. 즉 공유 된다.

• 캐시는 여러 인스턴스에서 공유하도록 설계될 수 있기 때문에, 한 인스턴스가 수정한 데이터를
  다른 인스턴스의 변경으로 덮어씌우지 않도록 해야함(동시성 문제를 예방, 해결)
  이를 해결하려면 데이터 정합성을 위한 확인 절차가 필요하다.
• 캐시된 데이터 업데이트 직전에 데이터가 조회된 이후로 수정되지 않았는지 확인하거나
  업데이트 전 Lock을 걸어 정합성을 유지해야 한다.
• Lock을 거는 방식의 경우 조회 업무를 처리하는 프로세스에 Lock을 기다리는 대기열이 생기며, 시간이 길 경우 타임아웃이 생길 수도 있다.
  따라서 데이터 크기가 작아 빠르게 수정 가능하거나 빈번하게 수정이 일어나는 경우 Lock을 쓰는게 좋다.
• 업데이트 전 변경 여부를 확인하는 전략을 사용할 경우, 업데이트가 드물고 충돌이 발생하지 않는 경우에 사용하며,
  확인 후 변경되지 않았다면 즉시 수정, 변경 되었다면 변경 여부를 애플리케이션에서 결정하도록 해야한다.

위 두가지 고려할 점을 기반으로 본다면, 캐싱을 사용하기 좋은 데이터는 다음의 조건을 갖추어야 할 것입니다.

• 자주 사용되며 변경 빈도가 낮은 데이터
• 데이터가 유실 되어도 상관없을 정도의 데이터(메모리 저장 기반이며, 다시 캐싱으로 불러와야 하니)

※ redis의 기능으로 메모리 기반 데이터를 디스크에 저장함으로써 지속성을 유지할 수 있지만,
캐싱을 위한 성능으로는 적합하지 않다는 의견이 있습니다. redis가 종료되고 재시작 되었을 때, 상태를 보존하기 위한 작업이 필요하다면 그때만 설정하면 좋을 것 같습니다.
다만, 이중으로 저장하게 되는 부분이 될 수 있어 데이터 정합성도 깨질 수 있습니다.

위의 사항을 고려하여 캐싱할 데이터를 선정하고 수명을 정하며 
캐싱을 사용하면 성능에 좀더 유리해질 수 있을 것입니다.

글을 작성하며...

캐싱을 적용하지 않았을 때, 동시성 문제를 해결하는 방법과,
캐싱을 적용했을 때, 동시성 문제를 해결하는 방법을 별도로 정리해둬야 할 것 같습니다.
이를 하기 전에, 지금은 캐싱에 사용할만한 데이터를 선정하는 기준과 활용방법, 주의할점을 다뤄봤습니다.
다음엔 구체적으로 캐싱을 사용하는 전략에 대해 정리해보려 합니다.