주요 변경 사항
이전에는 조직이 한 명의 사용자만 담을 수 있는 행에 불과했습니다. 이제는 직접 관리할 수 있는 페이지로 개편되었습니다. 동료를 초대하고 역할을 할당하여 회사가 비용을 지불하는 키를 발급할 수 있습니다. 또한 Proxy Finder는 단순히 "시도 횟수 초과"를 반환하는 대신 어떤 차단에 부딪혔는지 명시하기 시작했으며, Browser는 동일한 웹페이지에 일관된 정보를 전달하도록 개선되었습니다.
새로운 기능
직접 관리하는 조직 기능
이전에는 동료를 추가하려면 직접 이메일로 요청해야 했기에 팀마다 별도의 구독을 결제하곤 했습니다.
이제 대시보드에 조직 전용 페이지가 제공되며 세 가지 역할을 지원합니다. 소유자(Owner)는 키 사용량이 청구되는 구독을 보유하므로 조직당 단 한 명만 존재하며 소유권 이전을 통해 변경할 수 있습니다. 관리자(Admin)는 사용량, 결제 및 멤버를 관리합니다. 멤버(Member)는 서비스를 이용합니다. 초대는 이메일 주소로 발송되며 아직 가입하지 않은 사용자에게도 전달됩니다.
조직의 모든 구성원은 조직 소유의 키를 생성하거나 개인 키를 조직으로 이전할 수 있으므로, 개발자가 회사 업무로 인해 개인 비용을 지불할 필요가 없습니다. 조직 키 사용량은 소유자의 플랜에 청구되며, 모든 확인 메시지에는 결제 주체가 명시됩니다. 모든 멤버가 키 이름을 변경할 수 있지만, 키 재발급, 비활성화 및 삭제는 소유자와 관리자만 가능합니다. 해당 작업은 즉시 모든 동료의 사용을 중단시키기 때문입니다.
Overview, Detailed Metrics, Recent Activity 및 키 목록 전체에 하나의 소유자 필터가 적용됩니다. 멤버가 소유자의 쿼터를 조회할 필요는 없으므로 Usage & Limits와 Billing 페이지는 개인 단위로 유지됩니다.
추측을 끝낸 Proxy Finder
"Download maxTry limit reached" 오류는 모든 출구 노드가 차단되었거나, 모든 노드가 다운되었거나, 실제 페이지를 가져왔지만 자체 설정한 규칙으로 인해 폐기된 경우 모두 동일하게 표시되었습니다. 이 세 가지 경우는 각각 다른 해결 방식이 필요합니다.
이제 실패한 태스크에는 attemptReport 정보가 포함됩니다. 응답하지 않은 출구 수, 식별된 방어 시스템에 의해 거부된 횟수 및 관련 벤더, validate.status에서 거부된 횟수, 그리고 방어 시스템 없이 HTTP 200을 반환했으나 validate.data만 통과하지 못한 횟수를 제공합니다. 명확한 요약 문장도 함께 제공됩니다.
특히 마지막 수치는 매우 유용합니다. 일치하지 않는 콘텐츠 규칙은 기존 측정 방식으로는 모든 각도에서 차단된 것처럼 보였으며, 재시도로는 해결되지 않습니다. (validate 규칙이 성공을 판별하는 방식에 대해 자세히 알아보세요.)
나머지 절반은 프로필에 관한 부분입니다. 이전 Proxy Finder는 클라이언트 시그니처는 유지한 채 출구 노드만 순환했기 때문에, 특정 브라우저 프로필을 거부하는 사이트는 풀 내의 모든 출구 노드에서 요청을 거부했습니다. 이제 거부가 발생하면 기존 재시도 과정에서 프로필을 함께 변경하므로 태스크당 요청 수나 크레딧 소모는 달라지지 않습니다. profile을 직접 고정하면 기존 동작이 유지됩니다. 다만 난이도가 가장 높은 타깃의 경우 전송하는 프로필보다 도달하는 출구 노드가 여전히 더 중요합니다.
일관성을 확보한 Browser
Browser에 User-Agent를 요청하는 것은 차라리 요청하지 않는 것보다 못했습니다. 세 개의 레이어가 저마다 다른 식별 정보를 가지고 있어, 단일 request가 Windows, Mac, 그리고 플릿에서 실행되지도 않는 버전을 동시에 주장할 수 있었습니다. 이제는 하나의 값으로 한 번 결정되어 실행, 페이지, 페이지가 시작하는 worker 전체에 동일하게 전달됩니다.
Client hints는 해당 문자열에서 파생되므로 sec-ch-ua, 플랫폼, navigator.platform이 일치합니다. response는 실제로 전송한 문자열을 다시 보고하며, clearance cookie는 exit과 User-Agent에 함께 바인딩되므로 이 부분은 매우 중요합니다. 렌더러 관련 질문도 이제 document와 worker에서 동일하게 응답하며, 이는 누적되는 약한 신호들 중 하나입니다.
이에 더해 세 가지 변경 사항이 추가되었습니다.
- 시계가 exit을 따릅니다. Browser는 exit이 위치한 국가의 표준시로 실행되므로, 현지 시간을 렌더링하는 페이지에 해당 지역 방문자가 보는 화면이 표시됩니다. 국가를 알 수 없는 경우 시계는 그대로 유지됩니다.
- WebRTC가 다른 모든 트래픽과 동일한 경로를 유지합니다. proxy 설정은 브라우저가 TCP를 통해 전송하는 항목을 처리합니다. WebRTC는 해당 경로에 있지 않으므로 ICE candidate를 요청하는 페이지는 별도의 응답을 받게 됩니다. Browser는 request에 exit이 포함될 때마다 이를 비활성화합니다.
- 앵커가 포함된 URL이 정상적인 비용을 소모합니다.
#reviews(으)로 끝나는 URL은 매번 타임아웃을 유발했습니다. 이제 정상 속도로 복구되었습니다.
더 저렴해진 라우트, 정확하게 계산하는 Dashboard
Imperva는 차단 페이지뿐만 아니라 정상 페이지에도 스크립트를 삽입합니다. Auto는 둘을 구분하지 못해 정상 페이지가 불필요하게 브라우저로 에스컬레이션되었습니다. 한 렌터카 사이트에서는 6번의 시도에 걸쳐 75 크레딧과 27.5초가 소요되었으나, 이제는 1번의 시도로 약 6.5초 만에 10 크레딧만 소모합니다. 일부 사이트는 세션 없는 request에 대한 거부 응답 내에 세션을 전달하는데, 4개의 엔진 모두 에스컬레이션하기 전에 이를 즉시 다시 전송합니다.
Overview의 크레딧 카드에는 사용된 모든 금액이 표시되고 청구 금액으로 라벨이 지정되었습니다. 성공 시 결제 모델에서는 두 값이 다르며 그 차이는 실제 비용이므로, 카드에 두 항목을 모두 표시합니다. 청구 금액은 숫자로, 사용 금액은 그 아래에 제품별 및 총액으로 표기됩니다. Requests 카드도 동일하게 분리됩니다. 기간과 세부 정보 또한 별도의 컨트롤로 나뉘어 30분부터 1년 및 커스텀 범위까지 지정할 수 있으며, "1D"로 표시되면서 30일 데이터를 열던 필 버튼은 제거되었습니다.
Playground의 carry 버튼은 이제 마지막 response의 프로필을 제공하므로, 직접 입력하지 않은 프로필로 전송된 request라도 성공했던 버전을 그대로 재현합니다. 모든 파라미터는 API reference에 설명되어 있습니다.
내부 구현 세부사항
Proxy Finder는 호스트당 더 많은 이력을 보관합니다. 12개 대신 32개의 exit를 유지합니다. 라이브 A/B 테스트 결과 쉬운 타깃에서는 동등했고, 까다로운 타깃에서는 더 나은 성능을 보였습니다. 전체 fleet 지연 시간은 그대로 유지되면서 페이지 도달 중앙값 시간이 5.5초에서 3.8초로 단축되었습니다. 하나의 타깃은 반대 결과를 보였으며 아직 원인을 파악하지 못했으므로 별도의 측정을 진행하고 있습니다.
실패할 작업은 어떻게든 실패합니다. 차이는 1분 만에 티켓을 닫느냐, 아니면 엉뚱한 것을 측정하며 오후 시간을 낭비하느냐에 있습니다.