서론
JPA에 Cache 적용방법에 대해 다루고자 한다. 먼저 Cache 적용 기준 및 패턴에 대한 소개 및 적용 방법에 대해 설명하고자 한다. 또한 Spring Actuator를 통해 캐시 Metric에 대한 변화도 함께 살펴보고자 한다.
1. Cache 적용 기준
캐시는 기본적으로 속도와 효율성을 위한 기술로 테이터를 빠르게 제공하고 시스템 자원을 절약하는 것이 목적으로써 애플리케이션 레벨에서의 캐시란 데이터베이스나 외부 API 호출 결과를 캐싱해 불필요한 중복 작업(DB I/O 및 Newtork I/O)를 줄이기 위해 사용하며 이를 통해 시스템의 응답 시간 개선 및 리소스를 절약할 수 있다.
그렇다면 Cache의 적용 기준은 어떻게 될까
1. 데이터의 접근 빈도(Frequency of Access)
자주 사용되어지는 데이터를 캐싱하는 것이 가장 기본적인 원칙이며 자주 조회되는 제품 목록, 사용자의 프로필 정보등이 이에 해당된다.
2. 데이터의 크기(Size of Data)
캐시는 제한된 용량을 가지므로 데이터 사이즈가 작교 자주 요청되는 데이터를 우선적으로 캐시하는 것이 좋다.
3. 데이터 변동성 (Volatility of Data)
캐시할 데이터가 변동이 적고 안정적인지 판단해야 한다. 자주 변동되는 데이터는 캐시에 저장되더라도 무효화시점이 빠르기 때문에 캐시의 이점이 크지 않을 수 있기 때문이다.
4. 데이터 일관성 요구사항 (Consistency Requirements)
캐시는 일관성 문제를 발생 시킬 수 있기 때문에 캐시된 데이터가 최신 데이터와 불일치할 가능성이 있기 때문에 일관성이 중요한 애플리케이션에서 캐시의 적용을 신중히 해야 한다.
5. 캐시 히트율 (Cache Hit Rate)
캐시가 효과적으로 동작하는지 판단하는 중요한 기준은 캐시 히트율이다. 히트율이 높으면 캐시가 제대로 동작하고 있다는 뜻이며, 히트율이 낮으면 캐시의 적용범위나 정책을 조정해야 한다.
2. Cache 패턴
캐시에 적용되는 패턴은 크게 세가지 인데 다음과 같다.
1. No Caching
Application에서 직접 DB로 요청하는 방식을 말하며, 별도 캐시 내역이 없으므로 매번 DB와의 통신이 필요하며 이는 캐시를 사용하는 경우와 비교했을때 DB I/O에 영향을 보다 더 주게 된다.
2. Cache-aside
Application 기동시 캐시에는 아무 데이터가 없으며, Application 이 요청시에 Cache Miss가 발생하면, DB로부터 데이터를 읽어와 Cache에 적재한다. 이후에 동일한 요청이 반복되면 캐시에 데이터가 존재하므로 DB 조회 없이 바로 데이터를 전달 받을 수 있다.
3. Cache-through
캐시 데이터가 없는 상황에서 Miss가 발생했을 때 Application이 아닌 캐시 제공자가 데이터를 처리한 다음 Application에게 데이터를 전달하는 방법이다. 즉 기존 동기화의 책임이 Application에 있다면 해당 패턴은 캐시 제공자에게 책임이 위임된다.
Cache-through 패턴은 다음과 같이 세분화 할 수 있다.
Read-through
데이터 읽기 요청 시, 캐시 제공자가 DB와의 연계를 통해 데이터를 적재하고 이를 반환한다.
Write-through
데이터 쓰기 요청 시, Application은 캐시에만 적용을 요청하면, 캐시 제공자가 DB에 데이터를 저장하고, Application에게 응답하는 방식이며. 모든 작업은 동기로 진행된다
Write-through
데이터 쓰기 요청시, Application은 데이터를 캐시에만 반영한 다음 요청을 종료하며. 이후 일정 시간을 간격으로 비동기적으로 캐시에서 DB로 데이터를 저장 요청한다. 이 방식은 Application의 쓰기 요청 성능을 높일 수 있으나 만약 캐시에 DB에 저장하기 전에 다운된다면, 데이터 유실이 발생한다