Dev

General한 Cache 적용 위치

친환경사과 2024. 9. 1. 16:27

🍎 일반적인 상황에서 Cache를 위치시킬 때 참고할만한 사항을 글로 정리합니다. 일반적인 상황이며 경우에 따라서 Cache 적용 위치가 달라질 수 있습니다.


❓ Cache는 무엇이며 어떨 때 사용해야 할까?

- Cache는 데이터를 저장하여 빠르게 접근할 수 있도록 하는 메모리 구조 또는 저장소입니다. 자주 사용되는 데이터나 계산 결과를 미리 저장해 두어, 동일한 데이터에 대한 요청이 있을 때 데이터를 다시 계산하거나 원본 데이터 소스에 접근하는 대신, 저장된 데이터를 빠르게 제공함으로써 성능을 개선할 때 사용합니다.


🍏 어느 위치에 Cache를 적용했을 때 성능을 높일 수 있을까요?

  1. 병목지점 파악 : 병목지점은 여러 요인에 의해 파악할 수 있습니다. 데이터가 얼마나 자주 변경되는지, 얼마나 자주 조회되는지 등을 통해 알 수 있습니다.
    • DB가 복잡한 쿼리를 처리할 때 속도가 느려 웹 페이지 로딩 시간이 길어지는 것을 병목지점의 예로 들 수 있습니다. 이를 해결하기 위해 쿼리 결과를 캐시에 저장해 DB 접근 대신 캐시 저장소에서 직접 데이터를 가져와 성능을 개선할 수 있습니다.
  2. Cache Size를 고려 : Cache Size는 사용되는 Cache Key의 개수를 통해 알 수 있습니다. 동일한 효과를 내는 Cache 위치라면 Cache Size를 더 적게 사용하는 위치가 좋습니다.
    • Cache Size를 적게 사용하는 것이 많이 사용하는 위치보다 성능에 대해 유리한 이유는 제한된 캐시 저장소 크기와 관련되어 있습니다.
    • 캐시의 크기가 작고 캐시 키가 많을 경우, 캐시 충돌이나 메모리 오버헤드가 증가할 수 있습니다. 즉, 키의 개수가 많으면 충돌 확률이 높아져 데이터 조회 성능이 저하될 수 있습니다.
  3. Cache Hit Rate: 동일한 응답 시간을 갖는다면 최대한 Hit Rate가 높은 곳에 Cache를 위치시키는 것이 좋습니다.

🍎 한 걸음 나아가 생각해보기

- Cache는 다시 호출될 확률이 높은 부분에 사용되는 것이 효율이 좋습니다. 하지만 모든 상황에서 적용이 될까요?

🍏 예외 상황

- 사용자가 3월 3일 오전 9시부터 다음날 오후 3시까지 앱 사용자 통계 값을 얻고 싶어 합니다.

- 위의 상황에서 데이터의 지역성을 명확하게 할 수 있을까요? 다음 사용자는 다른 시간대에 통계 데이터를 원할 수 도 있습니다.

- 다시 말해 사용자마다 원하는 통계값이 다르다면 높은 Cache Hit Rate를 얻기 힘들다는 이야기입니다.

🤔 이러한 상황에서는 어떻게 해야할까요? Cache를 적용하면 안되는 것일까요?

- 하지만 Cache를 적용하지 못하는 것은 아닙니다. 특정 시점의 통계값을 요구하는 것은 많은 상황에서 일어나지 않을 것이고 LRU 알고리즘에 의해 조회되지 않으면. 즉, 오랫동안 참조되지 않으면 사라지게되어 Cache를 적용해도 무방합니다.