[Java] Ehcache

Cache?

데이터나 값을 미리 복사해 둔 임시 저장소를 말한다. 캐시는 캐시의 접근 시간이 리소스 접근 시간보다 적게 걸리거나 다시 어떠한 값을 계산하는 시간을 절약하고 싶을 때 훌륭한 대안이 될 수 있다. 서버나 DBMS 등의 부담을 줄여줄 수 있고 획기적인 성능향상을 이뤄낼 수 있기 때문에 많은 시스템에서 애용되고 있다

 

어떤 곳에 쓰여야 할까?

• 동일한 데이터를 반복적으로 제공할 때(ex. 정적 이미지 파일, 자주 요청되는 공통 API 응답 데이터)
• 변경주기가 길고 단위 처리 시간이 긴 데이터일 경우(ex. 날씨 데이터, 환율 정보, 실시간이 아닌 보고서 데이터)
• 데이터의 최신화가 빈번하지 않아도 서비스 품질에 영향이 적을 경우(ex. 상품 추천 목록, 사용자 프로필 이미지)

Local vs Global

캐시는 로컬 캐시(Local Cache)와 글로벌 캐시(Global Cache)로 나눌 수 있다

	Local Cache	Global Cache
사용 범위	Local 장치 내부	여러 서버
저장 위치	Local 장치의 리소스(Memory,Dise...)	별도의 Cache Server(Redis...)
데이터 공유	장치 내부에 저장되어 공유가 어렵다	각 서버간 공유가 쉽다

 

Ehcache란?

오픈 소스 기반의 로컬 캐시로 빠르고 경량이라는 장점이 있다. 가장 널리 사용되는 Java 기반의 캐시로 3가지 저장 위치를 제공한다

Memory, Off Heap, Disk를 제공하는데 Off Heap는 GC가 적용되지 않아 매우 큰 캐시가 가능하다.

또한, 캐시제거 알고리즘으로 LRU, LFU, FIFO를 제공한다

LRU- 가장 오랫동안 사용되지 않았던 데이터를 제거하는 알고리즘
LFU- 가장 적게 사용된 데이터를 제거하는 알고리즘
FIFO- 가장 오래전(가장 먼저)에 들어온 데이터를 제거하는 알고리즘

Cache Entry Expiration

Ehcache는 2가지 Cache Entry Expiration를 제공한다. 설정해 둔 일련의 시간이 지나면 자동으로 Cache Entry에서 해당 캐시를 제거하여 준다

• TTL(Time-To-Live): 캐시에 저장된 시점으로부터 설정한 시간이 지나면 제거
• TTI(Time-To-Idle): 캐시에 마지막으로 접근한 시점으로부터 설정한 시간으로 지나도록 접근이 없다면 제거

Ehcache의 Topology 유형

Ehcache는 3가지 Topology 유형을 제공한다

• Standalone: data set이 application node에 존재하는 방식
  • 각 application node가 독립적이고, 각 node 사이에 상호작용이 없는 방식
  • 여러 application node가 동일한 application을 실행중일 때 사용
•  Distributed: data가 원격 서버에 존재하고, application node가 원격 서버와 data를 공유하는 방식
•  Replicated: application node간 data를 복제하여 저장하는 방식으로 한 node의 변경사항이 다른 node로 전파

Application Node?

- 분산 환경에서 각각 애플리케이션이 실행되는 개별 인스턴스를 의미한다

 

Terracotta Server

Distributed를 사용하기 위하여 Ehcache는 'Terracotta Server'를 지원한다. 단순한 로컬 캐시인 Ehcache를 확장하는 핵심 컴포넌트로 다음과 같은 특징을 가지고 있다

• 분산 캐시 관리 - 여러 Application Node에서 동일한 캐시 데이터를 공유할 수 있도록 중앙에서 data를 저장 및 관리
• 고가용성 - 활성 서버와 대기 서버로 나뉘어 활성 서버가 요청을 처리하고 대기 서버는 활성 서버의 data를 복제, 만약 활성서버가 다운되면 대기 서버가 서비스를 유지
• 영속성 - 데이터를 Disk에도 저장할 수 있어 서버 재시작 후에도 data가 유지
• Scale-Out - 노드를 추가하거나 서버를 확장하여 처리량을 증가 가능

 

Ehcache Cache Usage Pattern

• Cache-aside - Application이 캐시를 직접 사용하는 방식으로 Application이 캐시에 접근하여 탐색하고 Cache Miss면 SoR에서 data를 가져와 캐싱하고 값을 가져오면 Cache Hit라면 캐시에서 데이터를 가져온다. data가 변동되면 캐시도 SoR과 함께 변경되어야 한다

Cache Hit, Cache Miss

- 캐시가 Application이 원하는 알맞은 data를 가지고 있을 때는 Cache Hit, 아닐 경우를 Cache Miss라 한다

• Cache-as-SoR - 캐시를 마치 주 저장소처럼 사용하는 방식이다. 이 방식을 통해 Application이 직접 SoR와 데이터를 읽고 쓰는 복잡한 작업에서 벗어나, 캐시가 이러한 작업을 대신 처리하도록 설계할 수 있다. 여기에는 데이터를 읽고 쓰는 다양한 패턴이 포함된
• Read-through - 캐시가 SoR에서 데이터를 로드하는 역할을 수행하는 로더(loader) 컴포넌트와 함께 동작하는 방식이다. 만약 요청한 (key, value)가 캐시에 없으면, 로더가 SoR에서 데이터를 가져온다. 가져온 데이터는 캐시에 저장된 후 사용자에게 반환된다. 이 방식은 SoR 접근이 느리거나 데이터 조회가 빈번한 상황에서 효과적으로 활용할 수 있다.
• Write-through - 캐시가 SoR에 데이터를 저장하는 역할을 하는 라이터(writer) 컴포넌트를 포함하는 방식이다.(key, value) 저장 요청을 받으면 캐시를 먼저 업데이트한다. 이후 라이터를 통해 SoR에도 데이터를 저장한다. 이이 방식은 데이터의 일관성을 유지하면서도 캐싱을 활용하려는 경우 적합하다
• Write-behind - SoR로 데이터를 쓰는 작업을 비동기적으로 처리하는 방식이다. 이 방식은 쓰기 작업이 빈번하지만 실시간으로 SoR 업데이트가 필요하지 않은 경우 유용하다. 이렇게 하면 사용자 스레드가 쓰기 작업을 기다리지 않고 더 빠르게 처리될 수 있다. 애플리케이션이 캐시에 데이터를 업데이트하면, SoR 업데이트는 나중에 실행된다. 쓰기 작업은 별도의 큐에 저장되고, 특정 시점에 SoR로 비동기 전송된다. 

 

SoR

- 은 데이터를 신뢰할 수 있는 권위 있는 소스 파일 시스템이나, 전통적인 DB를 의미

•