Dans les coulisses de Laravel Cloud : comment fonctionne la mise à l’échelle à zéro

Une application peut recevoir des centaines de visites à l’heure du déjeuner, puis presque aucune pendant la nuit. Pourtant, sur une infrastructure traditionnelle, ses serveurs continuent souvent de tourner et de coûter. Laravel Cloud s’attaque à ce décalage avec une mise à l’échelle à zéro qui permet à une application inactive de mettre en pause non seulement son calcul, mais aussi sa base de données et son cache. À la prochaine requête, l’ensemble se réveille en moins de 500 millisecondes dans le scénario prévu par cette nouvelle architecture Flex, soit environ vingt fois plus vite que l’ancien mécanisme, qui pouvait demander une dizaine de secondes.

Le changement repose sur une technique de checkpoint/restore : plutôt que de reconstruire les processus à chaque réveil, le runtime sauvegarde leur état en mémoire sur le disque du nœud, puis le restaure à la demande. Cette approche rapproche Laravel Cloud des promesses du serverless, tout en conservant une pile cohérente avec les outils habituels du développement web. Pour une petite boutique en ligne, une plateforme de réservation ou un service utilisé par pics, l’enjeu est concret : préserver les performances au retour du trafic et améliorer l’optimisation des coûts durant les périodes calmes. Voici comment cette gestion des ressources a été conçue, et ce qu’elle change en pratique.

En bref :

• Réveil accéléré : le temps passe d’environ dix secondes à moins de 500 millisecondes grâce à la restauration d’un état sauvegardé.
• Pile complète en pause : le calcul, la base de données et le cache peuvent dormir puis se réveiller à la demande.
• Coordination simplifiée : les connexions ordinaires de l’application déclenchent le réveil de MySQL et de Valkey.
• Continuité de service : les requêtes simultanées sont mises en attente pendant le réveil et un démarrage classique prend le relais si la restauration échoue.

Pourquoi l’ancien scale-to-zero ralentissait le réveil

Dans la première version, « dormir » signifiait que l’application était entièrement retirée du cluster de calcul. À l’arrivée d’une nouvelle requête, le proxy devait trouver un nœud disponible, y planifier le conteneur, récupérer l’image de l’application et relancer ses processus. Chaque étape ajoutait du délai : le réveil prenait autour de dix secondes, un temps perceptible pour une personne qui attend une page web.

Et la facture ne tombait pas nécessairement à zéro. Seul le calcul était mis en veille ; la base de données et le cache continuaient souvent de fonctionner pour éviter d’allonger encore le redémarrage. Pour une petite entreprise qui reçoit surtout des demandes en journée, cette configuration pouvait donc réduire les ressources consommées sans supprimer les coûts liés aux composants toujours actifs. Les enjeux de cette évolution sont également détaillés dans ce retour sur la réduction des coûts d’infrastructure pour les charges intermittentes.

La nouvelle approche ne se contente donc pas d’éteindre davantage de machines : elle vise à éviter de repartir de zéro au retour du trafic. C’est ce raccourci technique qui rend la mise à l’échelle à zéro plus utile au quotidien.

Checkpoint/restore : restaurer l’application plutôt que la reconstruire

Un instantané de l’état des processus

Quand une application Flex entre en veille, le runtime enregistre sur le disque du nœud une image de son état, notamment ses pages mémoire et ses descripteurs de fichiers ouverts. Lors d’une requête HTTP ou de l’exécution d’une commande, il restaure les processus depuis cet instantané. Le système évite ainsi plusieurs opérations coûteuses d’un démarrage à froid : la planification d’un nouveau conteneur, le téléchargement de l’image et l’initialisation complète des processus.

Cette technique s’appuie sur le checkpoint/restore de conteneurs, une famille de mécanismes liée à CRIU, ou « Checkpoint/Restore In Userspace ». Au repos, seul le runtime spécialisé reste actif pour pouvoir rétablir le conteneur. L’équipe Laravel explique les choix de conception dans son récit technique sur la création du scale-to-zero.

Un défi de fiabilité à l’échelle d’une flotte

Faire fonctionner la restauration sur une seule application est une chose ; la rendre fiable pour une flotte d’applications aux langages, configurations et dépendances variés en est une autre. L’infrastructure s’appuie sur Bottlerocket, un système Linux conçu pour les conteneurs, avec SELinux et ses politiques de sécurité strictes. L’intégration du nouveau runtime a demandé un travail au niveau du système d’exploitation, sans dépendre d’une variante personnalisée de Bottlerocket à maintenir et distribuer.

