Surcharge sur Git Kernel : l'infrastructure du noyau Linux face au moissonnage web

Le casse-tête de la génération d'URL avec cgit

L'infrastructure du noyau Linux héberge le dépôt principal linux.git — fort de 1,48 million de commits (validations de modifications de code) — ainsi que 922 forks (copies dérivées d'un dépôt). Si l'intégralité des données est disponible via la commande git clone, la majorité des robots d'indexation automatisés choisit d'aspirer le contenu page par page via cgit (l'interface web de consultation des dépôts Git). Cette méthode génère un volume gigantesque d'URL (adresses web) valides en sollicitant des diffs (comparaisons de code), des patchs ou des rendus HTML (langage de balisage web).

Sur un total de 90 cœurs CPU (unités centrales de traitement) répartis sur 5 nœuds géographiques, entre 14 et 16 cœurs sont constamment mobilisés à la seule tâche de générer du HTML pour ces robots. L'équipe d'administration système dresse un constat direct :

Nous dépensons plus de cycles CPU à générer des commits pour des aspirateurs de données que pour tous les autres types d'accès légitimes réunis, y compris les opérations git clone.

Du filtrage d'IP au Proof of Work avec Anubis

Pour contrecarrer ces accès, les administrateurs ont d'abord filtré les en-têtes User-Agent (chaînes d'identification envoyées par les navigateurs), puis banni les adresses IP (adresses d'identification réseau) et les numéros d'ASN (Autonomous System Number, identifiants des réseaux d'opérateurs d'hébergement). La riposte s'est rapidement complexifiée avec l'utilisation par les robots de réseaux de proxys résidentiels et mobiles alimentés par des SDK (kits de développement logiciel intégrés à des appareils grand public comme des téléviseurs), distribuant les requêtes sur des millions d'adresses distinctes.

Pour défendre le périmètre, l'infrastructure a déployé la solution Anubis. Elle s'appuie sur un mécanisme de Proof of Work (preuve de travail exigeant un calcul informatique) imposant au client de calculer une empreinte SHA-256 (fonction de hachage cryptographique) avec plusieurs zéros initiaux avant de lui accorder l'accès :

• 6 millions de requêtes quotidiennes ciblent des commits sur git.kernel.org.
• 66 % des requêtes sont immédiatement bloquées par le défi Anubis.
• 33 % des requêtes parviennent à résoudre le problème mathématique et franchissent le filtre.
• 2 % seulement du trafic total correspondrait à des accès légitimes de développeurs.

L'augmentation de la difficulté du défi au niveau 5 nécessite plusieurs secondes de calcul sur un appareil mobile et provoque une chauffe du matériel, sans stopper pour autant les robots les plus tenaces.

Restriction des fonctionnalités et impact sur la CI

Outre les robots d'indexation, les systèmes de CI (intégration continue, automatisation des builds et des tests) mal configurés constituent la seconde source critique de contrainte sur l'infrastructure. C'est notamment le cas lors de l'exécution simultanée de shallow clones (clones superficiels récupérant un historique Git tronqué) sur le dépôt stable.git depuis de multiples nœuds. L'équipe rappelle qu'il est préférable d'héberger son propre miroir plutôt que d'exécuter ces opérations sur les serveurs centraux.

Face à cette situation, l'équipe d'infrastructure va désactiver progressivement plusieurs fonctionnalités de l'interface web pour réduire le nombre d'URL indexables et restreindre les traitements coûteux demandés par des utilisateurs anonymes. Le téléchargement des dépôts via l'outil Git reste garanti, mais la consultation web anonyme imposera désormais davantage de contraintes.