24시간 만에 10억 페이지 크롤링, 최신 기술 분석

저자는 파싱(Parsing)이 주요 병목 지점임을 확인하고, 기존 lxml 라이브러리 대신 selectolax를 도입하여 성능을 개선했다. 특히, 평균 웹 페이지 크기가 2012년에 비해 크게 증가함에 따라, HTML5 파서(HTML5 Parser)인 Lexbor를 래핑(Wrapping)한 selectolax의 성능 향상이 두드러졌다. 또한, 페이지 콘텐츠를 250KB로 제한하여 파싱 속도를 더욱 향상시켰다. 이러한 최적화를 통해 단일 파서 프로세스(Parser Process)에서 초당 약 160페이지를 처리할 수 있었다.

페칭(Fetching) 단계에서는 SSL 핸드셰이크(SSL Handshake)가 CPU 사용량의 25%를 차지하며 병목 현상을 발생시켰다. 이는 2014년 30%였던 SSL 로드 비중이 2025년에는 80% 이상으로 증가한 데 따른 것이다. 저자는 네트워크 대역폭(Network Bandwidth)은 충분했지만, SSL 처리에 소요되는 CPU 자원 부족으로 인해 페칭 속도가 제한되었다고 분석했다. 이러한 CPU 부하를 줄이기 위한 추가적인 최적화가 필요함을 시사한다.

저자는 단일 노드(Single Node)에서 시작하여 수평적 확장(Horizontal Scaling)을 통해 12개의 i7i.4xlarge 노드 클러스터를 구축했다. 각 노드는 Redis 인스턴스, 9개의 페처 프로세스, 6개의 파서 프로세스로 구성되었다. 데이터 격리 아키텍처(Data Isolation Architecture)를 위해 각 노드는 자체적인 도메인 시드 리스트(Domain Seed List)를 처리했으며, 노드 간 통신은 최소화되었다. 이러한 설계를 통해 예산 제약 내에서 10억 페이지 크롤링을 달성했다.

저자는 S3와 같은 객체 스토리지를 사용하지 않고, 인스턴스 스토리지를 활용하여 비용을 절감했다. S3의 요청 기반 과금 및 GB-월(GB-month) 요금은 대규모 크롤링에 적합하지 않다고 판단했다. 10억 페이지를 하루 동안 저장하는 데 S3는 5,183달러가 소요되는 반면, 인스턴스 스토리지는 462달러로 비용 효율성을 확보했다. 이는 대규모 데이터 처리에서 비용 최적화(Cost Optimization)의 중요성을 보여준다.