자바에서 캐싱 솔루션

개요

데이터 캐싱은 자바 애플리케이션에서 매우 중요한 고려사항이다. 데이터 캐싱은 분산 애플리케이션에서 원격 호출의 수를 한정시키고 영구 데이터 저장에 대한 호출 수를 줄임으로써 웹 애플리케이션의 성능을 향상시킨다. 캐싱이 성능을 향상시키고 아키텍처가 실제로 동작하도록 하는데 기여하지만, 사실 설계를 복잡하게 하고 동시성 코드와 클러스터에 대한 동기화와 같은 복잡성을 유발시킬 수도 있다.

일단 데이터 캐싱이 아키텍처의 필요한 부분이라고 결정되었다면, 적합한 캐싱 솔루션을 채택하는 것이 어려울 수 있다. 항상 캐싱 솔루션을 구현하는데 선택사항이 있다. 이러한 접근방법은 분명 장점이 있을 수 있지만, 프로젝트의 비용과 시간에 불가결하게 영향을 미치게 된다. 또 다른 방법은 오픈 소스 캐싱 제품들 중에 하나를 선정하는 것이다. 캐싱 솔루션을 선정할 때 다음과 같은 사항들이 고려되어야 한다.

1. 캐싱 솔루션은 ORM 제품과 쉬운 통합을 제공하는가?

캐싱 제품은 Hibernate나 Toplink와 같은 유명한 ORM 제품들과 쉽게 통합이 되어야 한다. 도메인 객체는 RDBMS 엔티티에 매핑되는 POJO이며, 메모리에 캐싱된다. 따라서, RDBMS의 네트워크 트래픽을 줄이게 된다.

2. 캐싱 솔루션은 프레젠테이션 레이어 캐싱을 지원하는가?

캐싱 제품은 프레젠테이션 레이어의 HTTP 응답/JSP 캐싱을 지원해야 한다.

3. 캐싱 솔루션은 객체 저장을 메모리와 디스크에 저장하도록 가능한가?

메모리 용량이 찼을 경우, 캐시 제품은 객체를 로컬 디스크에 저장해야 한다.

4. 사용하기 쉬운가?

캐시 제품은 이를 사용하는 클라이언트에게 최소한의 API를 노출해야 한다.

5. 분산 캐시를 지원하는가?

각 JVM내에 있는 캐시는 클러스터링 환경에서 연합될 필요가 있다.

6. JVM과 같이 객체의 공유를 가능하게 하는가?

하나의 JVM 내의 모든 애플리케이션 쓰레드는 캐시의 한 객체에 대한 동일한 인스턴스를 접근할 수 있어야 한다.

7. 캐시 무효화를 지원하는가?

캐싱 제품은 캐시나 캐시 그룹을 무효화시키는 기능을 제공해야 한다. 캐시 무효화는 분산 캐시에서 일원화되어야 한다.

8. 가용성 수준은 어떤가?

캐시는 로컬 복사를 유지한다. 어떤 오퍼레이션은 원본 소스가 사용할 수 없더라도 지속 가능해야 한다.

9. 유지하기 쉬운가?

캐시 제품은 코드를 디버깅하기 위해 적절한 로깅 기능을 제공해야 한다.

10. 표준을 준수하고 있는가?

JCache가 표준이며, JSR 107 캐싱 서비스가 JCP 에서 만들어졌다. 캐시가 표준을 지원한다면, 클라이언트는 캐시를 일관된 형태로 접근할 수 있다.

가능 오픈 소스 솔루션들

위에서 언급되었던 내용을 기반으로, 자바 객체를 캐싱하는 다양한 제품들을 평가할 것이다. 다양한 제품들에 대한 가장 중요한 기능은 다음과 같다.

