DoorDash의 Entity Cache: 서비스 메시 안에서의 투명 프록시 캐싱
DoorDash는 수백 개의 마이크로서비스로 구성된 대규모 분산 환경에서 서비스 간 중복 호출 문제를 해결하기 위해 Entity Cache라는 플랫폼을 자체 구축했다. 이 플랫폼의 핵심은 Envoy와 Valkey를 조합한 투명 프록시 캐싱 구조로, 서비스 메시 내부에서 동작하기 때문에 각 애플리케이션 서비스가 캐시 존재를 별도로 인식하지 않아도 된다는 점이 가장 큰 특징이다. 결과적으로 초당 150만 RPS를 처리하면서 99.99999%의 가용성을 달성했다.
4년차 이상의 백엔드 개발자라면 서비스 간 레이턴시와 반복 조회로 인한 DB 또는 업스트림 서비스 부하 문제를 실무에서 빈번하게 마주쳤을 것이다. Entity Cache는 이 문제를 애플리케이션 코드 변경 없이 인프라 레이어에서 해결했다는 점에서 주목할 만하다.
아키텍처 설계의 핵심 요소
Entity Cache의 설계는 크게 네 가지 축으로 구성된다.
- 투명 캐싱(Transparent Caching): Envoy 사이드카 프록시가 서비스 요청을 가로채어 Valkey(Redis 포크)에서 응답을 조회한다. 캐시 히트 시 업스트림 서비스 호출 없이 바로 응답을 반환한다.
- 이벤트 기반 무효화(Event-driven Invalidation): 데이터 변경 시 이벤트를 발행하여 관련 캐시 항목을 무효화한다. TTL 기반 만료에만 의존하지 않고 실시간 일관성을 유지한다.
- 장애 처리(Failure Handling): 캐시 레이어 장애 시 요청이 업스트림 서비스로 자동 폴백(fallback)되도록 설계하여, 캐시 자체가 단일 장애점(SPOF)이 되지 않도록 했다.
- 성능 최적화: 네트워크 홉 최소화, 직렬화 최적화, Valkey 클러스터 구성 등을 통해 캐싱 오버헤드 자체를 최소화했다.
Envoy를 캐시 레이어의 진입점으로 사용한 것은 기존 서비스 메시 인프라를 재활용하면서 필터 체인을 통한 유연한 캐싱 로직 삽입이 가능하기 때문이다.
실무 적용 관점에서의 시사점
# Envoy 캐시 필터 설정 예시 (개념적)
http_filters:
- name: envoy.filters.http.cache
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.cache.v3.CacheConfig
typed_config:
"@type": type.googleapis.com/envoy.extensions.cache.simple_http_cache.v3.SimpleHttpCacheConfig
이 사례에서 백엔드 개발자가 특히 눈여겨봐야 할 부분은 캐시 무효화 전략이다. TTL만으로는 대규모 트래픽 환경에서 데이터 일관성을 보장하기 어렵다. 이벤트 기반 무효화를 병행함으로써 캐시 히트율과 데이터 정합성을 동시에 확보할 수 있다. 또한 캐시 장애 시 자동 폴백 구조를 갖추지 않으면 가용성 지표가 캐시 레이어 안정성에 직접 종속되는 문제가 발생한다.
Valkey는 Redis의 오픈소스 포크로, 라이선스 이슈를 회피하면서도 성숙한 인메모리 스토어의 기능을 활용할 수 있는 선택지다. Redis를 사용 중인 조직이라면 Valkey로의 전환 비용이 낮고, 클러스터 구성이나 복제 전략도 유사하게 적용 가능하다.
정리
- 서비스 메시의 Envoy 사이드카를 캐시 레이어로 활용하면 애플리케이션 코드 변경 없이 투명한 프록시 캐싱이 가능하다.
- TTL 기반 만료와 이벤트 기반 무효화를 병행하는 것이 대규모 환경에서 캐시 일관성을 확보하는 현실적인 전략이다.
- 캐시 장애 시 업스트림 폴백을 보장하는 구조 설계가 고가용성(99.99999%)의 전제 조건이다.