프록시 아키텍처가 숨기고 있는 비용
고성능 백엔드 시스템을 설계할 때 Redis(또는 그 포크인 Valkey)와 같은 인메모리 데이터 저장소 앞에 프록시 레이어를 두는 구성은 매우 일반적이다. 접속 풀링, 라우팅, 인증 등을 중앙에서 처리할 수 있어 편리해 보이지만, 이 구조가 숨겨진 비용을 유발한다는 점은 쉽게 간과된다.
프록시 레이어가 추가되면 다음과 같은 문제가 발생한다.
- CPU 오버헤드: 모든 요청이 프록시를 경유하므로 직렬화/역직렬화 및 네트워크 홉이 추가된다.
- 테일 레이턴시(tail latency) 증가: p99, p999 구간의 응답 시간이 눈에 띄게 악화된다. 프록시가 병목이 되는 순간 상위 백분위 레이턴시가 폭발적으로 늘어난다.
- 장애 전파(blast-radius): 프록시 노드에 장애가 생기면 그 뒤에 있는 모든 Valkey 인스턴스 접근이 동시에 불가능해진다. 장애 영향 범위가 불필요하게 넓어지는 것이다.
NASA 우주왕복선 사례는 이 문제를 잘 설명해 준다. 복잡한 중간 레이어가 추가될수록 시스템 전체의 신뢰성은 각 컴포넌트 신뢰성의 곱으로 낮아진다. 레이어가 하나 늘 때마다 SLA 달성이 그만큼 어려워진다.
직접 접근(Direct-Access) 아키텍처로의 전환
OSS Valkey는 Redis 포크로, 직접 접근 아키텍처를 적용하기에 적합한 구조를 갖추고 있다. 핵심 아이디어는 단순하다. 애플리케이션이 프록시를 거치지 않고 Valkey 노드에 직접 연결하는 것이다.
// 프록시 경유 방식 (기존)
// App → Proxy(:6380) → Valkey(:6379)
// 직접 접근 방식
JedisPoolConfig poolConfig = new JedisPoolConfig();
poolConfig.setMaxTotal(50);
JedisPool directPool = new JedisPool(poolConfig, "valkey-node-1", 6379);
직접 접근 구조에서는 클라이언트 사이드 라우팅 또는 클러스터 클라이언트(예: Jedis Cluster, Lettuce Cluster)가 프록시의 역할을 대신한다. 이를 통해 얻을 수 있는 이점은 다음과 같다.
- 레이턴시가 밀리초(ms) 단위에서 마이크로초(µs) 단위로 개선된다.
- 프록시 노드 자체의 인프라 비용이 제거된다.
- 장애 격리가 명확해져 특정 노드 장애가 전체 데이터 계층으로 번지지 않는다.
AI 피처 스토어(feature store)처럼 초저지연이 요구되는 워크로드에서는 이 차이가 서비스 품질을 결정짓는 요인이 된다. 수천 개의 피처를 실시간으로 조회해야 하는 상황에서 프록시가 추가하는 수 밀리초의 오버헤드는 SLA 위반으로 직결된다.
실무 적용 시 고려할 트레이드오프
직접 접근 방식이 항상 정답은 아니다. 이 구조로 전환할 때 실무에서 반드시 검토해야 할 사항들이 있다.
- 클라이언트 복잡도 증가: 라우팅, 재연결, 페일오버 로직을 클라이언트 또는 공통 라이브러리에서 직접 처리해야 한다. Lettuce나 Jedis의 클러스터 모드를 잘 이해하고 있어야 한다.
- 연결 수 관리: 프록시가 연결을 집약해 주던 역할이 사라지므로, 각 애플리케이션 인스턴스가 Valkey 노드에 직접 연결을 맺는다. 수평 확장 시 연결 수가 급격히 늘 수 있으므로 풀 설정에 주의해야 한다.
- 보안 및 접근 제어: 프록시가 담당하던 인증, TLS 종단 처리 등을 클라이언트 레벨에서 구성해야 한다.
// Lettuce 클러스터 직접 접근 예시
RedisClusterClient clusterClient = RedisClusterClient.create(
RedisURI.Builder.redis("valkey-node-1", 6379).build()
);
StatefulRedisClusterConnection<String, String> connection = clusterClient.connect();
4년차 이상의 백엔드 개발자라면 "프록시를 없애면 관리 포인트가 줄어드는가, 늘어나는가"를 팀의 역량과 운영 성숙도 관점에서 냉정하게 판단해야 한다. 단순히 레이턴시 수치만 보고 도입을 결정하기보다는, 클라이언트 라이브러리 운영 비용과 장애 대응 시나리오를 함께 설계해야 한다.
정리
- 프록시 기반 캐시 아키텍처는 편의성 이면에 CPU 오버헤드, 테일 레이턴시 증가, 장애 전파 위험이라는 숨겨진 비용을 수반한다.
- Valkey 직접 접근 아키텍처는 프록시 레이어를 제거해 마이크로초 수준의 레이턴시와 인프라 비용 절감을 동시에 달성할 수 있다.
- 전환 시에는 클라이언트 사이드 라우팅 복잡도, 연결 수 폭증, 보안 구성 변화를 반드시 함께 설계해야 한다.