Le stockage a également exigé des arbitrages : il doit écrire et relire rapidement les instantanés, tout en restant économiquement viable sur une infrastructure répartie à grande échelle. Pour une application de réservation fictive, ce compromis est décisif : une restauration rapide n’a de valeur que si elle reste stable aux heures de pointe. Le gain annoncé est donc autant une question de performances que de maîtrise opérationnelle.

La restauration accélère le calcul, mais une pile ne peut pas être considérée comme prête tant que ses services de données ne suivent pas. Le réveil coordonné apporte la suite de la réponse.

Comment le calcul, MySQL et Valkey se réveillent ensemble

Laravel Cloud ne s’appuie pas sur un orchestrateur central qui donne simultanément l’ordre de redémarrer chaque composant. Le calcul se réveille lorsqu’une connexion HTTP ou une commande arrive ; une fois l’application restaurée, celle-ci contacte MySQL et Laravel Valkey avec ses pilotes habituels. Ces connexions TCP déclenchent à leur tour le réveil de la base de données et du cache.

Cette coordination par les connexions réduit le nombre de mécanismes intermédiaires et évite d’ajouter une couche d’orchestration qui pourrait devenir un point de défaillance. L’application conserve son fonctionnement habituel : elle ouvre ses connexions sans avoir à savoir que les services étaient en veille. Dans le cas de Valkey, la restauration de l’état mémoire permet également de retrouver le cache tel qu’il était avant la pause, plutôt que de le remplir entièrement à nouveau.

Pour une boutique qui consulte le stock avant d’afficher un produit, le bénéfice est simple à comprendre : l’application reprend son activité, puis retrouve ses services au fil de ses connexions normales. La pile complète peut ainsi dormir sans imposer une réinitialisation manuelle à chaque réveil.

Requêtes simultanées, tâches planifiées et workers de queue

Un pic de visites peut commencer par plusieurs requêtes arrivant presque au même instant. La première déclenche le réveil ; les suivantes sont mises en attente puis transmises à l’application une fois qu’elle est prête. Cette gestion évite que les demandes soient abandonnées pendant la reprise et limite l’effet de « thundering herd », où un afflux simultané mettrait les services sous pression.

Les tâches planifiées suivent un autre chemin. Un ordonnanceur central, qui reste actif en dehors des applications clientes, repère les travaux à exécuter, réveille l’application concernée et lance schedule:run. Les workers de queue peuvent eux aussi être réveillés selon un calendrier défini par l’utilisateur. Si des jobs doivent être traités immédiatement dès leur arrivée, les files gérées constituent une option mieux adaptée : leurs workers restent disponibles et chauds pour consommer les tâches sans attendre un intervalle planifié.

La différence compte pour une plateforme de réservation : l’envoi d’un rapport nocturne peut tolérer un déclenchement programmé, tandis qu’une confirmation de paiement exige un traitement rapide. Le choix du mode de queue doit donc suivre le besoin métier, pas seulement la volonté de réduire les ressources actives.

La mise en veille ne signifie pas non plus qu’un échec de restauration se transforme automatiquement en erreur visible. Un mécanisme de secours préserve la continuité, tandis que la surveillance porte sur le runtime capable de réveiller l’application.

Repli en cas d’échec et déploiement sur Laravel Cloud

Si la restauration depuis l’instantané échoue, Laravel Cloud peut lancer un démarrage classique du conteneur. Ce repli prend plus de temps, mais évite qu’une requête soit rejetée uniquement parce que le chemin rapide n’a pas fonctionné. Le runtime spécialisé est surveillé en continu ; si ses contrôles de disponibilité dépassent un seuil défini, il est redémarré automatiquement.

La nouvelle architecture est active pour les nouvelles applications Flex. Les applications Cloud existantes peuvent accéder aux temps de réveil améliorés en choisissant une taille Flex de 512 Mo, 1 Go ou 2 Go, puis en redéployant. Laravel Cloud indique également qu’un premier mois de l’offre Starter est gratuit pour les nouveaux utilisateurs ; les modalités exactes sont à vérifier dans la documentation au moment de la souscription.

Pour une équipe qui prépare une nouvelle fonctionnalité, les environnements de prévisualisation complètent cette logique en facilitant les essais sans mobiliser inutilement des ressources en permanence. Le sujet est approfondi dans ce guide sur le couple entre prévisualisation et mise à l’échelle à zéro. La promesse de cette architecture cloud tient finalement à un équilibre concret : laisser dormir les ressources inutilisées, sans faire attendre les utilisateurs au retour du trafic.