프록시 IP는 실제로 몇 개가 필요한가

프록시를 사기 전에 가장 많이 나오는 질문은 동시에 잘못된 질문이기도 하다. 중요한 것은 IP를 몇 개 가졌느냐가 아니라 요청이 그 사이에 어떻게 분산되느냐다.

거의 모든 프록시 구매 전에 나오는 질문이 있다. IP가 몇 개 필요한가. 숫자로 답이 나와야 할 것 같은 종류의 질문처럼 들리고, 작업이 될지 안 될지를 결정하는 숫자처럼 느껴진다. 그러나 실제로는 대개 잘못된 질문이며, 이 질문으로 시작하는 팀은 엉뚱한 것을 사는 경우가 많다. 스크래핑이 깔끔하게 돌아갈지를 실제로 결정하는 것은 주소를 몇 개 보유했느냐가 아니라, 사용하는 주소들 사이에 요청이 어떻게 분산되느냐이며, 어떤 개별 타깃이 하나의 주소로부터 신경 쓸 만큼의 트래픽을 보게 되느냐다.

여기서는 이 문제를 제대로 생각하는 법을 다룬다. IP를 세는 것이 정말로 옳은 접근이 되는 유일한 경우도 함께 살펴본다.

왜 질문이 잘못 설정되었나

IP를 세려는 본능은 더 오래된 과금 모델의 잔재다. 프록시가 포트 단위나 정적 주소 단위로 팔리던 시절에는 특정 개수의 IP를 사면 그 숫자가 곧 용량이었으므로 세는 것이 말이 됐다. 현대의 레지덴셜 네트워크는 그렇게 동작하지 않는다. 큰 공유 풀에서 끌어다 쓰고, 건드린 주소가 아니라 옮긴 대역폭에 대해 과금되며, 결국 사용하게 되는 개별 IP의 수는 로테이션을 어떻게 구성했느냐의 결과이지 미리 구매하는 수량이 아니다. 이 변화는 포트 단위 시대가 끝난 이유에서 더 깊이 다루는데, 바로 이것이 “IP 몇 개”라는 질문이 실제로 구매하는 무언가와 더 이상 대응하지 않는 이유다.

이 틀이 오해를 부르는 두 번째 이유도 있다. 타깃 사이트는 당신의 풀을 보지 않는다. 자기 문 앞에 도착하는 요청을 볼 뿐이고, 그 요청들이 어떻게 행동하는지에 따라 주소별로 판단을 형성한다. IP가 만 개라도 전체 물량을 그중 몇 개로만 보내는 작업은 구제되지 않으며, 수는 많지 않아도 잘 분산된 주소들은 어설픈 구성으로는 돌릴 수 없는 작업을 무리 없이 처리한다. 변수는 분산이지 재고가 아니다.

필요량을 실제로 결정하는 것

작업에 무엇이 필요한지를 결정하는 요소는 네 가지다. 순서대로 짚어가면 답은 저절로 나온다.

첫째는 타깃당 요청 속도다. 전체를 합친 총 요청량이 아니라, 주어진 시간 창 안에 하나의 사이트로 몇 건을 보내느냐다. 속도 제한은 IP별, 타깃별로 적용되기 때문이다. 둘째는 동시성, 즉 동시에 떠 있는 요청이 몇 건이냐이며, 이것이 동시에 사용되는 주소의 수를 정한다. 셋째는 세션 요구사항이다. 여러 단계로 이어지는 흐름을 위해 IP를 붙잡아 두어야 하는지 여부이며, 이것이 실제 개수 세기로 이어지는 유일한 경우다. 넷째는 지리적 확산이다. 여러 시장을 다루는 작업은 다른 곳에 몰려 있는 큰 풀이 아니라 그 시장 각각에 물량이 분산되어야 하며, 도시 단위 타기팅이 관련될 때 물어야 할 것은 그 도시에서의 가용성이지 네트워크 전체의 규모가 아니다.

로테이션 작업의 대략적인 계산

일반적인 로테이션 수집에서 쓸모 있는 계산은 “IP가 몇 개 존재하는가”가 아니라 “각 타깃에서 예의를 지키려면 내 물량이 몇 개의 개별 주소로 분산되어야 하는가”다.