1. OSCache (http://www.opensymphony.com/oscache/)

1.1 HTTP 응답 캐싱
이 기능은 정적인 HTML 페이지를 처리할 때 유용하다. 페이지 응답이 메모리 상에서 무기한으로 캐싱될 수 있으며 따라서 페이지에 대한 재처리 과정을 피할 수 있다. OSCache는 유일한 키를 만들기 위해 URI와 질의 파라미터를 사용한다. 이 키는 페이지 내용을 저장할 때 사용된다. HttpResponse 캐싱은 ServletFilter를 사용해서 구현된다. 따라서, 캐시 필터가 클라이언트에게 API 사용을 추상화시킨다. 캐시 필터에 대한 설정은 web.xml에서 수행한다. 기본적으로 Cache Filter가 'Application' 영역의 페이지 응답을 캐싱하며 1시간 마다 캐시를 리프레쉬시킨다. 이러한 기본값들은 변경할 수 있다.

1.2 JSP 태그 라이브러리 캐싱
동적 페이지(JSP)의 경우, OSCache는 페이지에서 정적인 부분을 둘러싸고 있는 태그를 지원한다. 따라서, 페이지의 정적인 부분만이 캐싱된다.

1.3 데이터 접근 레이어 캐싱
모든 ORM 도구들은 RDBMS 개체들을 도메인 객체로 매핑한다. OSCache는 ORM 도구를 통해 반환받은 도메인 객체들을 캐싱하는데 사용될 수 있다. 이는 DBMS 서버로의 네트워크 연결의 수를 극적으로 줄여주고 객체 생성에 관련한 비용을 줄인다. 대부분의 ORM 도구들은 캐싱에 대한 플러그 가능한 아키텍처를 제공한다. 즉, OSCache는 모든 ORM 도구로 플러그인이 가능한다. ORM 도구는 클라이언트에게 도메인 객체에 대한 캐싱을 관리한다.

OSCache는 저장 캐시에 대해 설정이 가능하다. 메모리 용량이 찼을 때, 객체들을 메모리에서 꺼내와서 하드 디스크에 저장한다. 객체들을 설정된 캐시 알고리즘을 기반으로 메모리로부터 꺼내온다. 하지만, 하드 디스크 캐시를 처리할 때에는 주의가 필요하다.

독창적인 OSCache는 LRU(Least recently used)와 FIFO(First In First Out) 알고리즘을 사용한다. 두가지 알고리즘 모두 OSCache로 설정이 가능하다. 하지만, 다른 특정 알고리즘 역시 OSCache에서 설정에 의해 사용이 가능하다.

캐시 API는 비교적 사용이 쉽다. "GeneralCacheAdministrator"의 인스턴스가 생성되고 캐시 관리자가 캐시의 개체를 추가, 변경, 대체(flush)하는데 사용된다.

OSCache는 분산 캐싱을 지원한다. 애플리케이션이 애플리케이션 서버의 클러스터에 배포될 때 로컬 캐시가 클러스터의 모든 캐시 간의 통신을 통해 동기화를 유지시켜준다. 하지만, OSCache는 클러스터의 상태 관리를 위해 복잡한 지원을 제공하지 않는다.

OSCache는 JSR 107 표준을 준수하지 않는다.

2. EHCache (http://ehcache.org/)

2.1 HttpResponse와 페이지 영역 캐싱
EHCache는 정적 페이지 캐싱을 위해 'SimplePageCachingFilter'를 제공한다. SimplePageCachingFilter는 또한 브라우저에 HttpResponse를 gzip 형태로 압축해서 보내주고, 브라우저는 응답을 압축을 풀고 클라이언트에 보여준다. JSP와 같은 동적인 페이지에 대해 EHCache는 JSP의 정적 부분을 캐싱하기 위한 'SimplePageFragmentCachingFilter'를 제공한다. 하지만, 페이지 영역 캐시를 위해 OSCache와 같은 태그 라이브러리는 제공하지 않는다. 페이지 영역 캐시는 뷰에서 그리 잘 사용되지 않는다.

2.2 데이터 접근 캐싱
EHCache는 DB 엔티티에 대해 매핑하는 도메인 객체들을 캐싱하는 기능을 제공한다. 사실, EHCache는 Hibernate에서 기본 캐시로 사용된다. EHCache는 메모리와 디스크 저장을 지원한다. EHCache는 메모리로부터 객체를 꺼내오는 독창적인 알고리즘으로 LRU(Least Recently Used), LFU(Least Frequently Used), FIFO(First In First OUT) 알고리즘을 제공한다. EHCache는 분산 캐싱을 지원한다. 기본 구현은 멀티캐스트 혹은 수동 설정에 의한 캐시 탐색을 지원한다. 변경 사항이 사용자가 설정할 수 있는 RMI 연결을 통해 동기 혹은 비동기 방식으로 전달된다. 다른 업체가 만든 탐색 혹은 전달 체계가 플러그인 될 수 있다.

EHCache API는 매우 단순하며 사용하기 쉽다.

EHCache의 중요한 기능은 JMX를 사용할 수 있다는 것이다. 다음과 같은 내용들을 모니터링할 수 있다.

• CacheManager
• Cache
• CacheConfiguration
• CacheStatistics

EHCache는 최근의 JSR 107 JCache에 대한 가장 완벽한 구현체를 제공한다.

3. Jofti (http://www.jofti.com)

Jofti의 몇가지 두드러진 기능은 다음과 같다.

1. Jofti는 인덱싱 메커니즘을 제공한다는 차원에서 다른 캐시 구현체와는 다르다. 따라서, 캐시에서 객체를 조회하기 위해서 어떤 임의의 키가 아닌 객체의 속성들 중에 하나에 대해 조회를 한다.
2. Jofti가 제공되는 인덱싱 메커니즘은 자주 변경되는 경우에 잘 사용된다.
3. Jofti는 쉽게 사용 가능한 프로그래밍 인터페이스를 제공한다.
4. 그 자체에 대한 캐시 구현체를 제공하지 않는다. 하지만, 어떠한 캐시 구현체도 인덱싱 메커니즘으로 플러그인 될 수 있다.
5. 다음의 캐시 구현체가 현재 Jofti가 지원하는 것들이다.

• EHCache
• OSCache
• JBoss Cache
• Tangosol Coherence

따라서, 위의 캐싱 제품들은 Jofti의 인덱싱 기능으로 플러그인될 수 있다. 각각의 캐시가 제공하는 캐싱 기능을 Jofti와 같이 사용이 가능하다. Jofti 인덱싱 메커니즘은 여러 캐시에서 실행이 가능하다. 캐시는 로컬 캐시이거나 클러스터링된 캐시일 수 있다.

Jofti가 그 자체의 캐시 구현체를 가지고 있지 않기 때문에 플러그인 되는 제품의 구현체에 따라 달라진다.

3.1 Jofti의 인덱싱 메커니즘 질의
Jofti의 메커니즘은 '키'를 기반으로 하는 전통적인 질의 방식과는 별도로 객체에 대한 인덱스를 질의하는 총제적인 방법을 제공한다. Jofti는 EJB-QL과 SQL(ANSI)를 지원한다.

3.2 설정
Jofti가 그 자체의 고유 캐싱 메커니즘을 가지고 있지 않기 때문에 플러그인 되는 캐시 제품을 사용하기 위해 설정이 필요하다. Jofti는 다음과 같은 두가지 방식으로 설정될 수 있다.

• 래퍼 형태 : 이러한 방식에서 Jofti는 클라이언트에 대한 어댑터로 작용한다. Jofti는 Jofti로 플러그인 되는 내부 캐시를 호출을 탐색하는 고유한 API를 제공한다.
• 리스터 형태 : 이러한 방식에서 클라이언트는 캐싱에 대한 캐시의 API를 사용한다. Jofti의 인덱스 구현체는 리스너처럼 사용된다. 인덱스는 캐시의 API가 호출될 때마다 변경된다.

Jofti는 JTA 구현체를 통해 트랜잭션 지원을 제공한다. 만일 캐시가 트랜잭션 형태의 변경을 지원하지 않으면, Jofti는 'javax.transaction.Synchronization' 인터페이스를 사용한다.

4. ShiftOne (http://jocache.sourceforge.net/)

• ShiftOne은 가벼운 캐싱 프레임워크이다.
• ShiftOne은 LRU(Least Recently Used), LFU(Least Frequently Used), FIFO(First In First Out) 알고리즘과 같은 몇가지 캐시 알고리즘 구현체를 제공한다. 이러한 알고리즘들은 '정책 캐시'로 참조된다. 이는 다른 캐싱 메커니즘을 ShiftOne으로 설정하는 방법을 제공한다.
• ShiftOne은 캐시를 유지하기 위해 내부 캐싱 제품을 사용하는 몇가지 장치를 제공한다.

다음 캐싱 제품들이 ShiftOne으로 플러그인이 가능하다.
EHCache
SwarmCache
JCS Cache
Oro Cache

• ShiftOne은 통계 수집을 위해 JMX 구현체를 제공한다.
• 다른 제품과 같이 ShiftOne은 쉬운 프로그래밍 인터페이스를 제공한다.
• 트랜잭션 형태의 캐시를 제공하지 않는다.
• ShiftOne은 분산 캐시를 제공한다.

5. WhirlyCache (https://whirlycache.dev.java.net/)

WhirlyCache는 내장 메모리 캐시를 제공한다. WhirlyCache는 캐시를 없애는 별도의 쓰레드를 실행한다. 즉, 캐시로부터의 데이터가 클라이언트가 사용하는 동일한 애플리케이션 쓰레드에 의해 제공되지 않는다. 따라서, 애플리케이션 쓰레드에 대한 부담이 거의 없다. WhirlyCache는 메모리에 모든 데이터를 캐싱한다. 뒷단 쓰레드가 tuner 쓰레드에 의해 호출된다. 캐시마다 하나의 tuner 쓰레드가 있다. tuner 쓰레드는 매 n 초 간격으로 실행되도록 설정될 수 있다. 가장 최고에 도달했을 때 JVM 힙을 사용하려고 한다. - 캐시 메모리의 용량은 적절하게 세팅되어야 한다. WhirlyCache는 디스크 오버플로우 기능을 제공하지 않는다. 메모리 문제를 처리하기 위해 WhirlyCache는 소프트 참조(soft reference)를 사용한다. tuner 쓰레드는 사용되지 않는 참조를 제거하기 위해 cache를 모두 스캔한다. 내부적으로 WhirlyCache는 저장된 객체에 대한 소프트 참조를 유지하기 위해 FashHashMap과 ConcurrentHashMap을 사용한다.

5.1 프레젠테이션 레이어 캐싱

WhirlyCache는 JSP의 캐시 부분에 대해 JSP 태그 라이브러리나 PageFragmentFilter를 제공하지 않는다. 화면 레이어에 대한 HttpResponse 캐시를 지원하지 않는다.

5.2 데이터 레이어 캐싱

WhirlyCache는 데이터 접근 레이어의 도메인 객체에 대한 캐싱을 지원한다. WhirlyCache는 유명한 ORM 프레임워크인 Hibernate로 플러그인이 가능하다.

WhirlyCache에 대한 설정은 기본 값과 같이 있는 'whirlycache.xml'이라는 XML 파일에서 수행될 수 있다.

WhirlyCache는 캐시를 접근하는 프로그램적인 API를 제공한다.

6. SwarmCache (http://swarmcache.sourceforge.net/)

SwarmCache는 데이터 접근 레이어의 도메인 객체를 캐싱하기 위한 내장 메모리 캐시이다. 클러스터링 환경에서 분산 캐시를 위한 지원을 제공한다. 변경/삭제가 캐시의 도메인 객체에서 발생할 때 영향받는 캐시의 캐시 관리자가 캐시를 변경하기 위해 클래스터의 모든 다른 관리자와 통신하게 된다. 클러스터의 캐시에 대한 변경의 수가 증가할수록 성능이 느려진다. 캐시에 대한 모든 변경이 로컬 캐시를 변경하는 모든 캐시 관리자에 영향을 미친다.

6.1 프레젠테이션 레이어

SwarmCache는 HttpResponse 캐싱에 대한 지원을 하지 않는다. 또한 동적 JSP 페이지의 페이지 부분의 캐싱을 지원하지도 않는다.

6.2 데이터 접근 레이어 캐싱

위에서 언급했듯이 SwarmCache는 이 레이어의 도메인 객체의 캐싱을 지원한다.

유명한 ORM 도구로 플러그인 되는 SwamCache의 언급이 없다. 따라서, 데이터 접근 레이어의 캐싱은 특별히 SwarmCache의 API를 사용해서 수행될 필요가 있다고 가정된다.

SwarmCache는 LRU 캐싱 알고리즘을 지원한다. 하지만, SwarmCache는 기본적으로 내장 메모리 캐시이다. LRU가 캐싱 알고리즘으로 세팅되고 메모리 용량이 도달했을 때 SwarnCache는 메모리에서 LRU 로직마다 메모리 객체를 꺼낸다.

SwarmCache는 캐싱된 객체에 대해 소프트 참조를 사용한다. 따라서, LRU가 캐싱 알고리즘으로 세팅되지 않았다면, 메모리를 정리하고 최근에 자주 접근한 객체를 정리하기 위해 가비지 콜렉터에 의존한다. 하지만, SwarmCache는 캐싱 알고리즘으로 세팅되는 위의 두가지의 조합을 추천한다.

로컬 캐시를 정리하기 위한 API를 제공한다.

7. Java Caching System (JCS) (http://jakarta.apache.org/jcs/)

• JCS는 메모리나 혹은 RMI를 사용한 원격 서버에 대한 디스크에 데이터를 캐싱하는 것을 지원하는 캐시이다. JCS는 데이터 접근 레이어의 데이터를 캐싱하는데 더 적합하다.
• JCS는 HttpResponse에 대한 캐싱과 화면 레이어의 페이지 영역 캐싱을 지원하지 않는다.
• JCS는 분산 캐시를 지원한다. 로컬 캐시에 대한 모든 변경과 무효화는 클러스터에 관련된 모든 캐시에 전달된다. 그러므로, JCS는 자주 읽고 간헐적인 변경을 갖는 어플리케이션에 더 적합하다고 생각할 수 있다.
• JCS 캐시 영역은 메모리, 인덱싱된 디스크 공간, 원격 캐시, 측면 캐시(lateral cache)에 위치할 수 있다. 캐시에 대한 조합 역시 설정될 수 있다. 만일 메모리의 영역이 찼다면, 객체는 디스크로 옮겨진다.
• JCS에서 디스크에 있는 데이터는 디스크에서 쉽게 가지고 오게끔 하기 위해 인덱싱된다. 동일한 노드 상에서 운영되는 여러 웹 서버 JVM을 가지고 있는 경우 원격 캐시가 더 적합하다.
• JCS에 대한 설정은 config.ccf 파일이라고 하는 속성 파일에서 세팅된다.
• JCS는 자바 클래스로부터 캐시를 접근하기 위핸 API를 제공한다.

8. Cache4j (http://cache4j.sourceforge.net/)

• Cache4j는 메모리에 있는 객체만 저장하는 자바 객체에 대한 캐시이다. 데이터 접근 레이어의 POJO 객체를 캐싱할 때 주로 사용된다.
• LRU (Least Recently Used), LFU (Least Frequently Used), FIFO (First In First Out) 캐싱 알고리짐을 지원한다. 캐시에 객체를 저장하기 위해 Cache4j는 하드와 소프트 참조를 제공한다. Cache4j는 여러 애플리케이션 쓰레드가 동시에 캐시를 접근할 수 있도록 하는 방법으로 구현된다.
• Cache4j는 프로그래밍 API를 사용하기 편리하게 제공한다.

9. JBoss Cache (http://www.jboss.org/jbosscache)

JBoss는 'TreeCache'와 'PojoCache'라고 하는 두 종류의 캐시를 제공한다. 두가지 캐시에 대한 내용을 자세하게 살펴보자.

9.1 TreeCache

JBoss TreeCache는 POJO를 저장하는 캐시이다. 하지만, 캐시에 저장된 모든 객체는 직렬화된 자바 객체이어야 한다. 즉, 객체는 분산 트리 캐시에서 java.io.Serializable 인터페이스를 구현해야 한다. 캐시는 트리 형태로 구조화 된다. - 트리의 각 노드는 맵이다.

트리 캐시는 로컬이거나 분산 형태일 수 있다.

만일 POJO의 필드에 대해 변경이 가해지면, 트리 캐시는 전체 POJO를 직렬화시킨다. 이는 객체 크기가 클 경우 비용이 비쌀 수 있다.

JBoss TreeCache는 메모리에 캐싱을 제공한다. 만일 메모리가 한계에 도달하면, 객체는 디스크로 옮겨진다.

트리 캐시는 JMX가 가능하다. MBean 서버에서 캐시와 관련된 통계를 제공할 수 있다.

캐시 이벤트가 발생할 때 리스너를 부착시키는 클라이언트 코드에 대한 후크를 제공한다.

트린 캐시는 트랜잭션 형태를 자연적으로 지원한다. 따라서, 캐시에 있는 객체에 대한 변경/무효화는 트랜잭션인 성공적으로 커밋된 후에만 캐시의 모든 트리로 복제된다. 트랜잭션이 실패하는 경우, 트리 캐시 간에 어떠한 통신도 발생되지 않는다.

JBoss TreeCache는 유명한 애플리케이션 서버인 IBM WebSphere, Bea WebLogic, Hibernate ORM 도구 등 어떠한 서버에도 플러그인 될 수 있다. 또한 애플리케이션 서버의 컨텍스트에서 실행되지 않는 독립형 자바 애플리케이션에서 사용될 수 있다.

주의 : JBoss TreeCache는 도메인 객체에 대한 캐싱을 지원하며, JSP와 같은 동적 페이지의 경우 HttpResponse 캐싱과 Fragment 캐싱은 지원하지 않는다.

9.2 POJO 캐시

애초에 POJO 캐시에 있는 객체는 java.io.Serializable 인터페이스를 구현할 필요가 없다는 차원에서 TreeCache와는 다르다.

POJO 캐시는 고운 입자(fine grained) 복제를 지원한다. 즉, POJO에 가해지는 변경만이 직렬화된다. 또한, 객체에 대한 변경은 자동으로 클러스터 간에 복제된다. 이러한 행위를 위해 어떠한 API 호출을 할 필요가 없다.

POJO 캐시는 디스크로의 객체 저장(eviction)을 지원한다. 만일 메모리가 가득차면, 객체는 디스크로 전달된다.

POJO 캐시는 트랜잭션을 지원하며 분산 캐시도 지원한다.

트리 캐시처럼, POJO 캐시 도구는 데이터 접근 레이어의 도메인 객체 저장에 대해 더 강력하다.

POJO 캐시는 애플리케이션 서버의 컨텍스트와 독립형 자바 애플리케이션에서 사용될 수 있다.

10. Open Terracotta (http://www.terracotta.org/)

Terracotta는 hub-spoke 아키텍처를 사용한다. Terracotta는 클러스터링 환경에서 사용된다.

클러스터의 각 애플리케이션 서버는 클라이언트 노드(spoke)처럼 수행된다. JVM에 설치된 Terracotta 라이브러리가 클러스터의 각 JVM이 멈출때 로딩된다.

그 다음에 허브처럼 수행되는 terracotta 서버가 있다. 또 다른 terracotta 서버가 이를 백업할 수 있다.

terracotta 서버는 자바에서 구현된다.

terracotta 서버는 클라이언트 노드가 메모리 상에서 낮게 수행될 때 각 클라이언트 노드로부터 꺼내는 객체를 저장한다. 만일 서버가 메모리 상에서 낮게 수행된다면, 객체는 서버의 디스크 공간으로 전달된다.

terracotta는 분산 캐시를 지원한다. 분산 캐시에 있는 객체에 대한 락을 지원하기도 한다.

고운 입자 복제 : terracotta는 캐시에 있는 객체가 직렬화될 필요가 없으며 클러스터 간의 캐시에 수행되는 변경만 복제한다.

Terracotta는 클러스터의 클라이언트/서버 노드의 메모리 힙에 대한 통계 화면을 제공한다.

Terracotta는 다음과 같은 사항을 지원한다.

• HttpSession 복제
• 분산 객체
• POJO 클러스터링

여러 캐시 솔루션에 대한 비교

모든 애플리케이션은 다르지만, 다음의 애플리케이션에 대해서 캐시 제품을 고려한다.
1. UI에 집중적인 웹 애플리케이션
2. 뒷단 데이터 저장이 RDBMS
3. 웸 애플리케이션이 클러스터링 환경에 배포됨.

결론

Sl. #	평가 기준		OSCache		EHCache		Jofti		ShiftOne		Whirly Cache		Swarm Cache		JCS		Cache4j		JBoss Cache		Open Terracota
		가중치	순위	점수*	순위	점수	순위	점수	순위	점수	순위	점수	순위	점수	순위	점수	순위	점수	순위	점수	순위	점수
		1-5	1-5	1-25	1-5	1-25	1-5	1-25	1-5	1-25	1-5	1-25	1-5	1-25	1-5	1-25	1-5	1-25	1-5	1-25	1-5	1-25
1	기능
	HttpResponse 캐싱	4.5	5	22.5	5	22.5	4	18	3	13.5	0	0	0	0	0	0	0	0	0	0	0	0
	Page fragment 캐싱	3	5	15	4	12	4	12	3	9	0	0	0	0	0	0	0	0	0	0	0	0
	도메인 객체 캐싱	5	4.5	22.5	4.5	22.5	5	25	4	20	5	25	4	20	5	25	4.5	22.5	5	25	5	25
	메모리 내와 저장 캐싱	4	4	16	4	16	5	20	4	16	2	8	2	8	4.5	18	2	8	5	20	5	20
	분산 캐싱	5	4	20	4	20	5	25	4	20	4	20	4.5	22.5	4.5	22.5	3	15	5	25	5	25
	사용 편이성	3	3.5	10.5	4	12	4	12	3	9	4	12	4	12	4	12	4	12	4	12	4	12
	설정	4	3	12	3	12	3	12	3	12	4	16	4	16	4	16	4	16	3	12	3.5	14
	인덱스 기반 캐싱	4	0	0	0	0	5	20	0	0	0	0	0	0	0	0	0	0	0	0	0	0
	ORM 도구와의 플러그인 가능성	2	3	6	4	8	4	8	3	6	3.5	7	0	0	0	0	2.5	5	3.5	7	3	6
	캐시 내 객체의 비직렬화 정도	2	0	0	0	0	4	8	0	0	0	0	0	0	0	0	0	0	5	10	5	10
	JSR-107의 준수 여부	3	0	0	5	15	4	12	3	9	0	0	0	0	5	15	0	0	0	0	0	0
	트랜잭션 지원	3	0	0	0	0	5	15	0	0	0	0	0	0	0	0	0	0	5	15	5	15
	지원되는 알고리즘	2	2	4	3	6	2.5	5	3	6	0	0	1	2	2.5	5	3	6	3	6	3	6
	HttpSession 복제	2	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	3	6	5	10
2	유지보수성	4	3.5	14	3	12	3.5	14	3.5	14	3.5	14	3.5	14	3.5	14	3.5	14	4	16	4	16
3	확장성	4	4	16	4	16	4	16	4	16	2	8	2	8	4.5	18	2	8	4	16	4	16
4	성능	5	4	20	3.5	17.5	4	20	4	20	2.5	12.5	2.5	12.5	4.5	22.5	2.5	12.5	4	20	4	20
5	가격	4	4.5	18	4.5	18	4.5	18	4.5	18	4.5	18	4.5	18	4.5	18	4.5	18	2.5	10	4.5	18
6	총 점수			178.5		191.5		242		170.5		122.5		115		168		119		190		195
	*점수 = 순위 * 가중치

위의 비교 결과를 보면, 다음 두가지 캐시 제품을 추천한다.

• Jofti
• JBossCache

HttpSession 복제가 필요하지 않고 데이터 전달로 기존 직렬화된 객체를 가지는 일반적인 웹 애플리케이션의 경우, Jofti가 좋은 솔루션으로 나타난다.

하지만, 업체 지원이 필요한 복잡한 분산 캐시가 중요한 매우 기능이 높은 애플리케이션의 경우, JBossCache가 적합하다.

 

원문 : http://www.developer.com/java/ent/article.php/3700661