기능 개발을 하다보면 DB 접근을 줄이기 위해 캐시를 사용하는 경우가 종종 생긴다.
그리고 그 캐시로 인해 에러를 겪는 경우도 제법 많다. 사실 내가 그랬다.
내가 겪은 에러는 '동시 접속'에 관한 문제였다. 웹에 뿌려지는 모든 텍스트를 DB화 했는데 페이지에 접근할 때마다 DB와 연동할 수는 없으니 캐시 처리하기로 했다.
초기 캐시를 세팅할 때부터 '어디에 캐시를 넣어야 하는가?'로 많은 토론을 했다. 그리고 최종적으로 DB 업데이트를 캐시에 반영하기 위해 로그인/로그아웃을 기준으로 캐시를 집어넣고 삭제하길 반복했다.
그러자 같은 계정으로 동시 접속한 경우, 한 계정에서 로그아웃을 하면 서버 상 캐시가 모두 날아가면서 다른 접속 기기가 먹통이 되어버렸다. 심지어 서버를 재실행해야만 그 기기를 다시 사용할 수 있었다. 동시접속을 테스트하지 않고 배포했다면 생각만으로도 끔찍한 결과를 초래했을 것이다.
문제를 발견한 시점부터 나는 캐시 처리 로직의 시점을 고민하기 시작했다. 그리고 세 가지 방법을 찾을 수 있었다.
Lazy Loading (On-Demand Caching)
데이터를 처음 요청할 때 캐시에 값을 넣습니다.
- 장점: 초기 로드 시간과 메모리 사용량을 줄일 수 있다.
- 단점: 첫 요청 시 데이터베이스 또는 원본 데이터 소스에 접근해야 하므로 지연이 발생할 수 있다.
- 사례: 주로 데이터 접근 빈도가 낮거나 모든 데이터를 미리 캐시할 필요가 없는 경우.
Eager Loading (Preemptive Caching)
애플리케이션 시작 시 또는 특정 이벤트 시 모든 데이터를 미리 캐시에 로드한다.
- 장점: 데이터 요청 시 지연이 거의 없다.
- 단점: 초기 로드 시간과 메모리 사용량이 증가할 수 있다.
- 사례: 데이터 접근 빈도가 높거나 애플리케이션 시작 시 빠른 응답이 필요한 경우.
Scheduled Loading (Periodic Caching):
일정한 시간 간격으로 캐시를 갱신한다.
- 장점: 캐시 데이터의 최신성을 유지할 수 있다.
- 단점: 시간 간격에 따라 최신 데이터가 필요할 때 약간의 지연이 발생할 수 있다.
- 사례: 데이터의 갱신 주기가 일정하고 약간의 데이터 지연이 허용되는 경우.
나는 모든 웹 상의 텍스트를 DB화한 만큼 서비스 전체 영역에서 필요한 캐시이니 Preeptive Caching을 사용했다. 또한 캐시를 삭제하는 로직을 지우고 CachePut만 사용하는 방식으로 변경했다.
또한 ehcache의 xml에서 캐시 유지 시간 자체를 eternal로 변경했다.
이후 동시접속 문제를 해결할 수 있었다.
