이것은 첫 레지덴셜 프록시 프로젝트를 위한 사전 점검 목록이다. 확인해야 할 사항들을 각각 고치기 쉬운 순서로 정리했다. 프록시가 대략 무엇인지 알고 있다는 것을 전제로 하며, 만약 모른다면 초보자를 위한 레지덴셜 프록시부터 시작한 다음 돌아오면 된다.
이 순서대로 진행하면 보통 첫 프로젝트에서 몇 주를 낭비하게 만드는 실패들을 피할 수 있다. 잘못된 작업량에 맞춰진 플랜, 작동하는 것처럼 보이지만 아무것도 수집하지 못하는 작업, 그리고 아무도 예상하지 못한 청구서가 그것이다.
코드를 작성하기 전에
1. 정말로 레지덴셜이 필요한지 확인한다. 대상이 트래픽을 정밀하게 검사하지 않는다면 더 저렴한 인프라로도 같은 작업을 할 수 있다. 먼저 일반 연결과 데이터센터 주소로 대상 하나를 테스트해보라. 둘 다 작동한다면 프리미엄 비용을 절약한 것이다. 비교는 레지덴셜과 데이터센터 비교에 있다.
2. 로테이팅인지 고정인지 결정한다. 대량 수집에는 로테이팅을, 계정이나 장기 세션처럼 지속되어야 하는 작업에는 고정 ISP 주소를 사용한다. 이 결정을 잘못하면 잘못된 것을 더 사서 해결할 수 없다. 공유 프록시와 전용 프록시 비교를 참고하라.
3. 대상 시장을 나열한다. 어느 국가들이고, 도시 단위 정밀도가 필요한 작업이 있는지 확인한다. 이는 타겟팅뿐 아니라 해당 시장에서 풀 깊이를 확인해야 하는지도 결정한다. 국가별 가용성을 참고하라.
4. 플랜을 선택하기 전에 대역폭을 추정한다. 응답 크기 곱하기 요청 수, 여기에 재시도를 위한 여유분을 더한다. 가장 큰 요인은 데이터 엔드포인트를 가져오는지 아니면 전체 페이지를 렌더링하는지 여부이며, 이는 백 배까지 차이가 날 수 있으므로 먼저 이를 정해야 한다. 월간 대역폭 추정을 참고하라.
첫 연결
5. 기본 요청이 작동하도록 한다. 타겟팅 플래그도, 세션도, 아무런 특별한 것도 없이:
curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json이것이 실패하면 다른 것은 아직 중요하지 않다. 407은 자격 증명 문제나 잘못된 형식의 사용자 이름을 의미한다. 모든 것을 제거하고 한 번에 하나씩 다시 추가하라. 407 오류 해결을 참고하라.
6. 로테이션을 확인한다. 이 명령을 여러 번 실행하고 주소가 바뀌는지 확인한다. 바뀌지 않는다면, 특히 커맨드라인에서는 바뀌지만 코드에서는 바뀌지 않는다면 그 원인은 거의 확실히 프록시가 아니라 HTTP 클라이언트의 연결 재사용에 있다. IP가 로테이션되지 않는 문제를 참고하라.
7. 지리적 위치를 확인한다. 국가를 요청하고 두 가지를 확인한다. 하나는 출구 주소가 해당 국가를 보고하는지, 더 중요하게는 지리에 민감한 대상이 실제로 당신이 그곳에 있는 것처럼 현지 통화와 언어로 반응하는지 여부다. 데이터베이스와 대상 자체의 판단이 항상 일치하지는 않으며, 중요한 것은 대상의 판단이다.
8. 프록시 항목을 둘 다 설정하고 특수 문자를 처리한다. 코드에서는 하나가 아니라 HTTP와 HTTPS 항목을 모두 설정하고, URL에서 의미를 갖는 문자가 포함된 비밀번호는 퍼센트 인코딩한다. 형식에 대한 참고는 연결 방법에 있다.
규모를 확장하기 전에
9. 요청을 출구에 맞춘다. 단순한 User-Agent 대신 전체 브라우저 형태의 헤더 세트를 보내고, Accept-Language를 출구 국가와 연결해 둘이 서로 모순되지 않도록 한다. 브라우저를 구동한다면 로케일과 시간대도 일치시켜야 한다. 자세한 내용은 올바른 헤더 설정에 있다.
10. 상태 코드가 아니라 응답 본문을 검증한다. 이것이 작동하는 파이프라인과 조용히 아무것도 수집하지 못하는 파이프라인을 가르는 검사다. 대상별로 진짜 정상 페이지에서만 나타나는 마커를 정의하고, 그것을 통과할 때만 응답을 성공으로 계산한다. 챌린지 페이지가 200을 반환하는 것이 이 작업에서 가장 비용이 큰 실패다. 차단되거나 가짜인 콘텐츠 탐지를 참고하라.
11. 규모를 키우기 전에 페이싱과 합리적인 재시도를 추가한다. 지터를 포함한 대상별 속도 제한, 동시성 상한, 그리고 단순히 반복하는 것이 아니라 실패를 분류하는 재시도 로직이 필요하다. 구체적으로는 동일한 속도를 유지하려면 주소를 로테이션하기보다 속도 신호를 기다려야 하며, 종료성 오류는 절대 재시도하지 않는다. 속도 제한과 스로틀링과 재시도 로직을 참고하라.
12. 비용 안전장치를 마련한다. 요청당 바이트 수를 추적하고 플랜 할당량에 도달하기 훨씬 전에 경고를 설정한다. 흔한 첫 프로젝트의 놀라움은 렌더링 작업이 3일 만에 한 달치 대역폭을 소비하는 것이기 때문이다. 방법은 대역폭 비용 절감에 있다.
5분 검증
무엇이든 무인 상태로 실행하기 전에, 짧은 실행 한 번으로 다음을 모두 확인한다:
- 출구 주소가 자신의 것이 아니다
- 세션을 요청하지 않았을 때 요청 사이에 주소가 바뀐다
- 국가가 요청한 것과 일치하고, 대상도 그렇게 인식한다
- 의도적으로 잘못된 요청이 성공으로 계산되지 않고 실패로 분류된다
- 요청당 바이트 수가 대략 추정한 값과 같다
- 속도 제한 응답이 즉시 재시도가 아니라 대기를 유발한다
이 중 하나라도 잘못되었다면 지금 고쳐야 한다. 한 달치 데이터가 그 위에 쌓이고 나면 각각을 고치는 비용이 훨씬 커진다.
흔한 첫 프로젝트 실수
대부분의 문제를 일으키는 네 가지다.
처음부터 전속력으로 진행하는 것. 새 파이프라인은 보통 코드가 허용하는 최대 속도로 실행되도록 작성되는데, 이는 차단당하는 가장 빠른 길이다. 천천히 시작해서 의도적으로 속도를 높여야 한다.
상태 코드를 신뢰하는 것. 위에서 다뤘지만 반복할 가치가 있다. 사람들이 가장 자주 건너뛰는 것이면서 데이터셋을 조용히 오염시키는 것이기 때문이다.
렌더링이 필요하지 않은 페이지를 렌더링하는 것. 브라우저를 자동화하기 전에 데이터가 하위 엔드포인트에서 이용 가능한지 확인하라. 헤드리스 브라우저가 필요한 경우를 참고하라.
고정 세션을 보장된 것으로 취급하는 것. 세션은 실제 가정용 연결에서 최선의 노력 방식으로 작동하므로, 흐름은 시퀀스 도중에 주소가 바뀌는 것을 견뎌야 한다. 고정 프록시와 로테이팅 프록시 비교를 참고하라.
결론
레지덴셜이 정말로 필요한지 확인하고, 로테이팅인지 고정인지 신중하게 선택하고, 대상 시장을 나열하고, 플랜을 선택하기 전에 대역폭을 산정하라. 그런 다음 아무것도 추가하기 전에 기본 요청이 작동하도록 만들고, 로테이션과 지리적 위치를 확인하고, 코드에서 두 프록시 항목을 모두 설정하라. 규모를 확장하기 전에는 헤더가 출구와 일치하도록 만들고, 상태 코드가 아니라 응답 본문을 검증하고, 페이싱과 분류된 재시도를 추가하고, 비용 경고를 마련하라. 무엇이든 무인 상태로 두기 전에 5분 검증을 실행하라. 비용이 큰 첫 프로젝트 실패는 거의 모두 이런 단계 중 하나를 건너뛴 결과이며, 각각은 나중에 개선하는 것보다 지금 하는 것이 더 저렴하다.
이 단계들이 구성하는 제품은 레지덴셜 프록시로, 국가 및 도시 타겟팅과 필요할 때 사용할 수 있는 고정 세션을 갖춘 하나의 게이트웨이이며, GB당 과금되므로 작은 첫 프로젝트는 작은 첫 청구서로 유지된다.