Comment le commerce électronique survit aux promotions à grande échelle. Se préparer aux pics de charge sur le Web [Partie 1]

Bonjour à tous, je suis en contact avec Alexey Pristavko, directeur du projet Web DataLine.
Le Black Friday, le plus grand événement de commerce électronique au monde, a lieu chaque année dans les derniers jours de novembre. C'est le moment des remises records, les magasins ouvrent presque à minuit et les sites participant à l'action chutent, malgré la forte augmentation du trafic.

Par conséquent, en utilisant son exemple, nous analyserons comment se préparer à une augmentation sérieuse de la charge sur un site Web ou une application Web.
Sous le chat, nous parlerons en détail de la manière dont les responsables informatiques, les développeurs et les administrateurs de boutiques en ligne peuvent survivre à des événements à grande échelle.

Ce qui menace le Black Friday

Comme je l'ai écrit ci-dessus, le Black Friday est une journée qui cause beaucoup de problèmes à tous ceux qui sont impliqués dans la maintenance des sites de commerce électronique.

Pour le ressentir, considérez le tableau ci-dessous. Il reflète l'augmentation du nombre de demandes sur le site lors du Black Friday.



Par rapport aux pics quotidiens normaux, lorsqu'aucune action n'est détenue, le trafic du Black Friday augmente de 100 à 200%, et ce n'est pas la limite.

Si un grand site a déjà beaucoup de trafic, une modeste boutique en ligne pendant la période de la campagne recevra facilement autant de visiteurs et s'étouffera. Pour paraphraser un peu la vieille blague: «les affaires ont rendu tous les magasins différents, et le Black Friday en ligne a égalisé tout le monde.»

Gagné le Black Friday «nourrit» le vendeur toute l'année prochaine. L'entreprise est extrêmement intéressée à attirer le nombre maximum de nouveaux clients qui reviendront sur le site pour acheter encore et encore. Mais pour cela, leur première expérience avec le site doit se dérouler sans encombre, et pour s'assurer que c'est la tâche des informaticiens.

Plus il y a de clients simultanément sur le site, plus les exigences de stabilité et de vitesse de réponse sont élevées. Vous avez sûrement remarqué que le site Web du magasin, vers lequel vous êtes passé de la page de destination de blackfridaysales, fonctionnait extrêmement lentement ou ne fonctionnait pas du tout. Je doute que vous soyez resté en attente du téléchargement, mais que vous n'êtes pas reparti après quelques secondes.

Nous expliquerons ci-dessous comment protéger les clients contre les expériences négatives et le site contre les plantages dus à une surcharge. Cependant, d'autres conseils sont valables pour toute charge de pointe attendue.

En général, il y a deux étapes de préparation d'un site pour une circulation accrue: technique et organisationnelle. Dans cet article, nous discuterons de la phase technique, et je décrirai les détails organisationnels en détail dans la deuxième partie, qui sera publiée dans une semaine.

Préparation technique du site

Un petit avertissement: ne vous attendez pas à trouver ici des instructions détaillées sur quoi, où et comment le resserrer pour que «le bonheur pour tous vienne en vain, et que personne ne soit offensé». Tout d'abord, les sites et les projets sont différents pour chacun. Deuxièmement, des conseils techniques spécifiques sur un logiciel particulier sont plus que suffisants. Y compris sur Habré. Tout d'abord, je veux transmettre aux lecteurs les principes fondamentaux du travail avec des projets Web et montrer les points de départ, introduire des techniques de base et des nuances indépendantes de la plate-forme.

Commençons par l'axiome: l'utilisateur n'aime pas attendre, il est donc extrêmement important de travailler avec les timings et la vitesse de réponse. Le Black Friday, il y aura beaucoup plus de demandes sur le site que d'habitude, et vous pouvez rencontrer non seulement une baisse des conversions en raison d'une longue charge, mais également un excès de délais d'attente HTTP (le site ne répond pas).

