로컬 캐시(Guava, Caffeine Cache) 분산 캐시(Redis, Memcached), 하이브리드 캐시, 캐싱 전략

1. 캐싱, 캐시

1.1. 캐싱의 목적

 캐싱(Caching)의 주목적은 "자주 사용하는 데이터나 값을 미리 복사해 놓은 임시 장소"를 마련하는 것이다. 이는 데이터 지역성(Data Locality) 원칙, 즉 한번 사용된 데이터는 가까운 미래에 다시 사용될 가능성이 높다는 경험적 법칙에 근거한다.  

 캐싱의 직접적인 가치는 성능 향상에 있다. 데이터는 일반적으로 디스크(SSD, HDD) 기반의 데이터베이스에 영구 저장되지만, 디스크 접근은 메모리(RAM) 접근에 비해 속도가 현저히 느리다. 인메모리 캐시는 데이터를 RAM에 저장함으로써 밀리초 미만의 초저지연(ultra-low latency) 데이터 접근을 가능하게 하여, 애플리케이션의 전반적인 응답 속도를 크게 개선한다.  

 그러나 캐싱이 단순히 속도 개선에만 이점이 있는 것은 아니다. 현대 클라우드 환경에서 캐싱은 비용 최적화와 시스템 안정성을 위한 핵심 아키텍처 전략으로 자주 이용된다. 데이터베이스나 외부 API와 같은 느린 기본 스토리지 계층에 대한 접근 횟수를 줄임으로써, 서버의 부하를 낮추고 불필요한 네트워크 트래픽을 절감할 수 있다. 이는 직접적인 인프라 비용 절감으로 이어지며, 특히 처리량(IOPS)이나 데이터 전송량에 따라 요금이 부과되는 클라우드 서비스 환경에서는 그 효과가 더욱 커진다.  

 또한 캐싱은 시스템의 확장성과 가용성을 높이는 데 결정적인 역할을 할 수 있다. 대규모 트래픽이 발생하는 상황에서 데이터베이스는 종종 시스템 전체의 병목 지점이 된다. 캐시를 통해 데이터베이스의 '핫스팟'(특정 데이터에 대한 접근이 집중되는 현상)을 제거하고 예측 불가능한 트래픽 급증에 효과적으로 대응할 수 있다. 이처럼 캐싱은 단순히 성능을 보조하는 기술을 넘어, 시스템의 비용 구조와 안정성 목표를 달성하기 위한 근본적인 아키텍처 레벨의 의사결정이라 할 수 있다.   

 

1.2. 캐시의 기본 동작 원리: Hit와 Miss

캐시의 동작은 'Cache Hit'와 'Cache Miss' 두 가지 상태로 요약된다.

 애플리케이션이 특정 데이터를 요청했을 때, 해당 데이터가 캐시에 존재하여 즉시 반환되는 경우를 'Cache Hit'라고 한다. 반면, 데이터가 캐시에 존재하지 않아 원본 데이터 저장소(ex: 데이터베이스)까지 가서 데이터를 가져와야 하는 경우를 'Cache Miss'라고 한다.  

 캐싱 전략의 핵심 목표는 'Cache Hit Rate'(캐시 히트율)를 최대화하는 것이다. 히트율이 높을수록 애플리케이션은 더 빠른 응답 속도를 제공하고 원본 저장소의 부하를 효과적으로 줄일 수 있다. 반대로 미스율이 높으면 캐시의 이점을 제대로 활용하지 못하고, 오히려 캐시를 확인하는 추가적인 오버헤드만 발생시킬 수 있다.  

 

2. 로컬 캐시(Local Cache)

2.1. 로컬 캐시의 특징

 로컬 캐시는 애플리케이션 서버의 자체 리소스, 즉 메모리(RAM)나 디스크를 사용하여 데이터를 저장하는 가장 기본적인 캐싱 방식이다. 캐시가 애플리케이션 프로세스 내에 존재하므로, 애플리케이션과 생명주기를 완전히 같이 한다.  

 로컬 캐시의 가장 큰 장점은 압도적인 속도이다. 데이터가 애플리케이션과 동일한 메모리 공간에 존재하기 때문에 별도의 네트워크 통신이 전혀 필요 없다. 이로 인해 분산 캐시와 비교할 수 없을 정도로 빠른 데이터 접근 속도를 보장하며, 네트워크 지연이나 단절과 같은 외부 요인의 영향을 받지 않는다.  또한, 별도의 캐시 서버를 구축하거나 네트워크를 설정할 필요가 없어 구현과 관리가 매우 단순하고 직관적이라는 장점이 될 수 있겠다.

 

Java 환경에서는 로컬 캐시의 저장 공간을 크게 두 가지로 나눌 수 있다.

• On-Heap 저장소: JVM 힙 메모리 영역을 사용한다. 가비지 컬렉션(GC)의 대상이 되지만, 데이터 직렬화 과정이 필요 없어 접근 속도가 가장 빠르다.  
• Off-Heap 저장소: JVM 힙 외부의 네이티브 메모리 영역을 사용한다. GC의 영향을 받지 않아 GC로 인한 성능 저하를 피할 수 있지만, 데이터를 저장하고 읽을 때 직렬화 및 역직렬화 과정이 필요하여 On-Heap 방식보다는 상대적으로 느리다.  

2.2. 로컬 캐시의 단점

단순함과 빠른 속도에도 불구하고 로컬 캐시는 분산 시스템 환경에서 사용 시 여러 치명적인 단점들이 존재한다.

• 데이터 정합성 문제: 로드 밸런싱을 통해 여러 서버 인스턴스로 확장(Scale-out)된 환경에서 로컬 캐시는 심각한 데이터 불일치 문제를 야기한다. 각 서버 인스턴스가 자신만의 독립적인 캐시를 가지기 때문에, 한 서버에서 데이터가 변경되어도 다른 서버의 캐시는 갱신되지 않는다. 결과적으로, 동일한 데이터에 대한 요청이 어떤 서버로 전달되느냐에 따라 서로 다른 값이 반환될 수 있다. 이는 데이터의 신뢰성을 해치는 심각한 결함이다.  
• 데이터 휘발성 및 생명주기: 로컬 캐시는 애플리케이션 프로세스에 종속적이므로, 애플리케이션이 재시작되거나 장애로 인해 종료되면 캐시된 모든 데이터가 함께 소실된다. 이로 인해 서비스 재시작 직후 모든 요청이 데이터베이스로 몰리는 '캐시 스탬피드(Cache Stampede)' 현상이 발생하여 데이터베이스에 과부하를 줄 수 있다.  
• 확장성의 한계: 로컬 캐시는 데이터를 여러 서버에 분산(Sharding)하여 저장하는 것이 구조적으로 어렵고, 오직 복제(Replication)만 가능하다. 또한 캐시해야 할 데이터의 양이 늘어날수록 애플리케이션(WAS) 자체의 메모리 요구량이 비례하여 증가하므로, 수직적 확장(Scale-up)에 크게 의존하게 된다.
• 자원 낭비: 여러 서버 인스턴스가 동일한 데이터를 각각의 메모리에 중복해서 저장하여, 메모리 자원의 낭비가 발생한다.  

 이러한 문제들은 로컬 캐시 자체의 결함이라기보다는, 단일 프로세스 환경에 최적화된 기술을 그 설계 범위를 벗어난 분산 환경에 적용했을 때 발생하는 결과이다. 따라서 로컬 캐시를 선택하기 전에는 현재 시스템의 아키텍처뿐만 아니라, 미래의 확장 가능성까지 신중하게 고려해야 한다. 단일 인스턴스 실행이 보장되는 환경, 예를 들어 특정 배치 작업을 수행하는 독립적인 애플리케이션 등에서는 로컬 캐시가 여전히 가장 효율적인 선택일 수 있다.

2.3. Java 주요 로컬 캐시 라이브러리: Guava Cache, Caffeine Cache

Java 진영에서 가장 널리 사용되는 로컬 캐시 라이브러리는 Google의 Guava Cache와 이를 계승한 Caffeine Cache이다.

• Guava Cache: Google의 핵심 라이브러리인 Guava에 포함된 캐시 구현체이다. CacheBuilder 클래스를 통해 빌더 패턴으로 유연하게 캐시를 설정할 수 있으며, 크기 기반 제거, 시간 기반 만료(생성 후, 접근 후), 스레드 안전성 등 필수적 기능을 제공한다. 특히   LoadingCache 인터페이스는 캐시 미스가 발생했을 때 정의된 로직에 따라 데이터를 자동으로 로드해주는 편리한 기능을 제공한다.  
• Caffeine Cache: Guava Cache를 바탕으로 더 높은 성능을 목표로 설계된 로컬 캐시 라이브러리이다. Java 8 이상 환경을 요구하며, Guava Cache의 API와 거의 호환되어 기존 Guava 사용자들이 쉽게 마이그레이션할 수 있다. Caffeine의 가장 큰 특징은   TinyLFU(Tiny Least Frequently Used)라는 독창적인 캐시 제거 정책을 채택했다는 것이다. 이는 전통적인 LRU(Least Recently Used)와 LFU(Least Frequently Used) 정책의 장점을 결합하여, 접근 빈도와 최근성을 모두 고려함으로써 최적에 가까운 높은 캐시 히트율을 달성한다. 또한, 비동기 로딩, 만료된 데이터의 비동기 리프레시 등 Guava보다 발전된 기능을 다수 제공하며, Spring Framework 4.3 버전부터는 공식 캐시 구현체로 채택되어 널리 사용되고 있다.  

다음은 Caffeine을 사용하여 간단한 로컬 캐시를 구성하는 예제 코드이다.

import com.github.benmanes.caffeine.cache.Caffeine;
import com.github.benmanes.caffeine.cache.LoadingCache;
import java.util.concurrent.TimeUnit;

public class CaffeineExample {
    public static void main(String args) {
        // Caffeine 캐시 빌더를 사용하여 캐시 인스턴스 생성
        LoadingCache<String, String> cache = Caffeine.newBuilder()
               .maximumSize(100) // 캐시에 저장할 수 있는 최대 아이템 수
               .expireAfterWrite(10, TimeUnit.MINUTES) // 아이템이 쓰여진 후 10분 뒤 만료
               .refreshAfterWrite(1, TimeUnit.MINUTES) // 아이템이 쓰여진 후 1분마다 비동기 리프레시
               .build(key -> loadDataFromDatabase(key)); // Cache Miss 시 데이터를 로드할 로직 정의

        // 데이터 조회
        String value = cache.get("some-key");
        System.out.println("Cached Value: " + value);
    }

    // 데이터베이스나 외부 API에서 데이터를 가져오는 것을 시뮬레이션
    private static String loadDataFromDatabase(String key) {
        System.out.println("Loading data for key: " + key);
        return "Data for " + key;
    }
}

이 코드에서 build() 메서드에 전달된 람다 함수는 CacheLoader 역할을 하여, cache.get("some-key") 호출 시 캐시에 해당 키가 없으면 loadDataFromDatabase() 메서드를 자동으로 호출하여 데이터를 가져온 후 캐시에 저장한다.  

 

3. 분산 캐시(Distributed Cache)

3.1. 분산 캐시의 아키텍처와 특징

분산 캐시(Distributed Cache)는 애플리케이션 서버와는 독립된 별도의 서버(또는 서버 클러스터)에 캐시 저장소를 구축하고, 여러 애플리케이션 서버가 네트워크를 통해 이 공유 저장소에 접근하는 방식이다.  

 

이러한 아키텍처는 로컬 캐시의 근본적인 문제점들을 해결한다.

• 데이터 일관성 보장: 모든 애플리케이션 서버가 중앙의 단일 캐시 저장소를 참조하므로, 데이터 불일치 문제가 원천적으로 발생하지 않는다. 어떤 서버가 요청을 처리하든 항상 동일한 캐시 데이터를 보장받을 수 있다.  
• 높은 확장성과 가용성: 분산 캐시는 수평적 확장(Scale-out)에 매우 용이하다. 데이터 양이 늘어나거나 트래픽이 증가하면 캐시 서버를 추가하여 용량과 처리량을 선형적으로 늘릴 수 있다. 또한, 데이터 복제(Replication)나 클러스터링(Clustering) 구성을 통해 특정 캐시 서버에 장애가 발생하더라도 서비스 중단 없이 운영되는 고가용성(High Availability)을 확보할 수 있다.  
• 데이터 영속성: 캐시가 애플리케이션 프로세스와 분리되어 있기 때문에, 애플리케이션 서버가 재시작되거나 배포가 이루어져도 캐시 데이터는 그대로 유지된다. Redis와 같은 일부 솔루션은 스냅샷이나 로그 파일 형태로 데이터를 디스크에 저장하는 영속성 옵션을 제공하여, 캐시 서버 자체의 장애에도 데이터를 보존할 수 있다.  

3.2. 분산 캐시의 단점

분산 캐시는 많은 이점을 제공하지만, 그에 상응하는 트레이드오프를 가지고 있다.

• 네트워크 지연: 모든 캐시 접근은 네트워크 통신을 수반한다. 이는 아무리 빠른 네트워크 환경이라도 로컬 메모리 접근보다는 필연적으로 느릴 수밖에 없다. 또한 네트워크 상태에 따라 성능의 변동성이 발생할 수 있다는 점도 고려해야 한다.  
• 운영 복잡성 및 비용: 별도의 캐시 인프라를 구축하고, 모니터링하며, 장애에 대비하는 등 추가적인 운영 부담이 발생한다. 캐시 서버 자체가 또 다른 장애 포인트(Single Point of Failure)가 될 수 있으므로, 고가용성 구성이 필수적이며 추가적인 비용이 발생한다.
• 데이터 직렬화 오버헤드: 객체와 같은 복잡한 데이터를 네트워크를 통해 전송하려면, 데이터를 바이트 스트림으로 변환하는 직렬화(Serialization)와 이를 다시 객체로 복원하는 역직렬화(Deserialization) 과정이 필요하다. 이 과정은 CPU 자원을 소모하는 추가적인 오버헤드를 발생시킨다.  

3.3. 대표적인 분산 캐시 솔루션: Redis vs Memcached

가장 대표적인 분산 캐시 솔루션은 Redis와 Memcached이다. 두 솔루션 모두 고성능 인메모리 키-값 저장소라는 공통점을 가지지만, 근본 목적과 아키텍처에서 뚜렷한 차이가 있다.

 Memcached는 '휘발성, 단순성, 빠른 속도'라는 캐시 본연의 역할에 충실한 솔루션이다. 데이터베이스 부하 경감이 주된 목표이고, 원본 데이터로 즉시 복구가 가능하며, 단순한 키-값 캐싱만 필요하다면 Memcached의 멀티스레드 아키텍처와 단순성이 더 유리할 수 있다.  

 Redis는 다양한 자료구조와 영속성, 고가용성 기능을 제공함으로써 단순한 '캐시'를 넘어 '다목적 고속 데이터 저장소'로서의 역할을 수행한다. 랭킹 시스템, 실시간 채팅, 메시지 큐 등 복잡한 데이터 연산이나 데이터 보존이 필요한 시나리오에서는 Redis가 거의 유일한 선택지다.  

기능/특징	Redis	Memcached
자료구조	Strings, Lists, Sets, Sorted Sets, Hashes, Bitmaps 등 다양함	단순 Key-Value (Strings)만 지원
스레딩 모델	기본적으로 싱글 스레드 (I/O Multiplexing). Race Condition 우려가 적음	멀티 스레드 아키텍처. 다중 코어를 활용하여 높은 처리량(Throughput) 달성
영속성	RDB(스냅샷), AOF(로그 파일) 방식의 디스크 저장 지원	지원하지 않음. 순수 인메모리 휘발성 캐시
복제/고가용성	Master-Slave 복제, Sentinel을 통한 자동 Failover, Cluster를 통한 샤딩 및 고가용성 내장 지원	자체 기능 없음. 클라이언트 라이브러리(Consistent Hashing)나 외부 도구를 통해 구현 필요
트랜잭션	MULTI/EXEC 명령어를 통한 원자적 연산 지원	지원하지 않음
Pub/Sub	내장된 발행/구독 메시징 기능 제공	지원하지 않음
메모리 관리	동적 메모리 할당 (jemalloc). 메모리 단편화 발생 가능성 있음	Slab Allocator를 사용하여 메모리를 미리 할당하고 재사용. 단편화가 적음
주요 사용 사례	복합 데이터 캐싱, 랭킹 보드, 메시지 큐, 세션 스토어, 실시간 분석 등 다목적	단순 객체/문자열 캐싱, DB 쿼리 결과 캐싱 등 순수 캐싱 목적

4. 캐싱 전략과 데이터 정합성 문제

캐시를 효과적으로 사용하기 위해서는 데이터를 어떻게 읽고 쓸 것인지에 대한 명확한 전략, 즉 '캐싱 패턴'을 정의해야 한다.

4.1. 데이터 접근 패턴

• Cache-Aside (Lazy Loading): 가장 널리 사용되는 보수적이고 안전한 패턴이다. 애플리케이션이 데이터의 흐름을 직접 제어하며, 캐시는 조회 속도 개선 보조 역할만 수행한다.

Cache-Aside

Cache Hit 시나리오 

1. 애플리케이션이 데이터 조회를 위해 먼저 캐시를 확인한다. (Application → Cache (read request))
2. Cache Hit 시, 캐시 데이터를 즉시 반환한다. (cache hit: read from cache → Application)

Cache Miss 시나리오

1. 애플리케이션이 데이터 조회를 위해 먼저 캐시를 확인한다. (Application → Cache (read request))
2. Cache Miss (cache miss: (Cache → Application))
3. 애플리케이션이 직접 데이터베이스에서 데이터를 조회한다. (Application → Storage (read request))
4. 데이터 베이스에서 조회한 데이터를 반환한다. (read from storage (Storage → Application))
5. 캐시에 데이터를 저장한다. (write to cache (Application → Cache))

• 장점: 실제로 요청되는 데이터만 캐시에 저장되어 메모리가 효율적으로 사용되며, 캐시에 장애가 발생하더라도 데이터베이스 조회를 통해 서비스의 연속성을 보장할 수 있다.
• 단점: 최초 데이터 접근 시에는 항상 Cache Miss가 발생하여 지연 시간이 길어지며, 데이터베이스의 데이터가 변경되었을 때 캐시를 명시적으로 무효화(invalidate)하지 않으면 데이터 불일치가 발생할 수 있다.  

Read-Through

• Read-Through: 데이터 로딩 책임을 캐시에게 위임하여 애플리케이션 코드를 단순화하는 패턴이다.
  1. 애플리케이션은 항상 캐시에만 데이터 조회를 요청한다.
  2. Cache Hit 시, 캐시 데이터를 반환한다.
  3. Cache Miss시, 캐시가 직접 데이터베이스에서 데이터를 조회하여 캐시에 저장한 후, 애플리케이션에 반환한다.
  • 장점: 애플리케이션은 데이터베이스의 존재를 인지할 필요가 없어 코드가 간결해지고, 데이터 로딩 로직이 캐시에 집중되어 일관성 관리가 용이하다.  
  • 단점: 캐시 솔루션이 데이터베이스와 직접 통신하는 기능을 지원해야 하며, 캐시에 장애가 발생하면 데이터 조회 자체가 불가능해져 서비스 전체의 장애로 이어질 수 있다.  

Write-Through

• Write-Through: 데이터의 정합성을 최우선으로 고려하는 패턴으로, 주로 금융 거래와 같이 강력한 일관성이 요구되는 시스템에 적합하다.
  1. 애플리케이션이 데이터를 쓸 때, 먼저 캐시에 데이터를 쓴다.
  2. 캐시에 쓰기가 성공하면, 즉시 데이터베이스에도 동일한 데이터를 쓴다. 두 작업이 모두 성공해야 쓰기 작업이 완료된다.
  • 장점: 캐시와 데이터베이스의 데이터가 항상 동기화되므로 데이터 정합성이 매우 높다.  
  • 단점: 모든 쓰기 작업이 캐시와 데이터베이스 두 곳에서 이루어지므로, 쓰기 지연 시간이 증가하고 시스템 전체의 쓰기 처리량이 감소할 수 있다.  

Write-Back (Write-Behind)

• Write-Back (Write-Behind): 쓰기 성능을 극대화하기 위한 패턴으로, 데이터 정합성보다는 쓰기 처리량이 훨씬 중요한 특정 도메인(ex: 대량의 로그 수집, 실시간 통계 집계)에 사용된다.
  1. 애플리케이션은 데이터를 캐시에만 쓴다.
  2. 캐시는 쓰기 요청을 특정 버퍼에 모아두었다가, 일정 시간이 지나거나 버퍼가 가득 차면 비동기적으로 데이터베이스에 일괄 기록(batch write)한다.
  • 장점: 쓰기 작업이 메모리에서 즉시 완료되므로 응답 속도가 매우 빠르고, 데이터베이스의 쓰기 부하를 획기적으로 줄일 수 있다.  
  • 단점: 캐시에만 데이터가 기록된 상태에서 캐시 서버에 장애가 발생하면, 데이터베이스에 반영되지 않은 데이터가 영구적으로 유실될 위험이 존재한다.  

Write-Around

• Write-Around: 쓰기 작업이 잦지만 해당 데이터가 다시 읽힐 확률이 낮은 경우에 유용한 패턴이다.
  1. 애플리케이션은 쓰기 작업을 캐시를 거치지 않고 데이터베이스에 직접 수행한다. (위 그림의 1번 작업)
  2. 읽기 작업은 Cache-Aside 패턴을 따른다. (위 그림의 2,3,4번 작업)
  • 장점: 쓰기 작업이 빠르고, 불필요한 데이터가 캐시에 저장되는 것을 방지하여 캐시 효율을 높인다.  
  • 단점: 데이터를 쓴 직후에 해당 데이터를 읽으려고 하면 반드시 Cache Miss가 발생하여, 일시적으로 데이터 불일치를 경험하게 된다.  

4.2. 대용량 트래픽 환경에서의 문제와 해결책

대규모 트래픽 환경에서는 단순한 캐싱 패턴만으로는 해결하기 어려운 문제들이 발생한다.

4.2.1 캐시 쇄도 (Cache Stampede / Thundering Herd)

인기 있는 데이터의 캐시가 만료되는 순간, 수많은 요청이 동시에 Cache Miss를 일으키며 데이터베이스로 몰려가 시스템 전체에 과부하를 주는 현상이다.

• 문제 상황

Cache 만료 시점에 대량의 동시 요청 발생
↓
모든 요청이 DB로 직접 전송
↓
DB 과부하 및 응답 지연

• 발생 시나리오
  • 인기 상품 정보가 캐시에서 만료될 때
  • 트렌딩 콘텐츠에 대한 대량 조회
  • 프로모션 시간 등 특정 시점의 집중 요청
• 해결책 1 (Jitter 추가): 캐시 만료 시간(TTL)에 짧은 랜덤 시간(Jitter)을 추가하여, 여러 캐시 항목이 동시에 만료되지 않도록 시점을 분산시키는 전략이다.  
• 해결책 2 (분산 락 적용): Redisson(Redis 기반 분산 락을 쉽게 구현할 수 있게 해주는 라이브러리) 등 분산 락을 활용하여 단 한번의 쓰기 작업만 허용 시키기는 방법이다.

4.2.2. 캐시 관통 (Cache Penetration)

존재하지 않는 데이터에 대한 악의적이거나 비정상적인 요청이 반복적으로 발생하여, 매번 Cache Miss를 일으키고 데이터베이스에 불필요한 조회 부하를 가하는 문제이다.

• 해결책 (Null 값 캐싱): 데이터베이스 조회 결과 데이터가 없다는 사실 자체를 캐싱하는 방법이다. 예를 들어, 특정 키에 대해 "NULL"이라는 특수한 값을 짧은 TTL로 캐싱해두면, 이후 동일한 키에 대한 요청은 데이터베이스까지 도달하지 않고 캐시에서 차단된다.

5. 아키텍처별 캐싱 전략 선택

모놀리식 아키텍처와 마이크로서비스 아키텍처는 각각 다른 특성을 가지므로, 그에 맞는 캐싱 접근법이 필요하다.

5.1. 모놀리식 아키텍처에서의 캐싱

모놀리식 아키텍처는 모든 기능이 하나의 큰 배포 단위로 묶여 있는 구조이다.   

 

• 초기 및 소규모 단계: 애플리케이션이 단일 서버에서 운영되는 경우, 로컬 캐시는 네트워크 오버헤드 없이 최고의 성능을 제공하는 가장 효율적인 선택이다.
• 수평 확장 단계: 트래픽 증가로 서버를 여러 대로 확장(Scale-out)하기 시작하면, 로컬 캐시의 데이터 정합성 문제가 발생한다. 이 단계에서는 분산 캐시(ex: Redis)를 도입하여 사용자 세션 정보나 여러 인스턴스가 공유해야 하는 데이터를 중앙에서 관리하는 것이 일반적인 전환 경로이다.

5.2. 마이크로서비스 아키텍처에서의 캐싱

 마이크로서비스 아키텍처는 각 기능이 독립적인 서비스로 분리되어 있고, 서비스별로 자체 데이터베이스를 가지며, API를 통해 통신하는 구조이다. 이 환경에서 캐싱은 서비스 간의 결합도와 시스템 전체의 안정성에 큰 영향을 미치는 양날의 검이 될 수 있다.  

 잘못된 캐싱 전략, 예를 들어 여러 서비스가 하나의 거대한 공유 분산 캐시를 직접 읽고 쓰는 방식은 이 캐시를 새로운 형태의 '공유 데이터베이스'로 만들어 서비스 간의 강한 결합을 유발할 수 있다. 한 서비스의 캐시 데이터 구조 변경이 다른 서비스에 영향을 미치거나, 장애를 전파하는 원인이 될 수 있다.

따라서 마이크로서비스 환경에서는 서비스의 독립성과 경계를 명확히 하는 캐싱 패턴을 적용하는 것이 중요하다.

• 서비스별 로컬 캐시: 다른 서비스에 의존하지 않는 자체 데이터 중 변경 빈도가 매우 낮은 데이터(ex: 설정값, 국가 코드 등 메타데이터)를 캐싱할 때 유용하다. 각 서비스 인스턴스 내에 캐시를 두어 외부 API 호출 없이 가장 빠른 응답을 제공할 수 있다.  
• 공유 분산 캐시 (Sidecar Cache): 서비스가 다른 서비스의 데이터를 필요로 할 때, 해당 서비스의 API를 호출하여 얻은 응답을 자체적으로 관리하는 분산 캐시에 저장하는 패턴이다. 이는 서비스 간의 경계를 명확히 하고 API 계약을 존중하게 한다. 또한, 호출 대상 서비스에 일시적인 장애가 발생하더라도 캐시된 데이터로 응답을 계속할 수 있어, 장애 전파를 막고 시스템의 회복탄력성(Resilience)을 높이는 데 기여한다.   
• 데이터 일관성 유지: 한 서비스에서 데이터가 변경되었을 때, 해당 데이터를 캐싱하고 있는 다른 서비스들에게 변경 사실을 알려주는 메커니즘이 필요하다. 이를 위해 메시지 큐(ex: Kafka, RabbitMQ)를 활용한 이벤트 기반 아키텍처를 구축하여 캐시 무효화 이벤트를 전파하는 방식이 사용될 수 있다.

5.3. 하이브리드 캐싱 전략: 니어 캐시(Near-Cache)

하이브리드 캐싱은 로컬 캐시의 빠른 속도와 분산 캐시의 일관성 및 대용량이라는 장점을 모두 취하기 위한 패턴이다. 니어 캐시(Near-Cache)라 한다.  

• 동작 방식
  1. 애플리케이션은 요청 처리 시 가장 먼저 로컬 캐시를 조회한다.
  2. 로컬 캐시에 데이터가 없으면(로컬 캐시 Miss), 분산 캐시를 조회한다.
  3. 분산 캐시에 데이터가 있으면(분산 캐시 Hit), 해당 데이터를 가져와 로컬 캐시에 저장한 후 애플리케이션에 반환한다.
  4. 분산 캐시에도 데이터가 없으면(분산 캐시 Miss), 원본 데이터베이스에서 데이터를 조회하여 분산 캐시와 로컬 캐시에 모두 저장한 후 반환한다.  
• 장점: 자주 접근하는 '핫(Hot)' 데이터는 로컬 캐시에서 네트워크 지연 없이 초고속으로 처리된다. 동시에 분산 캐시를 통해 데이터의 일관성과 영속성을 확보할 수 있다. 이 구조는 전체적인 네트워크 트래픽과 분산 캐시에 가해지는 부하를 크게 줄여주며, 서버 재시작으로 로컬 캐시가 비워지더라도 분산 캐시 덕분에 빠르게 캐시를 워밍업할 수 있다.  
• 과제: 가장 큰 과제는 로컬 캐시 간의 동기화이다. 분산 캐시의 데이터가 변경되었을 때, 모든 서버 인스턴스의 로컬 캐시에 있는 구 데이터를 어떻게 무효화할 것인가의 문제이다. 이를 해결하기 위해 Redis의 Pub/Sub 기능과 같은 메시징 시스템을 활용하여 모든 인스턴스에 캐시 무효화 메시지를 전파하는 '백플레인(backplane)' 채널을 구현해야 한다.  

6. 어떤 캐시를 선택할 것인가?

6.1. 선택을 위한 핵심 질문

올바른 결정을 내리기 위해 다음 질문들을 스스로에게 던져보아야 한다.

1. 애플리케이션의 확장 계획은 무엇인가? 현재 단일 서버로 운영 중이며, 가까운 미래에도 수평 확장 계획이 없는가? 아니면 초기부터 분산 환경을 염두에 두고 있는가?
2. 데이터의 일관성 요구 수준은 어느 정도인가? 금융 정보처럼 1초의 불일치도 허용할 수 없는 강력한 일관성이 필요한가? 아니면 소셜 미디어 피드처럼 몇 초 정도의 지연이 허용되는 최종적 일관성으로 충분한가?
3. 주요 워크로드는 읽기 중심인가, 쓰기 중심인가? 데이터 조회(Read)가 압도적으로 많은가, 아니면 데이터 변경(Write)이 빈번하게 일어나는가?  
4. 데이터가 얼마나 자주 변경되는가? 한번 캐싱되면 거의 바뀌지 않는 데이터인가, 아니면 수시로 갱신되는 동적인 데이터인가?  
5. 운영 및 관리 역량과 예산은 충분한가? 별도의 캐시 인프라를 구축하고 24/7 유지보수할 수 있는 인력과 비용을 감당할 수 있는가?

6.2. 의사결정 매트릭스

 위 질문들을 바탕으로 각 캐싱 전략의 특징을 요약한 아래의 의사결정 매트릭스를 통해 프로젝트 상황에 가장 적합한 전략을 고민해 보면 좋을 것 같다.

의사결정 요소	로컬 캐시 (Local Cache)	분산 캐시 (Distributed Cache)	하이브리드 캐시 (Hybrid Cache)
애플리케이션 규모	단일 인스턴스 환경에 최적	다중 인스턴스, 분산/마이크로서비스 환경	다중 인스턴스, 특히 성능에 매우 민감한 대규모 환경
데이터 일관성	낮음 (인스턴스 간 불일치 발생)	높음 (중앙 저장소로 일관성 보장)	높음 (분산 캐시를 통해 일관성 보장, 로컬 캐시 동기화 필요)
성능 (지연시간)	매우 낮음 (네트워크 오버헤드 없음)	낮음 (네트워크 지연 발생)	매우 낮음 (로컬 캐시 Hit) / 낮음 (분선 캐시 Hit)
데이터 휘발성	높음 (애플리케이션 재시작 시 소실)	낮음 (애플리케이션과 독립적, 영속성 옵션 가능)	낮음 (분산 캐시 데이터는 보존됨)
운영 복잡도	매우 낮음 (라이브러리 추가로 구현)	높음 (별도 인프라 구축 및 관리 필요)	매우 높음 (로컬/분산 캐시 관리 및 동기화 구현 필요)
비용	매우 낮음 (추가 비용 없음)	높음 (별도 서버/서비스 비용 발생)	매우 높음 (분산 캐시 + 추가 개발/운영 리소스)

 

 

 

 

참고 자료:

https://medium.com/@ovkravindu95/in-process-cache-vs-centralized-cache-in-java-applications-4328d45c857b

In-Process Cache vs. Centralized Cache in Java Applications

https://blog.bytebytego.com/p/a-crash-course-in-caching-part-2

A Crash Course in Caching - Part 2

https://toss.tech/article/cache-traffic-tip

캐시 문제 해결 가이드 - DB 과부하 방지 실전 팁

https://dev.to/randazraik/microservices-caching-demystified-strategies-topologies-and-best-practices-43ad

Microservices Caching: Strategies, Topologies, and Best Practices

https://dev.to/mahmoud_nawwar_2024/hybrid-cache-strategy-in-spring-boot-a-guide-to-redisson-and-caffeine-integration-19g

Hybrid Cache Strategy in Spring Boot: A Guide to Redisson and Caffeine Integration

https://www.ibm.com/docs/ko/wxs/8.6.1?topic=topology-local-in-memory-cache

로컬 인메모리 캐시