Cloudflare는 1.1.1.1, Gateway DNS, DNS Firewall, AS112 및 여러 기타 DNS 서비스를 운영하는 Big Pineapple 플랫폼의 DNS 저장소에 적용한 일련의 저수준 최적화 결과를 발표했다. 이 플랫폼은 언제든 2,500억 개가 넘는 DNS 항목을 저장하므로, 항목당 1바이트를 줄이는 것만으로도 전체 인프라에서 250기가바이트가 넘는 메모리를 절약할 수 있다.
Rust로 작성된 데이터 구조에 다섯 가지 변경을 연속으로 적용한 결과, 항목 하나의 크기는 953바이트에서 420바이트로 56% 감소했다. 변경 사항을 전체에 적용한 뒤 Cloudflare 인프라에서 사용되는 작업 집합 메모리는 약 100테라바이트 줄었으며, 성능을 포기하기는커녕 오히려 향상됐다. 항목 삽입 속도는 43% 증가했고 저장소 검색 지연 시간은 19% 감소했다.
DNS 항목의 크기가 중요했던 이유
Big Pineapple은 시작할 때 빈 저장소로 시작한 다음 쿼리가 들어오면서 저장소가 채워지고, 최대 용량에 도달하면 오래됐거나 사용 빈도가 낮은 항목이 제거된다. 저장소 크기는 데이터센터마다 다르며, EDNS Client Subnet을 사용하면 동일한 쿼리에 대해 여러 응답을 저장할 수 있다. authoritative 서버가 클라이언트의 네트워크에 따라 서로 다른 응답을 제공할 수 있기 때문이다.
각 항목은 도메인 이름과 레코드 유형 및 일부 속성을 지정하는 키, 그리고 DNS 응답과 authority 및 additional 섹션, 생성 시각·사용 횟수 카운터·TTL 같은 메타데이터를 포함하는 값으로 구성된다. 이 규모에서는 불필요한 필드나 예약된 공간이 더 이상 작은 내부 구현 세부 사항이 아니라 막대한 운영 비용으로 이어진다.
절감 효과는 어디에서 나왔나?
Cloudflare는 응답을 저장한 뒤에는 데이터가 변경되지 않기 때문에 확장 가능한 Vec 및 String 구조를 고정 크기 구조인 Box<[T]> 및 Box<str>로 교체했다. 이 변경으로 확장 가능한 구조가 보유하던 용량 필드가 제거됐고 사용되지 않는 예약 공간도 줄었다. 각 항목에는 이러한 유형의 필드가 8개 있으므로 항목당 64바이트, 전체 저장소에서 15테라바이트가 넘는 공간을 절약했다.
또한 응답·authority·additional 섹션 목록을 하나의 목록으로 통합하고, 더 큰 포인터와 길이 대신 u16 유형의 오프셋을 사용했다. 이를 통해 항목당 28바이트를 절약했다. 구조는 여러 불리언 필드를 하나의 bitflag으로 압축하는 방식도 활용했으며, 이에 따라 Rust가 구조체 내부에서 요구하는 메모리 정렬로 인해 낭비되는 공간이 줄었다.
대부분의 DNS 레코드에서는 레코드 소유자가 쿼리된 도메인과 일치한다. 따라서 Cloudflare는 이러한 경우 소유자 이름 전체를 더 이상 저장하지 않고, 응답을 구성할 때 저장 키에서 이를 복원한다. CNAME 레코드에서처럼 이름이 다른 경우에는 전체 이름을 저장한다. 그 결과 대부분의 소유자 이름에 대한 메모리 할당이 제거되면서도 실제로 이름이 필요한 경우는 유지됐다.
큰 레코드 유형의 비용 줄이기
RecordData 구조는 가장 큰 레코드 유형의 크기와 동일한 크기의 enum을 사용했으며, 태그와 정렬을 포함하면 그 유형은 144바이트인 NAPTR였다. 그 결과 4바이트만 필요한 A 레코드와 16바이트가 필요한 AAAA 레코드는 필요량보다 훨씬 큰 공간을 차지했다. A와 AAAA가 테스트 트래픽의 80% 이상을 차지했음에도 그랬다.
큰 유형을 별도의 Box 안에 넣는 방식도 시험했다. 이 방법은 A 및 AAAA 레코드의 낭비를 줄였지만 별도의 할당과 메모리 locality 문제가 발생했다. 최종 해결책은 레코드 데이터 자체를 각 레코드에 2바이트 길이 접두사를 붙인 Box<[u8]> 내부의 연속된 원시 바이트로 저장하는 것이었다. 이로써 enum 비용과 여러 번의 할당이 제거됐고, 프로세서가 캐시 메모리를 더 효율적으로 활용할 수 있게 됐다.
이 선택으로 레코드는 더 이상 무작위 인덱싱이 불가능하고 순차적으로 순회해야 한다. Cloudflare는 하나의 항목에 포함되는 레코드 수가 적기 때문에 비용이 제한적이라고 본다. 또한 A, AAAA, TXT 및 DNSSEC 레코드를 포함한 대부분의 유형은 외부로 나가는 DNS 메시지에 직접 복사할 수 있다. 반면 CNAME, NS, MX, SOA처럼 도메인 이름을 포함하는 유형은 DNS 이름 압축을 적용하기 위해 여전히 파싱이 필요하다.
실제로 무엇이 달라졌나?
프로덕션 측정 결과, 상주 메모리는 99백분위에서 9.3기가바이트에서 5.3기가바이트로 줄어 43% 감소했으며, 90백분위에서는 6.5기가바이트에서 3.8기가바이트로 줄어 42% 감소했다. 항목당 할당량은 1.1킬로바이트에서 461바이트로 줄었고, 삽입 속도는 초당 625,000개에서 893,000개로 증가했다. 검색 지연 시간은 828나노초에서 670나노초로 감소했다.
변경 사항의 배포는 2026년 5월 18일에 시작됐고 2026년 7월 6일 모든 서비스에 완료됐다. Cloudflare는 프로덕션의 상주 메모리에는 저장소 외의 다른 데이터도 포함되므로, 프로세스 수준에서 실제로 감소한 비율은 항목별 격리 측정 결과보다 낮았다고 설명한다. 또한 회사는 해제된 메모리를 저장소 용량을 늘리는 데 재투자할 계획이다. 메모리 사용량은 늘리지 않으면서 캐시 적중률을 개선하고 상위 서버로 전송되는 쿼리를 줄이는 것이 목표다.
이 사례의 중요성은 수천억 개의 요소를 처리하는 서비스에서는 불필요한 용량 제거, 할당 통합, locality 개선과 같은 데이터 구조 최적화가 하드웨어 리소스를 직접 추가하는 것보다 더 큰 효과를 낼 수 있음을 보여준다는 데 있다. 그러나 일부 절충점은 남아 있다. 원시 저장 방식은 레코드 처리를 복잡하게 만들고, 소유자 이름을 다시 구성하려면 저장 키에서 값을 복원해야 하며, 테스트 결과는 프로덕션과 완전히 일치하지 않는 특정 트래픽 구성을 기반으로 한다. 따라서 이러한 최적화를 평가할 때는 이론적 수치만이 아니라 프로덕션 측정 결과가 여전히 가장 중요한 기준이다.