캐싱 (로컬캐싱, 글로벌 캐싱 trade-off)

Cache

• 캐시는 나중에 요청할 결과를 미리 저장해 둔 후 빠르게 서비스해주는 것을 의미한다.
• 즉, 결과를 미리 저장하고 나중에 요청이 오면, 이 요청에 대해서 DB를 참조하지 않고 캐시에 접근하여 요청을 처리하는 기법이다.

그렇다면 어떤 데이터를 캐싱해야할까?

• 자주 조회되면서 쓰기가 거의 일어나지 않는 데이터에 대해서 캐싱해야한다.

캐싱을 할때 로컬캐싱 vs 글로벌 캐싱

• 캐싱할 데이터를 선정했다면, 이 데이터를 "어디"에 저장할지 고민해야한다. 일반적으로 로컬메모리에 저장하거나, Redis와 같은 별도 서버에 저장할 수 있다.
• 로컬캐싱
  • 애플리케이션 서버의 메모리에 캐싱할 데이터를 저장하는 방법이며 일반적으로 Guava cache나 Caffeine cache를 많이 사용한다.
    • 장점
      • 애플리케이션 로직을 수행하다 바로 같은 서버 내의 메모리에서 캐시를 조회하므로 속도가 빠르다.
    • 단점
      • 인스턴스가 여러개일 경우 문제점이 발생한다.
        • 한 인스턴스에서 변경한 캐시를 다른 인스턴스에 전파할 수 없다. 단, 변경을 다른 인스턴스에 전파하는 로컬 캐싱 라이브러리도 있다.
        • 각 인스턴스마다 캐시가 저장되므로 새로운 인스턴스가 뜨면 캐시를 새로 넣어야한다. 이로 인해 캐시 미스가 발생하여 트래픽을 견디지 못해 인스턴스가 죽을 수 있다.
          • Cache miss : cpu가 원하는 데이터가 캐시에 없는 상태
• 글로벌캐싱
  • 글로벌 캐싱은 Redis와 같은 별도 서버에 캐시 데이터를 저장해두는 것이다.
    • 장점
      • 인스턴스간 캐시를 공유하므로 한 인스턴스에서 캐시를 수정하더라도 모든 인스턴스가 동일한 캐시 값을 얻을 수 있다. 새로운 인스턴스가 뜨더라도 이미 있는 캐시 저장소를 바라보면 되므로, 캐시를 채워 넣는 동작을 할 필요가 없다.
    • 단점
      • 네트워크 트래픽을 거쳐야 하므로 속도가 로컬 캐싱에 비해 느리다.
        • 별도의 캐시 서버를 두어야 하므로 인프라 관리 비용이 생긴다.
          • 인프라 관리 비용? → 서버 요금, 인프라 세팅 및 유지 보수하는 데 걸리는 시간, 장애 대응 대책 구상 등

내가 선택한 방식

• '견종 검색 API'은 쓰기가 거의 일어나지 않고 조회만 일어나기때문에 캐싱에 적합하였다.
• 로컬캐싱을 선택하였는데 그 이유는 조회속도가 글로벌 캐싱보다 빠르기 때문이다.
• 또, '견종 검색 API'에서 '견종'자체가 344개로 매우 적은 데이터이기 때문에 이를 위한 새로운 캐시를 위해 별도로 Redis를 두는 것은 인프라 비용적인 측면에서 적절하지 못하다고 판단하였다.
• 참조블로그
  • https://steady-coding.tistory.com/647