Cloudflare K2: 서버리스 이벤트 스트림

AI 요약

Cloudflare가 Developer Platform의 서버리스 이벤트 스트리밍 서비스 K2를 공개 베타로 선보였습니다. 이벤트를 순서가 있는 로그로 저장해 생산자와 소비자를 분리하고, 여러 소비자가 각자 처리 속도에 맞춰 읽도록 설계했습니다. 소비자가 오랫동안 중단되어도 데이터를 보존하며, 읽기 작업을 여러 소비자에게 나누거나 각 소비자가 모든 이벤트를 받는 방식으로 사용할 수 있습니다.

엣지 환경에 맞춘 구조

K2는 Cloudflare의 스트림 처리 서비스 Basin Pipelines에 내구성 있는 입력 버퍼가 필요해 처음 개발됐습니다. Pipelines는 데이터를 읽고 변환해 R2에 쓰는 pull 방식으로 동작하므로, 읽기 전에 이벤트를 보관할 계층이 필요합니다. Cloudflare는 335개가 넘는 도시에 분산된 엣지 인프라에서 전통적인 분산 시스템을 그대로 운영하기 어렵다고 설명합니다. 서버 자원이 작은 단위로 나뉘고 수명이 짧으며, 네트워크 통신이 공용 인터넷을 거치는 환경이기 때문입니다.

K2는 저장 계층으로 R2를 사용합니다. Cloudflare는 R2가 11개의 9로 표현되는 내구성과 강한 일관성을 제공한다고 밝힙니다. 복제와 합의를 저장소 계층에 맡기면 K2의 애플리케이션 계층을 단순하게 유지할 수 있고, 컴퓨팅과 저장 용량을 따로 확장할 수 있습니다. 객체 저장소는 로그에서 흔히 쓰는 append 연산을 지원하지 않으므로, K2는 엣지 서비스 메모리에 쓰기를 모았다가 일정 시간이 지나면 여러 이벤트를 세그먼트 파일 하나로 저장합니다. R2의 원자적 연산으로 이벤트 순서와 계속 증가하는 오프셋을 보장하며 별도 조정 서비스를 두지 않습니다.

이 설계에는 지연 비용이 따릅니다. 메모리에서 배치를 모으고 객체 저장소에 쓰는 시간이 필요해, 초기 버전의 쓰기 지연은 응답 시간 기준 99백분위에서 약 1초입니다. 로컬 디스크 복제에 의존하는 Kafka보다 지연이 높으며, 종단 간 지연도 커질 수 있습니다.

Queue, Pipelines와의 차이

Cloudflare Queues는 개별 작업의 완료 여부를 추적할 때 적합합니다. 작업마다 재시도, 지연 처리, 실패 메시지 큐(dead-letter queue)를 적용할 수 있습니다. 예를 들어 결제 API 호출이 실패하면 해당 작업을 다시 시도하고, 특정 메시지의 처리 상태를 관리하는 식입니다. K2는 대량의 데이터를 이동하고 오래 보관하며 여러 소비자에게 전달하는 데 초점을 둡니다. 메시지를 묶음 단위로 생산하고 소비하므로 처리 효율을 높이는 대신 개별 메시지 단위 재시도는 제공하지 않습니다. Pipelines는 이벤트를 변환해 R2나 Basin Catalog에 저장할 때 권장하며, 직접 처리하거나 다른 목적지로 보내려면 K2를 선택하라고 안내합니다.

사용 방식과 베타 조건

스트림은 cf 명령줄 도구, Wrangler, 대시보드, API로 만들 수 있습니다. Worker 바인딩이나 HTTP API로 바이트 데이터를 전송하고, 구독을 만들어 소비자를 연결합니다. 구독은 소비자 간 작업을 나눠 처리하는 방식과 소비자별로 별도 구독을 만들어 모든 이벤트를 전달하는 pub/sub 방식에 쓸 수 있습니다. 소비자가 읽으면 이벤트 묶음에 5분 임대가 걸립니다. 처리에 성공하면 ack, 실패하면 nack를 보내 재전달을 요청하고, 처리가 더 필요하면 임대를 연장합니다.

