텔레메트리 이벤트는 본질적으로 불규칙하게 쏟아진다. 특정 시간대에 몰렸다가 잠잠해지기를 반복하고, 네트워크 지연 때문에 과거 시각을 가진 이벤트가 뒤늦게 도착하기도 한다. 이런 스트림을 그대로 저장소에 흘려보내면 수많은 작은 파일이 생기고, 이후 분석 단계에서 비용과 성능 모두에서 손해를 본다. 소개된 사례는 클라우드플레어의 Workers, Queues, Workflows, R2를 조합해 이 문제를 'UTC 한 시간' 단위의 압축 아카이브로 정리하는 방법을 보여준다.
더블 버퍼링이라는 발상
핵심 아이디어는 그래픽에서 쓰는 더블 버퍼링을 데이터 수집에 가져온 것이다. 화면을 그리는 동안 보이지 않는 버퍼에 다음 프레임을 준비하듯, 두 개의 큐를 두고 하나는 지금 들어오는 이벤트를 받는 활성(active) 큐로, 다른 하나는 이미 채워진 뒤 안전하게 비울 수 있는 비활성(inactive) 큐로 번갈아 사용한다. 이렇게 하면 쓰기와 읽기가 같은 대상에서 충돌하지 않고, 특정 시간 구간의 데이터가 '닫혔다'고 판단할 명확한 기준이 생긴다.
라우팅은 복잡한 상태 관리 대신 모듈로 연산으로 해결한다. 프로듀서는 들어온 페이로드의 타임스탬프를 평가해 활성 큐로 메시지를 보내고, 컨슈머는 같은 방식의 계산으로 비활성 큐를 골라 비운다. 시간 기준을 UTC로 고정한 점도 중요하다. 로컬 타임존을 쓰면 서머타임(DST) 전환 때 한 시간이 중복되거나 사라져 구간 경계가 어긋나지만, UTC에는 그런 불연속이 없어 처리 로직이 단순해진다.
왜 정시가 아니라 30분인가
컨슈머 작업은 매시 정각이 아니라 '매시 30분'에 실행되며, 한 시간 전을 되돌아보아 지금 비워도 되는 비활성 큐를 판단한다. 이 30분의 여유는 경계 근처에서 지연 도착하는 이벤트를 흡수하기 위한 완충 장치로 읽힌다. 방금 끝난 시간 구간의 큐를 곧바로 비우면 늦게 도착한 메시지를 놓칠 수 있지만, 반 시간을 기다렸다가 이미 비활성으로 바뀐 이전 구간을 처리하면 그 구간은 사실상 더 이상 쓰기가 일어나지 않는 상태가 된다. 수집과 소비 사이에 의도적인 시간 간격을 둔 설계다.
마지막 단계에서 모인 배치는 압축된 뒤 간단한 파티셔닝 전략에 따라 R2에 기록된다. 결과물은 시간 단위로 분할·압축된 객체들의 집합, 즉 다운스트림 분석에 적합한 서버리스 데이터 레이크다. 수많은 개별 이벤트 대신 한 시간에 하나꼴의 압축 파일을 다루게 되므로 저장 비용과 조회 효율이 함께 개선된다. 사례에서 강조하는 지점도 클라우드플레어의 가격 구조를 최대한 활용해 저장 비용을 낮춘다는 데 있다.
실무자가 눈여겨볼 지점과 한계
이 패턴이 유용한 이유는 특별한 스트리밍 엔진이나 상시 가동 서버 없이, 큐와 스케줄된 작업만으로 '구간을 닫고 정리하는' 배치 경계를 만들어낸다는 데 있다. 상태를 외부에 저장하지 않고 타임스탬프와 모듈로 계산만으로 어느 큐가 활성인지 결정하기 때문에 구현이 가볍고 장애 지점도 적다. 로그, 메트릭, 클릭스트림처럼 끊임없이 발생하지만 실시간성보다 정리된 보관과 사후 분석이 중요한 데이터에 잘 맞는다.
다만 구조상 명확한 트레이드오프가 있다. 데이터는 최소 수십 분의 지연을 거쳐 R2에 도착하므로 실시간 대시보드나 즉각적인 알림 용도에는 부적합하다. 30분의 완충 시간보다 더 늦게 도착하는 이벤트는 해당 구간에 포함되지 못할 수 있고, 두 개의 큐만 쓰기 때문에 한 구간의 처리가 다음 구간을 침범하지 않도록 소비 작업이 제시간에 끝난다는 전제가 필요하다. 또한 원문은 전체 아키텍처의 윤곽을 제시할 뿐 구체적인 처리량, 실패 재시도, 중복 제거 같은 운영 세부는 다루지 않으므로, 실제 도입 시에는 멱등성과 장애 복구 설계를 별도로 검토해야 한다. 그럼에도 '불규칙한 스트림을 시간 단위 아카이브로 압축한다'는 접근은, 서버리스 환경에서 비용을 억제하며 분석용 데이터를 쌓아야 하는 팀에게 참고할 만한 설계 패턴이다.