웹 스크래핑에 어떤 VPS 사양이 필요한가요?

스택에 달렸습니다. 평범한 HTTP 스크레이퍼(API나 정적 HTML을 치는 httpx/requests)는 가볍습니다 — 1 GB의 $3 Nano면 충분. JavaScript가 많은 사이트에 실제 브라우저가 필요한 순간, 헤드리스 Chromium의 Playwright는 2~4 GB를 원합니다: 한둘의 브라우저 컨텍스트에는 $5 Micro, 여럿을 병렬로 돌리면 $8 Small. RAM을 먹는 것은 Chromium이지 당신의 코드가 아닙니다.

서버 자체의 IP에서 스크래핑할 수 있나요, 아니면 프록시가 필요한가요?

허용하는 사이트의 저용량, 예의 바른 스크래핑에는 서버 IP면 됩니다. 대규모, 또는 IP로 레이트 리밋하는 사이트에 대해서는 외부 프록시 풀이 필요합니다 — 하나의 IP(공유든 전용이든)는 부하를 분산할 수 없고, 단일 주소에서 두드리면 빠르게 차단됩니다. 전용 IP는 당신이 통제하는 깨끗한 평판을 주고; 프록시는 많은 것을 줍니다.

예약 스크레이프에 cron이냐 systemd 타이머냐?

거의 모든 경우 systemd 타이머. cron과 달리 journalctl을 통한 제대로 된 로깅, 의존 순서, 박스가 내려가 있었을 때 자동 캐치업, 검사할 수 있는 실행별 상태를 줍니다. cron도 아주 단순한 작업에는 되지만, 실제로 유지하는 서버에서는 타이머가 더 나은 기본값입니다.

VPS에서 웹 스크래핑이 허용되나요?

합법적이고 존중하는 스크래핑 — 네. 레이트 리밋이나 robots.txt를 무시하거나, 대상을 서비스 거부로 두드리는 것에 해당하는 공격적 스크래핑은 이용 정책 위반이고 서비스가 종료됩니다. 허용된 것을 스크랩하고, 스스로를 조절하고, 스크레이퍼를 공격으로 바꾸지 마세요.

웹 스크래핑용 VPS: 설정, 사이징, 솔직한 한계

노트북의 스크레이퍼는 실행 중에 닫거나, 가정 IP가 레이트 리밋되거나, 깨어 있든 아니든 같은 작업을 매시간 돌리고 싶어지기 전까지는 괜찮습니다. 그것을 VPS로 옮기면 셋 다 고쳐집니다: 24시간 내내 떠 있고, 가정 IP의 평판을 태우지 않고, cron이나 systemd 타이머가 당신 없이 스케줄대로 돌립니다. 여기 그 설정법, 실제로 서버가 얼마나 필요한지, 그리고 대부분의 가이드가 조용히 건너뛰는 부분을.

왜 이것에 VPS가 당신의 기기를 이기는가

24시간 내내 그리고 예약. 매시간 도는 스크레이퍼에는 항상 켜진 호스트가 필요합니다. 노트북은 아닙니다.
가정 IP가 깨끗이 유지됩니다. 집에서 스크래핑하면 레이트 리밋과 차단을 주거용 IP가 받습니다. 서버에서 하면 자신의 연결은 무사합니다.
안정성. 슬립 없음, 크롤 도중 wifi 끊김 없음, 안정적인 데이터센터 연결, 그리고 결과를 쌓을 곳.

스택과, 각 부분이 필요로 하는 것

아주 다른 두 체급이고, 잘못된 요금제를 고르면 돈을 낭비하거나 작업을 굶깁니다:

httpx / requests(Python) — API, JSON 엔드포인트, 정적 HTML에. 이것은 가볍습니다: 프로세스가 수십 메가바이트에 앉고, 네트워크 바운드이지 CPU 바운드가 아닙니다. **$3 Nano(2 vCPU / 1 GB)**가 편안히 돌립니다, asyncio를 통한 동시성도.
Playwright / 헤드리스 Chromium — 실제 브라우저가 필요한 JavaScript 렌더링 사이트에. 이것이 무거운 쪽. 헤드리스 Chromium은 대략 브라우저 인스턴스당 300~400 MB, 더해 열린 컨텍스트/탭당 100~200 MB, 더해 당신의 런타임. 예산:
- $5 Micro(2 vCPU / 2 GB) — 한 번에 한둘의 브라우저 컨텍스트.
- $8 Small(4 vCPU / 4 GB) — 여러 병렬 컨텍스트, 또는 무거운 페이지.

