클라우드플레어가 R2 오브젝트 스토리지 위에 직접 구축한 서버리스 이벤트 스트리밍 서비스 'K2'를 퍼블릭 베타로 공개했다. K2는 이벤트를 순서가 보장되는 내구성 있는 로그로 저장하고, 생산자(producer)와 소비자(consumer)를 분리해 대규모 데이터 이동과 장기 보관을 지원한다. 전통적인 브로커 클러스터를 직접 운영하지 않고도 지속성 있는 스트림을 다룰 수 있다는 점이 핵심이다.
왜 생산자와 소비자를 분리하는가
일반적인 RPC 기반 구조에서는 생산자와 소비자가 규모와 시점 양쪽에서 맞물려야 한다. 생산자가 보내는 데이터가 소비자의 처리 용량을 넘어서거나, 소비자나 하위 서비스가 잠시라도 중단되면 이벤트가 유실된다. 하나의 데이터를 여러 소비자가 각자 처리해야 할 때 문제는 더 커진다. 예컨대 전자상거래 백엔드가 거래 완료 이벤트를 발생시키면 이를 분석 시스템과 사기 탐지 서비스가 독립적으로 읽어야 한다. K2는 그 사이에 쓰기를 흡수하는 계층을 두어, 각 소비자가 자기 속도로 데이터를 소비하도록 만든다. 소비자가 오랜 기간 멈춰 있어도 데이터는 사라지지 않는다.
카프카 대신 R2를 택한 이유
K2는 원래 클라우드플레어의 베이신 파이프라인(Basin Pipelines)을 위한 수집 계층으로 출발했다. 파이프라인은 풀(pull) 방식의 스트림 처리 엔진이어서, 이벤트를 읽어 변환하고 R2에 쓰기 전에 어딘가에 먼저 저장해 둬야 한다. 게다가 일단 받아들인 이벤트는 절대 버리지 않겠다는 약속 때문에 그 저장소는 장기간 내구성을 유지해야 한다.
보통 이 지점에서 기업들은 아파치 카프카를 배포한다. 그러나 클라우드플레어의 파이프라인은 335개 이상 도시에 걸친 엣지 위에서 돌아가며, 이 독특한 환경에서는 카프카 같은 전통적 분산 시스템을 그대로 운영하기 어렵다. 엣지에서는 머신 자원을 작은 조각으로만 받고, 그 머신은 비교적 수명이 짧으며, 네트워킹도 공용 인터넷을 거치는 경우가 많다. 대신 사용자와 가깝고 수평 확장 능력이 뛰어나다는 강점이 있다. 그래서 클라우드플레어는 이미 보유한 강력한 상태 저장 기반인 R2를 택했다. R2는 11개의 9(99.999999999%)에 달하는 내구성과 강한 일관성 API를 제공하므로, 복제와 합의를 스토리지 계층에 맡기면 애플리케이션 계층을 훨씬 단순하고 저렴하며 빠르게 만들 수 있다. 컴퓨팅과 스토리지가 분리돼 각각 독립적으로 확장되고, 방대한 과거 데이터를 저렴하게 보관할 수 있다는 이점도 따라온다.
오브젝트 스토리지 위에 로그를 올리는 법과 대가
문제는 R2를 비롯한 오브젝트 스토리지가 로그의 기본 연산인 '추가(append)'를 지원하지 않는다는 점이다. K2는 대신 엣지 서비스 메모리에 쓰기를 모아 두었다가, 짧은 시간을 기다린 뒤 이벤트 묶음을 하나의 세그먼트 파일로 기록한다. 순서 보장과 단조 증가하는 오프셋은 별도의 조율 서비스 없이 R2의 원자적 연산만으로 구현한다. 이 방식의 대가는 생산 지연이다. 로컬 디스크보다 오브젝트 스토리지 쓰기가 느린 데다 배치가 쌓이기를 기다려야 하므로, 초기 버전에서 99번째 백분위 기준 약 1초의 생산 지연이 발생한다. 지연에 민감한 워크로드라면 이 특성을 반드시 고려해야 한다.
큐·파이프라인과의 구분
클라우드플레어에는 이미 비동기 전달 수단으로 Queues와 Basin Pipelines가 있어 선택 기준이 중요하다. Queues는 이미지 처리 요청처럼 비싸거나 오래 걸리는 개별 작업 항목을 비동기로 완료하는 데 초점을 두며, 작업 단위로 재시도·지연·데드레터 큐 같은 세밀한 제어를 지원한다. 반면 K2는 대규모 데이터 이동, 장기 보관, 팬아웃 소비에 맞춰 설계됐다. 메시지를 배치로 생산·소비하므로 효율은 높지만 메시지 단위 재시도는 포기하며, 그만큼 생산 지연도 높다. 베이신 파이프라인은 JSON 이벤트를 변환해 R2나 Iceberg 테이블에 쓰는 수집 서비스이므로, 최종 목적지가 오브젝트 스토리지라면 파이프라인을, 직접 처리하거나 다른 목적지로 보낸다면 K2를 택하는 것이 권장된다.
사용 방식과 현재 한계
사용은 스트림 생성에서 시작한다. 용도별로 여러 스트림을 두고 cf, Wrangler, 대시보드, API로 만들 수 있으며, HTTP API나 Worker 바인딩으로 이벤트를 보낸다. K2는 데이터를 바이트로 다루므로 인코딩 형식은 자유다. 소비 측에서는 구독(subscription)을 만들어 여러 소비자에게 작업을 나눠 읽기 병렬성을 확보하거나, 소비자마다 별도 구독을 둬 모든 메시지를 전달받는 펍/섭 패턴을 쓸 수 있고 둘을 혼합할 수도 있다. consume를 호출한 클라이언트는 해당 배치에 대해 5분짜리 리스를 받는다. 현재 K2는 Workers Paid 계정 대상 퍼블릭 베타로, 일정한 한도가 적용되고 베타 기간에는 과금되지 않는다. 다만 구체적 한도 수치, 정식 과금 시점의 가격, 로드맵 세부 내용은 아직 공개되지 않았으므로, 운영 도입을 검토한다면 약 1초의 생산 지연과 메시지 단위 재시도 부재라는 설계상 트레이드오프를 먼저 실측해 보길 권한다.