하나의 사이트로 향하는 요청 속도를 가져와, 하나의 주소에서 보내도 좋다고 여기는 속도로 나눈다. 어떤 작업이 한 타깃으로 시간당 60,000건을 보내고, 어떤 주소도 그 타깃으로 대략 20초에 1건, 즉 시간당 180건을 넘지 않기를 원한다면, 그 물량은 임의의 시점에 약 330개 수준의 개별 주소로 분산되어야 한다. 입력값 중 하나를 바꾸면 답도 움직인다. 물량을 절반으로 줄이면 필요한 수도 절반이고, 주소마다 속도를 낮추면 더 많이 필요하다. 여기의 숫자는 예시다. 타깃마다 허용하는 속도가 다르므로 특정 사이트가 실제로 받아들이는 수준에 맞춰 조정해야 한다. 중요한 것은 계산의 형태다. 당신이 푸는 것은 분산이며, 풀은 그저 대상 시장에서 충분히 크고 충분히 잘 분산되어 그것을 공급할 수 있으면 된다.

바로 이 일을 로드 밸런싱이 대신해 주며, 무제한 동시 연결이 헤드라인의 IP 숫자보다 더 중요한 이유도 여기에 있다. 물어뜯는 제약은 하나의 주소가 하나의 사이트로 몇 건을 보내느냐이지, 전체에 주소가 몇 개 있느냐가 아니다. 서로 다른 타깃을 많이 두드리고 있다면 이 계산은 타깃별로 적용되며, 오십 개 사이트에 나뉜 물량은 같은 물량을 하나에 겨눈 경우보다 훨씬 부담이 적다.

정말로 세어야 하는 경우: 스티키 세션

숫자가 진짜로 정답이 되는 상황이 하나 있고, 이 부분은 정확히 말할 가치가 있다. 유지되는 신원이 필요한 작업, 즉 여러 단계의 검색, 로그인 흐름, 체크아웃 형태의 시퀀스, 또는 사이트가 요청들 사이로 상태를 추적하는 모든 과정에서는, 그 동시 흐름 하나하나가 흐름이 지속되는 동안 자기 IP 위에 자기만의 스티키 세션을 필요로 한다. 여기서 세는 방식은 직접적이다. 동시에 오십 개 세션이면 그 순간 유지되는 주소가 오십 개이고, 오백 개면 오백 개다.

그러므로 이 질문의 정직한 형태는 “IP가 몇 개 필요한가”가 아니라 “동시 스티키 세션이 몇 개 필요한가”이며, 이는 네트워크에 관한 질문이 아니라 당신 워크로드의 형태에 관한 질문이다. 유지되는 신원을 요구하지 않는 모든 것은 로테이션해야 한다. 로테이션은 부하를 자동으로 분산하며, 로테이션 모델은 그렇게 쓰이도록 설계되었기 때문이다.

순수 풀 크기가 비교 지표로 약한 이유

공급자들은 풀 크기를 광고하고, 그 숫자들은 너무 커서 의미 있게 비교하기 어렵다. 헤드라인 수치보다 중요한 것이 셋 있다.

첫째는 당신 시장에서의 분산이다. 정작 필요한 국가나 도시에서 얇은 초대형 풀은, 그곳에서 밀도가 높은 더 작은 네트워크보다 당신 작업에 불리하다. 따라서 의미 있는 풀 크기는 수집하는 바로 그곳에서 가용한 몫뿐이다. 둘째는 품질이다. 플래그가 붙었거나 과다 사용된 주소는 개수가 얼마든 챌린지와 왜곡된 응답을 부른다. 그래서 IP 평판이 물량보다 성공률에 더 직접적으로 영향을 주며, 레지덴셜 IP가 실제로 무엇인지를 이해해 두면 도움이 된다. 셋째는 동시 가용성이다. 중요한 것은 트래픽을 보내는 그 순간에 쓸 수 있는 것이지, 네트워크가 여태 본 모든 주소의 누적 집계가 아니다.

실무적 귀결은, 공급자를 풀 크기로 고르지 말라는 것이다. 소액으로 구매해 자신의 워크로드를 돌리고 측정하라. 그것이 속도, 성공률, 위치 정확도 테스트 가이드의 목적이다.

대신 산정할 것: 대역폭