경험칙: 당신의 코드는 거의 결코 병목이 아닙니다 — Chromium이 그렇습니다. 스크레이퍼가 아니라 브라우저에 맞춰 크기를.

스케줄링: cron보다 systemd 타이머

cron도 되지만, 유지하는 서버에서는 systemd 타이머가 더 나은 기본값: journalctl을 통한 로그, 박스가 내려가 있었을 때 캐치업, 검사할 수 있는 실행별 상태. 최소한의 설정:

# /etc/systemd/system/scrape.service
[Unit]
Description=Run scraper
[Service]
Type=oneshot
User=scraper
WorkingDirectory=/home/scraper/job
ExecStart=/home/scraper/job/venv/bin/python scrape.py

# /etc/systemd/system/scrape.timer
[Unit]
Description=Hourly scrape
[Timer]
OnCalendar=hourly
Persistent=true
[Install]
WantedBy=timers.target

sudo systemctl enable --now scrape.timer
journalctl -u scrape.service -f   # 실행 보기

Persistent=true가 cron이 못 하는 부분: 서버가 실행 시각에 꺼져 있었다면, 조용히 건너뛰는 대신 부팅 시 한 번 발화합니다.

결과는 어디로

단순하게, 양에 맞추세요: 쿼리할 구조화 데이터에는 SQLite(한 파일, 설정 제로), 빠른 표 형식 덤프에는 CSV, 결과가 박스를 넘거나 서버 밖에 두고 싶을 때는 S3 호환 오브젝트 스토어. 로그를 돌려(logrotate나 journald 제한) 수다스러운 스크레이퍼가 서서히 디스크를 채우지 않게.

솔직한 부분: 송출 IP와 평판

이것이 스크레이퍼가 일주일 도는지 첫날에 차단되는지를 결정하는 세부입니다.

NAT 요금제에서 아웃바운드 트래픽은 하나의 송출 IP를 다른 고객들과 공유합니다. 그 IP의 평판은 공유됩니다 — 같은 대상을 스크래핑하는 이웃이 당신이 요청 하나 보내기 전에 주소를 레이트 리밋되게 할 수 있습니다. 가볍고 이따금의 스크래핑에는 괜찮음; 양에서는 부담.

전용 IP는 당신 자신의 송출 평판을 주고 — 남의 행동이 그것에 영향을 주지 않습니다. 하지만 양날: 공격적 스크래핑은 당신 자신의 깨끗한 IP를 태우고, 대상이 한 번 차단하면 차단된 채입니다. 전용 IP는 통제이지 면역이 아닙니다.

진짜 규모에는 외부 프록시 풀이 필요합니다. 하나의 IP — 공유든 전용이든 — 는 부하를 여러 주소에 분산할 수 없고, 그것이 IP 레이트 리밋 대상에 대한 본격적 스크래핑이 요구하는 것입니다. 프록시는 위에 더하는 범용의 제3자 층; VPS가 스크레이퍼를 돌리고, 프록시 풀이 주소를 제공합니다. 하나의 서버 IP에 프록시 풀의 일을 기대하지 마세요.

윤리와 AUP — 선택이 아님

스크래핑은 법적·윤리적 회색 지대에 살므로 또렷하게:

레이트 리밋과 robots.txt를 존중. 요청을 조절하세요. 예의 바른 스크레이퍼는 트래픽처럼 보이고; 무례한 것은 공격처럼 보입니다.
대상을 DoS하지 않기. 사이트가 쓰러질 때까지 두드리는 것은 스크래핑이 아니라 서비스 거부 — 그리고 여기서는 이용 정책 위반으로 서비스가 종료됩니다.
허용된 것만 스크랩. 합법적이고 허가된 데이터 수집이 경계선. 넘으면 당신 책임.

결론

VPS는 스크레이퍼의 알맞은 보금자리: 상시 가동, 예약, 가정 IP에서 떨어져. 요금제를 스택에 맞추고 — httpx에는 $3 Nano, Playwright에는 $5 Micro에서 $8 Small — systemd 타이머로 예약하고, IP에 솔직하게: 공유 송출은 평판을 공유하고, 전용 IP는 당신이 쌓거나 태우는 것, 진짜 규모는 프록시 풀을 뜻합니다. 먼저 새 VPS 보안 체크리스트로 박스를 잠그고, VPS 사이징 가이드로 제대로 크기를 잡고, 카드 없는 결제 프라이버시가 중요하면 익명 VPS 분석이 솔직한 버전입니다. 책임감 있게 스크랩하세요 — AUP는 진짜입니다.

스크랩할 준비가 됐나요? Micro 요금제가 든든한 출발; 큰 동시 크롤은 Small에서 더 잘됩니다.