클라우드플레어 DNS 빌드 지연 57% 단축: 79GiB 메모리 병목을 깬 타깃 빌드 아키텍처
클라우드플레어가 2,000만 개 이상 레코드를 보유한 도메인 설정 변경 시 발생하던 전체 빌드 병목을 제거하고 메모리 점유율을 85% 절감한 아키텍처 개편 내역을 분석한다.
발행일: 2026.11.04
공식 사이트 확인전체 영역 인메모리 로딩 제거로 85% 감축
불필요한 안전 대기열 단축으로 57% 가속
카프카 파티션 블로킹 원천 차단
2,000만 레코드 존의 전수 재연산이 유발한 메모리 폭주와 카프카 정체
글로벌 DNS 인프라에서 도메인 설정 변경 이벤트는 초당 수백 건 단위로 유입된다. 클라우드플레어(Cloudflare) 존 빌더(Zone Builder) 시스템이 처리하는 초당 DNS 레코드 갱신 요청은 2022년 약 250건에서 2026년 기준 700건으로 3배 가까이 증가했다. 여기에 도메인 설정 변경 등 기타 이벤트가 초당 100건 이상 추가되면서 전체 파이프라인의 작업 부하가 급증했다.
문제의 본질은 이벤트 유입량 자체보다 단일 도메인 내 레코드 규모 확장에 따른 연산 복잡도 폭증에 있었다. 상용 환경의 일부 대형 도메인은 단일 존(Zone) 내에 2,000만 개가 넘는 레코드를 유지하고 있으며, 향후 수억 개 규모로 확대되는 추세다. 기존 구조에서는 도메인 단위 설정이 단 하나만 변경되어도 해당 도메인의 전체 데이터베이스 행을 읽어 엣지 전송 포맷으로 변환하고 비교하는 전수 빌드(Full Build)가 실행되었다.
79GiB에서 12GiB로 작업자 메모리 축소
기존 7.7초 대비 절반 이하로 단축
전체 도메인 전수 재연산 회피 비율
2,000만 개 이상의 레코드를 메모리에 동시에 적재하고 엣지 데이터스토어인 퀵실버(Quicksilver)의 기존 키와 바이트 단위 대조를 수행하는 작업은 서버 인메모리 한계를 초과한다. 프로세스가 메모리 고갈(OOM)을 겪으며 재시도를 반복하는 동안, 동일한 아파치 카프카(Apache Kafka) 파티션을 공유하는 수많은 도메인의 변경 요청 전체가 큐 안에서 대기 상태에 갇혔다.
타깃 빌드 플래너와 스케줄러 병합을 통한 최소 단위 갱신 매커니즘
엔지니어링 팀은 전수 빌드를 근본적으로 대체하기 위해 안전성이 수학적으로 입증된 최소 단위 빌드만 선택하는 타깃 빌드 플래너(Targeted Build Planner)와 스케줄러를 도입했다. 유니버설 SSL(Universal SSL) 활성화와 같은 존 설정 이벤트는 전체 레코드가 아닌 도메인 루트(Apex)의 CAA(Certification Authority Authorization) 레코드와 공통 메타데이터 키만 수정하면 충분하다.
변경 이벤트 수신부터 퀵실버 쓰기까지의 단계
단순 타임스탬프 갱신인지 세부 변경 필드인지 식별
루트 레코드, 일반 네임, 메타데이터 중 영향 대상 격리
증명 불가능한 불확실성 감지 시에만 전수 빌드로 에스컬레이션
동일 도메인으로 인입된 후속 이벤트를 단일 빌드 사이클로 압축
새로운 빌드 플래너는 퀵실버 출력 대상을 네임별 레코드 키와 공통 메타데이터 키로 명확히 분리하고, 변경 유형을 5가지 빌드 타입으로 세분화했다. 핵심 안전 원칙은 타깃 빌드가 작성하는 모든 키가 전수 빌드가 작성했을 결과물과 정확히 일치해야 한다는 점이다. 변경 호출자나 필드 정보가 누락되어 엣지 데이터의 일관성을 검증할 수 없는 예외적 상황에서만 전수 빌드로 격상된다.
동시에 적용된 신규 스케줄러는 짧은 시간 간격으로 유입되는 동일 도메인 관련 이벤트를 단일 작업으로 병합했다. 과거에는 개별 레코드 수정과 설정 변경이 순차적으로 별도 빌드를 트리거하며 대기열을 채웠으나, 통합 스케줄러는 실행 직전 큐에 누적된 동일 존의 변경점을 한 번의 원자적 연산으로 처리하여 불필요한 빌드 횟수를 구조적으로 삭제했다.
실측 벤치마크로 확인한 지연 시간 및 인프라 비용 개선
신규 아키텍처 배포 이후 전체 빌드의 92.95%가 완전한 전수 빌드를 거치지 않고 타깃 빌드로 전환되었다. 도메인 설정 변경 이벤트로 인해 촉발되던 전수 빌드 횟수는 약 40% 감소했다.
| 지표 구분 | 기존 레거시 빌드 파이프라인 | 타깃 빌드 플래너 적용 후 | 개선 폭 및 실무 영향 |
|---|---|---|---|
| 작업자 피크 메모리(Peak RAM) | 79 GiB | 12 GiB | -85% (OOM 크래시 방지) |
| 중위(p50) 빌드 완료 시간 | 7.7초 | 3.3초 | 57% 단축 (배포 즉시 반영) |
| 최대 p99 지연 시간 스파이크 | 14.6분 (876초) | 1.21분 (72.6초) | 91.7% 단축 (파티션 지연 제거) |
| 전수 빌드 회피 비율 | 기준점 (0%) | 92.95% | 대규모 존 리빌드 40% 감축 |
| 카프카 파티션 가용성 | 재시도 중 큐 정체 빈발 | 무중단 스트리밍 유지 | 헤드오브라인 블로킹 해소 |
피크 메모리 및 최악 지연 시간 비교
피크 메모리가 79GiB에서 12GiB로 85% 줄어들면서 호스트 서버의 리소스 헤드룸이 크게 확보되었다. 이에 따라 기존 파이프라인이 파티션 과부하 복원력을 위해 강제하던 인위적 대기 시간을 절반 이하로 축소할 수 있었다. 그 결과 DNS 변경 사항이 데이터베이스에 커밋된 시점부터 엣지 분산 스토리지에 최종 기록되기까지의 중위 지연 시간이 7.7초에서 3.3초로 줄었다.
초대형 데이터셋 분산 인프라를 위한 의사결정 프레임워크
대규모 상태 데이터를 엣지 글로벌 네트워크로 동기화해야 하는 엔터프라이즈 환경에서 클라우드플레어의 이번 엔지니어링 전환은 세 가지 핵심 기준점을 제시한다.
코드 복잡도가 낮고 불일치 위험이 없어 유지보수 효율 우수
이벤트 메타데이터 추적 및 영향 격리 필수, 전수 빌드 상한선 강제
첫째, 이벤트 프로듀서의 계약(Contract)을 정밀화해야 한다. 데이터베이스에서 타임스탬프만 갱신하는 레거시 함수는 이벤트 컨슈머로 하여금 불확실성에 대비해 보수적인 전수 재연산을 강제하게 만든다. 변경 전후 필드 값과 변경 주체를 페이로드에 명시하지 않으면 파이프라인 하류(Downstream)의 연산 비용이 기하급수적으로 증가한다.
둘째, 데이터 규모에 따른 연산 에스컬레이션 차단 장치(Circuit Breaker)를 구축해야 한다. 클라우드플레어는 레코드 수가 임계치를 초과하는 초대형 존의 경우, 설정 변경 시에도 전수 빌드로의 격상을 원천 금지하도록 설계했다. 전수 빌드가 완료되지 못하고 무한 재시도 루프에 빠져 전체 파티션을 마비시키는 위험을 감수하는 대신, 루트 레코드와 메타데이터만 갱신하는 명시적 트레이드오프를 채택했다.
셋째, 안전성이 증명되지 않은 최적화는 거부해야 한다. 타깃 빌드 플래너는 엣지에 기록될 바이트 결과물이 전수 빌드와 100% 동일하다는 인과관계가 증명된 경우에만 부분 갱신을 실행한다. 이와 같은 정밀한 상태 비교 체계가 확보되어야만 데이터 정합성을 해치지 않고 연산 인프라 비용과 전파 지연을 동시에 제어할 수 있다.