Cloudflare, 대상 한정 영역 빌드로 DNS 빌드 작업 축소: 자체 측정에서 92.95%가 전체 재구성 회피, 평균 메모리 49GiB에서 7GiB로

2026년 11월 2일 Cloudflare는 Alex Fattouche가 쓴 엔지니어링 글을 게시해, DNS Zone Builder가 변경 후에 하는 일을 어떻게 줄였는지 설명했다. Zone Builder는 DNS 레코드와 영역 설정의 변경을 Cloudflare의 권한 있는 DNS 서버가 쓸 수 있는 데이터로 바꾸고, 이를 분산 키-값 저장소 Quicksilver에 기록한다. Quicksilver가 이 데이터를 네트워크 전체로 퍼뜨린다. 필자가 2022년에 이 파이프라인에 대해 썼을 때 빌더는 초당 약 250건의 레코드 변경을 받았다. 지금은 약 700건이며, 영역 설정 변경 같은 다른 이벤트가 약 100건 더 있다. 글은 이벤트 수가 진짜 문제였던 적은 없다고 말한다. 문제는 일부 이벤트가 요구하는 작업의 종류였다. 이제 일부 영역은 레코드가 2천만 개를 넘고, Cloudflare는 이것이 수억 개로 늘 것으로 예상한다.

기존 설계에는 한 가지 유용한 성질이 있었다. 전체 빌드는 영역이 왜 바뀌었는지 알 필요가 없었다. 영역과 모든 레코드를 읽고, Quicksilver 키로 변환하고, 저장된 내용과 비교해 차이만 기록했다. 작은 영역에는 저렴하지만, 모든 레코드를 읽고 비교하며 영역 전체를 메모리에 올려 둔다는 점은 같다. Universal SSL을 켜는 것 같은 영역 설정 변경은 메타데이터와 영역 정점(apex)의 인증 기관 권한 부여 레코드를 바꿀 수 있는데, 이벤트가 무엇이 바뀌었는지 알려 주지 않는 경우가 많았다. 그래서 Cloudflare는 이벤트 생산자가 바뀐 필드와, 가능하면 이전 값과 새 값을 담도록 바꾸고, 안전하다고 증명할 수 있는 가장 작은 빌드를 고르는 플래너를 만들었다.

플래너는 다섯 가지 빌드 유형 중에서 고른다. 리소스만, 리소스와 메타데이터, 정점과 메타데이터, 제거, 전체 영역이다. 글이 밝힌 규칙은 엄격하다. 대상을 좁힌 빌드가 기록하는 모든 키는 전체 빌드가 기록했을 내용과 바이트 단위로 같아야 하며, 이를 증명할 수 없으면 시스템은 전체 빌드를 한다. 세부 정보가 없거나 알 수 없는 이벤트, 타임스탬프만 바뀐 갱신은 여전히 전체 빌드를 일으키므로 불확실성이 더 적은 작업으로 바뀌는 일은 없다. 오래된 상태를 지우는 방식은 2022년과 같다. 레코드 이벤트에는 삭제된 레코드와 이전 버전이 들어 있고, 빌더는 다시 만드는 각 이름 아래의 기존 키를 Quicksilver에서 훑어 낡은 키를 제거한다. 가장 큰 영역에는 의도적인 예외가 있다. 레코드 수가 고정된 임계값을 넘으면 빌더는 전체 빌드로 올리지 않는다. 그런 빌드는 끝낼 수 없고 같은 Kafka 파티션의 다른 변경도 붙잡기 때문이다. 대신 정점, 메타데이터, 이벤트가 가리키는 이름을 다시 만들며, 드문 경우는 수동으로 고칠 수 있다.

공유되는 이름 때문에 일이 더 어려워진다. Quicksilver는 영역마다 레코드 키를 따로 저장하지만, 같은 도메인 이름을 가진 모든 영역이 공유하는 메타데이터 키도 하나 두며, 여기에는 질의에 응답할 수 있는 내부 영역 ID가 나열된다. 고객이 가입하거나 해지하는 동안 한 도메인에 여러 영역 객체가 잠시 존재할 수 있다. 글은 이벤트와 빌드 사이에 데이터베이스가 바뀔 수 있어 다시 읽는 방법, 그리고 Kafka 메시지를 잃지 않으면서 같은 영역의 작업을 하나의 스케줄러에서 합치는 방법도 다룬다.

