L’architecture vers laquelle convergent la plupart des systèmes de scraping est celle de conteneurs chez un fournisseur cloud, mis à l’échelle selon la profondeur de la file d’attente, sans état et jetables. C’est la bonne conception pour le calcul. C’est la pire conception possible pour la sortie, car les adresses que ces conteneurs obtiennent sont la première chose qu’un site défendu vérifie.
Les plages des fournisseurs cloud sont publiées. N’importe qui peut les énumérer, et c’est ce que font la plupart des fournisseurs anti-bot. Le trafic qui en provient n’est pas bloqué à cause de ce qu’il a fait, il est noté selon son origine avant même que la première requête ne se termine. La solution n’est pas d’avoir plus de workers ou de meilleurs en-têtes. C’est de séparer l’endroit où le code s’exécute de l’endroit où le trafic sort.
La couche de sortie est un problème distinct
Le modèle mental utile est que vos workers sont du calcul et vos adresses sont de l’identité, et ces deux éléments devraient évoluer indépendamment.
Les workers éphémères sont une bonne chose : en démarrer cinquante, terminer la file d’attente, s’arrêter. Les identités éphémères sont généralement mauvaises : chaque nouveau worker arrivant depuis une nouvelle adresse cloud constitue un flux de trafic inconnu. Ce que vous voulez, c’est un ensemble stable d’adresses de sortie qui persiste à travers les générations de workers, de sorte que l’identité vue par vos cibles ne change pas à chaque fois que votre autoscaler réagit.
Les proxies ISP, aussi appelés proxies résidentiels statiques, conviennent à ce rôle. Chaque proxy reste sur la ville et le FAI que vous choisissez pour toute la période de facturation, enregistré auprès d’un véritable FAI plutôt que d’un bloc cloud, et même si l’IP se renouvelle, elle reste sur cette même ville et ce même FAI. Vos workers vont et viennent ; les proxies, eux, restent là où vous les avez placés.
L’authentification fonctionne depuis n’importe où
Chaque proxy possède son propre nom d’utilisateur et ils se connectent tous via un même hôte, isp.shifter.io, sur le port 443, de sorte que vos workers n’ont besoin d’aucune adresse sortante fixe :
isp.shifter.io:443:USERNAME:PASSWORDC’est ce qu’il vous faut lorsque les workers sont réellement éphémères sur des adresses changeantes, ou répartis sur plusieurs régions, ou s’exécutent dans un environnement où vous ne contrôlez pas l’adresse sortante. Les fonctions serverless et les déploiements multi-régions fonctionnent de la même manière qu’un serveur unique.
Distribuer les adresses entre les workers
Vous avez N adresses et un nombre variable de workers, donc quelque chose doit assigner l’une à l’autre.
L’approche qui tient est de traiter la liste d’adresses comme une ressource partagée avec des baux explicites plutôt que de laisser chaque worker choisir. Un worker prend une adresse depuis une couche de coordination, la conserve pour la durée de sa tâche, puis la restitue. Deux propriétés comptent : deux workers n’utilisent jamais une même adresse simultanément d’une manière qui doublerait son taux de requêtes apparent, et le crash d’un worker ne retire pas définitivement une adresse de la circulation.
L’alternative naïve, qui consiste à hacher l’identité du worker vers un index, se brise dès que le nombre de workers change, ce qui pour un déploiement à mise à l’échelle automatique est constant. Vous obtenez des collisions lors de la montée en charge et des adresses inactives lors de la descente.
Le taux de requêtes par adresse est le véritable budget ici. La bande passante des plans ISP est illimitée, donc la contrainte n’est pas en gigaoctets, c’est combien de trafic un proxy peut plausiblement produire. Ce chiffre détermine le nombre d’adresses dont votre déploiement a besoin, et c’est pourquoi dimensionner selon le débit plutôt que selon le volume de données est le bon exercice.
Les contrôles de santé ont leur place dans le pool
Les adresses ne tombent pas en panne de manière uniforme. L’une peut commencer à recevoir des challenges d’une cible spécifique alors que tout le reste va bien, et un worker qui reçoit cette adresse produira des données inutilisables jusqu’à ce que quelque chose s’en aperçoive.
Suivez les résultats par adresse plutôt qu’en agrégat. Un taux de réussite par adresse sur une fenêtre glissante, par cible si vous collectez depuis plusieurs, vous donne la capacité de mettre une adresse en quarantaine sans retirer tout le pool. Les métriques agrégées vous montreront une baisse de cinq pour cent et masqueront le fait qu’il s’agit d’une adresse en échec complet.
La quarantaine doit être temporaire et automatique, avec une sonde qui réintègre l’adresse lorsqu’elle se rétablit. La méthode pour établir ce à quoi ressemble la normale en premier lieu se trouve dans tester la vitesse, le taux de réussite et la précision de localisation d’un proxy.
Planifiez la géographie avant d’acheter
Un détail qui aide les équipes cloud : avec les proxies ISP de Shifter, vous choisissez la ville et le FAI pour chaque proxy après l’achat, dans 120 pays.
Chaque proxy reste ensuite sur cette ville et ce FAI pour toute la période de facturation, décidez donc de la répartition en fonction des cibles depuis lesquelles vous collectez réellement plutôt que de la changer à chaque déploiement.
Quand ISP est le mauvais outil
Les proxies résidentiels statiques ne sont pas un remplacement général de la rotation, et l’infrastructure cloud rend tentant de prétendre le contraire car le modèle opérationnel est tellement plus simple.
Si votre charge de travail est une collecte à haut volume sur de nombreuses cibles, le taux de requêtes par adresse devient irréaliste bien avant que le coût ne le devienne, et le symptôme est une dégradation des données plutôt que des erreurs. Ce travail relève des proxies résidentiels rotatifs, où chaque requête peut provenir d’une adresse différente par conception. Le compromis est exposé dans proxies ISP vs datacenter et résidentiel.
Les charges de travail pour lesquelles une couche de sortie stable est réellement adaptée : les sessions de longue durée, tout ce qui est authentifié, et la collecte régulière où la cohérence importe plus que le volume. L’architecture mixte est courante et pertinente, avec des adresses ISP pour le travail persistant et une passerelle rotative pour le volume.
Notes opérationnelles
Gardez la liste d’adresses dans la configuration, pas dans les images. Reconstruire des conteneurs pour changer le pool est évitable. Lisez-la au démarrage depuis votre gestionnaire de secrets ou votre service de configuration.
Ne journalisez pas l’URL avec identifiants. C’est la façon la plus courante dont les identifiants de proxy finissent dans un agrégateur de logs, car la ligne de débogage naturelle est la chaîne de connexion complète.
Limitez la concurrence par adresse, pas seulement globalement. Une limite globale répartie de manière inégale sur un petit pool concentre la charge sur les adresses que votre logique d’attribution favorise. Les mécanismes pertinents se trouvent dans limitation de débit et régulation des requêtes.
Testez depuis l’intérieur du déploiement. Un test de connectivité depuis un ordinateur portable prouve que vos identifiants fonctionnent. Il ne prouve rien sur le fait que votre définition de tâche transmet correctement les variables d’environnement, ce qui est la cause réelle de l’échec la plupart du temps.
FAQ
Puis-je utiliser des proxies ISP depuis des fonctions serverless ?
Oui. Les identifiants fonctionnent depuis n’importe où, donc l’adresse sortante changeante d’une fonction n’est pas un problème.
De combien d’adresses un déploiement à mise à l’échelle automatique a-t-il besoin ?
Dimensionnez selon le pic de tâches simultanées et un taux de requêtes par adresse prudent, pas selon le nombre de workers. Les workers peuvent être inactifs ; les adresses ne devraient pas être ce qui vient à manquer au pic.
La couche proxy devient-elle un goulot d’étranglement ?
Les proxies ISP fonctionnent sur une infrastructure gérée avec un trafic illimité, donc le débit par proxy est rarement la limite. La politique de concurrence est généralement le facteur limitant en premier.
Chaque service devrait-il avoir ses propres adresses ?
Si leurs profils de trafic diffèrent substantiellement, oui. Mélanger un service stable à faible débit avec un service en rafale sur la même adresse signifie que le service en rafale détermine comment les deux sont traités.
L’essentiel à retenir
L’infrastructure de scraping cloud se fait bloquer pour une raison qui n’a rien à voir avec la qualité du code : les adresses sont publiées en tant qu’adresses cloud. Placer une couche de sortie ISP stable devant des workers éphémères sépare l’identité du calcul, ce qui est la séparation dont l’architecture avait de toute façon besoin.
Attribuez les adresses explicitement par bail, suivez la santé par adresse, dimensionnez selon le taux de requêtes plutôt que la bande passante, et décidez la géographie délibérément, en fonction des cibles depuis lesquelles vous collectez réellement. Les plans sont disponibles sur la page de tarification des proxies ISP.