클라우드 기반 웹 스크래핑 인프라에서 ISP 프록시 사용하기

대부분의 스크래핑 시스템이 도달하는 아키텍처는 클라우드 제공업체 내의 컨테이너로, 큐 깊이에 따라 확장되며, 상태를 갖지 않고 폐기 가능한 형태입니다. 이는 컴퓨팅에는 올바른 설계입니다. 하지만 이그레스(egress)에는 최악의 설계인데, 그 컨테이너들이 받는 주소가 방어 체계를 갖춘 사이트가 가장 먼저 확인하는 대상이기 때문입니다.

클라우드 제공업체의 IP 대역은 공개되어 있습니다. 누구나 이를 열거할 수 있고, 대부분의 안티봇 벤더들도 그렇게 합니다. 해당 대역에서 오는 트래픽은 그것이 무엇을 했는지 때문에 차단되는 것이 아니라, 첫 요청이 끝나기도 전에 어디서 왔는지에 따라 점수가 매겨집니다. 해결책은 워커를 더 늘리거나 헤더를 개선하는 것이 아닙니다. 코드가 실행되는 위치와 트래픽이 나가는 위치를 분리하는 것입니다.

이그레스 레이어는 별개의 관심사다

유용한 사고 모델은 워커는 컴퓨팅이고 주소는 아이덴티티이며, 이 둘은 독립적으로 확장되어야 한다는 것입니다.

일시적인 워커는 좋습니다: 50개를 시작하고, 큐를 끝내고, 멈춥니다. 하지만 일시적인 아이덴티티는 대개 나쁩니다: 새로운 클라우드 주소에서 도착하는 새 워커마다 낯선 트래픽의 흐름이 됩니다. 원하는 것은 워커 세대가 바뀌어도 지속되는 안정적인 출구 주소 집합입니다. 그래야 오토스케일러가 반응할 때마다 대상이 보는 아이덴티티가 바뀌지 않습니다.

ISP 프록시는 고정 레지덴셜 프록시라고도 불리며, 바로 이 역할에 적합합니다. 각 프록시는 결제 주기 전체 동안 선택한 도시와 ISP에 머무르며, 클라우드 블록이 아닌 실제 ISP에 등록되어 있고, IP가 갱신되더라도 동일한 도시와 ISP를 유지합니다. 워커는 오고 가지만, 프록시는 설정한 그대로 머무릅니다.

어디서나 작동하는 인증

각 프록시는 고유한 사용자 이름을 가지며, 모두 포트 443의 하나의 호스트 isp.shifter.io를 통해 연결되므로 워커에 고정된 아웃바운드 주소가 필요하지 않습니다:

isp.shifter.io:443:USERNAME:PASSWORD

워커가 변화하는 주소에 걸쳐 진정으로 일시적이거나, 여러 리전에 분산되어 있거나, 아웃바운드 주소를 제어할 수 없는 환경에서 실행될 때 이 방식이 필요합니다. 서버리스 함수와 멀티 리전 배포도 단일 서버와 동일한 방식으로 작동합니다.

워커 간 주소 분배

N개의 주소와 가변적인 수의 워커가 있으므로, 무언가가 하나를 다른 것에 할당해야 합니다.

효과적인 접근 방식은 주소 목록을 각 워커가 스스로 선택하게 하는 대신, 명시적인 리스(lease)를 갖는 공유 리소스로 취급하는 것입니다. 워커는 조정 레이어에서 주소를 가져와, 작업이 진행되는 동안 유지하고, 반환합니다. 두 가지 속성이 중요합니다: 두 워커가 동시에 하나의 주소를 사용하여 그 주소의 겉보기 요청률이 두 배가 되는 일이 없어야 하고, 워커의 크래시가 주소를 영구적으로 순환에서 제거하지 않아야 합니다.

워커 아이덴티티를 인덱스로 해싱하는 소박한 대안은 워커 수가 바뀌는 순간 깨지는데, 오토스케일 배포에서는 이것이 끊임없이 일어납니다. 스케일업 시 충돌이 발생하고 스케일다운 시 유휴 주소가 발생합니다.

여기서 실제 예산은 주소당 요청률입니다. ISP 플랜의 대역폭은 무제한이므로 제약은 기가바이트가 아니라, 하나의 프록시가 그럴듯하게 생성할 수 있는 트래픽의 양입니다. 이 수치가 배포에 필요한 주소 수를 결정하며, 데이터 볼륨이 아니라 처리량을 기준으로 사이즈를 산정하는 것이 올바른 방법인 이유입니다.

헬스 체크는 풀 안에 있어야 한다

