Redis 캐싱 전략

[REDIS] 캐시(Cache) 설계 전략 지침 총정리
[Cache & Redis] 캐싱 전략 (Cashing Strategies)
레디스(Redis)의 다양한 활용 사례

• 캐싱 전략은 최근 웹 서비스 환경에서 시스템 성능 향상을 위해 가장 중요한 기술
  • 캐시는 메모리를 사용함으로 디스크 기반 데이터베이스 보다 훨씬 빠르게 데이터를 반환할 수 있고 사용자에게 더 빠르게 서비스를 제공할 수 있음

배치 전략 종류

Cache Aside 패턴 (Look Aside)

• 읽기에 적합
• 반복적인 호출에 적합
• 캐시 장애 대비 구성
  • 레디스가 다운 되더라도 DB에서 데이터를 가져올수 있어 서비스 자체는 문제가 없음
• 대신 캐시에 붙어있던 connection 이 많았다면 레디스가 다운된 순간, 순간적으로 DB로 몰려서 DB에 부하가 올 수도 있음
• 정합성 문제 발생
  • Cache Store 와 Data Store 가 가지고 있는 데이터가 서로 다름

• Cache Asdie 패턴은 캐시로 부터 빠르게 데이터를 조회해 올 수 있도록 하는 기본적인 캐시 설계 방식
  • 읽기가 많은 경우 적합하며 가용성 측면에서 Cache 서버에 장애가 발생해도 Data Store를 통해 지속 서비스를 할 수 있음
• 다만 Cache Store 와 Data Store 간에 정합성 유지 문제가 발생할 수 있으며 초기 조회 시 무조건 Data Store 를 호출 해야 하므로 단건 호출 빈도가 높은 서비스에 적합하지 않음
  • 대신 반복적으로 동일 쿼리를 수행하는 서비스에 적합한 아키텍처

Tip!

• 초기에 데이터를 DB에만 저장했다면 처음엔 cache miss가 많기 때문에 성능 저하의 가능성이 있음
• 그래서 미리 DB에서 캐시로 데이터 넣어주는 작업이 필요한데 이를 Cache Warming 이라고 부름

Read Through 패턴

• Cache Aside 방식 업그레이드 버젼
• 읽기가 많은 워크로드에 적합

• Read Through 방식은 Cache Aside 방식과 비슷하지만 Cache Store 에 저장하는 주체가 Server 또는 Data Store 에서 차이점 존재
• Cache Aside 방식은 Data Store 로부터 서버가 쿼리 결과를 얻고나서 캐시에 저장
• Read Through 패턴은 초기 데이터는 cache miss 가 항상 발생한다는 단점을 커버할 수 있도록 애플리케이션 측면에서 캐시 대상을 판단하여 Data Store 저장 (Commit) 시 Cache Store 에 쿼리를 동일하게 자동 수행하도록 설정

Write Back 패턴 (Write Behind)

• 큐 역할
• 데이터베이스에 대한 전체 쓰기를 줄일 수 있어 해당 비용을 감소
• 정합성 확보
• 캐시 장애 시 데이터 유실
• 불필요한 리소스 저장

• Write Back 패턴의 경우 Cache Store 가 데이터 저장소 역할을 하면서 동시에 Data Store 에 Write 부하를 줄이기 위한 Queue 역할을 겸하게 됨
  • 이로 인해 Database의 부하를 경감시킬 수 있다는 장점 있음
  • 대체로 쓰기 작업이 많은 경우 적용을 권고

• Write Back 패턴의 장점으로는 데이터베이스의 일시적인 다운타임을 허용하거나 장애에 대응할 수 있으며 Cache Store 와 Data Store 간의 데이터 정합성을 유지하기에도 유용
  • 그러나 Cache Store 에서 Data Store 로 데이터를 전송하기 전에 장애가 발생할 경우 데이터 분실이 발생 위험이 있을 수 있음
  • 그리고 자주 사용되지 않는 데이터가 저장되어 리소스 낭비와 Write 작업에 부하가 발생할 수 있음
  • 그래서 이를 해결하기 위해 TTL 을 꼭 사용하여 사용되지 않는 데이터를 반드시 삭제해야 함

Tip!

• Read-Through와 결합하여 가장 최근에 업데이트되고 엑세스 된 데이터를 항상 캐시에서 사용할 수 있는 혼합 워크로드에 적합

Write Through 패턴

• 항상 동기화 되어 있어 데이터베이스에 작성할 때마다 캐시에 데이터를 추가
• 캐시와 백업 저장소에 업데이트를 같이 하여 데이터 일관성을 유지할 수 있어서 안정적
• 데이터 유실이 발생하면 안 되는 상황에 적합
• 단 속도가 느린 기억장치에 데이터를 기록할 때 CPU가 대기하는 시간이 필요하기 때문에 성능이 떨어짐

