De temps à autre, on voit des commentaires de développeurs sur les réseaux sociaux qui se demandent pourquoi quelqu’un utiliserait une solution de salle d’attente. À leurs yeux, installer CrowdHandler reviendrait à admettre sa défaite plutôt qu’à enrichir judicieusement leur boîte à outils.
Après tout, pourquoi auriez-vous besoin d'une solution pour la salle d'attente alors que vous pouvez simplement utiliser un cloud magique et évolutif à l'infini ?
Voici un exemple :
« Une stratégie de répartition de charge efficace avec une évolutivité illimitée ou une salle d'attente agaçante pour les clients… Hum, le choix est difficile. »
Une expansion illimitée ? Ça n'existe pas.
Pour une raison ou une autre, de nombreux développeurs semblent partir du principe que leurs solutions cloud – telles que les groupes EC2 à mise à l'échelle automatique, AWS Lambda ou leurs équivalents sur Azure ou Google – sont capables de s'adapter à l'infini.
Peut-être pensent-ils qu'ils sont faits de magie.
La vérité, c'est que les solutions cloud ne peuvent évoluer que dans certaines limites et, quel que soit le nombre de serveurs que vous pourriez ajouter comme par magie, vous finirez par atteindre ces limites.
Vos paramètres incluront ceux que vous aurez dû définir et payer vous-même — en d’autres termes, les paramètres dans lesquels ce cloud vous permet d’opérer en fonction de votre budget. Mais il y aura probablement aussi une limite ultime liée à votre technologie de base de données. (Après tout, aucune couche de stockage ACID ne peut évoluer à l’infini, car, de par sa nature même, aucune transaction ACID ne peut être infinie.)
Du coup, quand je tombe sur un commentaire comme celui-ci, je sais que la personne n'a pas vraiment l'habitude de gérer la mise à l'échelle en conditions réelles.
En effet, dès que vous aurez travaillé sur une application devant s'adapter à un trafic colossal en très peu de temps, vous atteindrez ces limites et vous comprendrez qu'il n'existe pas d'« expansion illimitée ».
L'auto-scaling fonctionne… jusqu'à ce qu'il ne fonctionne plus
Bien sûr, vous disposez d’une très belle application évolutive, capable de s’adapter automatiquement au cours d’une journée, voire d’un mois. Vous pouvez la régler pour qu’elle s’adapte sans problème aux variations de trafic, même pendant les périodes de forte affluence. Votre architecture à évolutivité automatique détectera que vous avez un peu plus de travail et ajoutera automatiquement des serveurs pour y faire face… puis elle remarquera quand l’activité redescendra et les retirera du circuit. Ça fonctionne bien.
Tout cela est parfait… dans 99 % des cas. Mais les profils de trafic qui exigeraient que votre architecture à évolutivité automatique soit infiniment évolutive ne se présentent pas du tout ainsi. Nous parlons ici d’un scénario où votre application se retrouve soudainement dix fois plus sollicitée, cent fois plus sollicitée — voire mille fois plus sollicitée… en moins d’une minute.
Tout à coup, mille fois plus occupé
La mise en vente de billets est l'exemple le plus évident de ce type de pic de trafic soudain que nous observons ici chez CrowdHandler. Lorsque les billets pour la dernière tournée d'une mégastar sont mis en vente, par exemple, le site d'un vendeur peut passer de zéro à un million de visiteurs à 10 heures pile.
Mais il ne s'agit pas seulement des ventes de billets pour des mégastars. Un pic de trafic soudain peut arriver à n'importe qui. N'importe quel type de vente présentant une dynamique de baisse, une pénurie soudaine d'une gamme populaire, une mention de votre produit par un influenceur sur les réseaux sociaux (que ce soit prévisible ou non !) : tous ces éléments peuvent provoquer un afflux de trafic.
Ce qui se passe généralement dans ce genre de situation, c'est que, en effet, le système d'auto-scaling détecte l'augmentation du trafic — peut-être constate-t-il que les temps de chargement des pages s'allongent ou que l'utilisation du processeur sur les serveurs augmente — et réagit en mettant en service davantage de serveurs.
Cependant, ce processus n'est pas instantané. Les conteneurs doivent démarrer et les caches doivent se mettre en route.
C'est assez ironique, en réalité : lorsque les mécanismes d'auto-scaling se déclenchent, on constate généralement une baisse notable des performances. Ce ralentissement, qui dure jusqu'à ce que les systèmes se stabilisent à nouveau, peut s'étendre jusqu'à cinq minutes.
Si une « salle d'attente » a été mise en place, c'est à ce moment-là qu'elle entre en action. Lorsque les performances ralentissent au point que les utilisateurs finaux risqueraient autrement de voir l'application planter, la « salle d'attente » sert à retenir les utilisateurs pendant ces quelques minutes, le temps que le système reprenne ses activités normales.
Disponibilité de Triple 9
Au fait : que prévoit votre SLA concernant la disponibilité globale ? Car, sur un mois, ces cinq minutes nécessaires à la remise en service passeront pratiquement inaperçues, même si elles peuvent causer d’importants dommages. Faites le calcul : 5/43 920, cela signifie que vous conservez tout de même une disponibilité de 99,99 % ! Mais ces cinq minutes sont probablement les plus critiques de tout le mois en termes d’expérience utilisateur et de réputation.
Alors, que pouvez-vous faire pour éviter ces problèmes ?
Réduire la surcharge de trafic - 1 : Quand elle est prévisible
Souvent, on sait à l'avance quand un pic de trafic va se produire. Vous organisez peut-être vos ventes promotionnelles sur les articles haut de gamme le vendredi matin. Vous prévoyez peut-être une promotion pour le Black Friday. Notre conseil est donc le suivant : n’attendez pas que le trafic déclenche l’auto-scaling ! Programmez votre « cloud magique » pour qu’il s’adapte à la hausse à l’avance. (C’est ce que font nos amis de Made Media: ils savent qu’un grand nombre de leurs clients vont lancer des promotions, ils savent que cela se produit généralement le vendredi matin, et leur infrastructure est donc programmée pour s’adapter à la hausse chaque vendredi matin.)
Et… vous l’avez deviné : installez CrowdHandler. Car même si vous maîtrisez parfaitement les paramètres de votre évolutivité et que vous êtes absolument certain de bien comprendre le niveau de trafic que vous allez recevoir, il subsiste tout de même une marge d’erreur considérable. Une « salle d’attente », en revanche, résistera à presque tout (et n’oubliez pas qu’elle ne s’activera pas si ce n’est pas nécessaire).
Nous pouvons également affirmer sans hésiter que des surprises surviennent. Il arrive souvent qu’un client nous demande pourquoi une salle d’attente s’est activée et nous signale que son tableau de bord CrowdHandler affiche un trafic « erroné » ou « inexistant ». Or, ce trafic est bien réel : il est simplement inattendu. Plus tard, ils découvrent qu’un influenceur a fait la promotion de leur événement, ce qui a entraîné un afflux massif de visiteurs sur leur site à un moment où ils ne s’y attendaient pas. Dans le monde de la billetterie, on constate que de plus en plus d’artistes prennent les devants et partagent un lien dans le cadre de l’annonce d’une tournée sans consulter le calendrier de communication soigneusement préparé.
Réduire la surcharge du trafic - 2 : Quand elle est imprévisible
Si vous ne savez pas quand les pics de trafic vont se produire (ou si vous travaillez avec des influenceurs imprévisibles !), vous devriez absolument installer CrowdHandler comme solution de secours, en le laissant fonctionner en permanence.
Mieux encore, utilisez-le avec la fonction Autotune activée. Dans ce cas précis :
- Augmentation du trafic
- La file d'attente est activée et la fonction Autotune de CrowdHandler gère le débit
- Le cloud à mise à l'échelle automatique réagit à l'augmentation de la charge et commence à s'adapter, ce qui ralentit les performances
- La fonctionnalité Autotune de CrowdHandler détecte le ralentissement, maintient certains utilisateurs dans la file d'attente et leur offre une expérience utilisateur positive grâce à des messages adaptés.
- Les niveaux de performance reviennent à la normale et Autotune augmente la fréquence pour vider rapidement la file d'attente
Un dernier mot sur l'expérience utilisateur
Voici un détail intéressant. Même si votre infrastructure cloud à mise à l’échelle automatique fonctionnait sans le moindre accroc et que votre produit était épuisé en moins d’une seconde, vos utilisateurs vivraient une expérience loin d’être optimale (et pourraient vous faire part de leur mécontentement). En effet, lorsqu’un événement se produit très rapidement – par exemple, s’il ne semble y avoir aucun délai entre le moment où la transaction devient disponible et celui où le produit est épuisé –, cela peut paraître très injuste aux yeux de l’utilisateur final. Certains de nos clients nous ont confié que le processus CrowdHandler et les notifications associées fidélisent les utilisateurs, en leur laissant le temps de respirer et en les tenant informés.
Alors, lorsque la file d'attente se met en place, faites confiance au processus. Ne paniquez pas (mais utilisez judicieusement les champs de message). Vos utilisateurs seront bien plus à l'aise à l'idée d'attendre quelques secondes ou quelques minutes qu'à celle de se retrouver face à un site qui plante ou à une page indiquant immédiatement « épuisé ».