참고
캐시 처리방식 지침
캐지 저장방식 지침
NOTE
캐시 솔루션은 자주 사용되면서 자주 변경되지 않는 데이터의 경우 서버에 적용하여 반영하면 높은 성능 향상을 이뤄낼 수 있다.
•
위와 같은 방법을 Cache Hit Rating이라고 한다.
•
한가지 고민해야 할 사항은 캐시 솔루션은 언제든지 데이터가 날라갈 수 있다는, 휘발성을 기본으로 하는데, 이는 데이터를 주기적으로 디스크에 저장하면 해결할 수 있지만, 실시간으로 저장하면 성능 저하가 발생하므로 유의하자.
•
따라서 캐시에 저장되는 데이터는 중요한 정보, 민감한 정보 등은 저장하지 않는것이 좋다.
파레토 법칙
•
전체 결과의 80%가 전체 원인의 20%에서 일어나는 현상을 말한다.
•
즉 캐시에 모든 데이터를 저장할 필요 없이 “파레토 법칙”에 따라 일부만 저장해도 대부분의 데이터를 커버할 수 있다.
캐시 제거 방식 지침
NOTE
캐시 데이터의 경우 캐시 서버에만 단독으로 저장되는 경우도 있지만, 대부분 영구 저장소에 저장된 데이터의 복사본으로 동작하는 경우가 많다.
•
이는 2차 저장소(영구 저장소)에 저장되어 있는 데이터와 캐시 솔루션의 데이터를 동기화 하는 작업이 필요함을 의미하며 ,개발 과정에 고려사항이 늘어난다는 점을 기억해야 한다.
◦
ex) 캐시서버와 데이터의 commit시점에 대한 고려등이 예가 될 수 있다.
•
캐시의 만료 정책이 제대로 구현되지 않은 경우 클라이언트는 데이터가 변경되었음에도 오래된 정보가 캐싱되어 있어 오래된 정보를 사용할 수 있다는 문제점이 발생한다.
•
따라서 캐시를 구성할 때 기본 만료 정책을 설정해야한다.
◦
캐시된 데이터가 기간 만료되면 캐시에서 데이터 제거 → 2차 저장소에서 데이터 탐색
◦
캐시 만료 주기가 너무 짧다 → 캐시를 사용하는 이점이 줄어듬
◦
캐시 만료 주기가 너무 길다 → 메모리 부족 현상, 자주 사용되어야 하는 데이터가 삭제됨.
TTL(Time To Live)
•
캐쉬를 생성할 떄 캐쉬의 만료기간을 정해두는 방식이다.
•
지정된 만료일이 지나면 캐쉬를 삭제하고, 다시 캐쉬를 생성함.
Cache Stampede 현상
•
TTL값이 너무 작게 설정되면, cache stamped 현상이 발생한다!
캐시 공유 방식 지침
NOTE
캐시는 애플리케이션의 여러 인스턴스에서 공유하도록 설계된다.
•
따라서 어느 한 애플리케이션이 캐시에 보유하는 데이터를 수정하는 경우, 애플리케이션의 한 인스턴스가 만드는 업데이트가 다른 인스턴스가 만든 변경을 덮어쓰지 않도록 해야한다.
•
그렇지 않으면 데이터 정합성 문제 발생!
⇒ 이는 트랜잭션의 Lock으로 해결할 수 있다.
캐시 가용성 지침
NOTE
캐시를 구성하는 목적은 빠른 성능 확보와 데이터 전달에 있으며, 데이터의 영속성을 보장하기 위함이 아니라는 점을 기억하고 설계해야 한다.
•
데이터의 영속성 → 기존 데이터 스토어에 위임, 캐시는 데이터 읽기에 집중해야함
•
캐시 서버에 장애가 발생해도, 기존 데이터 베이스로 계속 서비스가 가능해야 한다!