분산 캐시의 이해와 Redis : 분산 캐시의 필요성

드디어 Redis다

 

 - 분산 캐시의 개념과 필요성

 - 로컬 캐시(Local Cache)의 한계를 파악하고, 서버 확장 시 발생하는 문제

 - 다중 서버 환경에서 데이터의 일관성이 왜 중요한가?

 - 서버간 캐시 공유의 기본 원리를 이해하고, 확장성과 가용성 측면에서의 장점 익히기

 - Redis와 같은 분산 캐시 시스템을 도입해야 하는 이유

 

---

분산 캐시의 필요성

분산 캐시는 여러 서버(노드)가 동일한 캐시 데이터를 공유할 수 있도록 네트워크를 통해 접근 가능한 캐시 저장소를 말함

로컬 캐시(Local Cache)와 달리 서버간 데이터 일관성(Consistency)을 유지할 수 있고, 확장성과 안정성이 뛰어남

 

 

1. 로컬 캐시의 한계

로컬 캐시는 각 서버의 메모리에 캐시를 저장하는 방식임

 

로컬 캐시의 구조

 

1) 문제점

 - 서버마다 캐시가 서로 독립적으로 존재함

 - 한 서버에서 데이터가 갱신되어도 다른 서버의 캐시는 오래된 데이터(Old Data)를 유지할 수 있음

 - 서버가 재시작되면 캐시 데이터가 초기화되어, DB 부하가 일시적으로 급증하게 된다

import java.util.concurrent.ConcurrentHashMap;

public class test01 {
	ConcurrentHashMap<String, Object> localCache = new ConcurrentHashMap<>();
	
	public Object getData(String key) {
		if(localCache.containsKey(key)) {
			return localCache.get(key);
		}
		Object data = database.load(key); // db에서 조회하는 로직 예시
		localCache.put(key, data);
		return data;
	}
}

 

* 단일 서버에서는 빠르지만, 분산 환경에서는 데이터 불일치 문제가 필연적으로 발생한다

 

 

2. 다중 서버 환경에서의 데이터 일관성 문제

분산 시스템에서는 여러 서버가 동시에 같은 데이터를 캐시하고 변경할 수 있음

분산 캐시의 구조

 

데이터 일관성에 대한 문제들

항목	설명
데이터 불일치	한 서버의 캐시 업데이트가 다른 서버로 반영되지 않음
동시성 문제	여러 서버가 같은 키에 대해 동시에 다른 값을 캐시함
복구 지연	장애 복구시 캐시 초기화로 인한 DB 과부하

 

* 이러한 문제들을 해결하기 위해서버간 캐시 공유 구조가 필요하다

 

 

3. 서버간 캐시 공유 메커니즘

분산 캐시는 모든 서버가 공통 캐시 저장소(Shared Cache)에 접근하여 데이터를 읽고 저장한다

서버1, 서버2, 서버3이 하나의 캐시 저장소에 접근해서 읽고 저장함

 

1) 장점

 - 모든 서버가 동일한 캐시 데이터를 공유함

 - 한 서버가 데이터를 변경하면 즉시 모든 서버에 반영된다

 - 서버를 추가해도 캐시 일관성이 깨지지 않는다

// 분산 캐시의 예시(Redis, Memcached등 활용)
RedisTemplate<String, Object> redisTemplate;

public Object getData(String key) {
	Object data = redisTemplate.opsForValue().get(key); // Redis
    if(data != null) {
    	return data; // Redis 캐시를 조회함
    }
    
    data = dataBase.load(key); // DB를 조회함
    redisTemplate.opsForValue().set(key, data, 10, TimeUnit.MINUTES); // Redis에도 저장함
    return data;
}

 

* 모든 서버가 같은 캐시 저장소(Redis 등등..)를 바라보기 때문에, 데이터 일관성을 쉽게 유지할 수 있음

 

 

4. 확장성과 고가용성 요구사항

분산 캐시는 단순히 캐시 공유를 넘어, 확장성(Scalability)과 고가용성(High Availability)을 제공함

 

1) 확장성(Scalability)

 - 서버 수가 증가하더라도, 캐시 데이터는 중앙에서 관리되므로 부하를 균등하게 분산할 수 있음

 - Redis Cluster나 Sharding 기법을 통해 대규모 트래픽을 처리할 수 있음

 

분산 캐시, 확장성

 

2) 고가용성(High Availability)

 - 분산 캐시는 마스터 - 슬레이브 구조를 통해 장애시에도 서비스 중단 없이 운영됨

 - 장애 감지와 자동 복구(Failover)를 지원하고 있음

요소	역할
Master	데이터 저장 및 쓰기 처리
Replica(Slave)	읽기 요청 처리 및 복제 데이터 유지
Sentinel	장애감지 및 자동 Failover 수행

 

* 마스터 - 슬레이브와 같은 구조 덕에 캐시는 단순 속도 향상 수단이 아닌, 안정적 서비스 운영의 핵심 인프라가 된다고 함

 

---

실무 적용시 고려해야할 점

분산 캐시를 도입한다고 해서 모든 문제가 자동으로 해결되는건 아님

 

1. 네트워크 비용 고려

 - 캐시 접근이 로컬 메모리가 아닌 네트워크를 거치기 때문에, 지연(Latency)이 발생할 수 있음

 - 이를 완화하기 위해 로컬 캐시 + 분산 캐시 병행(Local + Distributed Hybrid) 구조를 자주 사용함

로컬캐시에서 miss나면 분산캐시 조회

 

* 자주 사용되는 데이터는 로컬 캐시에 두고, 나머지를 Redis를 통해 접근하는 방식임

 

 

2. TTL 정책의 중요성

 - 분산 캐시에도 TTL을 설정하지 않으면, 오래된 데이터가 계속 남아 데이터 불일치(Data Drift)를 초래할 수 있음

 - 각 항목별 TTL을 비즈니스 요구사항에 맞게 세밀하게 조정해야함

 

 

3. 장애시 복구전략

 - Redis 서버 장애시를 대비해 Replica 구성과 Persistence(RDB, AOF) 설정이 필요함

 - 장애 발생시 자동 복구되도록 Sentinel 기반 모니터링을 구성해야함

 

---

팁

* 하이브리드 캐시 구조(Local + Distributed)는 성능과 일관성을 모두 잡을 수 있는 가장 일반적 방식이라고 함

* 트래픽이 폭증할 경우, 먼저 캐시 구조와 TTL 정책을 점검하는게 중요함

* 캐시 서버와 애플리케이션 서버는 같은 리전 / 가용영역(AZ)에 배치해서 네트워크 지연을 최소화함

* 운영 환경에서는 캐시 모니터링 시스템(Prometheus + Grafana)을 반드시 구성해야함

 

---

정리

항목	로컬 캐시	분산 캐시
데이터 저장 위치	서버 메모리	외부 캐시 서버(Redis 등등)
데이터 일관성	서버별로 다름	서버간 공유 가능
확장성	낮음	높음(클러스터 구성 가능)
고가용성	서버 장애시 손실됨	복제 및 Failover 지원
네트워크 비용	없음	있음(TCP 통신이 필요)