ZGateway가 대규모 데이터베이스 연결을 운영 가능한 경계로 바꾸는 법

대규모 데이터베이스의 병목은 쿼리 처리에만 있지 않다. 클라이언트가 늘어날수록 연결 관리의 복잡성과 장애 전파 위험도 함께 커진다. Meta가 ZippyDB 앞에 ZGateway를 도입한 이유는 이러한 연결 확산을 통제 가능한 구조로 바꾸기 위해서다.

직접 연결을 두 개의 관리 가능한 구간으로 분리

ZippyDB는 Meta에서 가장 널리 사용되는 키-값 저장소로, 제품 메타데이터와 카운터, 구성 데이터를 초당 수십억 건의 작업 규모로 처리한다. 기존 구조에서는 100만 대가 넘는 클라이언트 호스트가 필요한 ZippyDB 서버에 직접 연결했다. 클라이언트가 늘면 서버의 연결 부담도 커지고, 재시작이나 배포가 겹칠 때 연결 폭주가 장애로 이어질 수 있다.¹

ZGateway는 클라이언트 애플리케이션과 ZippyDB 사이에 위치하는 무상태 프록시 계층이다. 요청 처리에 필요한 영구 상태를 자체적으로 보관하지 않으며, Meta의 서비스 메시인 ServiceRouter를 통해 검색되는 지역별 계층으로 운영된다.¹

이 구조에서는 클라이언트가 ZGateway에 연결하고, ZippyDB 서버는 통제 가능한 프록시 집합을 상대한다. 전체 연결이 없어지는 것은 아니지만, 직접 연결 하나로 얽혀 있던 경로가 두 구간으로 분리되면서 확장과 장애를 관리할 명확한 경계가 생긴다.

추가 비용과 공통 제어의 균형

프록시를 추가하면 네트워크 홉과 운영 계층도 늘어난다. 실제로 ZGateway의 평균 연산 오버헤드는 일반적인 사용 사례에서 약 6%다. 그럼에도 현재 ZippyDB 전체 트래픽의 약 40%를 처리한다는 점은, 이 비용보다 연결 구조를 중앙에서 관리하는 효과가 크다는 것을 보여준다.¹

ZGateway는 순수 프록시와 읽기 관통 캐시라는 두 가지 형태를 제공하며, 두 형태는 같은 처리 파이프라인을 공유한다. 또한 사용 사례별로 하나의 내부 C++ 클라이언트를 실행해 기존 ZippyDB 기능을 활용한다.¹

핵심은 모든 기능을 프록시에 다시 구현하는 것이 아니다. 공통 경로를 마련해 클라이언트와 데이터베이스 사이의 연결 정책을 일관되게 적용하고, 개별 클라이언트가 같은 운영 문제를 반복해서 해결하지 않도록 하는 데 있다.

ZGateway에서 얻을 수 있는 설계 판단 기준

프록시 계층이 항상 필요한 것은 아니다. 클라이언트 수가 적고 직접 연결 구조를 쉽게 변경할 수 있다면, 별도의 계층을 두지 않는 편이 더 단순할 수 있다.

반대로 다음과 같은 환경에서는 ZGateway와 같은 프록시 계층을 검토할 가치가 있다.

• 클라이언트 수가 빠르게 늘어나 데이터베이스 연결 부담이 커지는 경우

• 클라이언트 소유 팀이 분산돼 공통 정책을 일괄 적용하기 어려운 경우

• 배포나 재시작으로 인한 연결 폭주가 장애 위험을 높이는 경우

• 일정한 연산 오버헤드를 감수하더라도 확장과 장애의 경계를 명확히 해야 하는 경우

결국 중요한 판단 기준은 프록시의 오버헤드만이 아니다. 직접 연결의 단순함과 중앙 제어의 운영 가치를 비교해야 한다.

요약: ZGateway는 ZippyDB 앞에 무상태 프록시 계층을 두어 대규모 클라이언트 연결을 관리 가능한 경계로 전환한다. 대규모 시스템에서는 작은 오버헤드보다 연결 확산과 장애 범위를 일관되게 통제할 수 있는지가 더 중요한 설계 기준이 될 수 있다.

¹ZGateway: Learnings from Putting a Proxy in Front of ZippyDB - Engineering at Meta