요청별 프록시 과금

비용을 지불하는 대상

제공업체가 집계한 요청 수에 비용을 지불합니다. 고정 패키지를 판매하거나 사용량에 따라 청구할 수 있습니다. 가격은 흔히 요청 천 회 또는 백만 회 단위로 표시합니다. 요금 비교에는 편리하지만 결제 시 지출할 금액은 알 수 없습니다. 최소 패키지에 더 많은 요청이 포함될 수 있기 때문입니다.

같은 “요청”이라는 말이 서로 다른 서비스를 가리킬 수 있습니다. 일반 프록시는 애플리케이션의 요청을 웹사이트에 전달하고 응답을 돌려줍니다. 페이지 로딩과 데이터 추출은 애플리케이션이 담당합니다. 데이터 수집 API에서는 브라우저 실행, 접근 제한 처리, 결과 준비가 가격에 포함될 수도 있습니다. 따라서 요청 가격만 비교하지 말고 그 비용으로 서비스가 무엇을 하는지 알아야 합니다.

일정에 따라 실행되는 작업에 편리한 과금 방식입니다. 확인할 페이지 수와 빈도는 이미 알고 있을 수 있습니다. 다음으로 각 확인에 필요한 요청 수를 알아보세요. 한 달에 필요한 패키지와 페이지 추가 시 사용량 증가를 추정할 수 있습니다.

응답 크기가 반드시 가격에 영향을 주지는 않습니다. 요청마다 같은 금액을 청구한다면 응답 하나에서 많은 데이터를 가져와도 작은 응답과 비용이 같을 수 있습니다. 다만 대역폭, 응답 크기, 실행 시간 한도가 있을 수 있으므로 포함 항목을 확인하세요. 추가 데이터 처리에 별도 요금이 있을 수도 있습니다.

요청 패키지는 받는 IP 주소 수를 정하지 않습니다. 예를 들어 순환 서비스는 공유 접속 엔드포인트로 IP 풀에 접속하게 할 수 있습니다. IP 변경과 세션 동안 주소 유지는 서비스 설정에 달려 있습니다. IP가 바뀌었다는 사실만으로 몇 요청이 과금되는지 알 수 없습니다.

서비스가 요청 하나로 계산하는 기준

먼저 요청과 연결을 구분하세요. HTTP 요청은 페이지 반환이나 데이터 제공처럼 웹사이트에 특정 작업을 요구합니다. 웹사이트는 응답을 보냅니다. 데이터가 양방향으로 이동한다는 사실만으로 요청 두 개를 차감해야 하는 것은 아닙니다. 그렇게 계산하려면 별도의 과금 규칙이 있어야 합니다.

연결은 애플리케이션과 서버가 통신하는 통로입니다. 여러 요청이 같은 연결을 사용할 수 있습니다. HTTP/1.1은 연결 재사용을 허용하고 HTTP/2는 여러 통신을 동시에 처리합니다. 따라서 요청 수, 열린 연결 수, 동시에 활성 상태인 연결 수는 서로 다른 측정값입니다.

HTTPS에는 추가 사항이 있습니다. HTTP 프록시로 연결할 때 애플리케이션은 보통 CONNECT 명령으로 웹사이트까지 터널을 만듭니다. 이후 요청은 터널 안에서 암호화되어 이동합니다. 프록시는 데이터를 전달하지만 일반적인 사용에서는 개별 HTTP 요청을 읽을 수 없습니다. SOCKS 프록시도 목적지 연결을 제공합니다. 애플리케이션의 모든 동작에 새 연결이 필요한 것은 아닙니다.

이 때문에 일부 서비스는 프록시 서버가 셀 수 있는 연결이나 다른 이벤트를 “요청”이라고 부릅니다. 다른 서비스는 개별 HTTP 요청이나 API 호출을 셉니다. 따라서 브라우저 개발자 도구의 요청 수와 제공업체 대시보드 사용량이 다를 수 있습니다. HTTP, HTTPS, SOCKS5 지원만으로 집계 규칙을 알 수는 없습니다.

큰 패키지 구매 전 소규모 테스트를 하세요. 애플리케이션이 완료한 작업 수와 서비스가 차감한 요청 수를 기록하세요. 이후 사용할 것과 같은 애플리케이션, 프로토콜, 설정을 사용하세요. 단순 HTTP 클라이언트 테스트는 스크립트와 다른 페이지 자원도 불러오는 브라우저의 사용량을 보여 주지 못합니다.

페이지 하나에 여러 요청이 필요한 이유

페이지를 열 때 주 문서 외에 더 필요한 경우가 많습니다. 브라우저는 스타일, 스크립트, 이미지, 데이터를 별도로 불러옵니다. 열린 페이지가 갱신을 위해 서버에 계속 접속할 수도 있습니다. 애플리케이션 설정에 따라 이 요청 중 일부도 프록시를 통과합니다. 과금 방식은 요금 규칙에 달려 있습니다.

리디렉션을 따라가면 요청이 추가됩니다. 웹사이트가 페이지의 다른 주소를 알리면 리디렉션을 따르도록 설정한 애플리케이션은 그 주소로 새 HTTP 요청을 보냅니다. 따라서 단순 클라이언트로 문서 하나를 가져오는 것과 브라우저로 전체 페이지를 여는 것은 요청 수가 다를 수 있습니다. 목록의 URL 수만으로 처리 요청 수를 알 수는 없습니다.

API는 반대가 될 수 있습니다. 요청 하나로 여러 레코드를 가져올 수 있습니다. 이 예에서 브라우저는 가격이 표시된 헤드폰 상품 페이지를 여는 데 요청 다섯 개를 보냅니다. 애플리케이션은 같은 프록시로 해당 소매점의 카탈로그 API를 호출해 요청 한 번으로 상품 가격 다섯 개를 가져옵니다. 이는 상품 데이터를 제공하는 소매점의 API입니다. 카탈로그를 페이지로 나누어 반환하면 각 페이지에 요청이 추가됩니다. API가 지원하고 필요한 데이터를 모두 반환한다면 응답당 상품 수를 늘릴 수도 있습니다.

이 방식은 패키지로 더 많은 유용한 작업을 하게 도와줍니다. 전체 페이지 반복 로딩, 이미 저장한 데이터 재수집, 필요 이상으로 잦은 가격 확인은 허용량을 빨리 소진합니다. 호출당 여러 상품 조회, 결과 저장, 적절한 확인 빈도 선택은 같은 작업의 요청 수를 줄입니다. 같은 부하라면 유효기간 안에서 허용량을 더 오래 쓰거나 더 많은 상품을 확인할 수 있습니다.

완료한 작업당 사용량을 측정하면 도움이 됩니다. 페이지 하나 확인, 전체 목록 수집, 스크립트 실행 후 나타나는 요소 확인 등이 작업일 수 있습니다. 결과에 도달하는 데 필요한 전체 순서를 측정하세요. 시작 URL만 셀 때 놓치기 쉬운 추가 페이지 로딩도 포함해야 합니다.

이 과금 모델이 유용한 작업

예약 모니터링

요청 사용량을 정기 점검과 연결할 수 있습니다. 페이지 가용성, 공개 목록 변경, 특정 지역의 검색 결과를 모니터링하는 애플리케이션이 예입니다. 대상 수와 확인 빈도를 미리 알고 있으므로 테스트로 확인당 요청 수를 파악하여 월간 소비량을 추정할 수 있습니다.

모든 페이지를 같은 빈도로 확인할 필요는 없습니다. 하루에 한 번 바뀌는 정보를 매분 확인하면 보통 같은 데이터가 반환됩니다. 변화의 빠른 감지가 중요한 페이지에 더 잦은 확인을 배정할 수 있습니다. 필요한 관측에 패키지를 사용할 수 있게 해 줍니다.

API와 디렉터리의 데이터 수집

사용량은 웹사이트의 정보 제공 방식에 달려 있습니다. 목록에 이미 필요한 내용이 모두 있다면 상세 페이지를 각각 열 이유가 없습니다. 누락 데이터가 있거나 이전 실행 후 바뀐 항목에 추가 요청을 쓸 수 있습니다. 호출 한 번에 필요한 데이터를 많이 가져올수록 전체 수집에 필요한 요청이 줄어듭니다.

서비스가 하는 일도 고려해야 합니다. 검색 API는 파싱된 결과를 반환할 수 있지만 일반 프록시는 다운로드와 처리를 애플리케이션에 맡깁니다. 작업량이 서로 다릅니다. 가격 비교 시 응답 내용과 직접 해야 할 작업을 확인하세요.

사이트 감사와 브라우저 점검

