Cache#2 캐시에 대한 이해

📌 Cache

Cache는 컴퓨터 과학에서, 데이나 값을 미리 복사해놓는 임시 저장소를 가르킨다. 한글로는 고속완충기억기..지만 아무도 그렇게 안부른다

성능향상을 위해 결과를 캐싱(저장)하여 값을 재사용하는 것이며 보통 사용하는 입장에서는 캐싱 여부를 알 수 없다.

 

여러 분야에서 다양한 의미의 Cache가 사용되고 있지만,  스프링에서 말하는 캐시 추상화는 Java Method의 반환값 캐싱을 의미한다.

참고로 스프링의 @Cacheable 어노테이션을 클래스에 달면, 해당 클래스의 모든 메서드에 캐시가 적용된다.

 

 

📌 Cache 를 사용할 때 고려해야할 점

1. 캐시는 만능이 아니다.

- 캐시를 사용하는 목적은 성능의 향상과 서버 부하 방지이다. 자주 조회되는 곳에 사용해야 의미가 있다.

- 캐시는 반복적으로 동일한 결과를 주는 상황에서만 유효하다. 매번 결과가 달라지거나 업데이트된다면 의미가 없다

- 캐시의 유효성/유효시간(TTL, Time to Live)도 잘 생각해야한다. 캐시 때문에 최신이 아닌 옛 데이터를 계속 제공하고 있을 수 있다.

캐시를 아무리 떡칠해봐야, 캐시 적중률(Cache Hit Raito)가 낮다면 아무런 의미가 없다.

 

 

2. Local Cache 와 Global Cache 

로컬 캐시는 메모리, 즉 내부 저장소에 데이터를 저장한다. 속도가 빠르다는 장점이 있지만 서버간의 캐시 공유가 어렵다.

글로벌 캐시는 서버 외부에 캐시저장소를 사용한다. 서버간의 캐시 공유가 가능하나 네트워크 I/O가 필요하다는 단점이 있다.

 

이해를 돕기 위한 그림이다. 실제 동작은 구성하기 나름

단순히 '속도'만 생각한다면 로컬캐시가 좋아보일 수 있으나 로컬캐시는 Scale-Out 에 취약하다.

- 로컬 장비의 메모리를 사용한다. 캐시 크기가 커질수록 Was 인스턴스 크기가 커지게 된다.

- 캐시 데이터를 분산(Sharding)하여 저장할 수 없다. Scale-Out 시 전체를 복사(Replication) 해야한다.

- 캐시 데이터의 정합성이 깨질 수 있다. 같은 조회에서 서버마다 다른 결과를 반환할 수 있다.

- 이미 캐시에 저장되어있는 데이터가 변경되는 경우, 전체 서버에 변경을 전파해야한다.

 

Global Cache는 네트워크 I/O에 따른 지연시간이 생기지만, 트레이드 오프를 고려해서 사용해야한다. 정답은 없다. 내 서버가 Scale-Out하지 않고, 추후 늘어나봐야 2개 정도라면대라면 로컬캐시를 사용하는게 훨씬 좋을 수 있다.

 

물론 기능이나 상황에 따라 여러가지 캐시 방법을 섞어서 사용할 수도 있다.

실제로 스프링의 캐시 추상화는 이렇게 동작한다.

 

3. 운영 서버에 캐시 적용 시 확인해야할 체크리스트 ( 관련 글 링크 )

• ☀️ 캐시 히트율 (Cache hit ratio)를 모니터링하자.
  카나리 배포하여 먼저 hit, miss 확인 후 유효기간(TTL)이나 캐시 크기들을 고려해볼 수 있다. 이는 서버 모니터링으로 직접 확인하자.
  예를 들어 where in 절로 조회하는 데이터의 경우, 캐시 히트율이 엄청 낮아 캐시를 붙이는게 오히려 성능이 떨어질 수 있다.
  
  이 땐 캐시에서 먼저 조회한 후, 없는 데이터만 따로 조회/ 캐시에 추가하는 로직을 추가해 캐시 적중률을 높일 수 있다.
   
• ☀️ global cache를 사용할 경우, 캐시 때문에 잘못된 옛 데이터가 제공되는건 아닌지 확인하자.
  
  
• ☀️ 세션처럼 Scale-Out 된 모든 서버가 같은 데이터를 제공해야하는건 아닌지 확인하자
  물론 global cache를 사용하면 문제없지만, 서버 사용량이 정말 많은 경우 네트워크 지연 때문에 사용하기 어려울 수도 있다.
  정합성이 엄청나게 중요한 데이터가 아닌 경우, local cache의 TTL을 짧게하여 사용하는 방법도 있다.
  
  만약 정합성이 중요하다면 이벤트 버스를 구축하여 원본이 변경되었을 떄, 이벤트를 발행하는 방법도 있다.
  (zookeeper, kafka 같은 메시지 큐를 이용하여 서버에서 이벤트 구독 -> local cache 갱신)
  
  
• ☀️ 데이터에 만료일시가 있는 경우, 캐시까지 반영되는지 잘 챙겨야한다. ( ex 12월 31일 23시 59분까지만 사용하는 데이터)
  예를 들어 DB 쿼리로 endData < '202212312359' 까지 동작하게 해놓고, 이후 변경하는 로직이 있을 수 있다.
  이 때 데이터는 변경되었지만, 캐시는 만료되지 않았으므로 여전히 이전 데이터를 제공한다. 캐시 데이터도 확인해야한다.
  
  반대로 1월 1일 0시 0분부터 제공해야하는 데이터가 있는 경우에도 마찬가지로 캐시 TTL을 고려해서 만들어야한다.
  
  
• ☀️ 각 캐시에 대한 설정(만료정책, TTL, 캐시크기..) 등은 문서화하여 일괄적으로 관리해야한다.
  ex) batch 로 갱신되는 데이터의 경우, 배치 주기의 20~30% 정도로 TTL을 설정을 권장한다.
  
  
• ☀️ 캐시값 변조에 대해 고려해야한다.
  로컬 캐시의 경우, 캐시된 객체를 주고 받다가 내부 값을 실수로 변경할 수도 있다. -> 로컬 캐시안의 값도 함께 변경될 수 있다
  캐시값은 가능하면 불변한 객체로 사용하자. (물론 Json으로 Serialization 하여 캐싱한 후, 사용할 때 Deserialization 하면 괜찮음)

..계속해서 내용 추가할 예정..