Toute plateforme en croissance finit par affronter le même choix : rester sur une infrastructure virtualisée, rapide à provisionner et facile à redimensionner par petites étapes, ou passer à du matériel qu'on contrôle entièrement. Nous sommes restés sur la première option longtemps. Cette semaine, nous sommes passés à la seconde — en déplaçant toute la plateforme de compilation et d'hébergement de Canner d'une flotte de serveurs virtualisés vers du matériel dédié que nous exploitons nous-mêmes, pendant que les clients continuaient de déployer.
Pourquoi le VPS avait du sens
Les serveurs virtualisés ont été le bon choix pendant la majeure partie de la vie de cette plateforme. C'est rapide à provisionner, facile à redimensionner, et quelqu'un d'autre possède le matériel physique. Pour la plupart des charges de travail, à la plupart des étapes, c'est un bon compromis.
Le coût apparaît plus tard. On partage une machine physique avec des locataires qu'on ne voit pas. L'allocation CPU est souvent une tranche mesurée d'un cœur, ce qui rend la performance en pointe inconstante. Et une bonne partie de l'isolation au niveau du système d'exploitation dont dépend une plateforme moderne ne fonctionne pas pleinement à l'intérieur d'un invité virtualisé — même quand tout s'exécute sans erreur.
Un contrôle de sécurité qui ne faisait rien
Une partie de la façon dont nous isolons la compilation d'un client de celle d'un autre repose sur des restrictions réseau au niveau du noyau — le système d'exploitation qui empêche un processus d'atteindre ce qu'il ne devrait pas, plutôt que de compter sur le code applicatif pour bien se comporter.
Durant nos propres compilations de vérification post-migration sur le nouveau matériel, l'une d'elles a échoué en résolvant un nom de domaine en cours d'installation. Une autre a échoué en tentant de joindre notre proxy de base de données interne. Ni l'un ni l'autre ne s'était jamais produit auparavant.
La restriction sur laquelle nous comptions n'avait en fait jamais été appliquée sur notre ancienne infrastructure virtualisée — l'accès noyau de bas niveau dont elle dépend n'est généralement pas accordé à un invité virtualisé. Elle n'avait jamais rien fait, sans conséquence uniquement parce que personne n'était allé chercher la faille.
Le matériel dédié nous a donné cet accès, et la même configuration s'est mise à s'appliquer pour de vrai — un peu trop strictement, bloquant certaines choses dont une compilation a légitimement besoin. Nous l'avons ajustée et revérifiée avec une reconstruction en direct le jour même.
On ne peut pas découvrir ça sur un VPS. Confirmer qu'une limite de sécurité tient vraiment exige le même accès qu'un attaquant aurait besoin, et une infrastructure virtualisée ne peut souvent pas donner de réponse honnête dans un sens comme dans l'autre.
La migration elle-même
Déplacer le calcul en direct, les bases de données et chaque application cliente en cours d'exécution entre deux environnements physiques, dans une fenêtre fixe, pendant que les clients déploient jusqu'au moment même de la bascule, ce sont des dizaines de petites opérations réversibles, pas une seule grosse opération. Trois se sont démarquées.
Déplacer des données est d'abord un problème de physique.Notre première tentative de transfert des données applicatives des clients — des dizaines de gigaoctets répartis sur des centaines de lots — passait par une seule connexion intermédiaire. À ce débit, le transfert seul aurait consommé la majeure partie de la fenêtre de maintenance. L'envoyer directement entre les deux machines a réduit le temps d'environ dix fois.
Faire correspondre les numéros de version ne veut pas dire faire correspondre la compatibilité.Une poignée d'applications dépendent d'un environnement d'exécution précis. Nous avons installé ce qui aurait dû être la version identique sur le nouveau matériel, et plusieurs ont immédiatement planté avec une erreur de compatibilité binaire. Deux systèmes d'exploitation peuvent livrer le même numéro de version d'un environnement d'exécution, compilé contre des bibliothèques système incompatibles en dessous. La solution a été de copier l'installation exacte de l'ancien environnement plutôt que de faire confiance à une installation fraîche du même numéro.
La propriété des fichiers se résout par nom, pas par numéro.Chaque application cliente s'exécute sous son propre utilisateur système isolé. Recréer ces utilisateurs sur le nouveau matériel leur attribue de nouveaux numéros d'identifiant internes qui ne correspondent pas aux anciens — ce qui semble devoir casser la propriété de chaque fichier. Ce n'est pas le cas, tant que chaque utilisateur est recréé avec le même nom et que le transfert de fichiers fait correspondre par nom plutôt que par numéro. Nous avons vérifié que cela tenait pour chaque fichier, pour chaque client, avant de considérer la migration terminée.
Une dernière chose mérite d'être nommée : une partie de notre plateforme réconcilie automatiquement le routage réseau au redémarrage, mais reconstruire une route et redémarrer l'application derrière elle se sont révélés être deux tâches distinctes, logées à deux endroits différents. Plusieurs applications sont revenues avec une route qui pointait vers elles, mais sans aucun processus en cours d'exécution. Nous l'avons repéré durant la vérification, avant que cela n'atteigne un client, et c'est désormais une vérification permanente pour la prochaine migration.
Tout le reste — le code des clients, les bases de données, les domaines personnalisés, les certificats, les variables d'environnement — a été déplacé sans le moindre changement, parce que rien de tout cela n'avait été écrit en supposant un matériel particulier en dessous.
VPS ou dédié ?
Restez sur un VPS si votre charge de travail sollicite peu les entrées-sorties, n'a pas besoin d'un CPU constant en pointe, et si la simplicité de laisser quelqu'un d'autre gérer le matériel l'emporte sur le fait d'extraire le maximum de performance. C'est le cas d'une grande partie des charges de travail réelles en production.
Passez au matériel dédié quand vous observez une performance inconstante que vous ne pouvez pas expliquer par votre propre code, que votre coût de calcul croît plus vite que votre usage, ou que votre modèle de sécurité dépend d'une isolation au niveau du noyau que vous n'avez jamais réellement vérifiée. Si vous ne l'avez pas testée, vous ne le savez pas.
La différence de performance n'est pas subtile. Des charges de travail identiques, le même code, les mêmes dépendances, aucun changement, ont tourné nettement plus vite sur le matériel dédié que sur la flotte virtualisée — nous publierons les chiffres détaillés séparément. C'est la différence entre partager l'attention d'un CPU avec des inconnus et avoir la machine pour soi seul.
La plupart des équipes ne devraient pas avoir à faire ce choix elles-mêmes, ni à découvrir ces pièges à 2 h du matin pendant une fenêtre de maintenance. C'est exactement ce que Canner est conçu pour absorber à votre place.