용량 관련 질문은 대부분 순서가 거꾸로 된 채로 제기된다. 스레드를 몇 개 돌려야 하는지, 대역폭을 얼마나 사야 하는지를 묻는 경우가 많은데, 이는 실제 요구사항을 먼저 변환하기 전까지는 알 수 없는 것들이다. 실제 요구사항은 보통 “제품 레코드 5만 건을 매일 갱신해서 08:00까지 준비”와 같은 형태다. 이 문장 안에 필요한 모든 정보가 들어 있다. 이를 요청량, 동시성, 플랜 규모로 전환하는 방법과 실제로 제약이 걸리는 지점을 살펴본다.
요청이 아니라 레코드에서 시작하라
첫 번째 변환은 사람들이 자주 건너뛰는 단계이며, 여기서 추정치가 몇 배씩 어긋난다.
레코드 한 건이 요청 한 건과 같은 경우는 드물다. 제품 레코드 하나에 목록 페이지와 상세 페이지가 모두 필요할 수 있으므로 두 건이 된다. 목록이 페이지네이션 되어 있고 모든 항목이 필요하다면, 그 항목들이 산출하는 레코드 수에 걸쳐 분산된 페이지네이션 요청도 더해야 한다. 상세 페이지가 두 번째 호출로 데이터를 불러온다면 그것도 추가된다. 그리고 데이터 엔드포인트를 그대로 가져오는 대신 브라우저에서 페이지를 렌더링한다면, 논리적 요청 하나가 수십 건의 자산 요청으로 늘어나며, 이는 논리적 개수는 바뀌지 않더라도 대역폭 측면에서는 매우 중요하다.
따라서 다음과 같이 명시적으로 적어야 한다.
requests_per_record = detail_pages + (listing_pages / records_per_listing) + extra_calls레코드 5만 건에 대해 각각 1.2건의 요청이 필요하다면, 실행당 60,000건의 요청이 된다. 여기에 실패 여유분을 더해야 하는데, 검증된 성공률이 100%가 아니기 때문이다. 성공률이 90%라면 60,000건의 성공을 얻기 위해 대략 67,000건의 시도가 필요하고, 일시적 실패에 대해 재시도까지 하고 있다면 실제 수치는 다시 조금 더 높아진다. 시도 건수가 아니라 성공 건수를 기준으로 계획을 세우는 것이 두 번째로 흔한 추정 오류다.
동시성은 속도와 지연시간에서 도출된다
이제 사람들을 놀라게 하는 부분이다. 동시성은 임의로 선택하는 숫자가 아니라, 얼마나 빨리 처리해야 하는지와 요청 하나가 얼마나 걸리는지에 따라 결정된다.
4시간 안에 67,000건의 요청을 완료해야 한다면, 이는 초당 약 4.7건을 지속적으로 처리해야 한다는 뜻이다. 레지덴셜 요청은 다이렉트 요청보다 느리므로, 요청 하나당 종단 간 평균 2초로 가정한다. 필요한 동시 진행 건수는 단순히 속도에 지연시간을 곱한 값이다.
concurrency = requests_per_second x average_latency_seconds
= 4.7 x 2
~ 10 concurrent requests이 관계는 잘 익혀둘 가치가 있는데, 두 가지를 동시에 설명해주기 때문이다. 느린 타겟은 동일한 처리량을 내기 위해 더 많은 동시성이 필요하며, 이것이 조용히 성능이 저하되는 타겟이 오류 하나 없이도 스케줄을 고갈시킬 수 있는 이유다. 그리고 타겟이 속도를 늦추는 원인이라면 동시성을 높인다고 처리량이 늘지 않으며, 단지 대기 중인 요청 수만 늘어날 뿐이다.
반대 방향으로도 생각해보자. 동시성을 10으로 제한한 상태에서 지연시간이 2초에서 5초로 늘어나면, 처리량은 초당 5건에서 2건으로 떨어지고, 4시간짜리 작업이 10시간짜리 작업이 된다. 한계치가 아니라 여유를 두고 스케줄을 짜는 것이 지연시간 변동이 마감 실패로 이어지는 것을 막아준다.
제약은 여러분의 머신이 아니라 타겟이다
여기서 계획이 현실과 마주한다. 인프라가 감당할 수 있는 동시성은 거의 항상 실제 제약이 아니다. 진짜 제약은 타겟이 허용하는 수준이다.
레이트 제한은 IP 단위로, 그리고 점점 더 타겟 단위로 전체 합산되어 적용된다. 풀을 사용하면 IP당 부하를 분산시킬 수 있지만, 하나의 오리진에 도달하는 총량은 여전히 눈에 보이므로, 계획의 기준으로 삼아야 할 숫자는 워커가 내보낼 수 있는 양이 아니라 해당 사이트가 받아들이는 양이다. 페이싱 메커니즘은 레이트 제한과 요청 스로틀링에서 다루며, 그다음에 이어지는 분산 문제, 즉 물량에 얼마나 넓은 분산이 필요한지는 실제로 필요한 프록시 IP 개수에서 자세히 다룬다.
실무적으로는 전역 설정 하나가 아니라 타겟별 동시성 상한과 타겟별 레이트를 계획에 담아야 한다는 의미다. 각각 적당한 동시성을 가진 타겟 50곳은 동일한 총량을 한 사이트에 집중시키는 것과는 완전히 다른 상황이며, 후자만이 차단으로 이어진다.
실제로 구매하는 숫자는 대역폭이다
레지덴셜 프록시는 전송된 데이터량에 따라 과금되므로, 플랜 규모는 요청 수나 주소 수가 아니라 바이트 수에서 도출된다.
monthly_bandwidth = attempts_per_run x runs_per_month x average_bytes_per_response가장 큰 영향을 미치는 변수는 마지막 항목이며, 이는 전적으로 여러분의 통제 범위 안에 있다. JSON 응답이나 가벼운 HTML 페이지는 수십 킬로바이트 수준이지만, 이미지, 폰트, 서드파티 스크립트까지 완전히 렌더링된 페이지는 수 메가바이트에 달한다. 하루 60,000건의 요청 기준으로, 응답 크기 50 KB일 때는 월 약 90 GB가 되지만, 렌더링된 페이지 2 MB일 때는 동일한 논리적 작업량에서도 약 3.6 TB가 된다. 이는 적당한 플랜과 엔터프라이즈 플랜 사이의 차이이며, 데이터를 가져올지 페이지를 렌더링할지에 따라 결정된다. 자세한 내용은 헤드리스 브라우저가 필요한 시점과 대역폭 비용 절감을 참고하라.
플랜 규모를 정하기 전에 이 최적화를 먼저 하라. 이것만으로도 종종 한 단계 낮은 등급으로 내려갈 수 있다. 더 상세한 예측 방법은 월간 대역폭 추정에, 제품 수준의 선택 기준은 적합한 플랜 선택에 나와 있다.
스케줄링: 몰아치기보다 분산이 낫다
일일 물량이 동일한 두 작업이라도 실행 시점에 따라 완전히 다르게 동작할 수 있다.
모든 작업을 1시간짜리 창에 압축하면 모든 타겟에 대한 순간 레이트가 한꺼번에 배가되며, 이는 방어 체계를 촉발시키는 전형적인 형태다. 동일한 작업을 가능한 시간대 전체에 분산시키면 타겟당 레이트가 별다른 비용 없이 낮아지고, 실패한 요청도 작업 종료 시점에 몰리는 대신 이후 시간대에 재시도할 여유가 생긴다.
신선도 요구사항이 제약을 결정한다. 데이터가 08:00 기준으로 최신이어야 한다면 그 이전에 수집을 마쳐야 하지만, 이는 07:00에 시작하라는 지시가 아니라 마감시한일 뿐이다. 스케줄이 허용하는 한, 전체 시간대에 걸쳐 분산시키고 변동성이 큰 소스를 먼저 우선순위에 두는 것이 확실히 더 낫다.
커밋 전에 파일럿으로 검증하라
위의 모든 수치는 여러분이 가정한 두 가지 변수, 즉 실제 타겟에 레지덴셜 출구로 접속할 때의 실제 평균 지연시간과 수집 전략이 확정된 후의 응답당 실제 바이트 수를 측정하기 전까지는 가설에 불과하다. 두 가지 모두 소규모 실행으로 쉽게 측정할 수 있으며, 둘 다 계획에 상당한 영향을 미친다.
의도한 물량의 5% 정도로 파일럿을 실행하여 검증된 성공률, 지연시간 백분위, 타겟별 요청당 바이트 수를 기록한 다음 재계산하라. 결과가 예측치와 양쪽 방향으로 다를 것이라 예상해야 한다. 측정 방법은 속도, 성공률, 위치 정확도 테스트에 나와 있으며, 동일한 수치의 지속적인 버전은 프록시 KPI의 지표들이다.
예제 요약
요구사항: 매일 레코드 5만 건, 08:00까지 준비, 수집 시간대 04:00부터 08:00까지.
레코드당 요청 1.2건, 성공 60,000건. 검증된 성공률 90%에서 시도 건수는 약 67,000건. 4시간에 걸쳐 초당 4.7건. 평균 지연시간 2초에서 동시 진행 건수는 대략 10건이며, 이를 한 곳에 집중시키지 않고 여러 타겟으로 분산시킨다. 응답당 평균 80 KB에서 실행당 약 5.4 GB, 월 약 160 GB. 지연시간이 변동하고 성공률이 하락할 수 있으므로 동시성과 대역폭 모두에 여유를 두고, 파일럿 이후 재도출하라.
결론
거꾸로 계획하라. 레코드에서 요청으로, 요청에서 실패 여유분을 반영한 시도 건수로, 시간대에 걸친 시도 건수에서 레이트로, 레이트에 지연시간을 곱해 동시성으로, 시도 건수에 응답 크기를 곱해 대역폭으로. 동시성과 레이트는 전역이 아니라 타겟별로 상한을 두어라. 실제 제약은 각 사이트가 허용하는 수준이지, 인프라가 만들어낼 수 있는 수준이 아니기 때문이다. 플랜 규모를 정하기 전에 무엇을 가져올지 최적화하라. 렌더링할지 데이터를 가져올지에 따라 대역폭 답이 두 자릿수 차이로 달라질 수 있기 때문이다. 작업은 몰아치기보다 가능한 시간대 전체에 분산시켜라. 그런 다음 파일럿을 실행하라. 지연시간과 응답당 바이트 수는 플랜을 확정하기 전에 측정치로 대체할 가치가 있는 두 가지 가정이기 때문이다.
용량 자체는 레지덴셜 프록시에서 나오며, 여기서는 동시성이 플랜 규모를 결정하는 제약이 아니고, GB당 가격이 적용되므로 여러분이 도출한 대역폭 수치가 곧 실제로 구매하는 숫자가 된다.