늘어난 이벤트를 운반하는 방식 재검토
Cloudflare는 10월 13일 데이터 팀의 하드웨어 사용 억제 과정을 공개했다. 지난 5년의 개선을 하드웨어 확장 약 2년 반을 미룬 것에 해당한다고 표현하지만, 이는 회사의 성장 경로에 대한 비교다. 실제 구매 지출이나 다른 조직의 절감률을 직접 나타내는 값은 아니다. 회사에 따르면 5월에는 고객 트래픽과 내부 팀 데이터를 포함해 초당 약 20억 이벤트를 전달했다. Logfwdr가 분산된 원천에서 수집한 데이터를 중앙 수신기와 Buftee 버퍼로 보내고, 소비자가 ClickHouse 같은 목적지에 적재하는 구조다. 팀은 2026년 봄부터 가을까지 부하 분산·샘플링·집계 변경으로 백본의 압축 트래픽 약 70GB/s를 없앴다고 설명한다. 이는 해당 내부 파이프라인의 전송률 절감 보고이며 인터넷 전체 트래픽 감소나 서버 대수의 동일 비율 감축을 뜻하지 않는다.
압축과 복제 시점을 바꾼 서로 다른 효과
2024년에는 LZ4에서 zstd로 압축 방식을 바꾼 뒤 이 환경에서 압축 트래픽이 거의 40% 줄었고 CPU 영향은 작았다고 팀은 밝혔다. Zstandard 공식 문서는 압축률과 속도를 조절하는 여러 단계가 있음을 설명하므로, 이 결과를 어느 데이터와 설정에서도 같은 CPU 비용으로 얻는다고 일반화할 수 없다. 2026년에는 비지역 제한 분석 이벤트를 원천에서 두 중앙 지역으로 각각 보내던 방식을 바꿨다. 원천에서는 한 번 보내고 Buftee 이후에 복제해 두 ClickHouse 사본을 유지한다. 이전한 데이터셋에서는 전송 약 43GB/s를 줄이는 대신 지역 간 복제 약 7GB/s가 늘었다고 설명한다. 복제를 제거한 것이 아니라 수행 위치와 앞단 데이터량을 바꾼 것이다.
표본 추정과 미리 정한 집계의 차이
다른 변경은 Logfwdr에서도 샘플링하고, 중앙 수신기와 적재 과정에서 추가로 축약하는 방식이다. 원문은 키별로 많은 이벤트를 더 줄이되 샘플 비율을 이용해 원래 수치를 추정한다고 설명한다. Cloudflare의 공식 샘플링 문서도 분석 데이터가 표본에 기반할 수 있음을 밝힌다. 반면 원천부터 부분 집계를 합치는 방식은 차원과 지표를 먼저 정해 정해진 합계·개수를 다룬다. HTTP 집계 데이터셋에서는 압축 전송률이 9GB/s 이상에서 2GB/s 미만으로 줄었다는 보고다. 이 사례의 약 80%와 전체 파이프라인의 약 70GB/s는 대상과 단위가 다르다.
무엇을 남겨야 하는지가 최적화 기준
ARCH.B는 이 사례의 핵심이 원시 이벤트를 모두 중앙으로 가져온 뒤 줄이던 작업의 위치를 다시 정한 데 있다고 본다. 중복 전송과 불필요한 필드를 줄이는 것, 표본으로 통계를 추정하는 것, 미리 정한 집계를 합치는 것은 서로 다른 선택이다. 합계만 필요한 사용량 통계라면 부분 집계를 전달할 수 있지만, 이후 개별 이벤트에 관한 새로운 질문을 해야 한다면 같은 구조로 충분하지 않을 수 있다. 샘플링 역시 모든 원본 기록을 보존하는 기능과 다르다. 운영팀은 저장 행 수와 전송 바이트가 줄었다는 사실만 보지 말고, 필요한 질의를 여전히 수행할 수 있는지와 적은 빈도의 사건을 어떻게 관찰하는지를 함께 정해야 한다.
장애 복구와 성장 여유를 함께 보기
복제 위치를 늦추면 WAN 사용량을 줄일 수 있어도 지역 간 연결이 끊긴 동안의 누적분을 어떻게 따라잡는지까지 설계해야 한다. 회사는 Buftee 보존 버퍼에서 복구 후 따라잡는 경로를 설명하며, 지역 제한 데이터는 지정된 지역 안에 유지한다고 구분한다. 따라서 이를 데이터 위치 제한을 없애는 공통 구조로 해석할 수 없다. 비용 측면에서도 한 번 줄인 전송량이 영구적인 여유를 보장하지는 않는다. 원문은 성장으로 절감분이 다시 소진되는 과정을 보여 준다. 다른 조직에 적용할 때는 같은 압축률을 기대하기보다 전송·CPU·메모리와 복구 지연을 각각 측정하고, 표본 및 집계가 서비스의 분석 목적을 충족하는지를 먼저 검증하는 편이 유용하다.
출처
Cloudflare Blog의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
Rewinding the exponential: How we keep hardware usage down (새 창)
