Figma, 자체 개발 Redis 프록시(Proxy)로 99.9999% 가동 시간 달성

FigCache는 Redis Serialization Protocol(RESP) 기반의 RPC 프레임워크를 제공하는 Go 라이브러리인 ResPC를 기반으로 구축되었다. 프록시는 클라이언트 애플리케이션과 AWS ElastiCache의 Redis 클러스터 사이에 위치하며, 연결 관리(Connection Management) 및 프로토콜 기반 명령 구문 분석(Protocol-Aware Command Parsing)을 담당하는 프론트엔드 레이어와 연결 멀티플렉싱(Connection Multiplexing) 및 명령 실행(Command Execution)을 관리하는 백엔드 레이어로 구성된다. 이러한 분리를 통해 새로운 기능을 쉽게 추가할 수 있다.

FigCache의 백엔드는 정적 설정 파일 대신 Starlark 프로그램으로 구성된다. 이는 운영자가 서버 바이너리를 재배포하지 않고도 라우팅 로직(Routing Logic), 키-프리픽스 기반 거부 규칙(Key-Prefix-Based Rejection Rules), 명령 유형 분할(Command-Type Splitting)을 변경할 수 있음을 의미한다. 런타임 설정(Runtime Configuration)을 통해 유연성을 확보하고, 운영 효율성을 높였다는 평가를 받는다.

FigCache는 Redis Cluster 환경을 지원하며, CROSSSLOT 오류(Error)를 해결하기 위해 팬아웃 필터 엔진(Fanout Filter Engine)을 사용한다. 이 엔진은 여러 샤드에 걸쳐 있는 파이프라인 또는 트랜잭션을 가로채어 개별 명령을 병렬로 실행하고 응답을 집계하여 클라이언트에 반환한다. 애플리케이션 관점(Application Perspective)에서는 오류가 발생하지 않도록 설계되었다.

레딧(Reddit) 댓글에서는 2025년 하반기부터 운영된 시스템으로 6-nine 가동 시간(Uptime)을 달성했다는 주장에 대한 의문을 제기한다. 짧은 운영 기간으로 인해 신뢰성에 대한 검증이 부족하다는 지적이다. 가동 시간(Uptime) 측정 방식에 대한 추가 정보가 필요하다는 의견도 존재하며, 시스템 통합 과정에서 발생할 수 있는 문제에 대한 우려도 나타난다.

Figma는 기존 오픈 소스 프록시의 한계를 극복하기 위해 자체 솔루션을 구축했다. 특히, 기존 솔루션이 완전한 인자 추출(Full Argument Extraction)을 지원하지 않아 런타임 가드레일(Runtime Guardrails) 구현에 어려움이 있었다. Figma는 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 Redis 접근 계층을 중앙 집중화하여 시스템의 유연성을 확보했다. 또한, AWS MemoryDB 및 자체 Postgres를 지원하도록 설계되어 향후 확장성을 고려했다.