-
10억 개의 웹페이지를 24시간 만에 크롤링한 실제 경험과 현대적인 웹 크롤링 시스템 설계 과정 공유
- 최신 하드웨어·클라우드 인프라로 비용 수백 달러 수준에서 대규모 크롤링 실현, 주요 병목이 파싱임을 확인
- 자바스크립트를 실행하지 않고 HTML 파싱만 진행했지만, 여전히 상당수 웹페이지 접근 가능했음
-
Redis 기반 노드 클러스터 아키텍처 설계, 도메인별 샤딩 및 프로세스 구조 최적화로 효율 극대화
-
네트워크보다 CPU·SSL·메모리가 주요 병목으로 드러났고, 대형 도메인 프론티어 관리가 핵심 이슈였음
문제 정의
- 24시간 내에 10억 웹페이지 크롤링이라는 목표 설정
-
예산은 몇백 달러(최종 약 462달러)로, 2012년 사례와 비슷한 수준에 맞춤
-
HTML만 수집하며, 자바스크립트는 실행하지 않고
<a> 링크만 추출
-
Politeness(매너 크롤링) 중시: robots.txt 준수, User Agent 정보 포함, 요청시 도메인 제외, 인기 상위 100만 도메인만 대상, 같은 도메인에 70초 대기 등 적용
-
내결함성 확보: 노드 장애 시 재시작 및 일부 데이터 유실을 감안, 샘플 기반 접근
아키텍처 및 설계
-
기존 시스템 설계 인터뷰 스타일(기능별 분산) 과 달리, 각 노드가 모든 기능(크롤 상태, 파싱, 페치, 저장 등) 자체적으로 처리하는 구조 선택
- 12개 노드, 각 노드는
i7i.4xlarge(16 vCPU, 128GB RAM, 10Gbps, 3750GB 스토리지) 인스턴스 사용
- 각 노드는 1개의 Redis, 9개 fetcher, 6개 parser 프로세스로 구성
-
Redis에는 도메인별 프론티어, fetch queue, visited URL, Bloom filter, robots.txt, 파싱 큐 등 저장
-
Fetcher: 도메인별로 큐에서 꺼내서 URL을 fetch, asyncio로 6000~7000 동시 작업, 주 병목은 CPU
-
Parser: 80개 async 워커, HTML 파싱 및 링크 추출, CPU 중심 작업
-
스토리지: S3 대신 인스턴스 로컬 스토리지 선택, 대용량 페이지 저장 비용 절감
-
샤딩: 도메인별로 노드에 분배(크로스 커뮤니케이션 없음), 인기 도메인 불균형 문제 해결 위해 샤딩 노드 수 조정
주요 대안 및 실험
-
SQLite, PostgreSQL 등 다양한 저장소 실험, 최종적으로 Redis가 성능 우수
- 수직적 확장(단일 대형 인스턴스)도 시도했으나 소프트웨어 한계로 병목 발생, 결국 수평 확장(여러 노드) 구조로 결정
- 각 노드 간 크로스 커뮤니케이션 제거, 단일 노드 내에서 병렬 처리
크롤링 과정에서의 주요 교훈
파싱이 가장 큰 병목
- 평균 페이지 크기가 과거(2012년 51KB)보다 훨씬 커짐(평균 242KB, 중앙값 138KB)
-
lxml 대신 selectolax(Lexbor 기반) 로 변경 시 파싱 속도 대폭 향상
- 페이지 최대 크기 250KB로 트렁케이션하여 효율 개선
- 결과적으로, 단일 parser에서 초당 160페이지 파싱 달성, 최종적으로 fetcher:parser 비율을 9:6으로 조정해 약 950페이지/초 처리
Fetching: 쉬워진 점과 어려워진 점
-
네트워크 대역폭은 오히려 병목이 아님(노드당 25Gbps 중 8Gbps 정도만 사용)
-
DNS 병목도 인기 도메인만 대상으로 하여 문제되지 않음
- 반면, SSL 핸드셰이크가 전체 CPU 사용의 25%로 최대 병목 중 하나로 등장
- 대부분의 페이지가 HTTPS로 전환됨에 따라, CPU 비용이 증가함
실전 크롤 실행 및 문제
- 초기 실험에서는 단일 노드(
i7i.2xlarge)로 수 시간만 진행하다가, 본 크롤은 12노드로 확장
-
메모리 문제 발생: 인기 도메인의 프론티어(미방문 URL)가 수십 GB까지 증가해, 노드가 다운되는 현상 반복
- 인기 도메인(예: yahoo.com, wikipedia.org) 또는 비정상적으로 링크가 많은 사이트들이 문제를 일으킴
- 문제 도메인은 수동 제외, 장애 발생 시 노드 재시작 및 프론티어 트렁케이션으로 복구
이론과 실전 비교
- 기존 교과서적인 방법인 "5대 머신으로 5일에 100억 페이지" 추정과 비교, 실제 수치는 어느 정도 근접함
- 각 노드의 실제 네트워크 및 CPU 활용률을 감안하면, 최적화 여하에 따라 더 높은 처리량도 가능함
향후 과제와 생각
-
HTML 파싱만으로도 상당수 웹페이지에 접근 가능함을 재확인, 단 대형 플랫폼(예: GitHub 등)은 의미 있는 본문이 JS 내 포함되어 파싱 불가
- 미래 과제로 JS 렌더링 기반 대규모 크롤링 비용·방식 탐구가 필요
- 데이터 분석(실제 수집된 페이지의 메타 정보, 활성/비활성 비율 등)도 후속 주제로 언급
- 최근에는 AI와 결합한 공격적 크롤링 이 늘어나고 있으며, Cloudflare의 pay-per-crawl 등 신규 방어 체계가 등장하는 등 웹 크롤링 환경이 다시 변화 중임