Construction d'une archive Web à l'échelle du pétaoctet

Dans le monde idéal d'un ingénieur, l'architecture est toujours belle. Dans le monde réel des systèmes à grande échelle, il faut faire des compromis. L'un des problèmes fondamentaux qu'un ingénieur doit considérer dès le départ est le vicieux compromis entre la vitesse d'écriture et la vitesse de lecture.

Habituellement, on sacrifie l'un pour l'autre. Mais dans notre cas, en travaillant avec des pétaoctets de données dans AWS, ce compromis n'a pas affecté notre vitesse – il a affecté notre portefeuille.

Nous avons construit un système qui écrivait parfaitement les données, mais chaque fois qu'il lisait depuis l'archive, il épuisait le budget de la manière la plus douloureuse imaginable. Après tout, lire des pétaoctets depuis AWS coûte de l'argent pour le transfert de données, le nombre de requêtes et les récupérations de classe de stockage... Beaucoup d'argent !

Voici l'histoire de comment nous l'avons optimisé pour le rendre plus efficace et rentable !

Partie 0 : Comment nous avons fini par dépenser 100 000 $ en frais AWS !

Histoire vraie : il y a quelques mois, l'un de nos architectes de solutions voulait extraire un échantillon d'exportation d'un site web rare à faible trafic pour démontrer le produit à un client potentiel. En raison d'un bug dans l'API, la limite de sécurité sur le nombre de fichiers n'a pas été appliquée.

Comme les données de ce site "rare" étaient dispersées à travers des millions d'archives aux côtés de sites à fort trafic, le système a tenté de restaurer près de la moitié de notre stockage historique entier pour trouver ces quelques pages.

Cette erreur honnête a fini par nous coûter près de 100 000 $ en frais AWS !

J'ai immédiatement corrigé le bug de l'API (et ajouté des limites strictes), mais la vulnérabilité architecturale est restée. C'était une bombe à retardement...

Laissez-moi vous raconter l'histoire de l'architecture Web Archive de Bright Data : comment j'ai conduit le système dans le piège du stockage "bon marché" et comment j'en suis sorti en utilisant un Pipeline de Réarrangement.

Partie 1 : L'héritage "Écriture d'abord"

Quand j'ai commencé à travailler sur le Web Archive, le système ingérait déjà un flux de données massif : des millions de requêtes par minute, des dizaines de téraoctets par jour. L'architecture fondamentale a été construite avec un objectif principal : tout capturer sans perte de données.

Elle s'appuyait sur la stratégie la plus durable pour les systèmes à haut débit : Journal en mode append-only.

1. Les données (HTML, JSON) sont mises en mémoire tampon.
2. Une fois que le tampon atteint ~300 Mo, il est "scellé" dans une archive TAR.
3. L'archive s'envole vers S3.
4. Après 3 jours, les fichiers sont déplacés vers S3 Glacier Deep Archive.

Pour la phase d'ingestion, cette conception était parfaite. Stocker des données dans Deep Archive coûte des centimes, et le débit d'écriture est pratiquement illimité.

Le problème : cette nuance de tarification

L'architecture fonctionnait parfaitement pour l'écriture... jusqu'à ce que les clients demandent des données historiques. C'est là que j'ai fait face à une contradiction fondamentale :

• Le système écrit par temps : Une archive de 12h00 contient un mélange de cnn.com, google.com, et shop.xyz.
• Le système lit par domaine : Le client demande : "Donnez-moi toutes les pages de cnn.com pour l'année dernière."

C'est là que réside l'erreur qui a inspiré cet article. Comme beaucoup d'ingénieurs, j'ai l'habitude de penser en termes de latence, IOPS et débit. Mais j'ai négligé le modèle de facturation AWS Glacier.

Je pensais : "Eh bien, récupérer quelques milliers d'archives est lent (48 heures), mais ce n'est pas si cher."

La réalité : AWS facture non seulement l'appel API, mais aussi le volume de données restaurées ($ par Go récupéré).

L'effet "Octet d'or"

Imaginez qu'un client demande 1 000 pages d'un seul domaine. Comme la logique d'écriture était chronologique, ces pages peuvent être réparties sur 1 000 archives TAR différentes.

Pour donner au client ces 50 Mo de données utiles, un désastre se produit :

