인메모리 캐시는 많이 사용할까라는 걱정? 고민이 있었다.

추천할 영상은 개발바닥 채널의 카카오같은 회사는 왜 퇴사하는걸까? - 솔직하게 말씀드림 #1이다.

영상의 9분 35초에서 향로님께서 게스트에게 캐시 관련 질문을 한다. Ehcache, Redis, MemCache 등 캐시 레이어에서 쓸 수 있는 솔루션이 많은데 어떤 것을 사용했냐는 질문을 한다. 이후에도 이에 관한 기술적인 부분에서 약간의 티키타카가 오간다. 이후 영상 후반부에도 DB와 관련된 좋은 내용이 나오니 참고하면 좋을 것 같습니다.

 

결론적으로 게스트님께서 맡은 도메인에서는 Ehcache를 사용했다고 합니다. Ehcache는 톰캣 서버 내에서 사용할 수 있는 캐싱 구현체 중 하나이다. 쉽게 말해 스프링 부트로 프로젝트를 개발하면 사용할 수 있다. Spring Boot docs를 참고하면 다양한 캐싱 구현체를 확인할 수 있습니다.

 

개인 프로젝트에서는 나도 상품 도메인의 읽기 요청을 인메모리 캐시를 사용했었다. 구현체로는 Caffeine cache를 사용했는데 따로 정리하진 않았지만 성능적으로 좋다고해서 선택했다. 머쓱...ㅎ

 

그 외에는 기본적인 캐싱의 동작 방식에 대해서만 공부했지 더 깊게는 공부하지 않았다. 왜냐하면 나는 이 인메모리 캐시 솔루션이 부하를 분산하는 환경에서는 동기화 문제가 발생하기 때문에 보편화된 방식이 아니라고 생각했기 때문이다.

 

톰캣 서버를 한대만 사용한다면 상관없지만 부하 분산 환경에서는 인메모리 캐시를 사용할 경우 문제가 생길 수 밖에 없다. 만약에 10대의 톰캣 서버에서 라운드 로빈 방식으로 부하 분산을 받는다고 했을 때, 캐시가 동기화될려면 꽤 많은 시간이 걸릴 수 있다.

 

나는 이 문제를 심각하게 생각해서 경로 기반 라우팅을 통해 캐시가 발려져있는 로직은 특정 인스턴스로만 요청을 보내도록 변경했었다. 하지만 영상 내용을 보면 굳이 동기화가 늦게 되어도 상관이 없는 영역이기 때문에 그 단점을 안고 갈 수 있다고 한다.

 

이만 자야겠다.