[Spring Boot] 캐시 지침

1. 저장 방식
   • 자주 사용되면서 자주 변경되지 않는 데이터 (Cache Hit Rating)
   • 주로 In-memory 방식
   • 휘발성을 기본으로 함
   • 데이터 유실, 정합성이 보장되지 않아 민감정보는 저장하지 않는 것이 좋다.
   • 장애 발생시 적절한 대응방안 필요 → Time Out, DB 조회 병행 등
2. 제거 방식
   • 캐시 단독으로 저장되는 경우도 있지만, 대부분 영구 저장소에 저장된 데이터의 복사본으로 동작하는 경우가 많음.
   • 기본 만료 정책 설정이 꼭 필요함.
   • 캐시된 데이터가 만료되면 데이터가 제거되고, App은 원래 DB에 검색해야한다.
   • 대규모 환경에서 TTL이 너무 작으면 Cache Stampede 현상이 발생
3. 공유 방식
   • App의 여러 인스턴스에서 공유하도록 설계 됨.
   • 어느 1개의 App 인스턴스가 캐시에서 보유하는 데이터를 수정해야 하는 경우, 한 인스턴스가 만드는 업데이트가 다른 인스턴스가 만든 업데이트를 덮어쓰지 말아야 한다. → 정합성 문제
   • 데이터 충돌을 방지하기 위해 해야할 조치
     • 캐시데이터 변경하기 직전에 데이터가 검색된 이후 변경되지 않았는지 일일이 확인 → 업데이트가 드물고 충돌이 발생하지 않는 상황에 적용하기 용이
       
     • 캐시 데이터를 업데이트 하기 전에 Lock을 잡는 방식 → 대기현상발생, 데이터의 사이즈가 작아 빠르게 업데이트가 가능한 업무와 빈번한 업데이트가 발생하는 상황에 적합
       
4. 가용성 지침
   • 캐시의 목적은 빠른 성능 확보와 데이터 전달에 있다. → 영속성이 아님
   • 캐시 서버가 장애로 인해 서비스가 불가능할 때도 지속적인 서비스가 가능해야함.
   • 캐시에 저장되는 데이터는 결국 영구 데이터 스토어에 동일하게 저장되고 유지되어야 한다.

※ 참조

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