• Wrtie Through 패턴은 Cache Store 에도 반영하고 Data Store에도 동시에 반영하는 방식
  • Write Back은 일정 시간을 두고 나중에 한꺼번에 저장
  • 그래서 항상 동기화가 되어 있어 항상 최신정보를 가지고 있다는 장점이 있음
• 하지만 결국 저장할 때마다 2단계 과정을 거쳐치기 때문에 상대적으로 느리며 무조건 일단 Cache Store 에 저장하기 때문에 캐시에 넣은 데이터를 저장만 하고 사용하지 않을 가능성이 있어서 리소스 낭비 가능성이 있음
  • 이 역시 이를 해결하기 위해 TTL을 꼭 사용하여 사용되지 않는 데이터를 반드시 삭제해야 함

Write Around 패턴

• 읽은 데이터만 캐시에 저장
• Write Through보다 훨씬 빠름
• 데이터 정합성 문제 발생

• 요청이 들어오면 일단 DB에만 다 저장하고, 읽은 데이터만 캐시에 저장되는 방식
• 속도가 빠르지만 캐시에 업데이트하고 보조 기억장치에는 바로 업데이트 하지 않기 때문에 캐시와 보조메모리의 값이 서로 다른 경우가 발생할 수 있음

Tip!

• Write Around 는 Read Through 와 결합 될 수 있으며 Cache Aside와도 결합될 수 있음
• 데이터가 한 번 쓰여지고 덜 자주 읽히거나 읽지 않는 상황에서 좋은 성능을 제공
  • 예를들어 실시간 로그 또는 채팅방 메시지로 사용 될 수 있음

Tip! 추가 내용

Lazy Loading (=Look Aside)

• 이름에 나타나듯이 레이지 로딩은 클라이언트에게서 데이터가 필요로 해질 때 Cache 에 로딩하는 전략
  • DB나 외부 API에 접근하기 전 Cache 를 먼저 확인 한 후 Cache 에 데이터가 존재한다면 Cache 데이터를 그렇지 않다면 원본 (DB나 외부 API) 에 접근하여 값을 가져와 캐시에 올려놓음

• 장점

  • 요청 받은 데이터만 캐시에 저장
    • 파르토의 법칙에 따르면 전체 데이터 중 20% 정도가 대부분이 접근 하고 나머지 80%는 거의 접근이 없음
    • 따라서 실제로 접근이 있는 데이터만 캐시에 담을 수 있음
  • 캐시 미스가 발생했을 때 치명적이지 않음
    • 왜냐하면 차선책으로 실제 데이터에 접근하여 최신의 데이터 가져오기 때문
    • 그 후 데이터 접근에 대해서는 다시 캐시가 적용됨

• 단점

  • 값을 읽을 때 캐시 미스마다 3가지의 패널티를 가짐
    • 첫번째: 캐시에 확인 요청
    • 두번째: 데이터베이스에 확인 요청
    • 세번째: 캐시에 데이터를 데이터베이스에서 가져온 데이터를 쓰는 부분
    • 캐시 미스가 많이 일어난다면 딜레이는 눈에 띄게 증가할 것
  • 캐시 미스가 발생했을 때 마다 캐시에 데이터를 쓰기 때문에 캐시의 데이터는 최신을 유지 못할 가능성이 있음
    • 따라서 캐시의 데이터를 반환했는데 부정확한 데이터가 반환될 수 있음

Write Through

• Write Through 전략은 데이터를 추가하거나 업데이트할 때 캐시에 동시에 업데이트하는 전략
  • 아래의 이미지와 같음

• 그리고 읽을 때는 실제 DB를 볼 필요 없이 cache 만 읽으면 됨
  • 아래의 이미지와 같음

• 장점
  • 캐시에 들어있는 데이터는 항상 최신의 데이터를 유지
    • DB와 캐시의 값은 항상 동시에 쓰기 때문

• 단점
  • 값을 쓸 때 마다 캐시와 데이터베이스에 모두 쓰기 때문에 업데이트와 생성은 항상 2번의 패널티를 가짐
    • 이는 쓰기 작업이 많은 시스템이라면 눈에 띄는 딜레이를 유발할 수 있음
  • 새로운 노드가 추가되거나 했을 경우 데이터를 찾지 못할 수 있음
    • 왜냐하면 새로운 노드에는 해당 데이터가 없을 것이기 때문
  • 만약 읽을 때 캐시 미싱이 일어났다면 이를 다시 매꿔주기가 애매
  • 대부분의 데이터는 거의 읽히지 않으므로 리소스 낭비로 이어질 수 있음

