클라우드플레어, 데이터 파이프라인 최적화로 하드웨어 사용량 대폭 절감

파이프라인의 변화

클라우드플레어 데이터 팀은 기하급수적으로 증가하는 데이터 트래픽에 대응하고 하드웨어 사용량을 효율적으로 관리하기 위해 데이터 파이프라인에 여러 구조적 및 알고리즘적 최적화를 적용했다. 이러한 노력은 지난 5년간 약 2년 반에 해당하는 하드웨어 확장을 연기하는 효과를 가져왔다. 주요 개선 사항으로는 2022년 모놀리식 데이터 스키마 분할, 2024년 압축 알고리즘 변경, 2026년 파이프라인 복제 아키텍처 재설계, 샘플링 분산, 그리고 데이터 집계 기능 도입이 있다.

클라우드플레어의 데이터 파이프라인은 Logfwdr 서비스에서 분산된 데이터 소스(예: Workers, FL)로부터 이벤트를 수집하는 것으로 시작한다. 수집된 데이터는 중앙 집중식 수신기로 전달된 후 버퍼링 시스템인 Buftee에 저장된다. 이후 소비자(consumers)가 Buftee에서 데이터를 가져와 ClickHouse와 같은 최종 목적지로 분배하는 구조이다. 이 과정에서 발생하는 비효율성을 줄이고 확장성을 확보하는 것이 최적화의 핵심 목표였다.

최적화 배경 및 구현

클라우드플레어 네트워크는 전 세계 수만 대의 서버를 통해 웹 트래픽의 20% 이상을 처리하며, 2024년 5월에는 초당 약 20억 건의 이벤트를 처리했다. 이러한 방대한 데이터는 Cloudflare Logs, SQL API, 관측성, 내부 분석 등 다양한 서비스에 활용된다. 그러나 트래픽이 매년 기하급수적으로 증가하는 반면, 하드웨어 증가는 선형적으로 이루어져 리소스 비용을 통제하는 것이 중요한 과제로 부상했다.

2022년, 모놀리식 스키마 분할: 기존에는 모든 제품의 필드를 단일 스트림에 담는 모놀리식 스키마를 사용했다. 이로 인해 내부 소비자는 필요 없는 필드까지 모두 수집한 후 필터링해야 했다. 데이터 팀은 대부분의 제품이 스키마의 100% 필드를 필요로 하지 않는다는 가설 아래, 제품별로 필요한 필드만 포함하는 작은 메시지 스키마로 분할했다. 이 변화로 백본 대역폭 사용량이 35~40% 감소했으며, 이는 약 1년치 압축 트래픽 증가분을 상쇄하는 효과를 가져왔다.

2024년, zstd 압축 도입: 트래픽 증가로 인한 네트워크 혼잡 문제를 해결하기 위해 압축 알고리즘을 LZ4에서 zstd로 변경했다. 과거 zstd는 CPU 사용량이 높다는 우려가 있었으나, 점진적인 배포와 면밀한 모니터링 결과 CPU에 미치는 영향은 미미한 것으로 확인되었다. 이 변경으로 압축 트래픽 처리량이 약 40% 감소하여, 동일한 파이프라인으로 1.5배 이상의 트래픽을 지원할 수 있게 되었다. 이는 2024.6.2 버전에서 2024.7.1 버전으로의 전환을 통해 약 10개월 전의 트래픽 성장 수준으로 되돌리는 효과와 같다.

2026년 봄, 파이프라인 복제 아키텍처 재설계: 재해 복원력을 위해 Logfwdr가 비지역 분석 이벤트의 두 복사본을 두 중앙 집중식 지역으로 이중 전송하던 방식은 트래픽 증가에 따라 지속 불가능해졌다. 데이터 팀은 Logpush 모델을 분석 스트림에 적용하여 Logfwdr가 각 이벤트를 광역 전송망을 통해 사용 가능한 중앙 수신기로 한 번만 전송하도록 변경했다. 복제는 파이프라인에서 가능한 한 늦게, 즉 데이터가 분산 버퍼링 계층인 Buftee에 도착한 후 원격 삽입기(remote inserters)가 데이터 센터 간 복사본을 스트리밍하는 방식으로 이루어진다.

이러한 재설계를 통해 마이그레이션된 데이터셋에서 약 43GB/s의 압축 전송 트래픽이 제거되었고, 데이터 센터 간 복제는 약 7GB/s만 추가되어 순수하게 36GB/s의 광역 네트워크 트래픽 감소 효과를 얻었다. 이는 샘플링 이후 복제와 균일한 파티셔닝을 통한 압축률 향상 덕분이다. HTTP 분석 및 Ready-Analytics 데이터셋에 초기 적용되어 각각 약 20GB/s(50% 이상) 및 43%의 트래픽 감소를 보였다.

