CloudFront의 캐싱 히트율

 

 

 

사전적 개념

• 캐싱은 사전적으로 사용자들의 요청이 많은 콘텐츠를 별도 서버에 임시저장한 뒤 필요할 때마다 바로바로 데이터를 전송하는 기술을 의미한다.

개인적인 고찰

• 캐싱 히트율은 redis를 이용하는 것을 전제로 했을 때,
  조회에 성공한 횟수(redis에 실제 데이터가 존재함)/전체 redis 조회
  즉, 요청한 데이터가 캐시 저장소에 존재할 확률을 의미한다.
• 캐싱 히트율은 높을수록 서비스에서 캐시 저장소를 효과적으로 활용하고 있다는 것을 의미하게 된다. 하지만, 캐싱 히트율에 100%에 근사할 경우, 서비스에서 제공하는 모든 데이터가 캐시 저장소에 기반하고 있다는 것을 의미한다. 즉, 과도한 TTL 설정, 빈번하게 사용되지 않은 무의미한 데이터의 캐싱 등으로 인해 캐시 저장소의 리소스가 과부화되고 있을 우려가 있는 것이다.
• 반대로 캐싱 히트율이 낮다는 것은 그만큼 캐시 저장소가 제대로 활용되지 못하고, 기존 DB가 활용되고 있다는 것으로, 캐싱이 제대로 적용되지 못하고 있음을 의미한다.
• 이러한 맥락에서, 캐싱 히트율은 서비스의 특징, 인프라 등에 따라서 적절함의 정도가 달리 판단된다.
  - 모든 데이터를 캐시 메모리에 저장하고 클라이언트에 응답하면 좋겠지만, 이는 리소스 과부하를 야기하여, 캐시 메모리의 취지에 부합하지 않을 뿐더러, 캐시 메모리 성능을 저하시키는 것이다.
• 아울러, 적절한 캐싱 히트율을 위해 적절한 TTL 설정, write-through/lazy-loading 등 캐싱전략 혼용이 필요하다.

 

위의 맥락에서, 캐싱은 다음과 같은 상황에서 적용이 고려되어야 한다고 생각된다.

(대부분의 서비스들이 위 맥락에 따라 캐싱을 적용하고 있을 것이라 추론한다.)

• 서비스에서 제공하는 데이터의 양이 방대해짐에 따라, 쿼리 처리 속도가 매우 느려짐.
• 사용자가 특히 많이 이용하는 서비스의 경우, 그러한 쿼리 처리 속도가 사용자 경험의 질을 저하시킴.

요컨대, 캐싱은 기존 데이터베이스의 부하를 최소화하고, 클라이언트의 응답 속도를 개선하기 위한 목적으로 사용되는 "임시 메모리"이다.

캐싱 목적으로 사용되는 서버 내지는 DB가 서비스에서 제공하는 모든 데이터를 모든 순간에 제공한다면, 이는 그 DB가 서비스의 메인 DB로 활용된 것이지 "캐싱" 목적으로 활용된 것이 아닌 것이다.