만약에 300개의 "거의 변하지 않는" 데이터 중 일부에 대해 필요할때마다 api를 호출하여 불러오는 경우가 있다고 생각해보자.
api 호출로 서버의 응답시간 중 처리시간이 증가하는 상황이 발생할텐데 이때 캐시를 활용하는것이 하나의 해결 방법이 될 수 있다고 생각한다.
인메모리 캐시 사용 판단의 근거
- 일단 데이터 크기 자체가 작다. 300개 정도의 작은 데이터
- 따라서 레디스 같은 별도 시스템을 활용하는건 오버스펙이라고 생각
- 무엇보다 거의 변하지 않는 데이터라 서버마다 인메모리에 캐시된 데이터의 차이가 거의 없다.
caffeine을 사용할만한 이유
- 스프링부트에서 starter로 제공된다
- size-based eviction: 사이즈를 최초에 설정해두면 딱 그만큼만 저장해둔다. 넘어가면 evict(내보내다) 해버린다
- time-based eviction: 정해진 시간만큼 caching 한다.
- read based: cache를 마지막으로 읽은 시간부터 특정 시간
- write based: cache에 write한 시점부터 특정시간
- ⭐️Weak reference를 통해 GC를 활용하여 사용되지 않은 메모리를 처리할 수 있다.
- 서버의 메모리를 활용하고 그 중 힙 영역을 활용하게되는 인메모리 캐시를 사용할 때 GC를 효율적으로 사용할 수 있도록 설계되었다면 굉장히 유용할거라고 생각
상황: