1.1.1.1 DNS 캐시 최적화로 메모리 100TB 절감

3 weeks ago 18

Cloudflare의 Big Pineapple은 2,500억 개가 넘는 DNS 캐시 항목의 저장 구조를 다섯 차례 개선해 항목당 메모리를 953바이트에서 420바이트로 56% 줄이고, 전체 약 100TB를 확보함 변경되지 않는 데이터에 Vec·String 대신 Box<[T]>·Box<str>을 사용하고, DNS 섹션을 하나의 목록과 오프셋으로 합치며, 중복되는 레코드 소유자 이름을 생략함 큰 Rust 열거형 변형을 박싱한 뒤 레코드 데이터를 단일 DNS 와이어 형식 버퍼로 통합해 할당과 패딩을 줄이고 메모리 지역성을 높임 벤치마크에서 항목당 할당량은 1.1KB에서 461바이트로 58% 감소했고, 삽입 처리량은 초당 62만5,000개에서 89만3,000개로 43% 증가, 조회 지연은 828ns에서 670ns로 19% 줄어듦 프로덕션 p99 인스턴스 메모리는 9.3GB에서 5.3GB로 43% 감소했으며, 확보한 메모리는 전체 사용량을 늘리지 않고 캐시 용량을 확대해 적중률을 높이고 상위 DNS 서버 질의를 줄이는 데 활용할 계획임 2,500억 개 규모의 DNS 캐시 Big Pineapple은 1.1.1.1, Gateway DNS, DNS Firewall, AS112 등 Cloudflare DNS 서비스를 구동하며 항상 2,500억 개 이상의 캐시 항목을 저장함 이 규모에서는 항목당 1바이트만 낭비해도 전체 플릿에서 250GB 이상의 메모리가 소모됨 콜드 스타트 시 빈 캐시에서 시작해 DNS 질의가 들어올수록 채워지며, 최대 항목 수에 도달하면 오래됐거나 인기가 낮은 항목을 제거함 데이터센터마다 캐시 크기가 다르고, EDNS Client Subnet(ECS) 을 사용하면 클라이언트 네트워크별 응답을 따로 저장해야 함 같은 질의의 여러 버전이 생기고 항목당 메모리도 증가하므로 ECS 사용량이 많은 위치에서 최적화 효과가 특히 큼 캐시 항목과 측정 방법 캐시 키는 질의 도메인 qname, 레코드 유형 qtype, 인증 여부, 태그를 저장함 캐시 값에는 answer·authority·additional 레코드 섹션과 생성 시각, 적중 횟수, TTL, 확장 오류 등의 메타데이터가 포함됨 일부 필드의 자료형은 저장 이후 필요하지 않은 기능과 부가 비용까지 포함해 최적화 여지가 있었음 벤치마크는 프로덕션 트래픽 분포에 가깝도록 무작위 캐시 항목을 생성함 A 56%, AAAA 25%, TXT 19%로 구성함...

Read Entire Article