Le plus souvent, les sites subissent une charge non pas en raison de pannes physiques, mais parce que le temps de réponse a commencé à dépasser les délais d'attente en raison d'une surcharge sur un nœud. Cela ressemble à un embouteillage et pendant un certain temps, vous devrez prendre le contrôle de vos propres mains: étendre (mettre à l'échelle) l'équipement, ajuster, couper et configurer (délais), optimiser la charge sur les véhicules (colis et demandes) et travailler avec des exceptions.

Étant donné que dans le contexte de la performance du site a deux aspects - la vitesse de réponse et le nombre de demandes traitées simultanément, nous allons améliorer ces paramètres.

Le plus souvent, une entreprise représente la vitesse de réponse comme la vitesse du site selon Google Analytics, et le nombre de demandes simultanées comme le nombre d'utilisateurs simultanément sur le site.

Dans les travaux techniques, il n'est pas très pratique d'opérer avec ces paramètres.
Ensuite, je proposerai une métrique plus appropriée pour les calculs.

Nous optimisons la vitesse de réponse

Lors de l'optimisation de la vitesse de réponse, nous nous intéressons à deux indicateurs: la vitesse de réponse du serveur et le temps de chargement des pages.

Le temps de chargement de la page comprend les liens suivants:

• Temps de génération de page du serveur;
• Temps de transfert de page du serveur au client;
• Le temps de traitement des pages dans le navigateur du client.

Lorsque tout fonctionne comme d'habitude, le facteur décisif pour le temps de chargement de la page n'est pas l'heure à laquelle la page a été générée par le serveur et l'heure à laquelle la page a été livrée sur le réseau, mais la qualité de l'interface et la vitesse du site dans le navigateur. Comme ce dernier est entièrement du côté de l'utilisateur, vous ne pouvez pas avoir peur des freins du Black Friday. Cependant, des problèmes peuvent survenir en raison de surcharges sur votre canal Internet ou de la livraison d'un composant externe (compteurs affiliés, chats en ligne, plugins CRM, etc.).
Comment y faire face? Voici quelques conseils pratiques:

1. Vérifiez la charge du canal Internet. Comptez la croissance estimée. En cas de doute, agrandissez le canal. Certains fournisseurs, en plus des extensions coûteuses sur une base continue, peuvent vous offrir une extension temporaire pour la période de pointe (beaucoup moins cher) ou même vous permettre de dépasser brièvement la vitesse maximale.
2. Vous utilisez un CDN? Contactez le support technique et avertissez de la croissance prévue du trafic. Ils se préparent également pour le pic général, et vos prévisions vous seront utiles. Si le CDN promet que tout ira bien, mais, malgré tout, «se couchera», la présence de correspondance contribuera à faire valoir des demandes d'indemnisation.
3. À l'avance, élaborez un script pour désactiver temporairement les composants externes en cas de problème. Alignez le scénario avec l'entreprise. Il ne sera pas superflu de communiquer avec le support technique des services utilisés, de toute façon il est généralement impossible de les influencer d'une manière ou d'une autre.
4. Sur de nombreux sites, la statique est rendue à l'aide du serveur d'applications. Sous une charge élevée, le nombre de demandes à la statique augmente plusieurs fois et elles commencent à rivaliser pour les ressources avec l'application elle-même. Assurez-vous de configurer le retour statique directement depuis Nginx. Premièrement, cela fonctionnera beaucoup mieux avec cela, et deuxièmement, il y aura un travail beaucoup plus utile pour vos threads Apache, Tomcat ou Jetty.

Amélioration de la vitesse de réponse

L'optimisation de la vitesse de réponse en soi fait référence à l'amélioration globale des performances du site. En théorie, cela permet de réduire la quantité de travail effectuée par l'application et, de ce fait, améliore la mise à l'échelle - car si chaque demande devient «moins chère», vous pouvez traiter plus de demandes avec les mêmes ressources.

Mais en pratique, l'optimisation de la vitesse de réponse nécessite une grande quantité de travail indépendant. Il est impossible d'optimiser tout à la fois, mais casser quelque chose dans le processus est facile.

Astuce: pensez systématiquement. Disons que les performances du code ont augmenté et que l'application a commencé à effectuer davantage de requêtes de base de données simultanément. Mais voici le problème: les performances de la base de données ne permettent pas de traiter un tel nombre de demandes, et le site dans son ensemble n'a fait qu'empirer, et un temps précieux a été consacré avant le début de l'action.

Il est donc préférable de se concentrer sur la mise à l'échelle et l'évolutivité, et d'effectuer une optimisation générale séparément de la préparation du Black Friday, afin de ne pas gâcher en raison de délais serrés. Rappelez-vous, maintenant notre tâche est de nous assurer qu'au plus fort des charges, le site ne fonctionne pas pire qu'à l'extérieur.

La vitesse de génération de page ne nous intéressera qu'en conjonction avec un autre indicateur - la quantité de charge entrante.

Attention: pour le site, seul le nombre de demandes simultanées créées par les utilisateurs est important, et non le nombre d'utilisateurs en ligne sur le site. Et pour calculer avec une précision acceptable le nombre de demandes par seconde par le nombre de visiteurs est assez difficile (j'ai écrit à ce sujet ci-dessus). Il est préférable de demander à l'entreprise d'autres statistiques: pages vues par heure et temps du serveur.

