Cloudflare, 1.1.1.1 DNS 캐시 최적화로 메모리 100TB 절약

Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

Cloudflare, 1.1.1.1 DNS 캐시 최적화로 메모리 100TB 절약

Cloudflare가 1.1.1.1 DNS 캐시의 메모리 사용량을 50% 이상 줄여 약 100TB의 메모리를 절약했습니다. 이는 2500억 개 이상의 캐시 항목을 저장하는 Big Pineapple 플랫폼에서, 항목당 1바이트만 줄여도 250GB 이상의 메모리를 절약할 수 있는 규모입니다. 다섯 가지 최적화(Vec를 Box로 교체, 리스트 통합, 소유자 생략, enum 박싱, 와이어 포맷 저장)를 통해 메모리뿐 아니라 성능도 개선되어, 삽입 처리량은 43% 증가하고 조회 지연 시간은 19% 감소했습니다.

이 규모에서 항목당 1바이트를 낭비하면 전체 플릿에서 250GB 이상의 메모리가 낭비됩니다.
  1. lpapez

    이것이 소프트웨어를 제공하는 올바른 방법입니다.

    먼저 작동하는 제품을 만들고, 아이디어를 검증하고, 사업을 안정화하고, 수익을 창출하기 시작한 다음에 비용 최적화를 시작할 수 있습니다.

    사실 최적화는 이 과정에서 가장 쉬운 부분입니다. 이 HN 스레드에는 이러한 최적화를 사소하게 여기는 많은 시스템 프로그래밍 전문가들이 있기 때문입니다.

  2. irdc

    이것이 시스템 프로그래밍이 여전히 중요한 이유입니다.

    그들이 놓치고 있는 명백한 최적화는 레코드 데이터를 별도로 메모리를 할당하는 대신 CacheEntry 멤버 바로 뒤에 배치하는 것 같습니다. 하지만 그것은 C 프로그래머인 제 생각일 뿐이고 Rust에서는 그렇게 쉽지 않을 수도 있습니다.

  3. BikiniPrince

    Cloudflare에 대한 재미있는 점. 저는 그들의 상위 1천 또는 1만 개의 주소를 사용하는 DNS 워밍 스크립트를 가지고 있습니다. 그러면 마스터가 시작될 때 전체 캐시를 워밍합니다. 다른 모든 것은 memcache를 사용하므로 클러스터는 따뜻하고 아늑합니다. 제가 알기로는 그들처럼 도메인 통계를 공개하는 곳은 없습니다.

  4. strenholme

    제 MaraDNS에서는 블랙리스트 항목의 메모리 사용량을 적극적으로 최적화했습니다. 항목에 대한 메모리를 할당하기 위해 하나의 큰 malloc()을 사용하고, 잠재적으로 블랙리스트에 있는 항목에 대해 해당 메모리 블록을 탐색했습니다.

    항목당 하나의 malloc()을 사용할 때 큰 블랙리스트는 237MB의 메모리를 차지했습니다. 동일한 블랙리스트가 단일 malloc() 호출로 로드되도록 최적화되자 9.5MB만 차지했습니다.

    https://samboy.github.io/blog/entries/MaraDNS.html#BlogEntry...

  5. vinkelhake

    이것들은 메모리 사용량을 줄이기 위한 꽤 표준적인 접근 방식으로 보입니다. 여러 개의 개별 목록을 하나로 결합하는 접근 방식이 어떤 면에서 Rust의 안전 보장을 약화시킨다는 생각이 듭니다.

    이전에 세 개의 개별 Vec 객체가 있었다면 Rust는 인덱스가 범위를 벗어날 수 없다는 것을 보장합니다. 이제 모든 객체를 단일 Vec에 넣고 오프셋에 의존한다면, 이 하위 슬라이스의 범위를 벗어나는 인덱싱이 패닉 없이 발생할 수 있는 문이 열립니다.

    사소한 지적이고 최적화를 무효화하지는 않지만, 기사가 그것을 언급하지 않은 것이 놀랍습니다.

  6. ManBeardPc

    Record 구조체에는 rtype와 data가 포함되어 있고 RecordData는 태그된 유니온입니다. 이 둘은 항상 동기화되어 있지 않나요? DNS 전문가는 아니지만, 이것이 중복인지 아니면 둘 다 있어야 하는 이유가 있는지 궁금합니다. 이미 직렬화된 상태로 저장한다면 더 이상 중요하지 않지만, 왜 이렇게 되었는지 궁금합니다.

  7. superze

    이것은 유로로 얼마인가요 아니면 이제 메모리를 RAM으로 측정하나요?

  8. bhouston

    MacBook의 DNS 서버를 1.1.1.1 또는 8.8.8.8로 재정의할 때 공용 Wi-Fi를 사용하는 데 문제가 발생했습니다. 캡티브 포털이 captive.apple.com 이름의 사용자 지정 해석을 요구하기 때문이라고 생각합니다. 외부 DNS 서버는 해당 이름을 로컬 게이트웨이의 인증 페이지로 올바르게 해석하지 못합니다.

이 날의 다른 글

2026-08-27