Pendant cinq ans, acheter un serveur ici prenait en médiane trois minutes et vingt secondes, du webhook de règlement aux identifiants dans votre boîte mail. Personne ne s'en plaignait. C'était plus rapide que la plupart de l'industrie et considérablement plus rapide que tout ce qui exigeait qu'un humain vous approuve.
C'était aussi quatre étapes en série qui n'avaient aucune raison d'être en série, et une fois qu'on le remarque, on ne peut plus s'arrêter de le remarquer. La réécriture a été livrée en mars et la médiane est désormais de quarante-sept secondes, avec le quatre-vingt-quinzième percentile juste sous les quatre minutes.
Ce que faisait l'ancien système
| Étape | Médiane | Ce qui se passait |
|---|---|---|
| Copie d'image | 84 s | Récupération d'une image disque depuis un stockage local vers le nœud cible |
| Création de volume | 31 s | Allocation et formatage du volume NVMe |
| Allocation d'adresse | 46 s | Prise d'un verrou sur le pool d'adresses du site, choix d'une IPv4, écriture du DNS inverse |
| Premier démarrage et cloud-init | 39 s | Génération des clés, extension du système de fichiers, envoi du courrier |
Quatre étapes, un pool de workers global, et un verrou sur le pool d'adresses derrière lequel chaque commande du même site devait faire la queue. Un mardi calme, c'était parfait. Pendant une promotion, ou pendant l'heure qui suivait une grosse commande scriptée de quarante créations, la médiane doublait et la queue dépassait douze minutes.
Ce que nous avons changé
Les images sont préinstallées, pas copiées. Chaque nœud détient une base de clone allégée pour chaque image du catalogue, rafraîchie chaque nuit. La création d'un volume est désormais un clone copy-on-write contre un miroir NVMe Gen4 local plutôt qu'une récupération réseau. Cette étape est passée de quatre-vingt-quatre secondes à moins de deux.
Les adresses sont réservées à l'avance. Chaque site maintient un pool chaud d'adresses allouées avec le DNS inverse déjà écrit, dimensionné pour environ six heures de demande sur ce site. L'allocation est désormais un retrait d'un pool pré-construit plutôt qu'un verrou, une analyse et une écriture DNS. Quarante-six secondes sont devenues environ quatre cents millisecondes.
Les files d'attente sont par site. Une ruée à Francfort ne ralentit plus une création à São Paulo, ce qui semble évident et ne l'était pas dans la conception originale, car la conception originale avait quatre sites et un seul ingénieur.
Les workers sont idempotents et reprenables. Chaque étape est clé, donc un worker qui meurt à mi-chemin laisse un travail reprenable plutôt qu'une instance à moitié construite et un ticket de support. L'intervention manuelle sur une création échouée est passée d'environ un ordre sur quatre cents à un sur neuf mille.
Le résultat
| Métrique | Avant | Après |
|---|---|---|
| Médiane | 3 min 20 s | 47 s |
| 95e percentile | 12 min 10 s | 3 min 56 s |
| 99e percentile | 41 min | 8 min 20 s |
| Créations échouées nécessitant un humain | 1 sur 400 | 1 sur 9 000 |
| Concurrence par site avant que la médiane ne bouge | 6 | 90 |
Ce qui a mal tourné en chemin
En mars, pendant onze heures, le rafraîchissement nocturne des bases de clone allégées a échoué silencieusement sur quatre sites et l'image Debian préinstallée a servi une version ponctuelle vieille de neuf jours. Environ quatre-vingt-dix instances ont été construites à partir de celle-ci. Aucune n'était cassée d'une manière intéressante, car une version ponctuelle périmée n'est qu'à une mise à jour de paquets d'une version actuelle, mais personne qui achète un serveur ne devrait avoir à vérifier.
Nous avons reconstruit les instances concernées sur demande, envoyé un e-mail aux quatre-vingt-dix qu'ils l'aient demandé ou non, et ajouté une vérification qui compare le hachage de l'image de base avec le catalogue avant qu'un nœud ne puisse servir des créations. Un échec silencieux dans un travail nocturne est la cause la plus ennuyante possible, et cela vaut la peine d'être écrit précisément parce que c'est ennuyant.
Ce qui est encore lent
- Installations ISO personnalisées. Toujours manuelles, toujours mesurées en dizaines de minutes, généralement terminées dans l'heure. Le goulot d'étranglement est une personne qui confirme que l'image fait ce que son uploader prétend.
- Windows. L'activation de la licence ajoute deux à trois minutes et n'est pas sous notre contrôle.
- Bare metal. Le jour même plutôt que la même minute. Une machine physique a une reconstruction physique, et nous préférons vous citer honnêtement que de démarrer un chronomètre que nous ne pouvons pas battre.
- Délégation IPv6 /48. Manuelle sur trois sites où la configuration de la matrice est plus ancienne. En cours de correction, lentement.
Pourquoi nous nous sommes arrêtés là
Nous pourrions faire descendre la médiane à environ vingt secondes en gardant les instances pré-démarrées et en vous en remettant simplement une au paiement. Cela signifie maintenir une capacité inactive, ce qui signifie payer pour des cœurs que personne n'utilise, ce qui signifie facturer tout le monde un peu plus pour que les nouvelles commandes semblent onze secondes plus rapides.
Quarante-sept secondes est assez court pour que la contrainte soit désormais la chaîne confirmant votre paiement plutôt que quoi que ce soit que nous faisons. Optimiser au-delà du point où le client le remarque est un passe-temps, pas de l'ingénierie.