- Partage d’une expérience réelle d’exploration de 1 milliard de pages web en 24 heures et du processus de conception d’un système moderne de web crawling
- Grâce à du matériel récent et à une infrastructure cloud, un crawling à grande échelle a été réalisé pour quelques centaines de dollars, ce qui a permis de confirmer que le principal goulot d’étranglement était le parsing
- Sans exécuter JavaScript et en se limitant au parsing HTML, il a tout de même été possible d’accéder à une part importante des pages web
- Conception d’une architecture de cluster de nœuds basée sur Redis, avec sharding par domaine et optimisation de la structure des processus pour maximiser l’efficacité
- Plus que le réseau, ce sont le CPU, le SSL et la mémoire qui se sont révélés être les principaux goulots d’étranglement, la gestion de grandes frontiers de domaines étant l’enjeu central
Définition du problème
- Objectif fixé : crawler 1 milliard de pages web en 24 heures
- Le budget était de quelques centaines de dollars (environ 462 dollars au final), aligné sur un niveau comparable à un cas de 2012
- Collecte du HTML uniquement, sans exécution de JavaScript, avec extraction des seuls liens
<a>
- Importance accordée à la politesse du crawler : respect de robots.txt, inclusion d’informations dans le User Agent, exclusion de domaines sur demande, ciblage limité au million de domaines les plus populaires, attente de 70 secondes sur un même domaine, etc.
- Tolérance aux pannes prise en compte : redémarrage en cas de défaillance d’un nœud et acceptation d’une perte partielle de données, dans une approche fondée sur l’échantillonnage
Architecture et conception
- Contrairement au style classique des entretiens de conception système (répartition par fonctions), choix d’une structure où chaque nœud gère lui-même toutes les fonctions (état du crawl, parsing, fetch, stockage, etc.)
- 12 nœuds, chacun sur une instance
i7i.4xlarge (16 vCPU, 128 Go de RAM, 10 Gbit/s, 3750 Go de stockage)
- Chaque nœud se compose de 1 Redis, 9 fetchers et 6 processus de parsing
- Dans Redis sont stockés la frontier par domaine, la fetch queue, les URL visitées, le filtre de Bloom, robots.txt, la file de parsing, etc.
- Fetcher : récupération des URL depuis la file par domaine, fetch des URL avec 6000 à 7000 tâches simultanées via asyncio, le principal goulot d’étranglement étant le CPU
- Parser : 80 workers async, parsing HTML et extraction des liens, travail principalement centré sur le CPU
- Stockage : choix du stockage local de l’instance plutôt que S3, afin de réduire le coût de stockage des pages volumineuses
- Sharding : répartition des domaines entre les nœuds (sans communication croisée), avec ajustement du nombre de nœuds de sharding pour corriger les déséquilibres liés aux domaines populaires
Principales alternatives et expérimentations
- Expérimentation de plusieurs stockages, dont SQLite et PostgreSQL, Redis s’étant finalement montré supérieur en performances
- Une montée en charge verticale (une seule grosse instance) a aussi été testée, mais des goulots d’étranglement logiciels sont apparus ; le choix final s’est donc porté sur une montée en charge horizontale (plusieurs nœuds)
- Suppression de toute communication croisée entre les nœuds, avec traitement parallèle à l’intérieur de chaque nœud
Principales leçons tirées du crawling
Le parsing est le plus gros goulot d’étranglement
- La taille moyenne des pages a fortement augmenté par rapport au passé (51 Ko en moyenne en 2012 contre 242 Ko aujourd’hui, médiane à 138 Ko)
- Le passage de lxml à selectolax (basé sur Lexbor) a fortement amélioré la vitesse de parsing
- La troncature de la taille maximale des pages à 250 Ko a permis d’améliorer l’efficacité
- Au final, un parser unique a atteint 160 pages par seconde, et le ratio fetcher:parser a été ajusté à 9:6 pour traiter environ 950 pages par seconde
Fetching : ce qui est devenu plus simple et ce qui est plus difficile
- La bande passante réseau n’est au contraire pas le goulot d’étranglement (seulement environ 8 Gbit/s utilisés sur 25 Gbit/s par nœud)
- Le goulot d’étranglement DNS n’a pas non plus posé problème grâce au ciblage des seuls domaines populaires
- En revanche, la négociation SSL représente 25 % de l’utilisation CPU et s’est imposée comme l’un des plus gros goulots d’étranglement
- Comme la majorité des pages est passée en HTTPS, le coût CPU a augmenté
Exécution réelle du crawl et problèmes rencontrés
- Les premières expérimentations n’ont duré que quelques heures sur un seul nœud (
i7i.2xlarge), avant que le crawl principal ne soit étendu à 12 nœuds
- Apparition de problèmes de mémoire : la frontier de domaines populaires (URL non visitées) montait à plusieurs dizaines de Go, provoquant des pannes répétées des nœuds
- Des domaines populaires (par exemple yahoo.com, wikipedia.org) ou des sites avec un nombre anormalement élevé de liens ont causé ces problèmes
- Les domaines problématiques ont été exclus manuellement, et en cas de panne les nœuds ont été relancés avec troncature de la frontier pour restaurer le système
Comparaison entre théorie et pratique
- Comparé à l’estimation plus académique de « 10 milliards de pages en 5 jours avec 5 machines », les chiffres réels s’en rapprochent dans une certaine mesure
- En tenant compte des taux réels d’utilisation réseau et CPU de chaque nœud, un débit encore supérieur reste possible selon le niveau d’optimisation
Perspectives et réflexions
- Il est à nouveau confirmé qu’avec le parsing HTML seul, il reste possible d’accéder à une part importante du web ; en revanche, sur de grandes plateformes (comme GitHub), le contenu utile est inclus dans le JS et ne peut donc pas être parsé
- Parmi les chantiers à venir : explorer le coût et les méthodes du crawling à grande échelle basé sur le rendu JS
- L’analyse des données (métadonnées des pages réellement collectées, ratio de pages actives/inactives, etc.) est également citée comme sujet de suivi
- Récemment, le crawling agressif combiné à l’IA s’est multiplié, tandis que de nouveaux mécanismes de défense comme le pay-per-crawl de Cloudflare apparaissent, signe que l’environnement du web crawling est de nouveau en pleine évolution
3 commentaires
Impressionnant... bravo bravo...
C’est intéressant. Merci, j’ai bien lu.
Impressionnant… Une guerre entre la lance et le bouclier, haha ?