캐시 저장 방식 지침
- 데이터는 자주 사용되면서 자주 변경되지 않는 데이터를 기준으로 한다.
- 언제든지 데이터가 날라갈 수 있는 휘발성을 고려한다.
-> 중요한 정보, 민감 정보 등은 저장하지 않는 것이 좋다.
파레토 법칙
- 80%의 활동을 20%의 유저가 하기 때문에 20%의 데이터만 캐시 해도 서비스 대부분의 데이터를 커버할 수 있게 된다는 말이다.
캐시 제거 방식 지침
캐시 데이터는 대부분 영구 저장소에 저장된 데이터의 복사본으로 동작하는 경우가 많다.
이는 영구 저장소에 저장되어 있는 데이터와 캐시 솔루션의 데이터를 동기화 하는 작업이 반드시 필요함을 의미한다.
따라서 캐시를 구성할 때 기본 만료 정책을 설정해야 한다.
캐시 만료 주기가 너무 짧으면 데이터는 너무 빨리 제거되고 캐시를 사용하는 이점은 줄어든다.
반대로 너무 기간이 길면 데이터가 변경될 가능성과 메모리 부족 현상이 발생하거나, 자주 사용되어야 하는 데이터가 제거될 수 있다.
-> redis는 LRU(Least Recently Used)정책을 사용한다... 처음 알았다...!
Cache Stampede 현상
: 대규모 트래픽 환경에서 TTL 값이 너무 작게 설정하면 발생하는 현상이다.
키가 만료가 되면 여러개의 서비스에서 DB로 가서 찾게되는 duplicate read가 발생한다.
또 읽어온 값을 각 각 redis에 쓰는 duplicate write도 발생되어 Cache Stampede 현상이 발생하여 처리량도 느려지고 불필요한 작업이 굉장히 늘어나 요청양 폭주로 장애가 일어날 수 있다.
캐시 공유 방식 지침
캐시는 서비스의 여러 인스턴스에서 공유하도록 설계된다.
데이터 정합성 문제가 발생할 수 있기 때문에 두 가지 방법의 개발 방식을 취해야 한다.
1. 데이터가 검색된 이후 변경되지 않았는지 일일히 확인하는 방법이다.
변경되지 않았다면 즉시 업데이트하고, 변경되었다면 업데이트 여부를 애플리케이션 레벨에서 결정하도록 수정해야한다.
이와 같은 방식은 업데이트가 드물고 충돌이 발생하지 않는 상황에 적용하기 용이하다.
2. 캐시 데이터를 업데이트 하기 전에 Lock을 잡는 방식이다.
조회성 업무를 처리하는 서비스에 Lock으로 인한 대기현상이 발생한다.
이와 같은 방식은 데이터의 사이즈가 작아 빠르게 업데이트가 가능한 업무와 빈번한 업데이트가 발생하는 상황에 적용하기 용이하다.
캐시 가용성 지침
: 캐시를 구성하는 목적은 빠른 성능 확보와 데이터 전달에 있으며, 데이터의 영속성을 보장하기 위함이 아니라는 점을 기억하고 설계해야한다.
가용성 : 사용 가능성
자바의 JPA에서 영속성은 무언가를 Entity 속성에 영구히 저장해준다라는 뜻으로 해석이 가능.
데이터의 영속성은 기존 데이터 스토어에 위임하고, 캐시는 데이터 읽기에 집중하는 것이 성능 확보의 지침 사항이 될 수 있다.
또한, 캐시 서버가 장애로 인해 다운되었을 경우나 서비스가 불가능할 경우에도 지속적인 서비스가 가능해야 한다.
이는 캐시에 저장되는 데이터는 결국 기존 영구 데이터 스토어에 동일하게 저장되고 유지된다는 점을 뒷바침하는 설계방식이다. (Write Through)
즉, 캐시 서버가 장애로 부터 복구되는 동안 성능상의 지연은 발생할 수 있지만, 서비스가 불가능한 상태가 되지 않도록 고려해야 한다는 말이다.
