직접 연결 구조의 한계와 연결 폭풍의 위험
메타 엔지니어링(Engineering at Meta)은 내부 핵심 분산 키-값 저장소인 ZippyDB의 트래픽을 단일화하고 제어하기 위해 무상태(Stateless) 프록시 계층인 'ZGateway'를 구축했다고 발표했습니다. ZippyDB는 메타의 제품 메타데이터, 카운터, 설정값 등을 처리하며 대규모 호스트에 걸쳐 초당 수십억 건의 연산을 서비스하는 저장소입니다. 기존에는 100만 대가 넘는 클라이언트 호스트가 수만 개의 데이터 샤드와 수십만 대의 데이터베이스 호스트(ZServer)에 직접 TLS 연결을 수립하는 직접 접근(Direct-Access) 구조를 채택하고 있었습니다.
이러한 N:M 메쉬 구조는 시스템 규모가 커질수록 자원 낭비와 안정성 한계를 드러냈습니다. 유휴 연결 상태에서도 양단에서 메모리, CPU, 파일 디스크립터(File Descriptor)가 지속적으로 소모되었기 때문입니다. 특히 특정 클라이언트 집군(Cohort)이 재시작되거나 서비스 배포가 진행될 때 발생하는 '연결 폭풍(Reconnection Storm)'은 데이터베이스 호스트의 자원을 급격히 고갈시켰습니다. 실제로 라우팅 버그 등으로 인해 호스트가 파일 디스크립터 한계에 도달해 재부팅 루프에 빠지는 장애가 발생하기도 했습니다.
ZGateway 아키텍처와 트래픽 처리 파이프라인
ZGateway는 클라이언트와 ZServer 복제본 사이에 위치하는 무상태 프록시 티어로 구현되었습니다. 클라이언트는 메타의 서비스 메시 솔루션인 ServiceRouter를 통해 가장 인접한 리전의 게이트웨이 호스트를 검색하고, 여기에 고정 연결(Sticky connection)을 유지합니다. 내부 엔진으로는 수백 개 팀의 클라이언트 바이너리에 흩어져 있던 기존 C++ 'Thick Client' 코드를 프록시 계층 내부의 관리형 서비스 형태로 재활용하여 구동합니다.
ZGateway의 요청 처리 파이프라인은 TLS 연결을 종료한 뒤 테넌트별 접근 제어 목록(ACL) 확인과 허용 제어(Admission Control), 트래픽 셰이핑을 순차적으로 수행합니다. 이후 샤드 위치를 해석하고 로컬 캐시를 확인한 뒤, 동일한 샤드로 향하는 진행 중인 요청들을 일괄 묶음 처리(Batching & Coalescing)하여 데이터베이스 복제본으로 전달합니다. ZGateway는 순수 프록시(Pure Proxy) 모드와 읽기 관통 캐시(Read-Through Cache) 모드라는 두 가지 방식으로 운영됩니다.
대규모 트래픽 분담률과 모델 기반 연결 절감 수치
메타에 따르면 ZGateway는 현재 초당 10억 회 이상의 작업(>1B ops/sec)을 안정적으로 처리하고 있습니다. 발표 시점 기준 전체 ZippyDB 트래픽의 약 40%가 ZGateway를 경유하고 있으며, 향후 60% 이상으로 적용 범위를 확대할 계획입니다. 이 과정에서 프록시 계층 도입으로 인해 추가된 연산 오버헤드(Computational Overhead)는 평균 유스케이스 기준 약 6% 수준에 불과하다고 밝혔습니다.
연결 관리 측면에서는 비약적인 개선 수치가 제시되었습니다. 메타의 모델 추산치에 따르면, ZGateway 도입을 통해 인프라 전역의 총 지속 연결(Persistent connections) 수가 약 19배(roughly 19x) 절감되었습니다. 아울러 개별 데이터베이스 호스트가 감당해야 하는 인바운드 연결 수는 약 97~98% 감소한 것으로 분석되었습니다. 이를 통해 수백 개 팀의 클라이언트가 동시에 배포되더라도 데이터베이스 계층으로 직접적인 연결 부하가 전파되지 않도록 완충선을 형성했습니다.
단일 제어 지점 확보의 실무적 가치와 아키텍처 해석
ZGateway 구축 사례는 대규모 분산 환경에서 '클라이언트 제어 불능' 문제를 아키텍처 차원에서 어떻게 해결해야 하는지 보여주는 실무적 지표입니다. 수백 개 엔지니어링 조직이 소유한 100만 대 이상의 클라이언트 호스트를 대상으로 풀링 정책이나 재시도 로직을 일괄 업데이트하는 것은 사실상 불가능에 가깝습니다. 데이터베이스 관리 주체가 클라이언트 변경 주기를 통제할 수 없을 때, 중간 프록시를 배치하는 것은 N:M 문제를 관리 가능한 두 개의 1:N 홉으로 축소하는 강력한 통제 수단이 됩니다.
특히 병합 처리(Batching & Coalescing)와 허용 제어를 중앙화한 점은 실무적인 복원력을 크게 향상시킵니다. 장애가 발생했을 때 백엔드 인프라 운영팀은 며칠 혹은 몇 주가 걸리는 클라이언트 바이너리 롤아웃을 기다리지 않고, 중앙 프록시 티어의 설정 변경만으로 몇 분 안에 트래픽을 차단하거나 셰이핑할 수 있습니다. 즉, 프록시 계층은 단순한 네트워크 중계기를 넘어 전체 워크로드를 관측하고 즉각적인 방어 조치를 취할 수 있는 단일 제어 지점(Control Point)으로 기능합니다.
추가된 홉의 트레이드오프와 검증이 필요한 한계점
하지만 ZGateway 모델을 무조건적인 최적화로 받아들이기에는 명확한 트레이드오프와 확인되지 않은 지표들이 존재합니다. 아키텍처에 프록시 티어가 추가됨에 따라 네트워크상 1개의 홉(Hop)이 추가로 발생하며, 별도의 프록시 서버 플릿을 운영하고 유지보수해야 하는 인프라 비용이 수반됩니다. 메타는 약 6%의 연산 오버헤드만 발생한다고 밝혔으나, 추가된 홉으로 인해 엔드투엔드 요청의 지연 시간(P50 및 P99 Latency)이 구체적으로 몇 밀리초(ms) 증가했는지는 수치로 공개하지 않았습니다.
또한 본문에서 강조된 '19배 연결 절감' 및 '97~98% 호스트 연결 감소' 수치는 전역 실측값뿐만 아니라 내부 모델 추정치(Model estimates)가 포함되어 있다는 점을 유의해야 합니다. 더불어 메타는 사내 트래픽 60% 이상 전환을 목표로 제시했을 뿐 구체적인 달성 일정이나 로드맵을 밝히지 않았으며, 본 기술은 메타 내부 인프라 전용으로 발표되어 외부 오픈소스 공개 여부나 관련 라이선스 계획도 언급되지 않았습니다. 실무 환경 도입을 검토하는 엔지니어라면 이러한 성능 지연과 운영 비용의 상관관계를 면밀히 검증할 필요가 있습니다.
출처
Meta Engineering의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
ZGateway: Learnings from Putting a Proxy in Front of ZippyDB (새 창)
