소규모 스크래핑 작업은 작동하거나 작동하지 않으며, 이는 금방 알 수 있습니다. 대규모 작업은 결코 그런 이분법적인 상태에 있지 않습니다. 어느 순간에도 트래픽의 일부는 실패하고 있으며, 운영상 유용한 질문은 “프록시가 작동하는가”가 아니라 “이 중 어느 부분이 저하되었는가, 그리고 그것이 우리 자신인가, 프로바이더인가, 아니면 타겟인가”입니다.
유용한 답을 얻으려면 독립적으로 실패할 수 있는 차원을 따라 계측해야 하며, 이는 단순히 메트릭을 더 추가하는 것과는 다릅니다. 무엇을 측정해야 하는지, 대역폭을 낭비하지 않고 어떻게 프로브를 수행해야 하는지, 그리고 세 가지 실패 원인을 구별하는 방법을 살펴보겠습니다.
상태는 프록시 단위가 아니라 라우트 단위입니다
첫 번째로 정정할 점은 이것입니다: 풀링된 게이트웨이에서는 모니터링할 프록시가 존재하지 않습니다. 여러분은 출구 주소를 선택하지 않았고, 그것을 보관하지도 않으며, 한 번 실패한 주소는 시간이 지남에 따라 추적할 수 있는 개체가 아닙니다. 추적할 수 있는 것은 라우트이며, 이는 여러분이 제어하는 요소들의 조합, 즉 타겟, 국가, 그리고 관련이 있다면 도시나 ASN을 의미합니다.
따라서 상태의 단위는 라우트입니다. amazon-de, serp-us-chicago, marketplace-jp처럼요. 각각은 고유한 성공률, 레이턴시 프로파일, 실패 조합을 가지고 있으며, 다른 것들이 완벽하게 유지되는 동안 각각이 저하될 수 있습니다. 단일한 전역 “프록시 상태” 수치는 여러분이 필요한 신호를 정확히 평균으로 지워버립니다. 전체 95퍼센트는 20개 라우트가 99퍼센트이고 1개 라우트가 0퍼센트인 경우일 수 있으며, 두 번째 값만이 여러분에게 조치를 취하라고 알려줍니다.
세션 상태를 두 번째, 더 짧은 수명의 단위로 추가하세요. 챌린지를 유발하기 시작하는 고정 세션은 재사용되기보다는 폐기되고 교체되어야 하며, 이 결정은 프록시 매니저 구축에서 설명한 대로 세션을 배분하는 것과 동일한 컴포넌트에 속해야 합니다.
먼저 패시브 방식으로: 모든 실제 요청이 헬스 체크입니다
가장 저렴한 모니터링은 여러분이 이미 보내고 있는 트래픽입니다. 모든 프로덕션 요청은 결과를 만들어내며, 이를 라우트에 대해 기록하면 추가 대역폭 비용 없이 지속적인 상태 데이터를 얻을 수 있습니다.
여기서 핵심은 무엇을 성공으로 간주하느냐입니다. 200 상태 코드가 아닙니다. 챌린지 페이지, 일반적이거나 비어 있는 결과, 잘려진 목록, 또는 랜딩 페이지로의 리디렉션은 모두 200을 반환하지만 모두 여러분의 수집이 실패했음을 의미하므로, 상태 코드를 세는 모니터는 데이터셋이 저하되는 동안에도 상태가 양호하다고 보고할 것입니다. 결과를 기록하기 전에 타겟별 예상값에 대해 본문을 검증하세요. 이는 차단되거나 위조된 콘텐츠 탐지에서 다루는 원칙입니다. 이 단 하나의 변경이 문제를 포착하는 상태 대시보드와 여러분의 편향을 확인해주는 대시보드를 구분짓는 지점입니다.
최소한 요청당 다음을 기록하세요: 라우트, 검증된 결과, 레이턴시, 바이트, 실패한 경우 실패 클래스. 이 정도면 아래에서 다룰 모든 것을 계산하기에 충분합니다.
실패를 분류하세요, 클래스가 곧 진단이기 때문입니다
실패를 세는 것은 무언가 잘못되었다는 것을 알려줍니다. 실패를 분류하는 것은 무엇이 잘못되었는지를 알려줍니다. 다섯 가지 클래스가 거의 모든 것을 다루며, 각각은 서로 다른 곳을 가리킵니다.
인증 실패는 자격 증명이나 잘못된 형식의 타겟팅 플래그를 의미하며, 이는 여러분 쪽의 설정 문제이고 재시도로 해결되지 않습니다. 407 및 자격 증명 오류 해결을 참고하세요. 매치 없음 실패는 게이트웨이가 그 순간 여러분의 필터에 맞는 주소를 가지고 있지 않다는 뜻으로, 무언가 고장난 것이 아니라 타겟팅이 너무 좁다는 것을 의미합니다. 도시에서 국가로 범위를 넓히면 해결됩니다. 레이트 신호, 즉 429 및 그 유사한 것들은 해당 타겟에 대해 여러분의 페이싱이 너무 공격적이라는 뜻으로, 스로틀링 문제입니다. 차단 신호, 즉 챌린지와 지속적인 403은 타겟이 신원을 거부했다는 뜻이므로, 세션을 폐기하고 헤더나 핑거프린트가 실제 원인인지 고려해야 합니다. 트랜스포트 실패, 즉 타임아웃과 커넥션 리셋은 모호한 클래스이며 그 자체로 조사할 가치가 있습니다. 요청이 타임아웃되는 이유는 타겟의 느림, 상태가 불량한 라우트, 그리고 여러분 자신의 동시성이 너무 높은 경우를 포함하기 때문입니다.
총합보다 구성 비율이 더 중요합니다. 레이트 신호로 이루어진 성공률 80퍼센트의 라우트는 더 느린 페이싱이 필요합니다. 차단 신호로 이루어진 동일한 80퍼센트의 라우트는 다른 신원 전략이 필요합니다. 매치 없음 오류로 이루어진 경우에는 더 넓은 타겟팅이 필요합니다. 같은 숫자, 세 가지 다른 해법입니다.
아껴 쓰는 액티브 프로브
패시브 모니터링에는 한 가지 사각지대가 있습니다. 현재 사용 중인 라우트만 다룰 수 있다는 점입니다. 그래서 새벽 3시에 실행되도록 예정된 라우트는 밤 10시에는 이미 고장 났다는 경고를 주지 않습니다. 소수의 액티브 프로브가 이 공백을 채워주지만, 대역폭 비용이 들기 때문에 저렴하고 목적이 뚜렷하게 유지해야 합니다.
두 종류가 실행할 가치가 있습니다. 국가별 연결 및 지리 프로브는 주소와 위치를 에코하는 작은 엔드포인트를 호출하여, 게이트웨이가 도달 가능하고 요청한 국가가 실제로 받는 국가와 일치하는지 확인합니다. 이것이 가장 자주 실행하는 프로브이므로 가볍게 유지하세요. 중요한 타겟별 타겟 캐너리는 알려진 안정적인 페이지 하나를 가져와 검증함으로써, 그 특정 타겟이 정상적으로 응답하는지 알려줍니다. 이는 타겟 문제와 프록시 문제를 구별하는 체크입니다.
import requests
def geo_probe(country):
proxy = f"http://customer-USERNAME-country-{country}:PASSWORD@p.shifter.io:443"
try:
r = requests.get("https://ipinfo.io/json",
proxies={"http": proxy, "https": proxy}, timeout=15)
d = r.json()
return {"ok": d.get("country","").lower() == country,
"got": d.get("country"), "org": d.get("org")}
except Exception as e:
return {"ok": False, "error": type(e).__name__}여러분이 실제로 사용하는 국가들에 대해 느린 주기로 지리 프로브를 실행하고, 사일런트 실패가 얼마나 비용이 클지에 맞춘 주기로 캐너리를 실행하세요. 한 번이 아니라 반복적으로 실패하는 프로브에 대해 경고하세요. 로테이팅 풀에서의 단일 실패는 정상적인 노이즈이기 때문입니다.
세 가지 실패 원인 구별하기
이것이 인시던트 중에 실제로 제기되는 질문이며, 답은 단일 메트릭이 아니라 신호를 비교하는 데서 나옵니다.
여러분 쪽은 여러 관련 없는 타겟에서 동시에 실패로 나타나며, 보통 무언가 배포된 시점에 정확히 시작합니다. 모든 곳에서의 인증 실패, 한 워커 풀에서의 트랜스포트 오류 급증, 누군가 필터를 좁힌 후의 매치 없음 오류 증가는 모두 내부를 가리킵니다. 특징은 넓이입니다. 여러분 자신의 버그는 타겟 경계를 거의 존중하지 않습니다.
프로바이더는 여러 타겟에서 실패로 나타나지만 네트워크 계층에 국한됩니다. 연결 프로브 실패, 지리 프로브가 잘못된 국가를 반환, 트랜스포트 오류가 상승하는 동안에도 통과된 타겟 캐너리는 여전히 유효한 페이지를 반환합니다. 이곳이 또한 공개 상태 페이지가 그 역할을 하는 곳입니다. 여러분 자신의 저하를 프로바이더의 인시던트 히스토리와 대조하면 즉시 답이 나오기 때문입니다. 여러분이 받을 자격이 있는 것을 규정하는 계층 구조는 프록시 SLA 및 업타임 보장에 있습니다.
타겟은 다른 모든 라우트가 정상 상태를 유지하는 동안 한 타겟에만 국한된 실패로 나타나며, 그 타겟의 캐너리는 실패하는 반면 지리 프로브는 통과합니다. 모든 지역에서 동시에 실패한다면 그 사이트 자체가 문제를 겪고 있을 가능성이 높습니다. 한 지역에서만 실패한다면, 지역 특정적 차단이나 지역 엣지 문제를 보고 있는 것입니다.
이러한 비교가 오후 내내가 아니라 단 하나의 쿼리로 가능하도록 계측하세요. 라우트, 지역, 워커로 태그된 동일한 실패 클래스와 결과만으로 충분합니다.
무엇에 대해 경고할지
대시보드는 조사를 위한 것이고, 알림은 사람을 깨우기 위한 것입니다. 알림 세트를 작게 유지하고 각각을 실행 가능하게 만드세요.
전역 임계값이 아니라 자체 롤링 베이스라인 아래로 라우트의 검증된 성공률이 떨어질 때 경고하세요. 왜냐하면 적대적인 타겟에 대해 보통 70퍼센트로 실행되는 라우트는 70퍼센트에서 정상이고 40퍼센트에서 고장난 것이기 때문입니다. 실패 조합의 변화에 대해 경고하세요. 성공률을 유지하면서 레이트 신호가 차단 신호로 대체되는 라우트는 문제를 예고하는 방식으로 성격이 바뀐 것입니다. 재시도 비율 상승에 대해 경고하세요. 이는 성공률이 떨어지기 전에 상승하므로 가장 빠른 경고가 됩니다. 커버리지에 대해 경고하세요. 즉, 예정된 라우트가 자체의 최근 히스토리보다 실질적으로 적은 레코드를 생성하는 것은 성공률로는 볼 수 없는 사일런트한 축소를 포착합니다. 그리고 여러분이 의존하는 지역에 대해 프로브가 반복적으로 실패할 때 경고하세요.
단일 구간이 아니라 지속적인 편차를 요구하고, 롤링 베이스라인과 비교하세요. 이러한 것들 뒤에 있는 메트릭 정의는 프록시 KPI에 있으며, 파이프라인 수준의 계측은 웹 스크래핑 파이프라인 모니터링에 있습니다.
시스템이 그것에 따라 행동하도록 만드세요
그래프만 생성하는 모니터링은 기계가 처리해야 할 문제에 대해 사람을 루프 안에 남겨둡니다. 동일한 신호가 자동적인 행동을 이끌어야 합니다. 차단 신호를 누적하는 세션을 폐기하고, 성공률이 붕괴된 라우트에 대해 서킷 브레이커를 열어 응답하지 않는 타겟에 계속 요청을 보내지 않도록 하고, 한 지역이 저하될 때 멀티 리전 파이프라인의 페일오버에 따라 작업을 다른 지역으로 옮기고, 레이트 신호가 나타날 때 자동으로 백오프하세요. 사람은 판단이 필요한 것들에 대해 경고를 받아야 하며, 규칙이 필요한 것들에 대해서는 아닙니다.
결론
규모가 커지면 상태는 프록시의 속성이 아니라 여러분이 실행하는 각 라우트의 속성이므로, 타겟과 지역별로 계측하고 세션 상태는 자체의 짧은 수명 신호로 두세요. 상태 코드가 아니라 검증된 본문으로 모든 결과를 판단하세요. 이것이 모니터링과 자기 기만의 차이입니다. 실패를 분류하세요. 구성 비율이 여러분이 느려져야 하는지, 신원을 바꿔야 하는지, 타겟팅을 넓혀야 하는지, 아니면 여러분 자신의 설정을 고쳐야 하는지를 알려줍니다. 현재 실행 중이지 않은 라우트를 커버하고 프로바이더 문제와 타겟 문제를 구별하기 위해 지리 프로브와 타겟 캐너리로 이루어진 얇은 층을 추가하세요. 그런 다음 각 라우트 자체의 베이스라인으로부터의 지속적인 편차, 실패 조합의 변화, 재시도 비율에 대해 경고하고, 동일한 신호를 자동 폐기, 백오프, 페일오버에 연결해 누군가 깨어나기 전에 시스템이 스스로 고칠 수 있는 것을 고치도록 하세요.
그 아래에 있는 계층이 레지덴셜 프록시이며, 국가 및 도시 타겟팅과 세션 제어가 요청별로 표현됩니다. 이것이 라우트 수준의 상태를 통합 프로젝트가 아니라 여러분 자신의 요청에 태그를 붙이는 문제로 만들어주는 요소이며, GB당 가격 정책으로 인해 간소한 프로브 전략이 수집 자체에 비해 거의 비용이 들지 않습니다.