사용한 주소가 아니라 옮긴 데이터로 과금되므로, 예측할 가치가 있는 숫자는 대역폭이다. 타깃의 페이지 또는 응답 크기를 추정하고 수집할 물량을 곱하면 실제로 지불할 금액에 대응하는 수치가 나온다. 이것이 월간 대역폭 추정에서 제시한 접근이다. 그러면 가장 큰 비용 레버도 분명해지는데, 그것은 IP의 개수가 아니다. 렌더링된 페이지 전체가 아니라 필요한 것만 가져오는 데 절감이 있으며, 이는 프록시 대역폭 비용 절감에서 다룬다.

설정하기

두 모드 모두 같은 gateway에서 나오며, 차이는 사용자명의 필드 하나다. 세션 식별자를 빼면 요청마다 로테이션되고, 대부분의 수집은 이렇게 해야 한다.

import requests

# Rotating: every request exits through a different address
ROTATING = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"
r = requests.get("https://example.com/page",
                 proxies={"http": ROTATING, "https": ROTATING}, timeout=15)

# Sticky: one held IP per concurrent flow, counted per session
def sticky(session_id):
    url = (f"http://customer-USERNAME-country-us-sid-{session_id}:"
           f"PASSWORD@p.shifter.io:443")
    return {"http": url, "https": url}

# 50 concurrent flows means 50 distinct session identifiers
for i in range(50):
    proxies = sticky(f"flow{i}")
    # run one multi-step sequence on this held address

기본은 로테이션으로 두고, 흐름이 정말로 필요로 할 때만 세션을 유지하며, 고정된 주소 목록을 직접 관리하려 하지 말고 분산은 풀에 맡기라.

답을 검증하기

어떤 숫자에 도달하든 그것은 출발점의 가설이며, 믿을 수 있는 확인은 측정뿐이다. 타깃별, 지역별 성공률을 지켜보라. 하락은 주소당 속도가 그 사이트에 지나치게 공격적이라는 신호이며, 데이터 공백이 되기 훨씬 전에 나타난다. 그것을 주는 것이 파이프라인 모니터링이다. 경로가 나빠지면 페일오버가 조정하는 동안에도 작업을 계속 돌게 해준다. 그리고 차단이 보인다면, 해법은 주소를 늘리는 것보다 속도 조절과 요청 위생인 경우가 더 많으며, 그것이 차단 회피의 핵심이다.

짧은 체크리스트

가장 바쁜 단일 타깃으로 시간당 몇 건을 보내는가. 그 값을 그 타깃이 허용하는 주소당 속도로 나눈 것이 대략 필요한 분산이다.
유지되는 신원이 필요한 동시 흐름은 몇 개인가. 그것이 스티키 세션 수이며, 입에 올릴 가치가 있는 유일한 숫자다.
어떤 국가와 도시가 필요하며, 풀은 전체적으로 크기만 한 것이 아니라 그곳에서 조밀한가.
데이터를 얼마나 옮길 것인가. 그것이 비용을 결정하는 숫자다.
헤드라인 수치를 믿는 대신 자신의 워크로드에서 성공률을 측정했는가.

결론

“IP가 몇 개 필요한가”는 더 이상 적용되지 않는 과금 모델에서 물려받은 질문이다. 대역폭으로 과금되는 현대의 레지덴셜 네트워크에서는 주소의 개수를 사는 것이 아니라 풀에 대한 접근을 사고 그것을 통해 옮긴 데이터에 대해 지불한다. 따라서 설계해야 할 대상은 분산이다. 어떤 단일 타깃도 어느 한 주소로부터 평범한 수준 이상의 트래픽을 보지 않을 만큼 충분히 펼치는 것. 물량은 로테이션으로 처리하고, 세는 것은 동시 스티키 세션만으로 하며, 네트워크는 실제로 수집하는 시장에서의 밀도와 자신의 워크로드에서 나오는 성공률로 판단하고, 예산은 주소가 아니라 대역폭으로 산정하라. 분산만 제대로 잡으면 IP 개수는 더 이상 고민할 대상이 아니게 된다.

바로 그것을 제공하도록 만들어진 것이 레지덴셜 프록시다. 국가 및 도시 타기팅, 기본 로테이션, 그리고 필요한 흐름을 위한 스티키 세션을 갖춘 실제 가정용 IP의 대규모 풀이다. 계획의 기준으로 삼을 만한 숫자는 GB 단위 요금이다. 충분하기를 바라는 주소 수량이 아니라 실제로 가져온 데이터에 대해 지불하기 때문이다.