Toute plateforme ou entreprise SaaS en croissance finit par affronter le même choix. Restons-nous sur une infrastructure virtualisée, facile à provisionner et à redimensionner, ou passons-nous à du matériel que nous contrôlons vraiment, mais qu'il faudra entretenir (et éventuellement retirer)? C'est un peu comme louer ou acheter. Comme la plupart des gens, nous sommes restés sur la première option longtemps, mais cette semaine était la semaine du déménagement. Nous avons déplacé toute la plateforme de compilation et d'hébergement de Canner d'une flotte de serveurs virtualisés vers un serveur dédié que nous gérons — pendant que les clients continuaient de déployer.
Pourquoi le VPS avait du sens au départ
Les serveurs virtualisés ont été le bon choix pendant la majeure partie de la vie de la plateforme. Rapide à provisionner, facile à changer, quelqu'un d'autre s'en occupe. Le coût est apparu plus tard, et pas vraiment sur la ligne du bas. Le vrai problème, ce sont les autres locataires qu'on ne voit pas, l'allocation mystère du CPU, et la performance imprévisible aux heures de cron et autres fenêtres critiques. En plus de ça, certaines erreurs et l'isolation au niveau du système d'exploitation font qu'on n'a tout simplement pas un portrait complet du matériel qu'on utilise.
Un morceau de sécurité manquant dans l'histoire
Une partie de la façon dont nous isolons réellement les compilations de nos clients 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, ce qui veut dire qu'on ne se contente pas de "faire confiance" au code applicatif pour bien se comporter. On présume qu'il va échouer ou être brisé. Durant les compilations de vérification post-migration, une compilation a échoué à résoudre un domaine en cours d'installation. Une autre a échoué à joindre notre proxy de base de données. Ça ne s'était jamais produit auparavant, mais il s'est avéré que cette restriction n'avait en fait jamais été appliquée sur les anciennes machines virtuelles. L'accès au niveau du noyau n'avait tout simplement jamais été accordé à l'invité virtualisé! Sans conséquence, parce que les règles applicatives avaient fonctionné comme prévu, mais crucial pour notre sentiment de sécurité, et un vrai gain du passage au matériel dédié. C'est quelque chose qu'on n'obtient tout simplement pas sur un VPS — confirmer qu'une limite de sécurité tient vraiment n'est pas une question de lire un message d'erreur. Les commandes étaient acceptées, mais l'infrastructure refusait de les exécuter.
La migration elle-même
Déplacer le calcul en direct, des bases de données en continu, et redémarrer les applications clientes en déploiements bleus dans une fenêtre fixe — c'était des dizaines d'étapes réversibles, pas une seule grosse opération. C'est une idée fausse répandue : ce n'est pas parce qu'on déménage vers une seule grosse machine que le déménagement doit se faire d'un seul coup.
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 élevé et constant, et si la commodité du matériel vous convient. Si vous n'êtes pas à l'aise d'extraire de la performance supplémentaire sur une machine Linux, remettez ça à plus tard. L'ironie, c'est qu'au moment où vous avez besoin de plus de performance — et que vous commencez à voir des limitations aux heures de pointe — c'est probablement parce que d'autres locataires compriment votre machine. Si le coût de calcul augmente plus vite que l'usage, ou que votre modèle de sécurité ne peut pas être confirmé au niveau applicatif, il est temps de passer à une machine dédiée et prévisible.
Un mois après la migration, Canner a maintenu un temps de disponibilité de plus de 99,95 %, et nous avons observé des compilations bien plus rapides que ce à quoi nous nous attendions. Voyez les chiffres dans le journal des changements.