ehcache의 이해와 사용방법 예제

EH-cache란 우선, Spring 내부에 java 기반 오픈 소스 캐시 라이브러리다.

redis와, memchache와 달리, eh-cache는 데몬을 가지지 않고, 스프링 내부적으로 동작하여 캐싱처리를 한다.

또한 서버애플리케이션과 라이프사이클을 같이한다.

 

eh-cache는 2버전과 3버전의 차이가 크다.

 

3 버전 부터는 javax.cache API (JSR-107)와의 호환성을 제공한다. 따라서 표준을 기반으로 만들어졌다고 볼 수 있다.

또한 기존 2.x 버전과는 달리 3 버전에서는 offheap 이라는 저장 공간을 제공한다.

offheap이란 말 그대로 힙 메모리를 벗어난 메모리로 Java GC에 의해 데이터가 정리되지 않는 공간이다.

(offheap 과 java GC에 의한건 추후에 별도로 포스팅 해야겠다)

 

offheap은 힙밖에 저장을 한다는 것이고, Onheap은 힙 안에 저장을 한다는 것이다. 이것은 객체의 크기에 따라서,

Full GC를 유발할수있기 때문에 상황에 따라서 다르게 사용하는것이 어플리케이션 성능 향상에 좋다.

 

실제로, ehcache를 사용해보자,

 

1. build gradle 추가 (캐싱 관련된 라이브러리들을 추가해준다.)

2.ehcache.xml 파일. 추가 , apllication.yml 과 동일한 위치(application.yml에서 해당 config 파일경로를 잡아줘야하는데, 따로 가면 경로를 잡아주기 너무 귀찮다.)

ehcache의 모습

1.cache-template -> 캐시별로 적용된 템플릿이다. 별도로 캐시 개개인 별로 설정이 가능하다.

2.expiry -> 자동으로 관리. 및 유지하는데 들이는 시간이다. 기본 단위는 초이고, ttl,tti등의 속성을 가진다.

3.heap -> 메모리 크기 정의, ehcache3에서는 해당 힙 바깥쪽에도 등록을 할수있다고 하지만

해당 ehcache2를 먼저 실습해볼꺼라서 우선 해당 20 으로 설정한다.

 

캐싱을 사용할만한 상황

-> 반복적으로 같은 결과를 돌려주는 작업, 서버에 부하가 가는작업 (대량 조회 외부 api ,DB조회 등을 사용하는 경우)

캐싱을 하면 안될 상황

-> 데이터의 정확성에 민감한 것들, 데이터의 변화가 자주 일어나는 것들

 

 

3.applicatrion.yml에서 해당 config의 위치를 명시해준다.

 

 

 

사실 이렇게 되면, 사용할 준비를 모두 마친것이다.

그러면 이제 캐싱을 사용하여, 제대로 사용되는지 잘 적용되었는지 확인해보자

확인방법은 단순하게, 외부 url 요청시에, return 하는 객체의 주소를 sysout해서 확인할 예정이다.

 

 

우선 서비스에서, 메소드 단위로 사용하는 방법은 메소드의 이름위에

cacheable어노테이션을 주고, cacheNames로, 설정적용할 캐시이름, (condition 등등 다양한 설정 값들이 있다.)

이렇게 설정하면된다. 우선 캐싱을 적용하기 전에를 확인해봐야해서 우선 풀고 체크한다.

 

 

반복하여, 호출했을때 Post객체의 주소이다.

각각 다른 객체를 생성하여, 값은 같지만 주소는 다른 여러개의 객체가 생성되어 return되었음을 알수있다.

단순이 set해서 넘겼으니 값이 일정한데, 만약에 해당 객체가 db를 조회해서 return 하는 경우에는

해당 서버에 부하가 갈수있다.

 

그러면 캐싱을 적용해보자

 

여러번 호출해도, 동일한 주소를 return한다.

해당 expire 시간이 지나가면, 해당 객체에 대한 새로운 주소를 받을수있다.

 

간단하게 ehcache에 대한 적용을 해보았다.

해당 ehcache에 대한 튜닝을 하면 서버에 대한 엄청난 이득을 얻을수있다.

 

다음에는 해당 캐싱에 대해서 응용이랑 여러가지 심화 예제를 진행할 에정이다.