Passer à des espaces de travail plus grands sans faire attendre personne

Chaque projet Mythex dispose de son propre espace de travail : un petit ordinateur cloud où l'agent écrit du code et où l'aperçu de votre application tourne. Nous avions fait passer la mémoire des nouveaux espaces de travail de 1 Go à 2 Go, mais les anciens étaient restés à 1 Go — le jour où nous avons vérifié, environ un quart d'entre eux. Notre première correction déplaçait un projet vers un espace plus grand à sa prochaine ouverture. Le premier jour en production, cela a fait attendre une personne sept minutes. Nous avons alors fixé une limite de temps stricte, puis retiré le déplacement de l'ouverture d'un projet.

Pourquoi les anciens espaces restaient petits

Notre fournisseur de bacs à sable fixe la taille d'un espace de travail à sa création, et la conserve à chaque pause et reprise. Modifier le modèle — la recette à partir de laquelle les nouveaux espaces sont construits — ne concerne que les espaces créés après ce changement. Rien ne redimensionne ceux qui existent déjà.

Cela comptait. Un des petits espaces a manqué de mémoire pendant un git push pendant le démarrage de son aperçu, et n'a plus répondu pendant 11 minutes. Une publication a échoué à cause de cela.

Première tentative : déplacer le projet au réveil

Les espaces de travail se mettent en pause lorsque personne ne les utilise, et se réveillent à l'ouverture du projet. Le réveil semblait être le bon moment pour déplacer un projet, puisque personne n'y travaille encore.

Le déplacement fonctionnait ainsi :

1. Vérifier la taille. Si l'espace de travail fait moins de 2 Go, on le déplace. Si sa taille est inconnue, on ne fait rien.
2. Ne pas perturber une publication. Une publication lit les fichiers de l'espace de travail ; si une publication est en cours, on ne déplace pas.
3. Empaqueter le projet. Archiver tout ce qui est dans le projet — y compris son historique git, c'est-à-dire chaque checkpoint du projet, et le fichier .env de l'application, qui appartient au propriétaire — mais exclure les dépendances installées (node_modules), qui peuvent être réinstallées.
4. Copier directement. Diffuser l'archive depuis l'ancien espace de travail vers un espace neuf de 2 Go, afin qu'elle n'ait jamais à tenir dans la mémoire de notre propre serveur.
5. Comparer avant de basculer. Compter les fichiers, lire le dernier checkpoint et compter les checkpoints, dans les deux espaces. Basculer seulement si les trois correspondent.
6. Garder l'ancien espace en cas d'échec. Toute erreur ou tout écart jette le nouvel espace et ouvre le projet dans l'ancien, comme auparavant.

Un détail de la comparaison comptait plus qu'il n'y paraît. La vérification s'exécute avec le compte administrateur, et git refuse de lire un dépôt appartenant à un autre utilisateur. Elle n'affichait rien des deux côtés — et « rien » égalait « rien », si bien que la vérification réussissait sans comparer le moindre historique. Nous avons indiqué à git de faire confiance au répertoire, et ajouté un test pour que cela ne puisse plus se reproduire.

Ce qui s'est mal passé le premier jour

Le premier jour en production, l'empaquetage d'un projet a atteint un délai d'expiration de commande de cinq minutes — au sein même du réveil. Le propriétaire a attendu sept minutes que son espace de travail s'ouvre. Et comme le déplacement avait échoué, le projet restait petit, si bien que l'ouverture suivante aurait réessayé et les aurait fait attendre à nouveau.

Une migration qui fait attendre quelqu'un à l'ouverture de son propre projet est un mauvais compromis. Tout l'intérêt de la faire au réveil était que personne ne s'en aperçoive.

Deuxième tentative : un budget strict

Le même jour, nous avons changé quatre choses :

• Une minute pour tout le déplacement. Chaque étape — vérifier la taille, empaqueter, créer le nouvel espace, copier, décompresser, comparer — partage un budget unique de 60 secondes. Lorsqu'il est épuisé, le projet s'ouvre dans l'ancien espace.
• Arrêter le travail, pas seulement l'attente. Abandonner de notre côté ne suffit pas si l'archivage tourne encore dans l'espace de travail que le propriétaire s'apprête à utiliser. Chaque commande d'archivage est désormais tuée à l'intérieur de l'espace de travail, peu avant la fin du budget. Si le nouvel espace arrive après que nous avons abandonné, il est jeté.
• Ne pas faire attendre le propriétaire pour le nettoyage. La suppression de l'archive temporaire se fait désormais en arrière-plan.
• Ne pas réessayer à chaque ouverture. Un projet qui n'a pas pu être déplacé est laissé tranquille pendant 24 heures, si bien qu'un échec coûte au plus un retard par jour, et non un par ouverture.

Troisième tentative : sortir le déplacement du réveil

Cela ramenait le pire cas à une minute. Mais une minute reste une minute, et nous avons compris que le déplacement n'avait pas besoin de se trouver sur le chemin de qui que ce soit.

Aucun espace n'est plus créé à 1 Go. Il ne s'agit donc pas d'un processus continu, mais d'une tâche ponctuelle portant sur une liste fixe d'espaces de travail. Le faire dans le réveil signifiait qu'une vraie personne payait chaque déplacement lent, et que la seule façon de savoir qu'un espace ne pouvait pas être déplacé était que quelqu'un vienne d'attendre.

Nous avons donc retiré le déplacement du réveil complètement. Ouvrir un projet fait ce qu'il faisait avant. Les espaces restants, encore petits, sont traités par lot supervisé : personne n'attend, et un espace qui ne peut pas être déplacé apparaît dans le rapport du lot, que nous pouvons examiner, plutôt que sous les yeux de son propriétaire.

Ce que nous en retenons

• Le redimensionnement n'est pas toujours possible. Lorsqu'une plateforme fixe une taille à la création, relever la valeur par défaut n'aide que les nouveautés. Prévoyez pour les anciennes.
• « Personne ne l'utilise encore » ne veut pas dire que personne n'attend. Le travail effectué à l'entrée d'un produit est un travail qu'une personne observe.
• Mettez un budget sur tout ce qui se trouve sur le chemin d'un utilisateur, et arrêtez le travail lorsqu'il est épuisé. Abandonner de notre côté pendant qu'une commande continue ailleurs ne fait que déplacer le problème.
• Une migration ponctuelle appartient à une tâche ponctuelle. La cacher dans des actions quotidiennes la rend moins coûteuse à écrire et plus coûteuse à exécuter.
• Testez vos contrôles de sécurité. Une comparaison qui ne compare rien ressemble exactement à une comparaison réussie.

Si vous construisez sur Mythex, il n'y a rien à faire : l'objectif est simplement d'avoir moins d'espaces de travail à court de mémoire, en gardant l'ouverture d'un projet aussi rapide qu'avant. Le fonctionnement de la mise en pause et du réveil des espaces est documenté sous espace de travail privé. Pour une autre histoire de mémoire saturée, voir le crash de mémoire caché derrière une étiquette de progression.