[Spring Boot] 캐시 설계 전략

1. 공부하는 이유
   • 웹 서비스 환경에서 시스템 성능 향상을 기대하고자함.
   • Redis를 사용하는데 어떻게 해야 잘쓰는지 고민하는 시간을 갖게 됨
   • RAM의 용량은 한정되있기 때문에 데이터를 어느 종류, 얼마나, 얼마동안 데이터를 캐시에 저장하는지에 대한 전략을 숙지할 필요가 있다.
2. cache hit & cache miss
   • cache hit: 캐시 스토어에 데이터가 있을 경우 가져옴 (Fast)
     1. 클라이언트가 서버에 데이터를 요청한다.
     2. 서버는 캐시에 데이터가있는지 확인
     3. 캐시에 데이터가 있으므로 바로 반환
   • cache miss: 캐시 스토어에 데이터가 없을 경우 DB에서 가져옴 (Slow)
     1. 클라이언트가 서버에 데이터를 요청
     2. 서버는 캐시에 데이터가 있는지 확인
     3. 캐시에 데이터가 없으므로 원 데이터를 가져옴
     4. 가져온 데이터를 캐시에 저장
     5. 데이터를 클라이언트에 반환
3. Read Cache Strategy
   1. Look Aside Pattern
      • Cache Aside pattern, Lazy Loading 이라고도함.
      • 데이터를 찾을때 우선 캐시에 저장된 데이터가 있는지 확인함→ 없을시 DB에서 조회
      • 최신정보의 일관성이 크게 중요하지 않을 때 사용
      • 단점을 보완하기위해 Cache Warming을 함 → DB에서 캐시로 데이터를 미리 넣어주는 작업(용량이 한정적이라 TTL 설정잘해야함)
      • 장점
        • 요청 받은 데이터만 캐시에 저장함. 파레토의 법칙(데이터 20%가 대부분 접근)
        • 없으면 실제 데이터에 접근하기 때문에 Cache Miss가 발생했을 때 치명적이지 않음.
        • redis가 다운되더라도 DB에서 데이터를 가져오면 됨
        • Read를 반복적으로 할때 적합함.(단건 조회 빈도수가 높으면 비적합)
      • 단점
        • 값을 읽을 떄 Cache Miss 마다 3개의 패널티를 가짐. (캐시에 확인 요청, DB에 확인요청, 캐시에 데이터를 DB에 가져온 데이터를 쓰는부분)
        • Cache Miss가 발생했을 때 마다 캐시에 데이터를 쓰기 떄문에 캐시의 데이터는 최신을 유지 못할 가능성이 존재한다.
   2. Read Throgh Pattern
      • 캐시에서만 데이터를 읽어오는 전략(Inline cache)
      • 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식
      • 데이터 정합성이 중요할 때 적합
      • 처리과정은 Look Aside Pattern 와 유사하나 Cache Store에 저장하는 주체가 Server냐 Data Store냐에 차이가 있음.(Read Trough는 주체가 data store)
      • 단점을 보완하기 위해 Relication 또는 Cluster로 구성하여 가용성을 높임
      • 장점
        • 캐시에 들어있는 데이터는 항상 최신의 데이터를 유지한다. (데이터 정합성)
        • 직접적인 DB 접근을 최소화 하기 때문에 읽기가 많은 워크로드에 적합
      • 단점
        • 값을 쓸 때 마다 캐시와 DB에 모두 쓰기 때문에 쓰기는 항상 2번의 패널티를 가짐 → 쓰기 작업이 많은 시스템이면 딜레이 많음
        • 데이터를 조회하는데 있어서 전체적으로 속도가 느림
        • 데이터 조회를 캐시에 의존하기 때문에 redis가 다운되면 서비스 이용에 차질이 생김
4. Write Cache Strategy
   1. Write Back Pattern
      • Write Behind Pattern이라고도 불림
      • 캐시와 DB 동기화를 비동기처리로 하기 때문에 동기화 과정이 생략
      • 데이터를 저장할때 DB에 바로 쿼리하지 않고, 캐시에 모아서 일정 주기 배치 작업을 통해 DB에 반영 → 캐시가 일종의 Queue 역할을 겸하게 됨.
      • 단점을 보완하기 위해 Relication 또는 Cluster로 구성하여 가용성을 높임
      • 장점
        • 모아놨다가 DB에 쓰기때문에 쓰기 쿼리 회수 비용과 부하를 줄일 수 있음
        • Write가 빈번하면서 Read를 하는데 많은 양의 Resource가 소모되는 서비스에 적합
      • 단점
        • 자주 사용되지 않는 불필요한 리소스 저장
        • 캐시에 오류가 발생하면 데이터를 영구 소실함
   2. Write Through Pattern
      • DB와 Cache에 동시에 데이터를 저장하는 전략
      • 데이터를 저장 할 때 먼저 캐시에 저장한 다음 DB에 저장
      • DB 동기화 작업을 캐시에게 위임
      • Write Through + Read Through으로 AWS DynamoDB Accelator(DAX)만듬
      • 장점
        • 데이터 일관성 유지
        • 데이터 유실이 발생하면 안되는 상황에 적합
      • 단점
        • 자주 사용되지 않는 불필요한 리소스 저장
        • 요청마다 두번의 Write가 발생하게 됨으로써 빈번한 Write에 성능 이슈 발생
        • 기억장치 속도가 느릴 경우, 데이터를 기록할때 CPU 대기시간 때문에 성능 감소
   3. Write Around Pattern
      • 모든 데이터는 DB에 저장(캐시는 갱신하지 않음)
      • Cache miss가 발생하는 경우에만 DB와 캐시에도 데이터 저장
      • 장점
        • Write Through보다 훨씬 빠름
      • 단점
        • 캐시와 DB의 데이터 불일치 가능성
5. Cache Read + Write 조합
   1. Look Aside + Write Around
      • 가장 일반적으로 자주 쓰이는 조합
   2. Read Through + Write Around
      • 항상 DB에 쓰고, 캐시에서 읽을때 항상 DB에서 먼저 읽기 때문에 데이터 정합성 유지
   3. Read Through + Write Through
      • 데이터를 쓸때 항상 캐시에 먼저 쓰기 때문에 읽을때 항상 최신의 캐시 데이터 저장
      • 데이터를 쓸 때 항상 캐시에서 DB로 보내므로 정합성 보장

※ 참조

• https://inpa.tistory.com/entry/REDIS-📚-캐시Cache-설계-전략-지침-총정리