캐싱의 정의와 똑똑하게 캐싱하기

캐시의 보편성

캐시는 가장 낮은 수준부터 가장 높은 수준까지 어디에나 존재한다.

캐시의 정의

일시적으로 일부 데이터를 일정 시간 동안 저장하기 위한 계층.

캐시의 필요성

정보를 때마다 새로 생성하는 비용이 높기 때문

사용자 응답 속도를 높이기 위해서

캐시 무효화의 정의

캐시에 있는 데이터를 무효로 표시하는 프로세스

캐시 무효화 이후에 요청이 도착하면 캐시 미스로 처리되어 데이터베이스에서 새로 생성되어야 함.

캐시 무효화의 필요성

out-dated 데이터를 제공하게 될 수도 있기 때문에.

캐시 무효화가 어려운 이유

프로그램에 그렇다 할 장애가 없기 때문에 디버깅이 매우 어려움.
"관련 콘텐츠 링크"를 뿌려주는 페이지가 있다고 했을 때, 어떤 링크가 404가 떠서 이 링크를 삭제하기로 했지만 여전히 캐시 데이터가 뿌려질 때, 디버깅이 매우 어려움.
"여러 개의 상호 연결된 캐시가 있는 분산 시스템에서는 많은 종속성, 경쟁 조건 등으로 인해 무효화가 더욱 어려워집니다." => 복잡한 시스템의 경우 캐시를 뿌리는 프로세스 상에 꼬리에 꼬리를 물고 이어지는 종속성이 있는 경우가 발생을 하는 것 같음.

캐시를 사용하지 않아야 하는 경우

실시간성이 매우 중요한 데이터의 경우 - 예 : 환자의 실시간 의료 데이터, 자율 주행 모드일 때의 실시간 센서 데이터
캐시 하지 않아도 속도가 느리지 않은 데이터
데이터를 가져오는 작업 자체가 의미가 있어 캐싱에 적합하지 않은 경우 (카운터를 업데이트 해야하는 DB 트랜잭션)
캐시 히트가 적절하지 않은 경우 - 만약 캐시 없이 그냥 반환하면 한 요청당 60ms가 걸리고 캐시가 있는지 확인할 때는 10ms가 소요된다고 쳤을 때, 데이터의 5%만 캐시가 되면 95%의 요청에 대해 60ms + 10ms가 추가로 걸리므로 실제로 캐싱이 성능을 오히려 더 떨어뜨린다는 것을 알 수 있음.
캐시 전 : 100 requests * 60ms per request = 총 6,000ms
캐시 후 : (0.05 * 100 * 10ms) + (0.95 * 100 * (60ms + 10ms) ) = 총 6,700ms

참고 자료

와와의 개발 이야기