기술 감사는 주소 열기, 응답 확인, 필요 시 리디렉션 따르기, 결과 저장이라는 명확한 순서가 흔합니다. 대부분 비슷하게 처리되면 테스트로 사용량을 쉽게 추정할 수 있습니다. 브라우저 점검은 스크립트, 이미지, 작동하는 페이지 요소가 필요해 요청이 더 많을 수 있습니다.

목적에 맞게 점검 방식을 선택하세요. 페이지 응답 여부 확인에는 단순 클라이언트로 충분한 경우가 많습니다. 결제 양식 테스트에는 양식 작동에 필요한 요소를 불러와야 합니다. 필수 파일을 끄면 요청은 줄지만 사용자 경험을 보여 주는 테스트가 되지 않습니다.

오류와 재시도의 사용량 영향

보낸 요청이 항상 필요한 데이터를 반환하지는 않습니다. 웹사이트는 오류, 접근 확인, 다른 페이지를 반환할 수 있습니다. HTTP 200도 원하는 데이터 수신을 보장하지 않습니다. 상태는 HTTP 수준의 성공을 알리며 응답 내용은 별도로 확인해야 합니다.

이런 요청의 과금 규칙은 다양합니다. 일부는 보낸 요청을 세고 다른 서비스는 자체 성공 기준에 맞는 응답만 청구합니다. 관리형 API는 응답 하나의 가격에 여러 내부 수집 시도를 포함할 수 있습니다. 추가 모드나 기능이 과금 규칙을 바꾸기도 합니다. 따라서 “요청별 지불”이 자동으로 “수집한 데이터에만 지불”을 뜻하지 않습니다.

애플리케이션 재시도와 서비스 내부 재시도는 다릅니다. 애플리케이션이 다시 보내면 새 요청이 됩니다. 서비스가 이미 제출된 작업을 재시도한다면 가격에 포함될 수 있습니다. 어떤 시도가 패키지에서 차감되는지 확인하세요.

테스트 중 시작한 작업 수, 과금 요청 수, 완료한 작업 수를 기록하세요. 완료의 의미는 목적에 달려 있습니다. 데이터 수집에서는 필요한 필드와 충분히 최신인 정보가 응답에 있어야 합니다. 가용성 모니터링에서는 웹사이트 불가용을 올바르게 감지한 것도 완료한 점검입니다.

이 수치는 실제 작업 비용을 보여 줍니다. 응답을 계속 재시도하거나 버려야 하면 저렴한 요청도 경제성이 나쁠 수 있습니다. 더 비싼 서비스가 작업 일부를 대신할 수도 있습니다. 애플리케이션에 남은 작업까지 포함하여 필요한 결과를 얻는 지출을 비교하세요.

필요한 패키지 계산 방법

먼저 처리 대상 수와 빈도 등 예정 작업을 세세요. 그런 다음 테스트에서 관측한 재시도 등 일반 수집 외의 요청을 더하세요. 페이지 그룹의 동작이 다르면 따로 계산하세요. 같은 추가 요청을 두 번 더하지 않도록 부하 증가용 여유도 별도로 두세요.

설명용 예시로 애플리케이션이 URL 150개를 30분마다 30일 동안 확인합니다. 선택한 요금에서 일반 점검은 요청 하나를 쓰고 추가 시도로 사용량이 5% 증가한다고 가정합니다. 모든 수치와 가격은 가상이며 제공업체 시험 결과나 ProxyCompass 요금이 아닙니다.

선택한 패키지에는 요청 23,200회의 여유가 남습니다. 유효기간 안에서 부하 증가에 쓸 수 있습니다. 예상 재시도는 이미 추가 시도 10,800회에 포함되어 있습니다. 이 여유를 같은 재시도의 사용량으로 다시 세어서는 안 됩니다.

패키지 가격이 $10이라고 가정해 보세요. 요청 250천 회가 포함되어 있으므로 명목상 천 회당 가격은 $0.04입니다. 전체 패키지에 $10를 지불합니다. 예상 사용량 요청 226,800회에 이 단가를 곱하면 $9.072입니다. 이는 사용한 부분의 가치이지 구매 금액이 아닙니다. 고정 패키지 가격은 여전히 $10입니다.

추가 시도 후 애플리케이션이 예정 점검 216,000회를 모두 완료했다고 가정합니다. 완료 점검 천 회당 비용은 약 $0.0463이며 계산은 $10 ÷ 216,000 × 1,000입니다. 추가 요청과 구매한 여유분을 모두 반영합니다. 완료 점검이 더 적다면 실제 완료 수로 지출을 나누세요.