캐시 저장 방식 지침

• 캐시 솔루션은 자주 사용되면서 자주 변경되지 않는 데이터의 경우 캐시 서버에 적용하여 반영할 경우 높은 성능 향상을 이뤄낼 수 있는데 이를 Cache Hit Rating 이라고 함

• 일반적으로 캐시는 메모리에 저장되는 형태를 선호
  • 메모리 저장소로는 대표적으로 Redis 와 MemCached 가 있으며 이와 같은 솔루션은 메모리를 1차 저장소로 사용하기 때문에 디스크와 달리 제약적인 저장 공간을 사용
  • 이 때문에 자주 사용되는 데이터를 어떻게 뽑아 캐시에 저장하고 자주 사용하지 않는 데이터를 어떻게 제거해 나갈 것이냐를 지속적으로 고민해야 함
  • 따라서 캐시를 저장하는 시점은 자주 사용되며 자주 변경되지 않는 데이터를 기준으로하는 것이 좋음

• 또한 한가지 고민해야 할 사항은 캐시 솔루션은 언제든지 데이터가 날라갈 수 있는 휘발성을 기본으로 한다는 점
  • 이는 데이터를 주기적으로 디스크에 저장함으로서 어느정도 해결을 볼수는 있지만 실시간으로 모든 데이터를 디스크에 저장할 경우 성능 저하를 일으킬 수 있어 어느 정도 데이터 수집과 저장 주기를 가지도록 설계 해야함
  • 즉 데이터의 유실 또는 정합성이 일정 부분 깨질 수 있다는 점을 항상 고려해야 함
  • 따라서 캐시에는 중요한 정보나 민감 정보 등을 저장하지 않는 것이 좋으며 캐시 솔루션이 장애가 발생했을 경우 적절한 대응방안을 모색해 두는 것이 바람직

Adding TTL

• Lazy Loading 전략은 최신 데이터가 아닐 가능성이 있음
  • 하지만 캐싱 미스가 발생했을 때 심각한 오류를 발생하진 않음
• Write Through 전략은 항상 최신의 데이터를 유지
  • 하지만 캐싱 미스가 발생 했을 경우 잘못된 경우가 발생할 수 있으며 불필요한 메모리를 사용하여 낭비가 발생할 수 있음

• 각 전략에 TTL (time to live) 를 추가함으로써 이득을 취할 수 있음
  • TTL은 key가 자연스럽게 만료되어 없어지게 하는 시간
    • 레디스의 경우 Integer 당 1밀리초 단위
• Lazy Loading 전략에서는 TTL 을 설정 함으로써 자연스럽게 값이 없어지고 캐싱 미스를 일으켜 최신을 유지할 수 있게 됨
• Write Through 전략에서 TTL 을 설정하면 업데이트가 되지 않는 데이터들은 없어지게 되므로 메모리적인 이득을 얻을 수 있게 됨

캐시 제거 방식 지침

• 캐시 데이터의 경우 캐시 서버에만 단독으로 저장되는 경우도 있지만 대부분 영구 저장소에 저장된 데이터의 복사본으로 동작하는 경우가 많음
  • 이는 2차 저장소 (영구 저장소) 에 저장되어 있는 데이터와 캐시 솔루션의 데이터를 동기화 하는 작업이 반드시 필요함을 의미하며 개발 과정에 고려사항이 늘어난다는 점을 반드시 기억해야 함
  • 예를 들어 캐시 서버와 데이터베이스에 저장되는 데이터의 commit 시점에 대한 고려 등이 예가 될 수 있음
  • 캐시의 만료 정책이 제대로 구현되지 않은 경우 클라이언트는 데이터가 변경되었음에도 오래된 정보가 캐싱 되어있어 오래된 정보를 사용할 수 있다는 문제점이 발생

• 따라서 캐시를 구성할 때 기본 만료 정책을 설정해야 함
  • 캐시된 데이터가 기간 만료 되면 캐시에서 데이터가 제거 되고 응용 프로그램은 원래 데이터 저장소에서 데이터를 검색 해야 함
  • 그러나 캐시 만료 주기가 너무 짧으면 데이터는 너무 빨리 제거되고 캐시를 사용하는 이점은 줄어듬
  • 반대로 너무 기간이 길면 데이터가 변경될 가능성과 메모리 부족 현상이 발생하거나 자주 사용되어야 하는 데이터가 제거되는 등의 역효과를 나타낼 수도 있음