Dépôts GitLab : forte diminution des temps de sauvegarde

Les sauvegardes de dépôt sont un élément essentiel de toute stratégie de reprise après sinistre robuste. Cependant, à mesure que les dépôts grossissent, garantir des sauvegardes fiables devient de plus en plus difficile. Notre propre dépôt Rails mettait 48 heures à être sauvegardé, nous obligeant à faire des choix impossibles entre la fréquence des sauvegardes et les performances du système. Nous voulions résoudre ce problème pour nos clients ainsi que pour nos propres équipes internes.

Après investigation, la cause remontait à une fonction Git vieille de 15 ans, dont la complexité algorithmique O(N²) freinait lourdement les opérations. Nous l'avons corrigée en repensant l'algorithme, réduisant ainsi les temps de sauvegarde de manière exponentielle. Résultat : des coûts réduits, un risque diminué, et surtout, des stratégies de sauvegarde qui s'adaptent à la croissance de votre code source.

Il s'est avéré qu'il s'agissait d'un problème d'évolutivité de Git qui affecte tout utilisateur gérant de grands dépôts. Découvrez dans cet article comment nous l'avons identifié et résolu.

Sauvegarde à grande échelle : enjeux et solutions

À mesure que les entreprises développent leurs dépôts et que les sauvegardes se complexifient, elles sont confrontées aux défis suivants :

• Sauvegardes trop longues : pour les très grands dépôts, la sauvegarde peut prendre plusieurs heures, ce qui rend impossible la planification de sauvegardes régulières.
• Utilisation intensive des ressources : ces processus de sauvegarde prolongés mobilisent d'importantes ressources serveur, au risque d'impacter potentiellement d'autres opérations critiques.
• Fenêtres de sauvegarde : il peut être difficile de trouver des créneaux de maintenance adaptés à des processus aussi longs, en particulier pour les équipes fonctionnant 24 h/24 et 7 j/7.
• Risque accru d'échec : les longues sauvegardes sont plus exposées aux interruptions causées par des problèmes réseau, des redémarrages de serveur ou des erreurs système, obligeant souvent les équipes à reprendre tout le processus depuis le début.
• Conditions de concurrence : la durée allongée d'une sauvegarde augmente le risque que le dépôt ait beaucoup changé pendant le processus, conduisant à une sauvegarde invalide ou des interruptions liées à des objets devenus indisponibles.

Ces défis peuvent conduire à faire des compromis sur la fréquence ou l'exhaustivité des sauvegardes, ce qui est inacceptable en matière de protection des données. L'allongement des fenêtres de sauvegarde peut contraindre certains clients à adopter des solutions de contournement, comme adopter des outils externes ou réduire la fréquence des sauvegardes, ce qui fragilise les stratégies de protection des données au sein des entreprises en les rendant incohérentes.

Nous allons maintenant vous expliquer comment nous avons identifié ce goulot d'étranglement de performance, trouvé une solution et déployé une mesure corrective capable de réduire drastiquement les temps de sauvegarde.

Le défi technique

La fonctionnalité de sauvegarde des dépôts de GitLab repose sur la commande git bundle create, qui génère un instantané complet du dépôt, incluant tous les objets et références comme les branches et les tags. Ce paquet sert de point de restauration permettant de recréer le dépôt dans son état exact.

Cependant, l'implémentation de cette commande souffrait d'un problème d'évolutivité lié au nombre de références, créant un véritable goulot d'étranglement en termes de performance. À mesure que les dépôts accumulaient un nombre croissant de références, le temps de traitement des données augmentait de façon exponentielle. Dans nos plus grands dépôts, contenant des millions de références, les opérations de sauvegarde pouvaient dépasser les 48 heures.

Analyse des causes profondes

Pour identifier la cause profonde de ce ralentissement, nous avons analysé un flame graph de la commande pendant son exécution.

Ce graphique illustre le parcours d'exécution d'une commande à travers sa trace de piles d'appels, où chaque barre correspond à une fonction dans le code, et sa largeur indique le temps que la commande a passé à s'exécuter dans cette fonction spécifique.

