# 24시간 만에 10억 웹페이지를 크롤링한 2025년형 대규모 크롤러 구축기

> Clean Markdown view of GeekNews topic #22118. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=22118](https://news.hada.io/topic?id=22118)
- GeekNews Markdown: [https://news.hada.io/topic/22118.md](https://news.hada.io/topic/22118.md)
- Type: news
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-07-23T09:51:01+09:00
- Updated: 2025-07-23T09:51:01+09:00
- Original source: [andrewkchan.dev](https://andrewkchan.dev/posts/crawler.html)
- Points: 58
- Comments: 3

## Summary

최신 웹 트래픽 환경에서 **10억 웹페이지**를 단 하루 만에 수집하는 **대규모 크롤러 아키텍처** 구축 과정을 상세히 분석합니다. 수백 달러 예산으로도 **클라우드 리소스**와 **Redis 기반 노드 클러스터**를 적절히 활용하면, 병목을 야기하는 **파싱 작업**과 **CPU·SSL 처리**를 극복하며 최대 효율을 낼 수 있습니다. **도메인 샤딩, 노드 간 병렬 처리, HTML 파싱 최적화** 등 실제 실험 결과를 통해, 대용량 크롤링의 현실적 한계와 미래 과제로 **JS 렌더링** 기반 접근, 크롤러 방어 체계 변화 등을 제시합니다.

## Topic Body

- **10억 개의 웹페이지**를 **24시간** 만에 크롤링한 실제 경험과 **현대적인 웹 크롤링 시스템 설계** 과정 공유  
- 최신 하드웨어·클라우드 인프라로 **비용 수백 달러 수준**에서 대규모 크롤링 실현, 주요 병목이 **파싱**임을 확인  
- 자바스크립트를 실행하지 않고 **HTML 파싱**만 진행했지만, 여전히 상당수 웹페이지 접근 가능했음  
- **Redis** 기반 **노드 클러스터** 아키텍처 설계, **도메인별 샤딩** 및 프로세스 구조 최적화로 효율 극대화  
- **네트워크**보다 **CPU·SSL·메모리**가 주요 병목으로 드러났고, 대형 도메인 프론티어 관리가 핵심 이슈였음  
  
---  
  
### 문제 정의  
  
- 24시간 내에 **10억 웹페이지 크롤링**이라는 목표 설정  
- **예산**은 몇백 달러(최종 약 462달러)로, [2012년 사례](https://michaelnielsen.org/ddi/how-to-crawl-a-quarter-billion-webpages-in-40-hours/)와 비슷한 수준에 맞춤  
- **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억 페이지](https://www.hellointerview.com/learn/system-design/problem-breakdowns/web-crawler)" 추정과 비교, 실제 수치는 어느 정도 근접함  
- 각 노드의 실제 네트워크 및 CPU 활용률을 감안하면, 최적화 여하에 따라 더 높은 처리량도 가능함  
  
### 향후 과제와 생각  
  
- **HTML 파싱만으로도 상당수 웹페이지에 접근 가능**함을 재확인, 단 대형 플랫폼(예: GitHub 등)은 의미 있는 본문이 JS 내 포함되어 파싱 불가  
- 미래 과제로 **JS 렌더링 기반 대규모 크롤링** 비용·방식 탐구가 필요  
- 데이터 분석(실제 수집된 페이지의 메타 정보, 활성/비활성 비율 등)도 후속 주제로 언급  
- 최근에는 AI와 결합한 **[공격적 크롤링](https://news.ycombinator.com/item?id=23490367)** 이 늘어나고 있으며, Cloudflare의 **[pay-per-crawl](https://blog.cloudflare.com/introducing-pay-per-crawl/)** 등 신규 방어 체계가 등장하는 등 웹 크롤링 환경이 다시 변화 중임

## Comments



### Comment 41861

- Author: oninepa
- Created: 2025-07-28T04:13:17+09:00
- Points: 1

대단하심..짝짝짝...

### Comment 41725

- Author: tensun
- Created: 2025-07-23T14:43:44+09:00
- Points: 1

흥미롭네요. 잘 보고 갑니다 감사합니다

### Comment 41707

- Author: yangeok
- Created: 2025-07-23T10:04:59+09:00
- Points: 1

대단하네요.. 창과 방패의 싸움인가요 ㅎㅎ