Rejoignez-Nous sur

Comment nous avons optimisé CircleCI pour la vitesse et réduire nos temps de construction en…

0*Abs3wqhCgzwo0o5y

News

Comment nous avons optimisé CircleCI pour la vitesse et réduire nos temps de construction en…

Sam Rubin

Le réglage d’un serveur d’intégration continue présente un défi intéressant: les ingénieurs d’infrastructure doivent trouver un équilibre entre vitesse de construction, coûts et temps de file d’attente sur un système que de nombreux développeurs n’ont pas une longue expérience de la gestion à grande échelle. Les résultats, lorsqu'ils sont bien faits, peuvent constituer un avantage majeur pour votre entreprise, comme l'illustre le récent parcours entrepris pour améliorer la configuration de nos CI.

Au fur et à mesure de la croissance de Coinbase, la satisfaction de nos développeurs avec nos outils internes a été une priorité. Pour la majeure partie de l'histoire de Coinbase, nous avons utilisé Serveur CircleCI, qui a été un outil performant et nécessitant peu d’entretien. Toutefois, à mesure que la société et notre base de code se sont développées, les exigences imposées à notre serveur CI ont également augmenté. Avant les optimisations décrites ici, les constructions pour l’application monorail exécutée Coinbase.com avait considérablement augmenté en longueur (en doublant ou en triplant les temps de construction moyens précédents) et les développeurs se plaignaient généralement des constructions longues ou non finies.

Nos versions de CI ne répondaient plus à nos attentes et c’est avec les questions précédentes en tête que nous avons décidé de nous lancer dans une campagne visant à remettre notre configuration en forme.

Il est intéressant de noter ici que Coinbase utilise spécifiquement la version serveur CircleCI de CircleCI plutôt que son offre en nuage. L'hébergement de notre propre infrastructure nous importe pour des raisons de sécurité. Ces concepts s'appliquent spécifiquement aux clusters CI auto-gérés.

La première clé pour optimiser un système d’information de confiance est l’observabilité. En l’absence de moyen de mesurer les effets de vos modifications et ajustements, il est impossible de savoir vraiment si vous avez réellement apporté une amélioration. Dans notre cas, CircleCI hébergé sur le serveur utilise un cluster nomade pour les générations, et à ce moment-là n’a fourni aucune méthode pour surveiller votre cluster ou les nœuds qu’il contient. Nous devions construire nos propres systèmes et nous avons décidé qu’une bonne approche utiliserait le cadre de la quatre signaux d'or, Latence, Trafic, Erreurs, et Saturation.

Latence

La latence est le temps total nécessaire pour répondre à une demande. Dans un système CI, cela peut être considéré comme le temps total nécessaire à la compilation du début à la fin. La latence est mieux mesurée sur une base par rapport ou même par construction, car la longueur de construction peut varier énormément en fonction du projet.

Pour mesurer cela, nous avons construit une petite application qui a interrogé les fonctions de CircleCI. API régulièrement pour les longueurs de construction, puis expédié sur cette information à Datadog pour nous permettre de construire des graphiques et des visualisations des temps de construction moyens. Cela nous a permis de tracer les résultats de nos expériences d'amélioration de manière empirique et automatique plutôt que de nous baser sur des résultats anecdotiques ou conservés manuellement comme précédemment.

Résultats de l'API CircleCI

Trafic

Le trafic est la quantité de demande exercée sur votre système à tout moment. Dans un système CI, cela peut être représenté par le nombre total de versions exécutées simultanément.

Nous avons pu mesurer cela en utilisant le même système que celui que nous avons construit pour mesurer les métriques de latence. Cela nous a été utile pour déterminer les limites supérieure et inférieure de l'utilisation de nos ressources de génération, car cela nous a permis de voir exactement le nombre de tâches en cours d'exécution à la fois.

les erreurs

Les erreurs représentent le nombre total de demandes ou d'appels ayant échoué. Dans un système CI, cela peut être représenté par le nombre total de générations qui échouent pour des raisons d’infrastructure. Il est important ici de faire la distinction entre les versions qui échouent correctement, en raison de tests, de peluches, d’erreurs de code, etc., plutôt que celles qui échouent pour des raisons de plate-forme.

L'un des problèmes que nous avons rencontrés est qu' AWS nous donnait parfois de «mauvaises» instances lors de la génération de nouveaux constructeurs qui s'exécutaient beaucoup plus lentement que les «bonnes» instances normales. L'ajout de la détection d'erreur dans nos scripts de démarrage de générateur nous a permis de les terminer et de créer de nouveaux noeuds avant qu'ils ne puissent ralentir les générations en cours d'exécution.

Saturation

La saturation est le degré de «saturation» de votre service ou la quantité de ressources système utilisée. Dans un système CI, cela est assez simple: combien de générateurs sous charge utilisent les E / S, le CPU et la mémoire.

Pour mesurer la saturation de notre configuration, nous avons pu exploiter les métriques de cluster en installant un Agent Datadog sur chacun de nos constructeurs, ce qui nous a permis d'avoir une vue d'ensemble des statistiques système à travers le cluster.

Statistiques de travail Datadog

