지수적 트래픽 증가를 되돌리기: 하드웨어 사용량을 낮추는 방법

AI 요약

Cloudflare의 Data 팀은 2026년 5월 초당 약 20억 건의 이벤트를 처리했습니다. 트래픽은 지수적으로 늘지만 하드웨어는 선형적으로 증가하는 문제에 대응하기 위해 지난 5년간 데이터 스키마, 압축, 복제, 샘플링, 집계를 차례로 손봤습니다. 회사는 이런 최적화로 하드웨어 증설을 약 2년 반 미뤘다고 설명합니다.

파이프라인과 스키마 분리

데이터는 전 세계의 Workers 등에서 Logfwdr로 모인 뒤 중앙 수신기와 버퍼링 시스템 Buftee를 거쳐 ClickHouse 같은 저장소로 전달됩니다. 2022년 이전에는 모든 제품의 필드를 하나의 스키마에 넣었습니다. 내부 소비자는 필요한 필드만 추리기 전에 전체 스트림을 받아야 했습니다. 제품별 스키마로 나눈 뒤에는 일부 필드가 중복되더라도 백본 대역폭 사용량이 35~40% 줄었습니다. 글은 이를 압축 트래픽 증가 약 1년치에 해당하는 절감으로 설명합니다.

압축 알고리즘 변경

2024년에는 LZ4에서 zstd로 압축 알고리즘을 바꿨습니다. 과거 시험에서는 zstd의 CPU 사용량이 더 높았기 때문에 일부 서버에 먼저 적용하고 전체 서버로 확대하면서 CPU 지표를 확인했습니다. 눈에 띄는 CPU 증가 없이 압축 트래픽을 약 40% 줄였고, 같은 네트워크 용량으로 1.5배가 넘는 트래픽을 처리할 수 있게 됐다고 합니다. 원본 데이터량의 증가 추세는 그대로였지만 압축 후 전송량이 줄어 하드웨어 확장 시점을 약 10개월 늦춘 효과를 냈습니다.

전송 경로에서 복제 분리

재해 복구를 위해 기존에는 Logfwdr가 비지역 분석 이벤트를 중앙 데이터센터 두 곳에 각각 전송했습니다. 거의 모든 분석 스트림에 이중 전송을 적용하자 광역 네트워크 트래픽도 두 배로 늘었습니다. 새 구조에서는 Logfwdr가 이벤트를 한 번만 전송하고, 중앙 수신기가 샘플링한 데이터를 Buftee에 기록한 뒤 원격 inserter가 데이터센터 간 복제를 수행합니다. 한 지역이 중단되면 Logfwdr가 살아 있는 지역으로 전송을 돌립니다. 데이터센터 간 연결이 끊겨도 각 클러스터는 자기 몫의 데이터를 계속 수집하고, Buftee의 보존 데이터로 연결 복구 후 따라잡습니다.

이 구조를 적용한 데이터셋에서는 압축된 광역 전송량 약 43GB/s를 없애고 파이프라인 내부 데이터센터 간 복제에 약 7GB/s를 더했습니다. 글은 샘플링 후 복제해 원시 데이터 두 벌을 보내지 않는 점과, 중앙에서 데이터를 고르게 묶어 압축 효율을 높인 점을 차이의 이유로 듭니다. 해당 데이터셋 기준 순감소량은 36GB/s입니다.

Logfwdr 단계의 샘플링

기존 중앙 수신기에서 하던 샘플링을 Logfwdr에서도 시작했습니다. 각 데이터셋은 생산자 팀이 정한 키로 레코드를 묶습니다. 알고리즘은 키별 레코드를 먼저 섞어 편향을 줄이고, 각 그룹에서 전체 개수의 제곱근만큼 표본을 고릅니다. 표본 비율로 계산값을 보정합니다. 예를 들어 100건 중 10건을 뽑으면 표본 비율은 10/100이며, 추정 전체 개수는 10에 10을 곱한 100건입니다.

팀은 여러 트래픽 규모와 키를 골라 ClickHouse에 기록된 행 수와 표본을 바탕으로 추정한 전체 개수를 비교했습니다. 데이터가 많은 키일수록 표본 비율이 낮아져, 많이 관측되는 키의 저장 행 수를 억제합니다. 글에 따르면 1,160만 이벤트를 표현하는 ClickHouse 행 수는 기존 7만9천 건에서 1만8천 건으로 줄었습니다. 우선 적용한 상위 데이터셋 세 곳에서는 중앙 수신기로 보내는 압축 데이터가 각각 절반 이상 감소해 총 25GB/s, 하루 2PB 이상을 줄였습니다.

단계별 집계

샘플링이 다양한 질문에 근사 답변을 주는 방식이라면, 집계는 미리 정한 질문에 정확한 결과를 내는 대신 세부 원본 데이터를 보존하지 않습니다. 예를 들어 분 단위로 고유 IP 개수를 세거나 도메인과 HTTP 메서드별 요청 수를 합산합니다. 기존에는 파이프라인 후반부 inserter에서 집계했지만, 새 기능은 Logfwdr, 중앙 수신기, Buftee에서 데이터를 읽는 inserter, ClickHouse 순으로 여러 차례 부분 집계를 합칩니다.

첫 적용 대상인 HTTP 트래픽 데이터셋에서는 압축 전송량이 초당 9GB 이상에서 2GB 미만으로 줄었습니다. 글은 이를 약 80% 감소로 제시합니다. Cloudflare는 사용량 지표처럼 합계와 개수의 정확성이 중요한 데이터에 집계를 적용하고, 이를 위한 내부 제품 Ready-Aggregates도 만들었습니다.

전체 효과와 한계

Ready-Analytics에서는 로드 밸런싱으로 트래픽이 약 26GB/s에서 13GB/s로 줄었지만, 두 달 뒤 자연 증가로 약 20GB/s까지 다시 올랐습니다. 샘플링을 적용한 뒤에는 약 8GB/s로 낮아졌습니다. 두 조치가 없었다면 이 데이터셋만 9월에 60GB/s를 넘겼을 것으로 추산합니다. 수신기 CPU와 메모리 사용량은 약 50% 줄어 CPU 약 750개와 메모리 3.5TiB를 확보했습니다.

Cloudflare는 2026년 봄부터 가을까지 로드 밸런싱 약 38GB/s, 상위 데이터셋 샘플링 25GB/s, 집계 7GB/s 이상을 절감해 백본 압축 트래픽을 총 약 70GB/s 줄였다고 보고합니다. 다만 Ready-Analytics 사례처럼 절감분은 트래픽 증가로 빠르게 줄어들 수 있습니다. 회사는 2026년의 개선만으로도 5년 뒤 처리해야 할 데이터량을 절반으로 낮췄다고 추산하며, 구조와 알고리즘을 계속 개선해야 하드웨어 수요를 감당할 수 있다고 말합니다.

원문: Cloudflare Blog / 번역·요약: Trawling