Kafka·PostgreSQL 최적화로 보안 스캔 처리량 12배 높이기

Cloudflare가 Security Insights 스캔 시스템의 처리량을 초당 10건에서 120건 이상으로 12배 끌어올린 과정을 다룬다. 추가 하드웨어 없이 Kafka 소비자, PostgreSQL 쿼리, API 아키텍처 최적화만으로 달성했으며, 스캔 주기를 주 1~2회에서 플랜별 1~7일로 대폭 단축했다.

핵심 포인트

Kafka 파티션의 순서 보장을 유지하면서 고루틴 병렬 처리와 slow/fast 레인 분리로 소비자 처리량 극대화
PostgreSQL UNNEST(소량)와 COPY(대량)를 데이터 규모에 따라 동적으로 전환하는 하이브리드 삽입 전략
active-active 배포에서 포틀랜드·암스테르담 간 대서양 횡단 DB 왕복이 3초 지연 원인 — active-passive 전환으로 해결
계정 단위 카스케이드 스케줄을 존(zone)별 독립 타임스탬프로 교체 + 30분마다 adaptive rate limiting
결과: 초당 120+ 스캔, 엔터프라이즈 일 1회/프로·비즈니스 3일 1회/무료 7일 1회 스캔 주기 정착

상세 정리

초기 문제 3가지: 주 1~2회 스캔으로 최대 2주 위협 탐지 지연, 무료 계정 자동 스캔 옵트인 제한, 백로그 누적·API 타임아웃·프로세스 크래시
Kafka 배치 소비: 파티션당 여러 메시지를 동시에 소비하고 각각 별도 고루틴으로 처리해 처리량 증대
slow/fast 레인: 컨슈머 그룹을 전용 레인으로 분리해 느린 메시지가 빠른 메시지를 블로킹하지 않도록 격리
DB 왕복 문제: 초기 구현에서 인사이트당 개별 DB 왕복 발생 — 요청당 최대 500,000번 호출 가능
UNNEST vs COPY 하이브리드: 소량 삽입은 UNNEST(밀리초급), 대량 삽입은 COPY(초급)로 임계값 기준 동적 전환
active-active 지연 분석: 포틀랜드 응답 10ms, 암스테르담은 대서양 횡단 왕복으로 약 3초 지연 + 커넥션 풀 고갈 확인
active-passive 전환: 모든 API 트래픽을 주 DB 위치로 라우팅해 크로스-리전 왕복 제거
스케줄러 개선: 계정 레벨 카스케이드에서 존별 독립 타임스탬프로 교체, 기존 타임스탬프를 무작위 재분배해 클러스터링 제거
adaptive rate limiting: 30분마다 현재 고객 수·목표 스캔 주기 기반으로 자동 재계산해 과부하 방지
최종 성과: 초당 120+ 스캔(목표였던 10x 초과 달성), 엔터프라이즈 일 1회·프로/비즈니스 3일 1회·무료 7일 1회 스캔 정착

왜 읽나Kafka와 PostgreSQL 기반 대규모 스캔 시스템의 처리량을 추가 하드웨어 없이 끌어올려야 하는 인프라·백엔드 엔지니어에게 구체적 최적화 기법 레퍼런스.

Cloudflare Blog 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

Kafka·PostgreSQL 최적화로 보안 스캔 처리량 12배 높이기

이 글과 비슷한

엔터프라이즈 보안 요구사항을 충족하는 프라이빗 Amazon Bedrock AgentCore 구축하기

OpenTofu와 Argo CD로 구성하는 GitLab 기반 AWS 제어 플레인

Amazon Bedrock 기반 사내 LLM, 키 발급부터 비용 차단까지: F&F의 LiteLLM 게이트웨이 운영 사례