En conséquence, nous obtenons un objectif compréhensible: garantir la génération de pages pour le temps X avec le nombre de demandes par seconde Y. Avec des mesures numériques spécifiques en main, il est beaucoup plus facile d'évaluer le niveau de préparation et le résultat actuel.

Voici un plan général de formation technique:

1. Connaître les indicateurs actuels (effectuer des tests de charge de la version actuelle du site);
2. Pour comprendre ce qui manque exactement et combien de ressources sont nécessaires pour commander;
3. Ajouter des ressources;
4. Répétez les tests de résistance et voyez si cela aide.

Ça a l'air trop facile? Vous avez raison, chaque point est semé d'embûches.

Très souvent, l'ajout de ressources améliore partiellement la situation, mais ne sauve pas le tout. Ou dans un environnement de test, le site fonctionne comme une horloge, et sur la prod - encore une fois les freins.

Ensuite, je vais vous montrer comment identifier les problèmes potentiels et corriger les faiblesses. Commençons par comment effectuer des tests de résistance et obtenir un résultat réaliste.

Nous effectuons correctement les tests de charge

Où tester?

Souvent, les tests de résistance sont effectués sur un système productif. Cela peut être utile pour contrôler la situation dans son ensemble, mais pas pour résoudre de manière itérative des problèmes spécifiques. N'oubliez pas, généralement après de nouveaux problèmes découverts après l'élimination, de nouveaux peuvent apparaître. Les balles d'argent atteignent rarement la cible.

Un échec du test de charge peut gêner les utilisateurs du site ou même le «casser» pendant un certain temps. Il est préférable d'utiliser une zone dédiée comme lapin expérimental.

Il doit répondre aux exigences suivantes:

• La zone dédiée doit être complètement indépendante et isolée du productif;
  
• Idéalement, une zone dédiée doit correspondre à la taille du produit. Un modèle à grande échelle convient également, mais il réduira la qualité et l'importance des tests. Si la charge sur une ressource croît de façon non linéaire (comme cela arrive généralement), votre modèle ne montrera pas qu'en pleine charge, la ressource est épuisée à l'avance;
  
• Il est préférable d'utiliser exactement le même (mais pas le même!) Équipement pour les tests comme sur prod. Sinon, même si les valeurs quantitatives des ressources sont respectées, il ne sera pas possible de fournir de la qualité. Il peut jouer une blague cruelle au moment crucial. Si cela n'est pas possible, testez les performances de l'équipement sous votre charge et déterminez le coefficient de réglage.
  

Parlons maintenant des moyens de générer une charge de test. Je vais vous donner quelques techniques de base, chacune ayant ses avantages et ses inconvénients.

Comment générer une charge?

1. Test des demandes des journaux

Il est possible d'émuler le flux de trafic via les journaux du serveur de combat. Un avantage évident de cette approche est que vous n'avez pas à vous soucier de l'analyse, de la modélisation statistique et d'un profil de trafic synthétique.