다른 작업도 같은 방식으로 계산합니다. 사용량 과금에서는 해당 단가가 몇 요청을 포함하는지 고려해 과금 요청 수에 단가를 곱합니다. 패키지는 전체 구매 가격을 사용합니다. 그런 다음 완료한 작업 수로 지출을 나누세요. 여러 프로젝트가 패키지를 공유하면 비용 배분 방식을 정하세요.

애플리케이션이 제시간에 끝낼 수 있는지도 확인하세요. 예시는 하루 점검 7,200회로 평균 분당 시작 다섯 번이 필요합니다. 반시간마다 점검 150개를 한꺼번에 시작하거나 구간 안에 나눌 수 있습니다. 각 점검의 시도 수가 가정과 같다면 사용량은 같지만 시작 부하는 다릅니다. 연결 한도나 요청 빈도 한도 때문에 첫 일정이 계획대로 실행되지 못할 수 있습니다.

불필요한 요청을 줄이는 방법

중복 주소를 제거하고 작업 중 결과를 저장하세요. 실패 후에는 멈춘 곳부터 계속해야 합니다. 매번 전체 목록을 다시 시작하면 이미 처리한 페이지가 패키지를 다시 소모합니다. 완료한 작업과 남은 작업을 기록하세요.

데이터 수집에 필요한 로딩 방식을 사용하세요. 필요한 텍스트가 서버 응답에 이미 있으면 브라우저 실행이 불필요할 수 있습니다. 스크립트 실행 후에만 나타나는 데이터라면 단순 다운로드로는 부족할 수 있습니다. 데이터 수집 서비스의 브라우저 모드와 추가 기능은 크레딧을 더 쓰거나 다른 단가를 적용하기도 합니다. 크레딧 하나가 항상 요청 하나와 같지는 않습니다.

응답 크기를 줄여도 요청이 줄지는 않을 수 있습니다. 제공업체가 HTTP 호출을 세면 짧은 응답도 긴 응답과 같은 요청 수를 소모할 수 있습니다. 변하지 않은 데이터 확인 빈도를 낮추거나 저장 결과를 재사용하거나 API 한 번으로 여러 레코드를 가져와 수를 줄일 수 있습니다. 그래도 작업에 충분히 최신인 정보여야 합니다.

재시도를 제한하고 실패 이유를 고려하세요. 웹사이트가 일시적으로 불가용하거나 속도를 낮추라고 요구하면 즉시 재시도해도 같은 응답을 받고 요청을 또 소모할 수 있습니다. 대기하거나 빈도를 줄이는 편이 유용할 수 있습니다. 데이터를 생성하거나 바꾸는 동작에는 특히 주의하세요. 다시 제출하기 전에 첫 시도의 결과를 확인하세요. 응답 손실이 서버에서 아무 일도 하지 않았다는 뜻은 아닙니다.

변경 후 사용량뿐 아니라 결과도 확인하세요. 애플리케이션이 작업 일부를 멈춰서 요청 수가 줄었을 수도 있습니다. 더 적은 요청으로 필요한 데이터를 같은 완전성과 시의성으로 얻을 때 유용한 절감입니다.

요금 선택 시 확인할 사항

먼저 웹사이트와 애플리케이션에서 서비스가 작동하는지 확인하세요. 프록시 유형, 제공 국가, 세션 동작, 제공된 IP로 필요한 페이지에 접속할 수 있는지가 모두 중요합니다. 다음으로 페이지 로딩, 브라우저 실행, 데이터 추출, 실패 재시도를 누가 담당하는지 비교하세요. 두 서비스의 요청당 가격 차이를 이해하는 데 도움이 됩니다.

패키지 유효기간, 충전 규칙, 미사용 요청 처리를 확인하세요. 요청 단가가 낮은 대형 패키지는 기간 안에 필요한 작업에 쓸 수 있다면 경제적입니다. 구매한 요청 일부를 쓰지 못하면 작은 패키지보다 완료 작업당 비용이 높을 수 있습니다.

비교하려면 자주 문제가 생기는 페이지를 포함하여 프로젝트의 대표 페이지를 선택하세요. 소요 시간, 사용 요청, 얻은 결과, 애플리케이션 설정을 기록하세요. 테스트로 필요한 패키지 크기, 대략적인 작업 비용, 제시간에 끝낼 수 있는지를 알 수 있습니다.