공개 베타는 Workers Paid 계정에서 사용할 수 있습니다. 현재 제한은 저장 공간 10GB, 스트림당 초당 생산량 30MB이며 베타 기간에는 요금을 받지 않습니다. 이후 예상 요금은 생산 데이터와 소비 데이터 각각 GB당 0.04달러, 보관 데이터는 GB·월당 0.02달러입니다. 로드맵에는 쓰기 처리량 확대, 키 기반 순서 보장, Worker 소비자의 푸시 방식 지원, 저지연 Express 등급, Apache Kafka 클라이언트 호환이 포함됩니다.

Hacker News 반응

• @necubi — K2 게시물 작성자이자 기술 책임자입니다. Basin Pipelines의 입력 계층으로 처음 만들었고, 아직 공개할 수 없는 새 제품을 만드는 여러 팀도 K2를 사용하고 있다고 답했습니다.
• @samtp — 글을 읽고도 Cloudflare Queues와 K2 중 언제 무엇을 써야 하는지 잘 모르겠다고 물었습니다.
  • @necubi — Queue는 결제 처리처럼 개별 작업을 완료하고, 성공할 때까지 재시도하며 상태를 추적할 때 적합합니다. K2는 대량의 데이터를 옮길 때 씁니다. 가격도 메시지 수가 아니라 GB 기준이며, 여러 소비자가 같은 레코드를 읽고 장기간 보관할 수 있습니다.
• @theredsix — 기존 GKE Pub/Sub, Kafka나 다른 큐 서비스보다 나은 점이 무엇인지 질문했습니다.
  • @necubi — Google Pub/Sub도 좋은 제품이라고 전제한 뒤, K2의 장점은 특히 장기 보관 비용이라고 답했습니다. 객체 저장소를 쓰므로 저장 비용을 낮출 수 있고, 서버리스라 클러스터를 관리하거나 확장할 필요가 없습니다. 대신 쓰기와 종단 간 지연이 더 높아 비용이 지연보다 중요한 경우에 맞다고 설명했습니다.
• @psanford — 객체 저장소가 데이터 시스템의 기반으로 자리 잡는 흐름에 기대를 보이며, 앞으로 S3 API가 이런 용도에 맞게 확장될지 궁금해했습니다.
  • @Onavo — S3의 비트 손상 방지와 복구 기능을 높이 평가하면서도, AWS가 아닌 서비스가 같은 신뢰성을 제공하는지가 관건이라고 지적했습니다. R2에서도 객체가 사라졌다는 포럼 글을 가끔 봤다고 덧붙였습니다.
  • @necubi — 100ms 미만 지연이 필요하지 않은 데이터 시스템은 객체 저장소로 이동하고 있다고 동의했습니다. K2 팀이 R2 팀과 가까이 일해 두 제품을 함께 발전시킬 수 있다고 답했습니다.
• @e1g — 쓰기 지연은 1초 미만이지만 종단 간 전달 지연은 p95 2.5초, p99 7.5초였다고 공유하며 예상 범위인지 물었습니다.
• @pcthrowaway — 소비자가 배치를 ack하는 대신 다음 consume 요청에 배치 끝의 ID를 보내면 어떻겠냐고 제안했습니다.
  • @necubi — 같은 의미를 유지하면서 왕복 요청을 줄이는 좋은 제안이라며 추가하겠다고 답했습니다.
• @nnx — 생산 요금 GB당 0.04달러는 합리적으로 보이지만 소비 요금도 같으면 소비자 한 명만 있어도 GB당 0.08달러가 들고, fan-out을 쓰면 비용이 빠르게 커진다고 지적했습니다.
• @thepaulmcbride — 업계 표준이 아닌 제품에 기반을 두는 일을 망설인다고 말했습니다.
  • @necubi — Kafka API 호환은 Kafka 생태계에 투자한 기업이 쉽게 도입하고, 필요하면 빠져나갈 수 있도록 돕기 위한 계획이라고 답했습니다.

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