Mais vous devez toujours nettoyer les journaux des demandes qui ne peuvent pas être effectuées ou qui ne sont pas nécessaires.
Par exemple, vous n'avez pas besoin «d'acheter» des biens sur le site de production, cela entraînera des problèmes avec le contenu du produit de la base de données.

Il sera difficile de reproduire des délais réalistes entre les demandes.
L'émulation de sessions utilisateur est également extrêmement difficile, cette méthode est très proche des tests basés sur les résultats.

2. Utilisation de Yandex.Tank et Phantom

Le réservoir en conjonction avec Phantom est un outil très pratique et populaire pour les tests basés sur les coups. Il a une interface réfléchie et vous permet de gérer la charge. Pour commencer à décortiquer à partir d'un réservoir, vous devez préparer des «cartouches» - des fichiers spéciaux contenant des demandes pour un générateur.

Mais, malgré toute la commodité, le Tank a un inconvénient majeur: il ne sait pas utiliser les sessions utilisateurs.

Vous pouvez oublier l'autorisation, le travail complet avec les cookies et les délais variables. Un réservoir ne peut «picorer» les demandes qu'à partir d'une seule adresse.

Il vous conviendra si:

• Il n'y a aucune différence dans le temps de réponse du serveur pour les utilisateurs autorisés et non autorisés, ou il est négligeable;
• Test de l'API sans sessions HTTP explicitement;
• Cette approche est généralement cohérente avec la logique de votre site (généralement pas adaptée aux boutiques en ligne).

3. Utilisation d'Apache JMeter

Il s'agit de l'outil le plus flexible qui vous permet d'émuler des sessions utilisateur en détail. Ainsi, avec son aide, vous pouvez toujours répondre à la question de l'entreprise "combien d'utilisateurs le site peut-il supporter?" De plus, JMeter peut fonctionner en tandem avec Yandex.Tank.
Son principal inconvénient est la consommation de ressources et la complexité de la préparation des tests.

Le principal conseil directement sur JMeter: essayez d'éviter d'analyser les corps de page avec ses forces, il est préférable d'utiliser des jeux de données pré-préparés pour reproduire la logique de session. En principe, il est préférable de minimiser le travail effectué par JMeter en général. Comme Tank, il est possible d'y attacher des "cartouches" pré-générées. C'est là qu'ils doivent prendre en compte la distribution de pages spécifiques au sein d'un même type, la variabilité des demandes et tout ce jazz.

Dans JMeter lui-même, les modèles de comportement des utilisateurs doivent être programmés. Si la tâche consiste à tester non seulement la partie serveur, mais également le retour du contenu statique, exécutez ce test séparément à l'aide de Phantom, si nécessaire simultanément avec le test JMeter. Cela contribuera à réduire considérablement la consommation de ressources du générateur de charge et à augmenter la reproductibilité du test.

Recommandations en matière de tests de résistance

Un bon test de charge est basé sur une analyse de trafic compétente et la préparation de haute qualité d'un modèle statistique et de profils d'émulation.