Cloudflare는 안전성 주장을 세 가지 방법으로 검증했다. 동등성 테스트는 같은 데이터베이스 상태에서 전체 빌드와 대상을 좁힌 빌드를 실행하고 후자가 맡는 모든 키를 비교한다. 배포 중에는 좁힌 빌드마다 옆에서 전체 빌드도 실행했다. 이어서 미러 Zone Builder가 프로덕션 Kafka 스트림을 소비하고 프로덕션 데이터베이스 상태를 읽으면서, 고객에게 서비스하지 않는 별도의 Quicksilver에 기록했다. 비교기는 영역의 20퍼센트를 표본으로 점검했고, 글의 대시보드는 짝지어진 234,313개 영역에서 차이율 0.31퍼센트를 보여 준다. 대부분은 타이밍 차이다. 배포는 영역 이름의 해시에 따라 단계적으로 진행했고, 무료 영역을 먼저, 그다음 유료 영역으로 넓혔다.

24시간 빌드 유형 집계에서 리소스만 86.81퍼센트, 리소스와 메타데이터 2.54퍼센트, 정점과 메타데이터 2.30퍼센트, 제거 1.30퍼센트였다. 따라서 92.95퍼센트가 영역 전체 재구성을 피했고 전체 빌드는 7.04퍼센트로, 이전 11.88퍼센트에서 약 40퍼센트 감소했다. 별도 병행 비교에서는 옛 운영 스케줄러와 새 미러 스케줄러가 같은 이벤트를 같은 24시간 동안 처리했다. 일반적인 완료 지연은 거의 그대로였지만 최대 p99 급등은 14.6분에서 1.21분으로 줄었다. 완료 지연은 Quicksilver 기록까지이며 전 세계 배포 시간은 제외한다. Zone Builder 배포 전체의 집계 작업 집합 메모리는 평균 49GiB에서 7GiB, 최고 79GiB에서 12GiB로 떨어졌지만 배포 그래프가 같은 24시간을 증명하지는 않는다. 이후 영역별 재구성 간격과 Kafka Aggregator 버퍼를 줄이고 나서야 중앙값이 약 7.7초에서 3.3초가 됐다. 거친 히스토그램 그래프는 약 두 시간, 나중의 세밀한 히스토그램은 약 네 시간이며 중앙값은 약 3.4초다.

이는 Cloudflare가 서로 다른 단계와 명시된 구간에서 보고한 자체 측정이다. 모든 지표가 하루의 실험이라는 증거도, 반드시 서로 다른 달력 날짜라는 증거도 없다. 빌드 비율의 분모는 빌드 횟수이고 배포 전체 작업 집합 메모리는 단일 빌드 메모리가 아니다. 병행 비교 지연은 모든 빌드 유형과 요금제를 합친 값으로 개별 영역 보장이 아니다. 다른 팀은 이벤트에 변경 사항을 싣고 대상 출력의 동등성을 검증하며 초대형 영역 예외가 있는 안전한 대체 경로를 유지하고 배포 전에 미러에서 시험할 수 있다.

공학적으로 가장 가치 있는 부분은 이 글이 ‘증명’을 대하는 태도이다. 많은 시스템이 속도를 위해 증분 처리를 하지만, 증분 결과가 전체 결과와 같다는 증거는 갖추지 않는다. 여기서는 동등성을 테스트로 쓰고, 배포 때 두 종류의 빌드를 함께 돌리고, 미러 환경과 표본 비교기로 계속 지켜본 뒤, 새로운 유형의 차이가 더 나오지 않을 때에만 비율을 넓혔다. 이런 여러 겹의 검증이 어떤 단일 성능 수치보다 이 변경을 안심하고 넓힐 수 있는 이유를 잘 설명해 준다.