2026년 여름, Logfwdr 샘플링 분산: 기존에는 중앙 집중식 수신기에서 샘플링을 수행하여 다운스트림 시스템의 부하를 줄였다. 데이터 팀은 Logfwdr에서도 샘플링을 추가로 적용하여 처리 과정을 파이프라인 초기로 앞당겼다. 샘플링 알고리즘은 각 데이터셋의 키를 기준으로 레코드를 섞은 후, 총 레코드 수의 제곱근에 해당하는 샘플 크기를 선택하는 방식이다. 이중 샘플링을 통해 데이터 양은 줄이면서도 데이터 품질과 대표성을 유지할 수 있었다. 상위 3개 데이터셋에 적용한 결과, 중앙 수신기로 전송되는 압축 데이터 양이 최소 절반으로 줄어들어 총 25GB/s, 즉 하루 2PB 이상의 데이터 절감 효과를 보였다.

2026년 가을, 파이프라인에 집계 도입: 과거에는 집계(롤업)가 파이프라인의 후반부, 즉 Buftee에서 데이터를 읽어 ClickHouse에 삽입하는 단계에서 이루어졌다. 데이터 팀은 이 집계 기능을 파이프라인의 모든 단계로 분산하여 데이터가 수렴될 때마다 부분 집계를 결합할 기회를 만들었다. Logfwdr, 중앙 수신기, 버퍼링 후 ClickHouse 삽입기, 그리고 ClickHouse 자체의 집계 테이블 엔진에서 순차적으로 집계를 수행한다. HTTP 트래픽 데이터셋에 이 기능을 처음 적용한 결과, 압축 바이트 트래픽이 9GB/s 이상에서 2GB/s 미만으로 감소하여 약 80%의 절감 효과를 달성했다. 이는 샘플링과 달리 미리 정의된 차원과 지표에 대해 정확한 답변을 제공하는 데 유용하다.

개발자 및 시스템 영향

이러한 파이프라인 최적화는 클라우드플레어의 운영 효율성과 비용 절감에 지대한 영향을 미쳤다. 특히, Ready-Analytics 데이터셋의 경우 로드 밸런싱 적용으로 트래픽이 50% 감소했으나, 두 달 만에 유기적 트래픽 증가로 절반가량 회복되었다. 이후 샘플링을 적용하여 다시 한 자릿수 GB/s로 트래픽을 줄이는 등, 지속적인 최적화가 트래픽 증가 속도를 늦추는 데 필수적임을 보여준다.

전체 파이프라인에 걸쳐 2026년 봄부터 가을까지 로드 밸런싱으로 약 38GB/s, 상위 데이터셋 샘플링으로 약 25GB/s, 집계로 현재까지 약 7GB/s 이상의 압축 트래픽을 백본에서 제거했다. 이는 총 약 70GB/s의 압축 트래픽 절감 효과를 가져왔다. 또한, 중앙 데이터 센터에서 처리하는 데이터 양이 줄어들면서 Ready-Analytics 수신기에서만 CPU 약 750개와 메모리 3.5TiB를 절감하는 등 상당한 컴퓨팅 리소스 절감 효과도 얻었다.

적용 조건 및 한계

데이터 파이프라인 최적화는 장기적인 관점에서 클라우드플레어의 지속 가능한 성장을 가능하게 한다. 2026년 한 해 동안의 노력만으로도 2031년 예상 데이터 볼륨을 절반으로 줄이는 장기적인 영향을 미칠 것으로 전망한다. 이는 하드웨어 수요를 지속 가능한 수준으로 유지하기 위한 구조적 및 알고리즘적 최적화의 중요성을 강조한다.

그러나 이러한 최적화 방식에는 각각의 적용 조건과 한계가 존재한다. 샘플링은 데이터 양을 줄이는 데 효과적이지만, "어떤 질문이든 대략적으로 답변"하는 방식이므로 정확한 합계나 개수가 필요한 사용 사례에는 적합하지 않을 수 있다. 반면 집계는 "고정된 질문 세트에 정확하게 답변"하지만, 미리 차원과 지표를 선택해야 한다는 제약이 있다. 또한, 고객 메타데이터 경계(Customer Metadata Boundaries)에 해당하는 데이터는 지정된 지역 내에 엄격하게 저장되어야 하는 등 데이터 주권 관련 제약 사항도 복제 아키텍처 설계 시 고려된다. zstd 압축 도입 시 초기 CPU 사용량 증가 우려가 있었으나 점진적 배포와 모니터링으로 극복한 사례처럼, 새로운 기술 도입에는 잠재적 제약이 따른다. 트래픽은 지속적으로 증가하므로, 이러한 최적화 노력은 일회성이 아닌 지속적인 과정이 되어야 한다.