Mettez en surbrillance 5-7 principaux types de pages (n'oubliez pas également les pages de destination pour les stocks), calculez le pourcentage du trafic total réparti entre eux. N'oubliez pas qu'il peut y avoir plusieurs demandes de contenu dynamique par page. Pour vous, la page est l'ensemble du groupe de ces demandes. Analysez le temps que les utilisateurs passent sur chaque type de page: moyenne, minimum moyen, maximum moyen.

Si la page est construite sur plusieurs requêtes, tenez compte du délai entre elles. Voyez combien de pages un utilisateur visite habituellement par session, quelle est la distribution de ce nombre. Mettez en surbrillance 5 à 10 des chemins utilisateur les plus courants par type de page.

En utilisant les données obtenues, construisez les scénarios de manière à reproduire tous les paramètres statistiques décrits avec une extrême précision. N'oubliez pas la variabilité des scénarios, ils doivent varier à la fois en nombre et en composition de clics.

Dans chaque type de page, mettez en surbrillance des adresses individuelles. Le plus, le mieux, mais quelques milliers des adresses les plus populaires seront déjà sous les yeux. Vous pouvez en préparer des listes de requêtes en ajoutant chaque adresse à la liste autant de fois que nécessaire.

S'il y a trop de pages, divisez-les en plusieurs groupes en fonction du pourcentage de trafic.

Les profils ne jouent un rôle que pour JMeter, mais en créant des listes de requêtes, vous pouvez équiper des cartouches "tank".

Et encore: lorsque vous utilisez JMeter en mode d'émulation utilisateur, n'oubliez pas les délais entre les requêtes. Si vous ne les ajoutez pas, votre charge générée sera beaucoup plus élevée que prévu!

Après un essai, assurez-vous de vérifier les journaux du serveur Web pour voir si le trafic émulé est productif.

La voltige préparera les scripts à l'avance pour amener la base de données du site à l'état dont vous avez besoin. Habituellement, les données préparées de la manière décrite ci-dessus ne fonctionnent qu'avec l'état de la base de données pour laquelle des informations sur les marchandises ont été collectées. Il peut être extrêmement long de recharger le vidage SQL à chaque fois. De plus, il est très souhaitable d'apprendre à gérer les stocks en cours à l'aide de scripts dans la zone de test. Souvent, ils sont importants pour le fonctionnement du système, et vous devez comprendre avec quel ensemble et comment exactement les stocks de travail sont testés.

Tout est-il prêt? Super, allez-y!

Nous utilisons la surveillance dans les tests

Nous avons donc effectué des tests compétents et obtenu les résultats. Si tout va bien et que votre site fait face à une charge élevée, aucun Black Friday ne vous fait peur. Mais cet article serait incomplet si l'on ne considérait pas un triste scénario réaliste.

Imaginez qu'un site puisse résister à une vitesse acceptable ... enfin, même si seulement un cinquième de ce que l'entreprise souhaite obtenir. Est-il vraiment nécessaire d'appeler l'hébergeur dans la panique et de commander cinq fois plus de capacité?

En principe, l'hôte appréciera cette approche. Vous pourriez même obtenir le statut de client d'or.

Mais avant d'agir précipitamment, essayons de comprendre ce qui s'est exactement passé.

Votre bouée de sauvetage en mer de causes possibles est un système de surveillance.



Par conséquent, nous prenons du recul et installons autant d'échantillons que possible avant de tester. Idéalement, toutes les ressources épuisables devraient être surveillées.

Voici une liste pour vous aider à démarrer:

• Charge CPU (utilisation CPU, charge CPU);
• Chargement RAM;
• Chargement de disque (IOPS, latence);
• Nombre de connexions réseau (attente de temps, attente de fin, attente de fermeture, établie);
• Le nombre de prises ouvertes;
• Le nombre de processus utilisateur;
• Le nombre de fichiers ouverts;
• Trafic réseau (en mégabits et en paquets, plus erreurs et baisses).

Et aussi:

• Le nombre de requêtes, de réponses et de connexions à la base de données et aux autres composants;
• Vitesse de réponse des composants (base de données, serveur de recherche, caches, etc.);
• Tous les journaux disponibles pour les erreurs.

Pour tous ces paramètres, vous devez connaître les limites disponibles. Cela nous permettra de comprendre exactement où le «goulot d'étranglement» s'est formé lors des tests de résistance. N'oubliez pas que la plupart de ces «ressources» sont configurables, certaines sont généralement gérées par des paramètres.

Peut-être quelques modifications mineures seront suffisantes et les performances s'amélioreront.

Quelque part, des changements non quantitatifs mais qualitatifs seront nécessaires: par exemple, remplacer un disque dur par un SSD. Quelques conseils sur l'optimisation et la mise à l'échelle des applications Web, ainsi que l'amélioration de la tolérance aux pannes, peuvent être trouvés dans mon article précédent .

. .

: , , ? , , , 2- , - (, 0,5 ) 1,5 . - «, ».

1 , . , . , . , ( ) , .

, , , .

«» , . 2-3 , , .

, : . , . , , , , .

. . , SLA, , , , , «» .

. , . .

, , . , , .

, .
-, ( ), -, . .

, . - , .

, , , « e-commerce. », 16 . .