대부분의 스크래핑 시스템이 도달하는 아키텍처는 클라우드 제공업체 내의 컨테이너로, 큐 깊이에 따라 확장되며, 상태를 갖지 않고 폐기 가능한 형태입니다. 이는 컴퓨팅에는 올바른 설계입니다. 하지만 이그레스(egress)에는 최악의 설계인데, 그 컨테이너들이 받는 주소가 방어 체계를 갖춘 사이트가 가장 먼저 확인하는 대상이기 때문입니다.
클라우드 제공업체의 IP 대역은 공개되어 있습니다. 누구나 이를 열거할 수 있고, 대부분의 안티봇 벤더들도 그렇게 합니다. 해당 대역에서 오는 트래픽은 그것이 무엇을 했는지 때문에 차단되는 것이 아니라, 첫 요청이 끝나기도 전에 어디서 왔는지에 따라 점수가 매겨집니다. 해결책은 워커를 더 늘리거나 헤더를 개선하는 것이 아닙니다. 코드가 실행되는 위치와 트래픽이 나가는 위치를 분리하는 것입니다.
이그레스 레이어는 별개의 관심사다
유용한 사고 모델은 워커는 컴퓨팅이고 주소는 아이덴티티이며, 이 둘은 독립적으로 확장되어야 한다는 것입니다.
일시적인 워커는 좋습니다: 50개를 시작하고, 큐를 끝내고, 멈춥니다. 하지만 일시적인 아이덴티티는 대개 나쁩니다: 새로운 클라우드 주소에서 도착하는 새 워커마다 낯선 트래픽의 흐름이 됩니다. 원하는 것은 워커 세대가 바뀌어도 지속되는 안정적인 출구 주소 집합입니다. 그래야 오토스케일러가 반응할 때마다 대상이 보는 아이덴티티가 바뀌지 않습니다.
ISP 프록시는 바로 고정되어 있다는 점 때문에 이 역할에 적합합니다. 각 주소는 플랜 기간 동안 귀하의 계정에 전용으로 할당되며, 클라우드 블록이 아닌 실제 ISP에 등록되어 있고, 로테이션되지 않습니다. 워커는 오고 가지만, 주소는 그렇지 않습니다.
두 가지 인증 방식, 그리고 그 선택은 아키텍처의 문제다
플랜 내 모든 주소는 동일한 포트(1337)를 사용하며, 인증 방법은 두 가지입니다. 클라우드 배포 환경에서 이는 선호의 문제가 아니라, 네트워킹 구조에서 따라 나오는 결과입니다.
인증된 소스 IP. 패널에서 인프라의 퍼블릭 주소를 화이트리스트에 등록하고 자격 증명 없이 연결합니다:
185.199.108.153:1337이는 이그레스가 예측 가능한 경우, 즉 실질적으로 워커들 앞에 안정적인 주소를 가진 NAT 게이트웨이 또는 그에 상응하는 것이 있는 경우에 작동합니다. 적용 가능한 경우 이는 더 깔끔한 선택인데, 컨테이너 안에 자격 증명이 전혀 존재하지 않기 때문입니다.
사용자명과 비밀번호. 어디서든 작동하며, 화이트리스트가 필요 없습니다:
185.199.108.153:1337:USERNAME:PASSWORD워커가 변화하는 주소에 걸쳐 진정으로 일시적이거나, 여러 리전에 분산되어 있거나, 아웃바운드 주소를 제어할 수 없는 환경에서 실행될 때 이 방식이 필요합니다. 서버리스 함수와 멀티 리전 배포가 여기에 해당합니다.
흔한 함정은 소스 주소가 실제로는 고정되어 있지 않은 환경에서 소스 IP 인증을 선택하는 것입니다. 테스트할 때는 하나의 서브넷에서 작동하지만, 프로덕션에서는 플랫폼이 다른 곳에 할당하면서 간헐적으로 실패합니다. 이그레스 주소를 확신 있게 명시할 수 없다면, 자격 증명을 사용하세요.
워커 간 주소 분배
N개의 주소와 가변적인 수의 워커가 있으므로, 무언가가 하나를 다른 것에 할당해야 합니다.
효과적인 접근 방식은 주소 목록을 각 워커가 스스로 선택하게 하는 대신, 명시적인 리스(lease)를 갖는 공유 리소스로 취급하는 것입니다. 워커는 조정 레이어에서 주소를 가져와, 작업이 진행되는 동안 유지하고, 반환합니다. 두 가지 속성이 중요합니다: 두 워커가 동시에 하나의 주소를 사용하여 그 주소의 겉보기 요청률이 두 배가 되는 일이 없어야 하고, 워커의 크래시가 주소를 영구적으로 순환에서 제거하지 않아야 합니다.
워커 아이덴티티를 인덱스로 해싱하는 소박한 대안은 워커 수가 바뀌는 순간 깨지는데, 오토스케일 배포에서는 이것이 끊임없이 일어납니다. 스케일업 시 충돌이 발생하고 스케일다운 시 유휴 주소가 발생합니다.
여기서 실제 예산은 주소당 요청률입니다. ISP 플랜의 대역폭은 무제한이므로 제약은 기가바이트가 아니라, 하나의 고정 주소가 그럴듯하게 생성할 수 있는 트래픽의 양입니다. 이 수치가 배포에 필요한 주소 수를 결정하며, 데이터 볼륨이 아니라 처리량을 기준으로 사이즈를 산정하는 것이 올바른 방법인 이유입니다.
헬스 체크는 풀 안에 있어야 한다
주소는 균일하게 실패하지 않습니다. 하나가 특정 대상에서 챌린지를 받기 시작하는 동안 다른 모든 것은 괜찮을 수 있으며, 그 주소를 받은 워커는 누군가 알아차릴 때까지 쓸모없는 결과를 만들어냅니다.
집계된 값이 아니라 주소별로 결과를 추적하세요. 여러 대상에서 수집하는 경우 대상별로, 롤링 윈도우에 걸친 주소별 성공률을 보면 전체 풀을 빼지 않고 하나의 주소를 격리할 수 있습니다. 집계 지표는 5퍼센트 하락만 보여줄 뿐, 사실은 하나의 주소가 완전히 실패하고 있다는 사실을 숨깁니다.
격리는 임시적이고 자동적이어야 하며, 주소가 회복되면 이를 되돌리는 프로브가 있어야 합니다. 정상 상태가 무엇인지 처음에 확립하는 방법은 프록시 속도, 성공률, 위치 정확도 테스트하기에 있습니다.
구매 전에 지리적 분포를 계획하라
클라우드 팀을 곤란하게 만드는 한 가지 세부 사항: ISP 플랜에서는 주소가 프로비저닝되기 전에 국가 분포를 한 번 선택하며, 이후에는 변경할 수 없습니다. 7개국이 이용 가능합니다.
이는 클라우드 배포에서 흔히 접하는 대부분의 다른 것들과 다른데, 그런 것들에서는 마음을 저렴하게 바꾸는 데 익숙합니다. 실제로 수집하는 대상을 기준으로 분배를 결정하고, 두 시장 사이에서 확신이 없다면 추측하는 대신 확신이 있는 플랜을 구매하고 추가하세요.
ISP가 잘못된 도구인 경우
고정 주소는 로테이션의 일반적인 대체물이 아니며, 클라우드 인프라는 운영 모델이 훨씬 단순하기 때문에 그렇지 않은 것처럼 착각하게 만들기 쉽습니다.
워크로드가 많은 대상에 걸친 고볼륨 수집이라면, 주소당 요청률이 비용보다 훨씬 먼저 비현실적이 되고, 그 증상은 오류가 아니라 저하된 데이터로 나타납니다. 그 작업은 각 요청이 설계상 다른 주소에서 올 수 있는 로테이팅 레지덴셜 프록시에 속합니다. 그 트레이드오프는 ISP 프록시 대 데이터센터 및 레지덴셜에 설명되어 있습니다.
고정된 이그레스 레이어가 진정으로 옳은 워크로드는: 장기간 지속되는 세션, 인증이 필요한 모든 것, 귀하의 주소를 허용목록에 올리는 대상, 알려진 소스를 기대하는 파트너 API, 그리고 볼륨보다 일관성이 더 중요한 안정적인 수집입니다. 혼합 아키텍처는 흔하고 올바른 방식으로, 지속적인 작업에는 ISP 주소를, 대량 작업에는 로테이팅 게이트웨이를 사용합니다.
운영 노트
주소 목록은 이미지가 아니라 설정에 두세요. 풀을 변경하기 위해 컨테이너를 재구성하는 것은 피할 수 있는 일입니다. 시크릿 스토어나 설정 서비스에서 시작 시점에 읽어 오세요.
자격 증명이 포함된 URL을 로그에 남기지 마세요. 프록시 자격 증명이 로그 수집기로 흘러가는 가장 흔한 방식인데, 자연스러운 디버그 로그 라인이 전체 연결 문자열이기 때문입니다.
전역뿐 아니라 주소별로도 동시성을 제한하세요. 작은 풀에 불균등하게 분산된 전역 제한은 할당 로직이 선호하는 주소에 부하를 집중시킵니다. 관련된 메커니즘은 속도 제한 및 요청 스로틀링에 있습니다.
배포 환경 내부에서 테스트하세요. 노트북에서의 연결 확인은 자격 증명이 작동한다는 것만 증명합니다. 작업 정의가 환경 변수를 실제로 전달하는지에 대해서는 아무것도 증명하지 못하며, 대부분의 경우 실제 실패 원인은 바로 이것입니다.
FAQ
서버리스 함수에서 ISP 프록시를 사용할 수 있나요?
네, 자격 증명 인증을 사용하면 가능합니다. 소스 IP 화이트리스팅은 그 경우 실용적이지 않은데, 아웃바운드 주소가 고정할 수 있는 것이 아니기 때문입니다.
오토스케일 배포에는 몇 개의 주소가 필요한가요?
워커 수가 아니라 피크 동시 작업 수와 보수적인 주소당 요청률을 기준으로 사이즈를 산정하세요. 워커는 유휴 상태가 될 수 있지만, 피크에서 부족해지는 것이 주소가 되어서는 안 됩니다.
프록시 레이어가 병목이 되나요?
ISP 주소는 기가비트 속도의 데이터센터 인프라에서 실행되므로, 주소당 처리량이 제한 요소가 되는 경우는 거의 없습니다. 동시성 정책이 보통 먼저 제약을 걸게 됩니다.
각 서비스마다 별도의 주소를 가져야 하나요?
트래픽 패턴이 상당히 다르다면, 그렇습니다. 안정적인 저속 서비스와 버스트성 서비스를 동일한 주소에서 섞으면, 버스트성 서비스가 둘 다에 대한 처리 방식을 결정하게 됩니다.
결론
클라우드 스크래핑 인프라가 차단되는 이유는 코드의 품질과는 아무 관련이 없습니다: 주소가 클라우드 주소로 공개되어 있다는 것이 이유입니다. 일시적인 워커 앞에 고정된 ISP 이그레스 레이어를 두는 것은 아이덴티티를 컴퓨팅에서 분리하는 것이며, 이는 아키텍처가 원래부터 필요로 했던 분리입니다.
주소를 명시적으로 리스하고, 주소별로 상태를 추적하고, 대역폭이 아니라 요청률을 기준으로 사이즈를 산정하고, 지리적 분포는 구매 전에 결정하세요, 그 선택은 영구적이기 때문입니다. 플랜은 ISP 프록시 가격 페이지에 있습니다.