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 conviennent particulièrement à ce rôle car ils sont fixes. Chaque adresse est dédiée à votre compte pour toute la durée du plan, enregistrée auprès d’un véritable FAI plutôt que d’un bloc cloud, et ne tourne pas. Vos workers vont et viennent ; les adresses, elles, ne bougent pas.
Deux modes d’authentification, et le choix est architectural
Chaque adresse d’un plan utilise le même port (1337), avec deux façons de s’authentifier. Dans un déploiement cloud, ce n’est pas une préférence, cela découle de votre réseau.
IP source autorisée. Vous mettez sur liste blanche l’adresse publique de votre infrastructure dans le panneau et vous vous connectez sans identifiants :
185.199.108.153:1337Cela fonctionne lorsque votre sortie est prévisible, ce qui signifie en pratique une passerelle NAT ou équivalent avec une adresse stable devant vos workers. C’est l’option la plus propre lorsqu’elle s’applique, car il n’y a aucun identifiant dans vos conteneurs.
Nom d’utilisateur et mot de passe. Fonctionne depuis n’importe où, sans liste blanche :
185.199.108.153:1337: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 relèvent de ce cas.
Le piège consiste à choisir l’authentification par IP source dans un environnement où l’adresse source n’est en réalité pas fixe. Cela fonctionne pendant les tests depuis un sous-réseau puis échoue de manière intermittente en production à mesure que la plateforme alloue ailleurs. Si vous ne pouvez pas indiquer votre adresse de sortie avec certitude, utilisez des identifiants.
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 une adresse fixe 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 piège les équipes cloud : sur les plans ISP, vous choisissez la répartition par pays une seule fois, avant que les adresses soient provisionnées, et cela ne peut être modifié par la suite. Sept pays sont disponibles.
Ceci diffère de presque tout le reste dans un déploiement cloud, où vous avez l’habitude de changer d’avis à moindre coût. Décidez la répartition en fonction des cibles depuis lesquelles vous collectez réellement, et si vous hésitez entre deux marchés, achetez le plan dont vous êtes sûr et ajoutez plutôt que de deviner.
Quand ISP est le mauvais outil
Les adresses 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 fixe est réellement adaptée : les sessions de longue durée, tout ce qui est authentifié, les cibles qui mettent vos adresses sur liste blanche, les API partenaires qui attendent une source connue, 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, avec l’authentification par identifiants. La mise sur liste blanche par IP source est impraticable dans ce cas car l’adresse sortante n’est pas la vôtre à fixer.
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 adresses ISP fonctionnent sur une infrastructure datacenter à des vitesses gigabit, donc le débit par adresse 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 fixe 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 avant d’acheter, car ce choix est permanent. Les plans sont disponibles sur la page de tarification des proxies ISP.