A arquitetura para a qual a maioria dos sistemas de scraping converge é containers em um provedor de nuvem, escalados por profundidade de fila, sem estado e descartáveis. É o design certo para o processamento. É o pior design possível para o egress, porque os endereços que esses containers recebem são a primeira coisa que um site com defesas verifica.
Os intervalos de provedores de nuvem são publicados. Qualquer pessoa pode enumerá-los, e a maioria dos fornecedores de anti-bot faz isso. O tráfego proveniente deles não é bloqueado pelo que fez, mas avaliado pela origem antes mesmo de a primeira requisição terminar. A correção não é mais workers ou headers melhores. É separar onde o código roda de onde o tráfego sai.
A camada de egress é uma preocupação separada
O modelo mental útil é que seus workers são processamento e seus endereços são identidade, e eles devem escalar de forma independente.
Workers efêmeros são bons: inicie cinquenta, termine a fila, pare. Identidades efêmeras geralmente são ruins: cada novo worker chegando de um novo endereço de nuvem é um fluxo de tráfego desconhecido. O que você quer é um conjunto estável de endereços de saída que persista entre gerações de workers, para que a identidade que seus alvos veem não mude toda vez que seu autoscaler reage.
Os proxies ISP, também conhecidos como proxies residenciais estáticos, se encaixam nesse papel. Cada proxy permanece na cidade e no ISP que você escolher durante todo o período de cobrança, registrado em um ISP real em vez de um bloco de nuvem, e mesmo que o IP seja atualizado, ele permanece naquela cidade e ISP. Seus workers vêm e vão; os proxies permanecem onde você os colocou.
A autenticação funciona de qualquer lugar
Cada proxy tem seu próprio nome de usuário e todos se conectam através de um único host, isp.shifter.io, na porta 443, então seus workers não precisam de um endereço de saída fixo:
isp.shifter.io:443:USERNAME:PASSWORDIsso é o que você quer quando os workers são genuinamente efêmeros em endereços variáveis, ou distribuídos por regiões, ou executando em um ambiente onde você não controla o endereço de saída. Funções serverless e implantações multirregionais funcionam da mesma forma que um único servidor.
Distribuindo endereços entre workers
Você tem N endereços e um número variável de workers, então algo precisa atribuir um ao outro.
A abordagem que se sustenta é tratar a lista de endereços como um recurso compartilhado com locações explícitas, em vez de deixar cada worker escolher. Um worker retira um endereço de uma camada de coordenação, o mantém durante a duração do seu trabalho e o devolve. Duas propriedades importam: dois workers nunca usam um endereço simultaneamente de forma que dobre sua taxa aparente de requisições, e uma falha de worker não remove permanentemente um endereço de circulação.
A alternativa ingênua, fazer hash da identidade do worker para um índice, quebra no momento em que o número de workers muda, o que em uma implantação com autoscaling é constante. Você obtém colisões durante o scale-up e endereços ociosos durante o scale-down.
A taxa de requisições por endereço é o orçamento real aqui. A largura de banda em planos ISP é ilimitada, então a restrição não é gigabytes, é quanto tráfego um proxy pode plausivelmente produzir. Esse número é o que determina quantos endereços sua implantação precisa, e é por isso que dimensionar por vazão em vez de volume de dados é o exercício correto.
Verificações de saúde pertencem ao pool
Os endereços não falham de forma uniforme. Um pode começar a receber desafios de um alvo específico enquanto tudo o mais está bem, e um worker que receber esse endereço vai produzir lixo até que algo perceba.
Acompanhe os resultados por endereço, não de forma agregada. Uma taxa de sucesso por endereço em uma janela deslizante, por alvo se você coleta de vários, dá a você a capacidade de colocar um único endereço em quarentena sem retirar o pool todo. Métricas agregadas vão mostrar uma queda de cinco por cento e ocultar o fato de que é um endereço falhando completamente.
A quarentena deve ser temporária e automática, com uma sondagem que devolve o endereço quando ele se recupera. O método para estabelecer o que é considerado normal em primeiro lugar está em testando velocidade, taxa de sucesso e precisão de localização de proxy.
Planeje a geografia antes de comprar
Um detalhe que ajuda equipes de nuvem: com os proxies ISP da Shifter, você escolhe a cidade e o ISP para cada proxy depois de comprar, em 120 países.
Cada proxy então permanece naquela cidade e ISP durante o período de cobrança, então decida a divisão com base nos alvos dos quais você de fato está coletando, em vez de alterá-la a cada implantação.
Quando ISP é a ferramenta errada
Proxies residenciais estáticos não são um substituto geral para rotação, e a infraestrutura em nuvem torna tentador fingir o contrário porque o modelo operacional é muito mais simples.
Se sua carga de trabalho é coleta de alto volume em muitos alvos, a taxa de requisições por endereço se torna implausível muito antes do custo, e o sintoma é dados degradados em vez de erros. Esse trabalho pertence a proxies residenciais rotativos, onde cada requisição pode vir de um endereço diferente por design. A troca está explicada em proxies ISP vs datacenter e residencial.
As cargas de trabalho para as quais uma camada de egress estável é genuinamente adequada: sessões de longa duração, qualquer coisa autenticada, e coleta constante onde consistência importa mais que volume. A arquitetura mista é comum e correta, com endereços ISP para o trabalho persistente e um gateway rotativo para o volume.
Notas operacionais
Mantenha a lista de endereços em configuração, não em imagens. Reconstruir containers para alterar o pool é evitável. Leia-a na inicialização a partir do seu armazenamento de segredos ou serviço de configuração.
Não registre a URL com credenciais em log. É a forma mais comum de as credenciais de proxy chegarem a um agregador de logs, porque a linha natural de debug é a string de conexão completa.
Limite a concorrência por endereço, não só globalmente. Um limite global distribuído de forma desigual em um pool pequeno concentra a carga em quaisquer endereços que a sua lógica de atribuição favoreça. A mecânica relevante está em limitação de taxa e throttling de requisições.
Teste de dentro da implantação. Uma verificação de conectividade de um laptop prova que suas credenciais funcionam. Não prova nada sobre se a definição da sua tarefa passa as variáveis de ambiente corretamente, o que é a falha real na maioria das vezes.
FAQ
Posso usar proxies ISP a partir de funções serverless?
Sim. As credenciais funcionam de qualquer lugar, então o endereço de saída variável de uma função não é um problema.
Quantos endereços uma implantação com autoscaling precisa?
Dimensione pelo pico de jobs concorrentes e por uma taxa de requisições por endereço conservadora, não pelo número de workers. Workers ficam ociosos; os endereços não devem ser o que falta no pico.
A camada de proxy se torna um gargalo?
Proxies ISP rodam em infraestrutura gerenciada com tráfego ilimitado, então a vazão por proxy raramente é o limite. A política de concorrência geralmente restringe primeiro.
Cada serviço deve receber seus próprios endereços?
Se os padrões de tráfego deles diferem substancialmente, sim. Misturar um serviço constante de baixa taxa com um em rajadas no mesmo endereço significa que o em rajadas determina como ambos são tratados.
Conclusão
A infraestrutura de scraping em nuvem é bloqueada por uma razão que não tem nada a ver com a qualidade do código: os endereços são publicados como endereços de nuvem. Colocar uma camada estável de egress ISP na frente de workers efêmeros separa identidade de processamento, que é a separação de que a arquitetura precisava de qualquer forma.
Aloque endereços explicitamente, acompanhe a saúde por endereço, dimensione pela taxa de requisições em vez de largura de banda, e decida a geografia de propósito, de acordo com os alvos dos quais você realmente coleta. Os planos estão na página de preços de proxies ISP.