Cache

캐싱은 DB 정보를 매번 조회하지 않아도 되므로, 응답속도에도 잇점이 있고, DB 부하를 줄일 수 있는 잇점도 있다. 

보통은 MemoryDB 인 Redis를 많이 사용하고, 외부 Redis를 통해 다수의 서버가 캐싱을 공유 한다. 

 

캐시를 잘못 사용하게 되면 오히려 미스매치로 인해 Cache 검색 + 실제 DB 조회 때문에 오히려 성능이 더 떨어질 수 있다. 

따라서 적절한 데이터를 캐싱해야 한다. 

 

캐시 해야 하는 데이터와 그렇지 않은 데이터

• 쓰기 항목보다 읽기 항목이 월등히 많은 데이터
• 실시간 데이터 혹은 변동이 많은 데이터는 캐싱하면 안된다.

 

캐싱 방법

• 가장 최근에 읽은 데이터
  • 시간 기반
• 인근 데이터들 혹은 연관 데이터들을 캐싱하는 방법(페이지네이션 등)
  • 연관성 기반

 

주의점

• 캐싱에는 오래된 데이터가 캐시에 의해 리턴될 수 있으므로, 쓰기 작업이 일어났을때 캐시갱신 혹은 무효화가 필요하다.

 

캐싱 방법

• Cache-Aside : 어플리케이션이 캐시를 직접 관리 하는 것으로 일반적으로 많이 사용.
  • 데이터 조회 요청 -> 캐시에 있으면 바로 반환하고 만일 없을시 DB에서 조회 후 데이터 반환 -> 캐시에 저장
  • DB에 저장된 데이터와 캐시에 저장된 데이터가 불일치 할 수 있다. 
    
    
• Write-Through : 쓰기 작업시 DB 및 캐시에 동시 저장
  • 데이터 쓰기 요청 -> DB와 캐시에 둘다 저장 -> 응답
  • 읽기가 많지 않은 데이터 까지 캐시에 저장하다보니, 효율성이 떨어질 수 있다.
    
    
• Write-Behind : 쓰기 작업시 캐시에 먼저 저장하고 응답 후 DB에 반영
  • 데이터 쓰기 요청 -> 캐시에 기록 후 바로 응답 -> 비동기로 캐시에 있는 항목을 DB에 모아서 반영
  • 캐시 서버 장애시 DB에는 반영되지 않아서 데이터가 영구적으로 유실 될 수 있다.
  • 잘 쓰지는 않는 방식이다.

 

캐시 웜업

캐시를 초반에 구성해 놓았을 경우 캐시에 아무것도 없기 때문에 결국 DB로 요청이 몰리게 된다. 또한 캐시의 갱신이 필요한 경우에도 마찬가지 이다.  따라서 자주 노출되는 데이터에 한해서 batch 작업을 통해 캐시를 주기적으로 갱신해 놓는것을 말한다.

 

 

캐시 누수 방지

• 무제한으로 증가하는 키 (예 : uuid) 를 설정하면 안된다.
• 만료 시간이 없거나 너무 길 경우 문제가 된다.
• 크기 제한 (maxSize) 설정이 없으면 무한히 축적된다.
• 모니터링을 통해 메모리 증가 추세를 잘 살펴봐야 한다. 
• 데이터 삭제시 캐시 삭제를 잊지 말아야 한다. (필요하다면 갱신시 에도)

 

캐시 오염 및 무한캐싱 문제

• 부적절하거나 불필요한 데이터가 캐시를 점유해서 필요한 데이터가 캐싱되지 못하는 것을 말한다. 
  • null 값, 빈 문자열, 에러메시지, 예외상황 결과 등이 캐싱되는 경우
    
    • 예 : 특정 메서드에 캐싱 설정이 되어 있고 try-catch 로 묶여있으며, 실패했을때 기본값을 리턴하는 경우 등
  • 대용량 객체 (이미지, 파일, 복잡한 객체 등) 를 무분별로 캐싱하는 경우
  • 만료시간 미설정 혹은 너무 과도하게 긴 만료시간 설정시
• 이를 방지 하기 위해 condition, unless 속성을 통해 null 값일 경우, 용량이 큰 경우 등을 제외하고 캐싱하겠다는 설정 필요.