10억 웹페이지 24시간 크롤링: 현대적 웹 크롤링 시스템 설계 경험 공유

핵심 기술: 본 콘텐츠는 현대적인 웹 크롤링 시스템을 설계하여 24시간 내 10억 개의 웹페이지를 크롤링한 실제 경험과 그 과정에서 얻은 핵심 인사이트를 공유합니다. 제한된 예산(수백 달러)으로 최신 인프라를 활용하여 대규모 크롤링을 실현하고, 파싱이 주요 병목임을 확인했으며, HTML 파싱만으로도 상당수 웹페이지 접근이 가능함을 입증합니다.

기술적 세부사항:

• 목표: 24시간 내 10억 웹페이지 크롤링, 예산 수백 달러 (최종 약 462달러).
• 크롤링 범위: HTML만 수집, 자바스크립트 미실행, <a> 링크만 추출.
• Politeness: robots.txt 준수, User Agent 포함, 요청 시 도메인 제외, 인기 상위 100만 도메인 대상, 70초 대기 등 적용.
• 내결함성: 노드 장애 시 재시작 및 일부 데이터 유실 감안, 샘플 기반 접근.
• 아키텍처: 각 노드가 모든 기능(크롤 상태, 파싱, 페치, 저장)을 자체 처리하는 구조. Redis 기반 노드 클러스터, 도메인별 샤딩, 프로세스 구조 최적화.
• 인프라: 12개 노드, 각 노드 i7i.4xlarge (16 vCPU, 128GB RAM, 10Gbps).
• 노드 구성: 1개의 Redis, 9개의 fetcher, 6개의 parser 프로세스.
• Redis 활용: 도메인별 프론티어, fetch queue, visited URL, Bloom filter, robots.txt, 파싱 큐 저장.
• Fetcher: asyncio 기반, 6000~7000 동시 작업, 주 병목 CPU.
• Parser: 80개 async 워커, HTML 파싱 및 링크 추출, CPU 중심 작업, selectolax 사용으로 속도 향상 (단일 parser 초당 160페이지).
• 스토리지: 인스턴스 로컬 스토리지 사용 (S3 대비 비용 절감).
• 샤딩: 도메인별 노드 분배, 크로스 커뮤니케이션 제거.
• 병목 분석: 네트워크 대역폭(8Gbps/노드 사용)보다 CPU, SSL, 메모리가 주요 병목. SSL 핸드셰이크가 CPU 사용의 25% 차지.
• 메모리 문제: 인기 도메인 프론티어 증가로 노드 다운 반복, 수동 제외 및 트렁케이션으로 복구.
• 성능 개선: lxml에서 selectolax로 변경, 페이지 최대 250KB 트렁케이션.
• 결과: fetcher:parser 비율 9:6 조정으로 약 950페이지/초 처리.

개발 임팩트: 이 경험은 제한된 예산으로도 최신 클라우드 인프라와 효율적인 아키텍처 설계를 통해 대규모 데이터 크롤링 목표를 달성할 수 있음을 보여줍니다. CPU, SSL, 메모리 병목 분석 및 selectolax와 같은 파싱 라이브러리 활용은 시스템 최적화에 대한 실질적인 가이드라인을 제공합니다. 또한, 자바스크립트 렌더링 없이도 상당한 데이터 수집이 가능함을 재확인하고, 향후 JS 렌더링 기반 크롤링의 필요성을 제기합니다.

커뮤니티 반응: (원본에 직접적인 커뮤니티 반응 언급 없음. 하지만 내용 자체는 개발자 커뮤니티에서 높은 관심을 받을 만한 주제임.)