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 se encaixam nesse papel especificamente porque são fixos. Cada endereço é dedicado à sua conta durante toda a vigência do plano, registrado em um ISP real em vez de um bloco de nuvem, e não rotaciona. Seus workers vêm e vão; os endereços não.
Dois modos de autenticação, e a escolha é arquitetural
Todo endereço em um plano usa a mesma porta (1337), com duas formas de autenticação. Em uma implantação em nuvem, isso não é uma preferência, decorre da sua rede.
IP de origem autorizado. Você inclui o endereço público da sua infraestrutura na lista de permissões no painel e se conecta sem credenciais:
185.199.108.153:1337Isso funciona quando seu egress é previsível, o que na prática significa um gateway NAT ou equivalente com um endereço estável na frente dos seus workers. É a opção mais limpa quando se aplica, porque não há credenciais nos seus containers.
Nome de usuário e senha. Funciona de qualquer lugar, sem lista de permissões:
185.199.108.153:1337: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 se encaixam aqui.
A armadilha é escolher autenticação por IP de origem em um ambiente onde o endereço de origem não é de fato fixo. Funciona durante testes de uma sub-rede e depois falha intermitentemente em produção conforme a plataforma aloca em outro lugar. Se você não pode afirmar com confiança seu endereço de egress, use credenciais.
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 endereço fixo 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 pega equipes de nuvem de surpresa: em planos ISP, você escolhe a distribuição por país uma vez, antes de os endereços serem provisionados, e isso não pode ser alterado depois. Sete países estão disponíveis.
Isso é diferente de quase tudo o mais em uma implantação em nuvem, onde você está acostumado a mudar de ideia com baixo custo. Decida a divisão com base nos alvos dos quais você de fato está coletando, e se você estiver em dúvida entre dois mercados, compre o plano do qual tem certeza e adicione em vez de arriscar um palpite.
Quando ISP é a ferramenta errada
Endereços 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 fixa é genuinamente adequada: sessões de longa duração, qualquer coisa autenticada, alvos que colocam seus endereços em lista de permissões, APIs de parceiros que esperam uma origem conhecida, 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, com autenticação por credenciais. A inclusão de IP de origem em lista de permissões é impraticável nesse caso porque o endereço de saída não é seu para fixar.
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?
Endereços ISP rodam em infraestrutura de datacenter em velocidades de gigabit, então a vazão por endereço 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 fixa 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 antes de comprar, porque essa escolha é permanente. Os planos estão na página de preços de proxies ISP.