100테라바이트의 문제
Cloudflare는 최근 전 세계 네트워크에서 100테라바이트의 운영 용량을 확보하는 놀라운 메모리 최적화를 수행했습니다. 이러한 괄목할 만한 최적화는 새로운 하드웨어를 단 하나도 추가하지 않고도 130대의 최신 Gen 13 서버 전체 RAM 용량을 인프라에 추가한 것과 맞먹는 효과를 냅니다. 이처럼 방대한 메모리 회수는 저수준 소프트웨어 효율성이 미치는 심대한 영향을 잘 보여줍니다.
1.1.1.1, Gateway DNS, DNS Firewall과 같은 핵심 서비스를 구동하는 Cloudflare의 Big Pineapple 플랫폼은 엄청난 규모를 관리합니다. 이 시스템은 매 순간 2,500억 개 이상의 DNS 캐시 항목을 저장하며, 각 항목은 인터넷 라우팅 정보의 핵심 요소로서 매일 수십억 건의 글로벌 요청을 처리합니다. 이러한 거대한 규모에서는 아주 작은 비효율성도 운영 및 비용 측면에서 큰 문제로 이어질 수 있습니다.
Cloudflare의 핵심 과제는 사소해 보이는 오버헤드의 누적 효과였습니다. 2,500억 개의 DNS 항목에서 항목당 단 1바이트만 낭비되어도 global fleet 전체에서는 수백 기가바이트의 불필요한 메모리 낭비가 발생합니다. 이렇게 방대한 시스템에서 발생하는 미세한 비효율성은 귀중한 자원을 소모할 뿐만 아니라 성능에 영향을 미치고 운영 비용을 증가시키므로, 데이터 구조에 대한 근본적인 재평가가 필요했습니다.
다섯 번의 개선, 거대한 성과
Cloudflare는 메모리 비대화를 해결하기 위해 5단계의 정밀한 Rust 수준 최적화를 수행하여 100TB라는 거대한 성과를 거두었습니다. 우선, 엔지니어들은 변경 불가능한 캐시 항목을 위해 Vec<T>와 String을 Box<[T]>와 Box<str>로 교체했습니다. 이를 통해 사전 할당된 용량과 불필요한 힙 오버헤드를 제거하여, 항목당 64바이트를 즉시 확보하고 전체 플릿에서 15TB 이상의 메모리를 절감했습니다.
두 번째 핵심 변경 사항은 DNS 레코드를 완전히 파싱된 Rust 구조체가 아닌 raw wire-format bytes로 저장한 것입니다. 이를 통해 시스템이 중복 파싱 및 직렬화를 피하게 되어 처리 과정이 간소화되었습니다. 또한, 더 많은 관련 데이터를 캐시 라인에 압축하여 cache locality를 크게 향상시켰습니다.
추가적인 레이아웃 개선을 통해 메모리 낭비를 방지했습니다. Cloudflare는 RecordData enum 내의 NAPTR과 같은 큰 enum variants를 박싱(boxing)하여, A나 AAAA와 같이 더 작고 일반적인 레코드 유형이 과도한 패딩을 예약하지 못하도록 했습니다. 이를 통해 메모리 할당이 실제 데이터 크기와 더 밀접하게 일치하도록 했습니다.
엔지니어들은 또한 세 개의 개별 DNS 응답 레코드 목록(answer, authority, additional)을 하나의 통합된 목록으로 병합했습니다. 이제 두 개의 2바이트 u16 오프셋이 섹션을 구분하며, 기존의 더 큰 포인터/길이 쌍을 대체하여 항목당 28바이트를 절약했습니다. 이러한 통합은 데이터 구조를 크게 압축했습니다.
마지막으로, 조건부 소유자(owner) 저장이 다섯 번째 개선 사항입니다. Cloudflare는 이제 소유자 이름이 쿼리된 도메인과 다를 경우에만 저장하고, 그렇지 않으면 캐시 키에서 유추하도록 했습니다. 이러한 세부적인 최적화가 결합되어 항목당 메모리 점유율이 953바이트에서 420바이트로 56% 감소했으며, Cloudflare의 메모리 환경을 완전히 바꾸어 놓았습니다.
더 작아짐으로써 더 빨라지다
데이터 구조를 축소하면 성능 저하가 발생하는 경우가 많지만, Cloudflare의 최적화는 드문 이중 성과를 거두었습니다. 캐시 삽입 처리량(throughput)은 초당 625,000개에서 893,000개로 43%나 급증했습니다. 동시에 조회 지연 시간(latency)은 828ns에서 670ns로 19% 개선되었습니다.
이러한 가속은 마법이 아니라 메모리 밀도의 직접적인 결과입니다. DNS 캐시 항목당 메모리 사용량을 56%(953바이트에서 420바이트로) 줄임으로써 Cloudflare의 데이터 구조가 더욱 간결해졌습니다. 더 작은 데이터는 더 적은 공간을 차지하므로, CPU의 더 빠른 L1, L2, L3 캐시에 더 많은 캐시 항목을 담을 수 있어 CPU 캐시 지역성(CPU cache locality)이 향상됩니다.
식료품 저장실을 채우는 것과 비슷하게 생각하면 됩니다. 포장이 작을수록 자주 사용하는 물건을 손이 닿기 쉬운 앞쪽 선반에 더 많이 배치할 수 있습니다. 프로세서는 느린 메인 메모리(RAM)에서 데이터를 가져오는 시간을 줄이고, 이러한 고속 캐시에서 직접 데이터를 처리하는 시간을 늘려 대기 상태를 획기적으로 단축합니다.
리소스 소비와 운영 속도 모두에서 이처럼 엄청난 개선을 이루어낸 것은 엔지니어링 측면에서 매우 드문 일이며, 메모리 사용량과 실행 시간 사이의 일반적인 절충안을 뛰어넘는 성과입니다. Cloudflare는 100테라바이트의 메모리를 확보했을 뿐만 아니라 DNS 리졸버의 속도도 확실하게 높였습니다. 기술적인 세부 사항에 대해 더 자세히 알아보려면 Cloudflare의 공식 블로그를 확인하세요: How we saved 100 terabytes of memory by optimizing 1.1.1.1's DNS cache.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
효율성이 가져오는 파급 효과
Cloudflare는 확보된 100TB의 메모리를 그대로 방치하지 않을 것입니다. 대신 이 상당한 용량을 글로벌 네트워크에 직접 재투자하여, 특히 1.1.1.1과 같은 서비스를 위한 DNS 캐시를 확장하는 데 사용합니다. 이러한 전략적 할당은 메모리 복구의 효과를 극대화하여 기술적 성과를 즉각적인 운영 업그레이드로 전환합니다.
더 커진 DNS 캐시는 전 세계 수백만 명의 사용자에게 직접적인 혜택을 제공합니다. 캐시 적중률이 높아지면 Cloudflare 서버가 상위 조회를 시작하는 대신 로컬 메모리에서 더 많은 쿼리를 해결할 수 있으므로 더 빠른 DNS 응답이 가능해집니다. 이는 인터넷 경험의 반응성과 복원력을 직접적으로 향상시킵니다.
Cloudflare의 성과는 업계에 중요한 교훈을 줍니다. 심층적인 시스템 최적화는 여전히 효율성을 위한 강력한 수단이라는 점입니다. AI 워크로드에 대한 수요로 인해 서버 메모리 비용이 상승함에 따라, 하드웨어 변경 없이 기존 인프라를 최적화하여 100테라바이트의 메모리를 확보하는 것은 단순한 엔지니어링 업적을 넘어 전략적 필수 과제입니다. 이러한 세심한 Rust 수준의 작업은 시스템 프로그래밍에서 정밀함이 가지는 지속적인 가치를 강조합니다.
자주 묻는 질문(FAQ)
Cloudflare는 실제로 얼마나 많은 메모리를 절약했나요?
Cloudflare는 1.1.1.1 DNS 캐시를 최적화하여 전 세계 서버 인프라 전반에서 약 100테라바이트(TB)의 RAM을 절약했으며, 이는 서버 130대분의 메모리 용량에 해당합니다.
최적화에는 어떤 프로그래밍 언어가 사용되었나요?
최적화는 Rust로 구현되었습니다. Rust는 메모리 효율성, 성능, 그리고 데이터 구조에 대한 저수준 제어 능력 때문에 선택되었습니다.
메모리를 절약하면 DNS 리졸버의 속도가 느려지나요?
아니요, 오히려 최적화 덕분에 성능이 향상되었습니다. 캐시 삽입 처리량은 43% 증가했고 조회 지연 시간은 19% 감소했습니다.
메모리는 어떻게 절약되었나요?
절약은 벡터 내의 사용되지 않는 메모리 용량 제거, 데이터 목록 병합, 레코드를 원시 바이트로 효율적으로 저장하는 등 DNS 데이터 저장 방식에 대한 5가지 주요 변경 사항을 통해 이루어졌습니다.
Cloudflare는 절약된 100TB의 메모리를 어떻게 사용할 예정인가요?
확보된 메모리는 DNS 캐시 크기를 늘리는 데 재투자될 것입니다. 이를 통해 캐시 적중률이 향상되어 상위 쿼리가 줄어들고, 사용자에게 1.1.1.1 서비스가 더욱 빨라질 것으로 기대됩니다.