FigCache 도입을 통한 Redis 레이어 99.9999% 가용성 달성

Figma Builds In-House Redis Proxy to Hit Six Nines Uptime

Matt Saunders2026년 5월 5일6분advanced

AI 요약

Context

클라이언트 서비스의 급격한 확장에 따른 Connection 급증으로 Redis I/O 포화 및 Thundering Herd 현상 발생. 파편화된 클라이언트 라이브러리로 인한 Observability 저하와 Redis Cluster의 구조적 제약인 CROSSSLOT 에러가 사이트 가용성의 핵심 병목으로 작용.

Technical Solution

ResPC 라이브러리 기반의 Stateless Proxy 계층 구축을 통한 애플리케이션 코드와 인프라 복잡도 분리
Frontend(연결 관리 및 프로토콜 파싱)와 Backend(커넥션 멀티플렉싱 및 명령 실행)의 계층 분리 설계를 통한 확장성 확보
Starlark 기반의 런타임 구성 엔진 도입으로 바이너리 재배포 없는 라우팅 로직 및 거부 규칙 변경 구현
Fanout Filter Engine 설계를 통한 Multi-shard Pipeline의 병렬 Scatter-gather 처리로 CROSSSLOT 에러 원천 차단
Redis Cluster Emulation 모드 제공을 통해 기존 Cluster-aware 클라이언트의 투명한 마이그레이션 지원
RESP 인터페이스 추상화를 통한 AWS MemoryDB 및 Postgres 등 다양한 백엔드 저장소 교체 가능 구조 설계

실천 포인트

1. Connection 포화 방지를 위한 전용 Proxy 계층 도입 검토

2. 런타임 설정 변경을 위해 Starlark와 같은 임베디드 스크립트 언어 활용 고려

3. 분산 DB의 구조적 제약(예: CROSSSLOT)을 애플리케이션이 아닌 프록시 단에서 해결하는 Fanout 패턴 적용 검토

4. 인프라 교체 가능성을 염두에 둔 표준 프로토콜(RESP 등) 기반의 추상화 레이어 설계

태그

#High Availability #Redis #Starlark #RESP #Proxy

원문 읽기