"몇 개의 동시 요청을 보낼 수 있나요?"라는 질문에는 단 하나의 숫자로 답할 수 없습니다. 이는 사용자의 풀 크기, 목표 허용치, 그리고 실제로 무엇을 최적화하느냐에 따라 달라지기 때문입니다. 추측하는 대신 다음과 같은 방식으로 생각해야 합니다.

사전에 고려하지 않는 풀 크기 계산법

만약 풀에 1,000개의 IPs가 있고 회전(rotation)을 사용하며 500개의 동시 스레드를 실행한다면, 실제로 1,000개 IP만큼의 분산을 얻는 것은 아닙니다. 몇 초 만에 풀의 거대한 부분을 소진하게 되어, 많은 요청이 방금 사용된 IP에 떨어지게 됩니다. 효과적인 분산은 단순히 풀 크기만으로 결정되는 것이 아니라 동시 스레드 대 풀 크기의 비율에 달려 있습니다.

대략적인 시작 규칙: 각 IP가 동일한 목표로 요청을 보내는 사이에 의미 있는 '휴식 시간'을 갖기를 원한다면, 동시 스레드를 활성 풀 크기의 약 5~10% 수준으로 유지하세요. 그보다 훨씬 높게 설정하면, 진정한 분산에 의존하는 것이 아니라 목표가 빠른 재사용을 감지하지 않도록 하는 것에 의존하게 됩니다.

목표별 허용치는 엄청나게 다릅니다

한 목표에게는 눈에 띄지 않는 동시성 수준이 다른 목표에서는 몇 분 만에 차단될 수 있습니다:

• 정적 콘텐츠, 낮은 보호: 높은 동시성이 허용되며, 목표는 IP당 요청 속도를 크게 추적하지 않습니다.
• 기본 속도 제한이 있는 검색/목록 페이지: 동시성보다 'IP당 분당 요청 횟수'가 더 중요합니다. 개별 IP가 목표의 IP당 임계값을 초과하지 않는 한 많은 스레드를 실행할 수 있습니다.
• 계정 기반 또는 공격적으로 지문 인식되는(fingerprinted) 목표: 전체 풀에 걸친 동시성보다 세션별 행동이 더 중요합니다. 이 경우 순수한 스레드 개수보다는 지속적인 세션(sticky sessions)과 인간의 속도에 맞춘 타이밍이 더 중요합니다.

위의 세 가지 범주 중 어느 것에 목표가 속하는지 고려하지 않고 고립적으로 동시성을 테스트하면, 다른 목표에는 전혀 적용되지 않는 수치를 얻게 됩니다.

최대 동시성으로 바로 점프하기보다 단계적으로 증가시키기(Ramping instead of jumping straight to max concurrency)

이론적인 최대 동시성(theoretical max concurrency)으로 새로운 대상을 시작하는 것은 이론적 최대치가 틀렸다는 것을 힘든 방식으로 알게 되는 방법입니다. 램프 패턴(ramp pattern)이 더 잘 작동합니다:

1. 낮은 동시성(5~10 스레드)에서 시작하여 의미 있는 샘플(수십 개가 아닌 수백 건의 요청) 동안 차단/실패율을 측정합니다.
2. 점진적으로 증가시키면서 각 단계마다 실패율을 재측정합니다.
3. 실패율이 기준선(baseline)보다 눈에 띄게 상승하기 시작하면 증가를 중단합니다. — 이것이 오늘날 이 특정 대상을 위한 실제 한계치입니다.

이 한계치는 영구적이지 않습니다. 대상은 시간이 지남에 따라 허용 오차(tolerance)가 변경됩니다 (때로는 사용자의 트래픽 패턴 때문에, 때로는 독립적으로). 따라서 처음에 찾은 숫자를 영원한 진실로 취급하기보다는 램프 테스트를 주기적으로 다시 실행할 가치가 있습니다.

IP당 동시성 대 풀(pool)당 동시성

이들은 서로 다른 수치이며, 이를 혼동하면 혼란을 야기합니다:

• IP당 동시성 (Concurrency per IP): 특정 IP 하나가 현재 처리하고 있는 동시 요청의 개수입니다. 대부분의 대상에 대해 이 값은 1이어야 합니다. 동일한 대상을 향해 여러 개의 동시 요청을 처리하는 IP는 일반 사용자 행동과는 거리가 멀어 보이기 때문입니다.
• 풀당 동시성 (Concurrency per pool): 전체 IP 풀에서 실행하고 있는 총 동시 요청의 개수입니다. 이는 훨씬 높을 수 있는데, 왜냐하면 각 IP가 정상적인 단일 사용자로 행동하는 여러 개의 다른 IP에 걸쳐 분산되기 때문입니다.

만약 높은 차단율이 관찰되는데 그 이유를 확신할 수 없다면, 요청 큐 로직에서 실수로 IP당 동시성(concurrency-per-IP)이 1을 초과했는지 확인해 보세요. 이는

이러한 풀 크기 조정 및 동시성 계획은 대규모 스크래핑 및 자동화용 프록시 인프라를 설계할 때 저희가 팀들을 돕는 바로 그 부분입니다. 만약 이와 같은 무언가를 현재 미세 조정(mid-tuning)하고 계신다면, 기꺼이 의견을 교환하겠습니다.