Le flame graph de git bundle create exécuté sur un dépôt contenant 10 000 références révèle qu'environ 80 % du temps d'exécution est consommé par la fonction object_array_remove_duplicates(), introduite dans Git par le biais de la validation b2a6d1c686 (paquet : permettre à la même référence d'être spécifiée plusieurs fois, 17/01/2009).

Pour comprendre ce changement, il est important de savoir que git bundle create permet de spécifier les références à inclure dans le paquet et que, pour les paquets de dépôt complets, le flag --all compacte toutes les références.

Cette validation corrigeait un problème lié aux références dupliquées fournies via la ligne de commande, telles que git bundle create main.bundle main main, ce qui créait un paquet sans gérer correctement la duplication de la référence « main ». Lors de la décompression, Git tentait d'écrire la même référence deux fois provoquant une erreur. Le code ajouté pour éviter ces duplications utilise des boucles for imbriquées qui parcourent toutes les références afin de détecter les doublons. Cet algorithme de complexité O(N²) devient un goulot d'étranglement majeur en termes de performance dans les dépôts contenant un grand nombre de références, engendrant un temps de traitement des données très important.

La solution : d'O(N²) à un mappage efficace

Pour résoudre ce problème, nous avons proposé une correction en amont dans Git, remplaçant les boucles imbriquées par une structure de type map. Chaque référence y est ajoutée une seule fois, ce qui élimine automatiquement les doublons et optimise le traitement.

Ce changement améliore considérablement les performances de git bundle create et permet une bien meilleure évolutivité dans les dépôts contenant un grand nombre de références. Des tests de benchmark effectués sur un dépôt contenant 10 000 références montrent une amélioration des performances par un facteur de 6.

Benchmark 1: bundle (refcount = 100000, revision = master)
  Time (mean ± σ): 	14.653 s ±  0.203 s	[User: 13.940 s, System: 0.762 s]
  Range (min … max):   14.237 s … 14.920 s	10 runs

Benchmark 2: bundle (refcount = 100000, revision = HEAD)
  Time (mean ± σ):  	2.394 s ±  0.023 s	[User: 1.684 s, System: 0.798 s]
  Range (min … max):	2.364 s …  2.425 s	10 runs

Summary
  bundle (refcount = 100000, revision = HEAD) ran
	6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)

Le correctif a été accepté et fusionné dans Git en amont. Chez GitLab, nous l'avons rétroporté afin que nos clients puissent en bénéficier immédiatement, sans attendre la prochaine version officielle de Git.

Résultat : des temps de sauvegarde radicalement réduits

Les gains de performance découlant de cette amélioration ont été tout simplement transformateurs :

• De 48 heures à 41 minutes : la sauvegarde de notre plus grand dépôt (gitlab-org/gitlab) ne prend désormais plus que 1,4 % du temps initial.
• Performances constantes : l'amélioration est stable et s'adapte efficacement, quelle que soit la taille du dépôt.
• Efficacité des ressources : la charge du serveur lors des opérations de sauvegarde a été fortement réduite.
• Applicabilité étendue : si le processus de sauvegardes est celui qui bénéficie le plus de cette amélioration, toutes les opérations basées sur des paquets traitant un grand nombre de références en profitent également.

Avantages pour nos clients GitLab

Pour les clients GitLab, cette amélioration apporte des bénéfices immédiats et concrets en matière de sauvegarde de leurs dépôts et de leur planification de reprise après sinistre :

• Des stratégies de sauvegarde transformées
  • Les équipes peuvent désormais planifier des sauvegardes complètes chaque nuit, sans impacter les workflows de développement ni nécessiter de longues fenêtres de maintenance.
  • Les sauvegardes s'exécutent désormais en arrière-plan, de manière fluide, pendant les créneaux nocturnes, sans nécessiter de processus longs ou dédiés.
• Continuité des activités améliorée
  • Avec des temps de sauvegarde réduits de plusieurs jours à quelques minutes, les objectifs de point de récupération (RPO) sont considérablement réduits ainsi que le risque métier : en cas de sinistre, ce sont potentiellement seulement quelques heures de travail qui sont perdues, au lieu de plusieurs jours.
• Réduction de la charge opérationnelle
  • La consommation de ressources serveur diminue, tout comme la durée des fenêtres de maintenance.
• Des sauvegardes plus rapides réduisent également les coûts de calcul, en particulier dans les environnements cloud où chaque minute de traitement des données se traduit directement en factures plus élevées.
• Une infrastructure pérenne
  • La croissance des dépôts ne contraint plus les entreprises à faire des choix difficiles entre la fréquence des sauvegardes et les performances du système.
• À mesure que votre code source se développe, votre stratégie de sauvegarde peut désormais évoluer.

Les entreprises peuvent à présent mettre en œuvre des stratégies de sauvegarde plus robustes sans compromettre les performances ou l'exhaustivité. Ce qui relevait autrefois d'un arbitrage difficile est devenu une pratique opérationnelle simple.

À partir de la version GitLab 18.0, tous les clients GitLab, quelle que soit leur version de licence, peuvent désormais profiter pleinement de ces améliorations pour leur stratégie de sauvegarde et l'exécution de leurs sauvegardes, sans aucune autre modification de la configuration.

Et après ?

Cette avancée s'inscrit dans notre engagement continu à proposer une infrastructure Git évolutive, adaptée aux exigences des entreprises. Bien que réduire le temps de sauvegarde de 48 heures à 41 minutes représente un jalon majeur, nous poursuivons nos efforts pour identifier et éliminer d'autres goulots d'étranglement dans l'ensemble de notre pile.

Nous sommes particulièrement fiers que cette amélioration ait été intégrée en amont dans le projet Git, bénéficiant ainsi non seulement aux utilisateurs de GitLab, mais aussi à l'ensemble de la communauté Git. Cette approche collaborative du développement garantit que les améliorations sont rigoureusement revues, largement testées et accessibles à tous.

Des travaux d'infrastructure en profondeur comme celui-ci illustrent notre approche de la performance chez GitLab. Participez à l'événement virtuel de lancement de GitLab 18 pour découvrir les autres améliorations fondamentales que nous proposons. Inscrivez-vous dès aujourd'hui !