Une fois que votre configuration de surveillance est en place, il devient plus facile de creuser la cause première du ralentissement de la construction. Une des difficultés pour diagnostiquer les problèmes de CI sans surveillance à l'échelle du cluster est qu'il peut être difficile d'identifier quels générateurs subissent une charge à un moment donné ou en quoi cette charge affecte vos générations. La surveillance de latence peut vous permettre de déterminer les générations qui prennent le plus de temps, tandis que la surveillance de saturation peut vous permettre d'identifier les noeuds exécutant ces générations pour une investigation plus approfondie.

Pour nous, la nouvelle mesure de la latence que nous avons ajoutée nous a permis de confirmer rapidement ce que nous avions deviné auparavant: toutes les versions n'étaient pas égales. Certaines versions fonctionnaient à la vitesse que nous avions connue auparavant, mais d'autres traînaient encore plus longtemps que prévu.

Dans notre cas, cette découverte constituait une avancée décisive: une fois que nous avons pu identifier rapidement les versions avec une latence accrue et trouver les nœuds saturés, le problème s'est rapidement révélé: conflit de ressources entre les constructions de départ! En raison du grand nombre de tests pour nos plus grandes versions, nous utilisons les tests de CircleCI. parallélisation permet de répartir nos tests et de les exécuter dans l’ensemble de la flotte dans des conteneurs distincts. Chaque conteneur de test nécessite également un autre jeu de conteneurs de support (Redis, MongoDB, etc.) afin de répliquer l'environnement de production. Le démarrage de tous les conteneurs nécessaires pour chaque génération est une opération gourmande en ressources nécessitant d'importantes quantités d'E / S et de CPU. Depuis Nomad utilise bin-emballage pour les distributions de tâches, nos constructeurs lancent parfois jusqu'à 5 ensembles différents de ces conteneurs à la fois, provoquant ainsi des ralentissements importants avant même que les tests ne puissent commencer.

La configuration d'un environnement de développement est essentielle pour résoudre les problèmes de CI une fois détectés, car elle vous permet de pousser votre système à ses limites tout en garantissant qu'aucun de vos tests n'affecte la productivité en production. Coinbase gère un cluster de développement pour CircleCI que nous utilisons pour tester les nouvelles versions avant de les mettre en production. Toutefois, afin d'étudier nos options, nous avons transformé le cluster en une réplique plus petite de notre instance de production, ce qui nous permet de charger efficacement les constructeurs CircleCI de test. . Garder votre cluster de développement aussi près que possible de la production peut vous aider à vous assurer que les solutions que vous trouvez reflètent ce qui peut réellement aider dans un environnement réel.

Une fois que nous avions identifié les raisons pour lesquelles nos versions rencontraient des problèmes et que nous avions configuré un environnement dans lequel effectuer des expériences, nous pouvions commencer à développer une solution. Nous avons exécuté à plusieurs reprises les mêmes grandes versions qui posaient des problèmes sur notre cluster de production sur différents tailles et types EC2 afin de déterminer les options les plus économiques et les plus rentables.

Comparaison de type d'instance EC2

Alors que nous utilisions auparavant un plus petit nombre de grandes instances pour exécuter nos versions, il s'avère que la configuration optimale pour notre cluster était en réalité un très grand nombre d'instances plus petites (m5.larges dans notre cas) – suffisamment petit pour que Circle ne envoie qu'un conteneur de construction parallélisé à chaque instance, ce qui évite les problèmes de piétinement de la construction à l'origine du ralentissement. L’identification des types d’instance appropriés a eu un effet secondaire intéressant: en effet, elle nous a permis de réduire considérablement l’empreinte sur les coûts de nos serveurs, car nous avons été en mesure de dimensionner notre cluster plus précisément.

L'application de vos modifications à un environnement de production est la dernière étape. Déterminer si les effets de l'accord a fonctionné peut être fait de la même manière que les problèmes ont été identifiés – avec les quatre signaux d'or.

Après avoir identifié ce qui fonctionnait le mieux sur notre cluster de développement, nous avons rapidement implémenté le dimensionnement des nouveaux constructeurs en production. Les resultats? Une réduction de 75% du temps de construction de nos plus grosses versions, des économies de coûts considérables en raison de la taille réduite de notre cluster, et le plus important: des développeurs heureux!

Construit, avant et après

Ce site Web peut contenir des liens vers des sites Web tiers ou d’autres contenus à des fins d’information uniquement («sites tiers»). Les sites tiers ne sont pas sous le contrôle de Coinbase, Inc. et de ses filiales («Coinbase»), et Coinbase n’est pas responsable du contenu de tout site tiers, y compris, sans limitation, tout lien contenu dans un site tiers. Site tiers, ou toute modification ou mise à jour d'un site tiers. Coinbase n'est pas responsable de la diffusion Web ou de toute autre forme de transmission reçue d'un site tiers. Coinbase ne vous fournit ces liens que par souci de commodité, et l’inclusion de tout lien n’implique en aucun cas l’approbation, l’approbation ou la recommandation du site par Coinbase, ni toute association avec ses opérateurs.

Sauf indication contraire, toutes les images fournies aux présentes appartiennent à Coinbase.



Traduction de l’article de Sam Rubin : Article Original

BlockBlog

Le Meilleur de l'Actualité Blockchain Francophone & Internationale | News, Guides, Avis & Tutoriels pour s'informer et démarrer facilement avec Bitcoin, les Crypto-Monnaies et le Blockchain. En Savoir Plus sur L'Équipe BlockBlog

Commenter cet Article

Commenter cet Article

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Plus dans News

Top
sem, nunc lectus in adipiscing ut ante.