1. Le système doit déclencher une restauration pour 1 000 archives.
2. Il extrait 300 Go de données du "congélateur" (1 000 archives × 300 Mo).
3. AWS nous facture pour la restauration de 300 Go.
4. J'extrais les 50 Mo requis et je jette les 299,95 Go restants 🤯.

Nous payions pour restaurer des téraoctets de déchets juste pour extraire des grains d'or. C'était un problème classique de localité des données qui s'est transformé en trou noir financier.

Partie 2 : Corriger l'erreur : le Pipeline de Réarrangement

Je ne pouvais pas changer rapidement la méthode d'ingestion – le flux entrant est trop parallèle et massif pour être trié "à la volée" (bien que j'y travaille), et j'avais besoin d'une solution qui fonctionnerait aussi pour les données déjà archivées.

J'ai donc conçu le Pipeline de Réarrangement, un processus en arrière-plan qui "défragmente" l'archive.

C'est un processus ETL (Extract, Transform, Load) asynchrone, avec plusieurs composants essentiels :

1. Sélection : Il n'est pas logique de trier des données que les clients ne demandent pas. Ainsi, je dirige toutes les nouvelles données dans le pipeline, ainsi que les données que les clients ont spécifiquement demandé à restaurer. Nous surpayons pour la récupération la première fois, mais cela ne se produit jamais une seconde fois.

   \

2. Brassage (Regroupement) : Plusieurs workers téléchargent des fichiers non triés en parallèle et organisent les tampons par domaine. Comme le système est asynchrone, je ne m'inquiète pas que le flux entrant surcharge la mémoire. Les workers gèrent la charge à leur propre rythme.

   \

3. Réécriture : J'écris les fichiers triés dans S3 sous un nouveau préfixe (pour distinguer les fichiers triés des bruts).

• Avant : 2024/05/05/random_id_ts.tar → [cnn, google, zara, cnn]
• Après : 2024/05/05/cnn/random_id_ts.tar → [cnn, cnn, cnn...]

1. Échange de métadonnées : Dans Snowflake, la table de métadonnées est en mode append-only. Faire un MERGE INTO ou UPDATE est prohibitivement coûteux.

• La solution : J'ai découvert qu'il était beaucoup plus efficace de prendre tous les enregistrements pour un jour spécifique, de les écrire dans une table séparée en utilisant un JOIN, de supprimer les enregistrements du jour original, et d'insérer le jour entier avec les enregistrements modifiés. J'ai réussi à traiter plus de 300 jours et plus de 160 milliards d'opérations UPDATE en quelques heures sur un entrepôt Snowflake 4X-Large.

Le résultat

Ce changement a radicalement modifié l'économie du produit :

• Précision chirurgicale : Maintenant, quand un client demande cnn.com, le système ne restaure que les données où cnn.com réside.
• Efficacité : Selon la granularité de la demande (domaine entier vs URLs spécifiques via regex), j'ai obtenu une réduction de 10% à 80% dans la récupération de "données poubelles" (ce qui est directement proportionnel au coût).
• Nouvelles capacités : Au-delà de simplement économiser de l'argent sur les extractions, cela a débloqué des cas d'utilisation commerciaux entièrement nouveaux. Comme la récupération de données historiques n'est plus douloureusement coûteuse, nous pouvons maintenant nous permettre d'extraire des ensembles de données massifs pour l'entraînement de modèles d'IA, la conduite d'études de marché à long terme, et la construction de bases de connaissances pour que les systèmes d'IA agentiques puissent raisonner dessus (pensez aux moteurs de recherche spécialisés). Ce qui était auparavant une mission suicide financière est maintenant une opération standard.

Nous recrutons

Bright Data développe encore davantage le Web Archive. Si vous aimez :

• Les systèmes distribués à haut débit,
• L'ingénierie des données à grande échelle,
• La construction de pipelines fiables sous charge réelle,
• Pousser Node.js à ses limites absolues,
• Résoudre des problèmes qui n'apparaissent pas dans les manuels…

Alors j'aimerais discuter avec vous.

Nous recrutons des ingénieurs Node.js expérimentés pour aider à construire la prochaine génération du Web Archive. Avoir de l'expérience en ingénierie de données et ETL est hautement avantageux. N'hésitez pas à envoyer votre CV à vadimr@brightdata.com.

Plus de mises à jour à venir alors que je continue à faire évoluer l'archive — et que je continue à trouver de nouvelles façons créatives de la casser !

\