클라우드플레어가 보안 스캔 인프라 확장에 성공했다. 처리 능력을 초당 10개에서 100개로 10배 증대하고, 동시에 스캔 빈도를 주 1~2회에서 매일로 2배 증가시켰다. 특히 무료 요금제 사용자도 자동 스캔 대상에 포함되도록 확대했다.

보안 인사이트(Security Insights) 서비스는 모든 클라우드플레어 계정과 존(DNS 레코드)을 정기적으로 점검해 설정 오류와 취약점을 찾아낸다. 그러나 두 가지 문제가 있었다. 첫째, 스캔이 너무 드물었다. 주 1~2회만 진행되어 신규 보안 위협은 최대 2주간 미탐지 상태로 방치됐다. 둘째, 무료 계정의 자동 스캔은 선택사항이었다. 즉 수백만 개 계정이 아예 스캔되지 않았다.

이는 심각한 문제다. 자동화된 공격이 가속화될수록 보안 오류를 탐지할 시간 창이 줄어든다. 클라우드플레어는 "모든 고객의 보안을 책임진다"는 사명을 달성하려면 체계적인 인프라 개선이 필수였다.

10배 증설의 기술적 해답

메시지 큐 병렬화

스캔 작업은 아파치 카프카(Apache Kafka)라는 분산 메시지 스트리밍 플랫폼에 전달된다. 기존에는 카프카의 각 파티션마다 메시지를 순서대로 처리해야 했는데, 이는 특정 메시지가 오래 걸리면 뒤의 모든 메시지가 대기하는 "선두 행 차단(head-of-line blocking)" 문제를 야기했다.

클라우드플레어는 단순하면서도 효과적인 해법을 도입했다. 여러 메시지를 배치로 수신한 후 각각을 별도의 고루틴(goroutine)에서 병렬 처리하는 방식이다. 이를 통해 카프카 파티션을 추가하지 않고도 처리량을 크게 늘릴 수 있었다.

느린 메시지를 위한 별도 레인

그런데 또 다른 병목이 있었다. 일부 고객의 자산(도메인 수, 규칙 수)이 지나치게 많으면 스캔 시간이 수초에서 수분, 심지어 수시간까지 걸렸다. 이런 "느린" 메시지들이 "빠른" 메시지들을 막고 있었다.

해결책은 느린 것과 빠른 것을 분리하는 것이었다. 메시지 크기를 빠르게 판별하는 로직을 추가한 후, 빠른 레인에 도달한 느린 메시지는 자동으로 느린 레인으로 우회시킨다. 결과적으로 느린 메시지는 충분한 시간과 리소스를 확보하고, 빠른 메시지는 지연 없이 처리된다.

데이터베이스 쿼리 최적화

스캔 결과는 포스트그레스SQL(PostgreSQL) 데이터베이스에 저장된다. 기존 코드는 보안 이슈마다 한 건씩 INSERT 문을 실행했다. 최악의 경우 한 번의 API 호출에서 50만 건의 이슈를 개별 처리했으니, 50만 번의 왕복 지연이 누적됐다.

초기에는 포스트그레스의 벤치마크 기법인 COPY 명령어를 시도했지만 시스템 테이블 팽창 문제가 발생했다. 결국 하이브리드 접근법을 선택했다: 이슈 수가 임계값 이하면 UNNEST로 빠르게 삽입(밀리초), 초과하면 COPY로 대량 처리(초 단위)한다. 이 조합이 전체 성능을 최적화했다.

지리적 분산 API의 레이턴시 해결

의외의 병목도 발견됐다. 클라우드플레어의 API는 포틀랜드(미국)와 암스테르담(네덜란드)에서 이중 운영되는데, 두 지역 간 왕복 지연이 50밀리초에 달했다. 결과 암스테르담 API 인스턴스의 응답 시간은 10밀리초 대신 거의 3초가 돼버렸다.

더 심한 건, 클라이언트 연결 풀이 암스테르담 인스턴스로부터의 응답을 기다리며 모두 점유돼 타임아웃이 발생했다. 대규모 스캔을 트리거할 때 처리량이 시간이 지날수록 떨어지는 이유도 여기에 있었다. 해결은 지역별 API 인스턴스에 대한 로드 밸런싱 로직을 정교화하는 방식으로 진행됐다.

보안 검사의 진화

이번 개선은 단순한 성능 향상이 아니라 보안 서비스의 근본적인 강화다. 스캔 빈도가 2배로 줄어들면 새로운 위협 탐지 시간도 절반으로 단축된다. 특히 무료 사용자까지 자동 스캔 대상에 포함되면서 클라우드플레어는 더 많은 중소 기업과 개발팀의 보안 리스크를 조기에 포착할 수 있게 됐다.

분산 시스템의 확장성은 끝이 없는 과제다. 클라우드플레어는 이번 개선으로 단기 목표를 달성했지만, 사용자 증가와 스캔 규모의 증대가 계속되면 다음 병목은 또 다른 곳에서 나타날 것이다. 다만 이번 경험은 대규모 SaaS 서비스가 마주치는 아키텍처 과제를 풀어내는 방식을 보여준다.