주소는 균일하게 실패하지 않습니다. 하나가 특정 대상에서 챌린지를 받기 시작하는 동안 다른 모든 것은 괜찮을 수 있으며, 그 주소를 받은 워커는 누군가 알아차릴 때까지 쓸모없는 결과를 만들어냅니다.

집계된 값이 아니라 주소별로 결과를 추적하세요. 여러 대상에서 수집하는 경우 대상별로, 롤링 윈도우에 걸친 주소별 성공률을 보면 전체 풀을 빼지 않고 하나의 주소를 격리할 수 있습니다. 집계 지표는 5퍼센트 하락만 보여줄 뿐, 사실은 하나의 주소가 완전히 실패하고 있다는 사실을 숨깁니다.

격리는 임시적이고 자동적이어야 하며, 주소가 회복되면 이를 되돌리는 프로브가 있어야 합니다. 정상 상태가 무엇인지 처음에 확립하는 방법은 프록시 속도, 성공률, 위치 정확도 테스트하기에 있습니다.

구매 전에 지리적 분포를 계획하라

클라우드 팀에 도움이 되는 한 가지 세부 사항: Shifter ISP 프록시에서는 구매 후 각 프록시의 도시와 ISP를 120개국에 걸쳐 선택할 수 있습니다.

그런 다음 각 프록시는 결제 주기 동안 그 도시와 ISP에 머무르므로, 배포할 때마다 바꾸기보다는 실제로 수집하는 대상을 기준으로 분배를 결정하세요.

ISP가 잘못된 도구인 경우

고정 레지덴셜 프록시는 로테이션의 일반적인 대체물이 아니며, 클라우드 인프라는 운영 모델이 훨씬 단순하기 때문에 그렇지 않은 것처럼 착각하게 만들기 쉽습니다.

워크로드가 많은 대상에 걸친 고볼륨 수집이라면, 주소당 요청률이 비용보다 훨씬 먼저 비현실적이 되고, 그 증상은 오류가 아니라 저하된 데이터로 나타납니다. 그 작업은 각 요청이 설계상 다른 주소에서 올 수 있는 로테이팅 레지덴셜 프록시에 속합니다. 그 트레이드오프는 ISP 프록시 대 데이터센터 및 레지덴셜에 설명되어 있습니다.

안정적인 이그레스 레이어가 진정으로 옳은 워크로드는: 장기간 지속되는 세션, 인증이 필요한 모든 것, 그리고 볼륨보다 일관성이 더 중요한 안정적인 수집입니다. 혼합 아키텍처는 흔하고 올바른 방식으로, 지속적인 작업에는 ISP 주소를, 대량 작업에는 로테이팅 게이트웨이를 사용합니다.

운영 노트

주소 목록은 이미지가 아니라 설정에 두세요. 풀을 변경하기 위해 컨테이너를 재구성하는 것은 피할 수 있는 일입니다. 시크릿 스토어나 설정 서비스에서 시작 시점에 읽어 오세요.

자격 증명이 포함된 URL을 로그에 남기지 마세요. 프록시 자격 증명이 로그 수집기로 흘러가는 가장 흔한 방식인데, 자연스러운 디버그 로그 라인이 전체 연결 문자열이기 때문입니다.

전역뿐 아니라 주소별로도 동시성을 제한하세요. 작은 풀에 불균등하게 분산된 전역 제한은 할당 로직이 선호하는 주소에 부하를 집중시킵니다. 관련된 메커니즘은 속도 제한 및 요청 스로틀링에 있습니다.

배포 환경 내부에서 테스트하세요. 노트북에서의 연결 확인은 자격 증명이 작동한다는 것만 증명합니다. 작업 정의가 환경 변수를 실제로 전달하는지에 대해서는 아무것도 증명하지 못하며, 대부분의 경우 실제 실패 원인은 바로 이것입니다.

FAQ

결론

클라우드 스크래핑 인프라가 차단되는 이유는 코드의 품질과는 아무 관련이 없습니다: 주소가 클라우드 주소로 공개되어 있다는 것이 이유입니다. 일시적인 워커 앞에 안정적인 ISP 이그레스 레이어를 두는 것은 아이덴티티를 컴퓨팅에서 분리하는 것이며, 이는 아키텍처가 원래부터 필요로 했던 분리입니다.

주소를 명시적으로 리스하고, 주소별로 상태를 추적하고, 대역폭이 아니라 요청률을 기준으로 사이즈를 산정하고, 지리적 분포는 실제로 수집 대상이 되는 타겟을 기준으로 의도적으로 결정하세요. 플랜은 ISP 프록시 가격 페이지에 있습니다.