{"id":83188,"date":"2020-05-29T07:43:02","date_gmt":"2020-05-29T05:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali"},"modified":"2020-05-29T07:43:02","modified_gmt":"2020-05-29T05:43:02","slug":"kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","title":{"rendered":"Comment nous avons g\u00e9r\u00e9 une augmentation soudaine de la charge par x10 en t\u00e9l\u00e9travail et quelles conclusions nous en avons tir\u00e9es","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour, Habr ! Ces derniers mois, nous avons v\u00e9cu une situation tr\u00e8s int\u00e9ressante, et je voudrais partager notre histoire d'extensibilit\u00e9 de l'infrastructure. Pendant ce temps, SberMarket a vu ses commandes quadrupler et a lanc\u00e9 le service dans 17 nouvelles villes. L'explosion de la demande de livraison de produits a n\u00e9cessit\u00e9 l'extension de notre infrastructure. Lisez ci-dessous pour d\u00e9couvrir les conclusions les plus int\u00e9ressantes et utiles.<\/p>\n

\"Comment
\n<\/a><\/noindex>
\nJe m'appelle Dima Bobylev, je suis le directeur technique de SberMarket. Comme c'est le premier article de notre blog, je vais dire quelques mots sur moi et sur l'entreprise. L'automne dernier, j'ai particip\u00e9 \u00e0 un concours de jeunes leaders de Runet. Pour le concours, j ai \u00e9crit une petite histoire<\/a><\/noindex> sur la fa\u00e7on dont nous voyons chez SberMarket la culture interne et l'approche au d\u00e9veloppement du service. Bien que je n'aie pas r\u00e9ussi \u00e0 gagner le concours, j'ai cependant formul\u00e9 pour moi les principaux principes de d\u00e9veloppement de l'\u00e9cosyst\u00e8me IT. <\/p>\n

Lors de la gestion d'une \u00e9quipe, il est important de comprendre et de trouver un \u00e9quilibre entre ce dont l'entreprise a besoin et les besoins de chaque d\u00e9veloppeur sp\u00e9cifique. Actuellement, SberMarket conna\u00eet une croissance de 13 fois d'une ann\u00e9e sur l'autre, ce qui a un impact sur le produit, n\u00e9cessitant une augmentation constante des volumes et des cadences de d\u00e9veloppement. Malgr\u00e9 cela, nous consacrons suffisamment de temps aux d\u00e9veloppeurs pour une analyse pr\u00e9liminaire et une r\u00e9daction de code de qualit\u00e9. L'approche formul\u00e9e aide non seulement \u00e0 cr\u00e9er un produit fonctionnel, mais \u00e9galement \u00e0 son extensibilit\u00e9 et \u00e0 son d\u00e9veloppement ult\u00e9rieurs. En cons\u00e9quence de cette croissance, SberMarket est d\u00e9j\u00e0 devenu un leader parmi les services de livraison de produits : nous livrons quotidiennement environ 18 000 commandes par jour, alors qu'au d\u00e9but f\u00e9vrier, il y en avait environ 3 500.<\/p>\n

\"Comment
\nUn jour, un client a demand\u00e9 \u00e0 un coursier de SberMarket de lui livrer des produits de mani\u00e8re sans contact \u2014 directement sur son balcon.<\/i><\/p>\n

Mais passons aux choses concr\u00e8tes. Au cours des derniers mois, nous avons activement travaill\u00e9 sur l'extension de l'infrastructure de notre entreprise. Ce besoin \u00e9tait d\u00fb \u00e0 des facteurs externes et internes. En parall\u00e8le avec l'augmentation de notre base de clients, le nombre de magasins connect\u00e9s est pass\u00e9 de 90 au d\u00e9but de l'ann\u00e9e \u00e0 plus de 200 \u00e0 la mi-mai. Bien s\u00fbr, nous \u00e9tions pr\u00e9par\u00e9s, ayant r\u00e9serv\u00e9 l'infrastructure principale et pr\u00e9vu la possibilit\u00e9 d'une scalabilit\u00e9 verticale et horizontale de toutes les machines virtuelles h\u00e9berg\u00e9es dans le cloud de Yandex. Cependant, la pratique a montr\u00e9 : \u00ab Tout ce qui peut mal tourner, tournera mal \u00bb. Aujourd'hui, je souhaite partager les situations les plus int\u00e9ressantes qui se sont produites durant ces semaines. J'esp\u00e8re que notre exp\u00e9rience vous sera utile.<\/p>\n

Slave en pleine pr\u00e9paration op\u00e9rationnelle<\/h3>\n

\nAvant m\u00eame le d\u00e9but de la pand\u00e9mie, nous avons constat\u00e9 une augmentation du nombre de demandes sur nos serveurs backend. La tendance \u00e0 commander des produits avec livraison \u00e0 domicile a commenc\u00e9 \u00e0 prendre de l'ampleur, et avec l'introduction des premi\u00e8res mesures de confinement li\u00e9es \u00e0 la COVID-19, la charge augmentait de mani\u00e8re dramatique tout au long de la journ\u00e9e. Il est devenu n\u00e9cessaire de d\u00e9charger rapidement les serveurs master de la base de donn\u00e9es principale et de transf\u00e9rer une partie des demandes de lecture sur les serveurs r\u00e9pliques (slave).<\/p>\n

Nous nous \u00e9tions d\u00e9j\u00e0 pr\u00e9par\u00e9s \u00e0 cette \u00e9tape, et pour ce man\u0153uvre, 2 serveurs slave \u00e9taient d\u00e9j\u00e0 en service. Ils \u00e9taient principalement utilis\u00e9s pour les t\u00e2ches de batch g\u00e9n\u00e9rant des flux d'information pour l'\u00e9change de donn\u00e9es avec nos partenaires. Ces processus cr\u00e9aient une charge suppl\u00e9mentaire et avaient \u00e9t\u00e9 justement mis \u00ab de c\u00f4t\u00e9 \u00bb quelques mois plus t\u00f4t.\u00a0<\/p>\n

\u00c9tant donn\u00e9 que la r\u00e9plication se faisait sur le Slave, nous suivions le principe que les applications ne pouvaient interagir avec eux qu'en mode lecture seule. Le Plan de R\u00e9cup\u00e9ration apr\u00e8s Sinistre stipulait qu'en cas de catastrophe, nous pouvions simplement monter un Slave \u00e0 la place du Master et rediriger toutes les demandes d'\u00e9criture et de lecture vers le Slave. Cependant, nous souhaitions \u00e9galement utiliser les r\u00e9pliques pour les besoins du d\u00e9partement d'analyse, c'est pourquoi les serveurs n'avaient pas \u00e9t\u00e9 enti\u00e8rement transf\u00e9r\u00e9s en statut lecture seule, chaque h\u00f4te ayant son propre ensemble d'utilisateurs, et certains disposaient de droits d'\u00e9criture pour conserver les r\u00e9sultats interm\u00e9diaires des calculs.<\/p>\n

Jusqu'\u00e0 un certain niveau de charge, nous avons pu utiliser le ma\u00eetre \u00e0 la fois pour les \u00e9critures et les lectures lors du traitement des requ\u00eates http. Mi-mars, juste au moment o\u00f9 Sbermarket a d\u00e9cid\u00e9 de passer compl\u00e8tement au t\u00e9l\u00e9travail, nous avons connu une augmentation exponentielle des RPS. De plus en plus de nos clients ont commenc\u00e9 \u00e0 s'isoler ou \u00e0 travailler depuis chez eux, ce qui a eu un impact sur nos indicateurs de charge.<\/p>\n

La performance du \u00ab ma\u00eetre \u00bb devenait insuffisante, nous avons donc commenc\u00e9 \u00e0 d\u00e9placer certaines des requ\u00eates de lecture les plus lourdes vers une r\u00e9plique. Pour diriger les requ\u00eates d'\u00e9criture vers le ma\u00eetre et les lectures vers le slave, nous avons utilis\u00e9 la gemme ruby \u00abOctopus<\/a><\/noindex>\u00bb. Nous avons cr\u00e9\u00e9 un utilisateur sp\u00e9cial avec le suffixe _readonly sans droits d'\u00e9criture. Cependant, en raison d'une erreur de configuration sur l'un des h\u00f4tes, certaines requ\u00eates d'\u00e9criture ont \u00e9t\u00e9 envoy\u00e9es au serveur esclave au nom d'un utilisateur qui avait les droits appropri\u00e9s.<\/p>\n

Le probl\u00e8me ne s'est pas manifest\u00e9 imm\u00e9diatement, car la charge accrue a augment\u00e9 le retard des slaves. L'incoh\u00e9rence des donn\u00e9es a \u00e9t\u00e9 constat\u00e9e le matin, lorsque, apr\u00e8s les importations nocturnes, les slaves n'ont pas \u00ab rattrap\u00e9 \u00bb le ma\u00eetre. Nous avons mis cela sur le compte de la forte charge du service lui-m\u00eame et des importations li\u00e9es au lancement de nouveaux magasins. Mais fournir des donn\u00e9es avec un retard de plusieurs heures \u00e9tait inacceptable, et nous avons bascul\u00e9 les processus vers le deuxi\u00e8me slave analytique, car il disposait de ressources plus importantes et n'\u00e9tait pas charg\u00e9 de requ\u00eates de lecture (ce que nous avons utilis\u00e9 pour expliquer l'absence de retard de r\u00e9plication).de<\/strong>Lorsque nous avons compris les raisons de la \u00ab d\u00e9rive \u00bb du slave principal, le slave analytique \u00e9tait d\u00e9j\u00e0 hors service pour la m\u00eame raison. Malgr\u00e9 la pr\u00e9sence de deux serveurs suppl\u00e9mentaires vers lesquels nous avions pr\u00e9vu de transf\u00e9rer la charge en cas de d\u00e9faillance du ma\u00eetre, en raison d'une erreur malheureuse, il s'est av\u00e9r\u00e9 qu'\u00e0 un moment critique, nous n'en avions aucun.<\/p>\n

Mais comme nous avons non seulement effectu\u00e9 un dump de la base de donn\u00e9es (la restauration \u00e0 ce moment-l\u00e0 prenait environ 5 heures), mais aussi un snapshot du serveur ma\u00eetre, nous avons r\u00e9ussi \u00e0 lancer la r\u00e9plique en deux heures. Cependant, apr\u00e8s cela, nous avons d\u00fb faire face \u00e0 l'application du journal de r\u00e9plication pendant une p\u00e9riode prolong\u00e9e (car le processus se d\u00e9roule en mode mono-thread, mais cela est une autre histoire).<\/p>\n

Mais comme nous avons fait non seulement un dump de la base de donn\u00e9es (la restauration \u00e0 ce moment-l\u00e0 prenait environ 5 heures), mais aussi un snapshot du serveur ma\u00eetre, nous avons r\u00e9ussi \u00e0 relancer la r\u00e9plique en deux heures. Cependant, apr\u00e8s cela, nous avons d\u00fb appliquer le journal de r\u00e9plication pendant une p\u00e9riode prolong\u00e9e (car le processus se d\u00e9roule en mode monoc\u0153ur, mais c'est une toute autre histoire).<\/p>\n

Conclusion :<\/strong> Apr\u00e8s un tel incident, il est devenu clair qu'il fallait abandonner la pratique de la restriction des \u00e9critures pour les utilisateurs et d\u00e9clarer le serveur en mode lecture seule. Avec une telle approche, on peut \u00eatre assur\u00e9 que les r\u00e9pliques seront disponibles au moment critique.<\/p><\/blockquote>\n

<\/p>\n

L'optimisation m\u00eame d'une seule requ\u00eate lourde peut \u00ab redonner vie \u00bb \u00e0 la base de donn\u00e9es.<\/h3>\n

\nBien que nous mettions constamment \u00e0 jour le catalogue sur le site, les requ\u00eates que nous avons transf\u00e9r\u00e9es sur les serveurs esclaves affichaient un l\u00e9ger retard par rapport au serveur ma\u00eetre. Le temps pris pour d\u00e9tecter et r\u00e9soudre le probl\u00e8me des esclaves \u00ab soudainement hors course \u00bb d\u00e9passait le \u00ab seuil psychologique \u00bb (durant ce temps, une mise \u00e0 jour des prix pouvait avoir lieu, et les clients auraient vu des donn\u00e9es obsol\u00e8tes), ce qui nous a contraints \u00e0 rediriger toutes les requ\u00eates vers le serveur principal de la base de donn\u00e9es. En cons\u00e9quence, le site fonctionnait lentement... mais au moins fonctionnait. Et pendant que l'esclave se r\u00e9tablissait, nous n'avions d'autre choix que l'optimisation.\u00a0<\/p>\n

Alors que les serveurs esclaves se r\u00e9tablissaient, chaque minute passait lentement, le ma\u00eetre restait surcharg\u00e9, et nous avons concentr\u00e9 tous nos efforts sur l'optimisation des t\u00e2ches actives selon la \u00ab r\u00e8gle de Pareto \u00bb : nous avons s\u00e9lectionn\u00e9 les TOP-requ\u00eates g\u00e9n\u00e9rant la majorit\u00e9 de la charge et avons commenc\u00e9 \u00e0 effectuer des r\u00e9glages. Cela se faisait en temps r\u00e9el.<\/p>\n

Un effet int\u00e9ressant \u00e9tait que MySQL, charg\u00e9 \u00e0 bloc, r\u00e9agissait m\u00eame \u00e0 une l\u00e9g\u00e8re am\u00e9lioration des processus. L'optimisation de quelques requ\u00eates, qui n'assuraient que 5 % de la charge totale, a d\u00e9j\u00e0 montr\u00e9 une r\u00e9duction significative de l'utilisation du CPU. En cons\u00e9quence, nous avons r\u00e9ussi \u00e0 garantir une r\u00e9serve de ressources acceptable pour le fonctionnement du ma\u00eetre avec la base de donn\u00e9es et \u00e0 obtenir le temps n\u00e9cessaire pour r\u00e9cup\u00e9rer les r\u00e9pliques.\u00a0<\/p>\n

Conclusion :<\/strong> M\u00eame une petite optimisation permet de \u00ab survivre \u00bb \u00e0 une surcharge pendant plusieurs heures. C'est pr\u00e9cis\u00e9ment ce qu'il nous a fallu pour le temps de r\u00e9cup\u00e9ration des serveurs avec les r\u00e9pliques. \u00c0 propos, nous discuterons de l'aspect technique de l'optimisation des requ\u00eates dans l'un de nos prochains articles. Donc, abonnez-vous \u00e0 notre blog si cela peut vous \u00eatre utile.<\/p><\/blockquote>\n

<\/p>\n

Organisez la surveillance de la disponibilit\u00e9 des services partenaires.<\/h3>\n

\nNous traitons les commandes des clients, et donc nos services interagissent constamment avec des API tierces \u2014 il s'agit de passerelles pour l'envoi de SMS, de plateformes de paiement, de syst\u00e8mes de routage, de g\u00e9ocodeurs, des services de la FNS et de nombreux autres syst\u00e8mes. Et lorsque la charge a commenc\u00e9 \u00e0 augmenter rapidement, nous avons commenc\u00e9 \u00e0 rencontrer les limites API de nos services partenaires, auxquelles nous n'avions m\u00eame pas pens\u00e9 auparavant.<\/p>\n

Un d\u00e9passement inattendu des quotas des services partenaires peut entra\u00eener un temps d'arr\u00eat pour le v\u00f4tre. De nombreuses API bloquent les clients qui d\u00e9passent les limites, et dans certains cas, un exc\u00e8s de requ\u00eates peut surcharger la production chez le partenaire.\u00a0<\/p>\n

Par exemple, au moment de l'augmentation du nombre de livraisons, les services d'accompagnement ne parvenaient pas \u00e0 g\u00e9rer les t\u00e2ches de distribution et de d\u00e9termination des parcours. En cons\u00e9quence, des commandes \u00e9taient pass\u00e9es, mais le service qui cr\u00e9ait le parcours ne fonctionnait pas. Il faut dire que nos logisticiens ont r\u00e9alis\u00e9 l'impossible dans ces conditions, et l'interaction claire de l'\u00e9quipe a aid\u00e9 \u00e0 compenser les pannes temporaires des services. Mais un tel volume de demandes n'est pas r\u00e9aliste \u00e0 traiter manuellement en permanence, et au bout d'un certain temps, nous serions confront\u00e9s \u00e0 une rupture inacceptable entre les commandes et leur ex\u00e9cution.\u00a0<\/p>\n

Un certain nombre de mesures organisationnelles ont \u00e9t\u00e9 mises en place et le travail coordonn\u00e9 de l'\u00e9quipe nous a permis de gagner du temps, pendant que nous n\u00e9gociions de nouveaux termes et attendions la modernisation des services de certains partenaires. Il existe d'autres API qui offrent une grande robustesse et des tarifs exorbitants en cas de trafic \u00e9lev\u00e9. Par exemple, au d\u00e9but, nous utilisions une API cartographique connue pour d\u00e9terminer l'adresse du point de livraison. Mais \u00e0 la fin du mois, nous avons re\u00e7u une facture rondelette de pr\u00e8s de 2 millions de roubles. Apr\u00e8s cela, nous avons d\u00e9cid\u00e9 de le remplacer rapidement. Je ne vais pas faire de publicit\u00e9, mais je dirai que nos d\u00e9penses ont largement diminu\u00e9.
\n\"Comment<\/p>\n

Conclusion : <\/strong>Il est imp\u00e9ratif de surveiller les conditions de travail de tous les services partenaires et de les garder \u00e0 l'esprit. M\u00eame si aujourd'hui il semble qu'ils disposent d'une \u00ablarge marge\u00bb, cela ne signifie pas que demain ils ne deviendront pas un obstacle \u00e0 la croissance. Et bien s\u00fbr, il est pr\u00e9f\u00e9rable de s'accorder \u00e0 l'avance sur les conditions financi\u00e8res des demandes accrues au service.\u00a0<\/p><\/blockquote>\n

<\/p>\n

Il arrive parfois que \u00abil faille plus d'or<\/a><\/noindex>\u00bb (c) ne soit pas utile<\/h3>\n

\nNous sommes habitu\u00e9s aux \u00ab goulets d'\u00e9tranglement \u00bb dans la base de donn\u00e9es principale ou sur les serveurs d'applications, mais lors de la mise \u00e0 l'\u00e9chelle, des probl\u00e8mes peuvent survenir l\u00e0 o\u00f9 on ne les attend pas. Pour la recherche en texte int\u00e9gral sur le site, nous utilisons le moteur Apache Solr. Avec l'augmentation de la charge, nous avons constat\u00e9 une diminution du temps de r\u00e9ponse, et l'utilisation du processeur du serveur atteignait d\u00e9j\u00e0 100 %. Quoi de plus simple \u2014 nous allons donner plus de ressources au conteneur avec Solr.<\/p>\n

Au lieu d'une augmentation de performance attendue, le serveur s'est simplement \u00ab \u00e9teint \u00bb. Il se chargeait imm\u00e9diatement \u00e0 100 % et r\u00e9pondait encore plus lentement. Au d\u00e9part, nous avions 2 c\u0153urs et 2 Go de RAM. Nous avons d\u00e9cid\u00e9 de faire ce qui aide g\u00e9n\u00e9ralement \u2014 nous avons donn\u00e9 au serveur 8 c\u0153urs et 32 Go. Tout est devenu beaucoup pire (comment et pourquoi exactement \u2014 nous en parlerons dans un autre billet).\u00a0<\/p>\n

En quelques jours, nous avons compris les subtilit\u00e9s de cette question et avons atteint une performance optimale avec 8 c\u0153urs et 32 Go. Cette configuration permet encore aujourd'hui de continuer \u00e0 augmenter la charge, ce qui est tr\u00e8s important, car la croissance ne concerne pas uniquement le nombre de clients, mais aussi le nombre de magasins connect\u00e9s \u2014 en 2 mois, leur nombre a doubl\u00e9.\u00a0<\/p>\n

Conclusion : <\/strong>Les m\u00e9thodes standard comme \u00ab ajouter plus de mat\u00e9riel \u00bb ne fonctionnent pas toujours. Ainsi, lors de la mise \u00e0 l'\u00e9chelle de tout service, il est crucial de bien comprendre comment il utilise les ressources et de tester \u00e0 l'avance son fonctionnement dans de nouvelles conditions.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Stateless \u2014 la cl\u00e9 d'une mise \u00e0 l'\u00e9chelle horizontale simple.<\/h3>\n

\nDans l'ensemble, notre \u00e9quipe adh\u00e8re \u00e0 l'approche bien connue : les services ne doivent pas avoir d'\u00e9tat interne (stateless) et doivent \u00eatre ind\u00e9pendants de l'environnement d'ex\u00e9cution. Cela nous a permis de faire face \u00e0 l'augmentation de la charge par une mise \u00e0 l'\u00e9chelle horizontale simple. Mais nous avions un service d'exception \u2014 le gestionnaire de t\u00e2ches de fond prolong\u00e9es. Il s'occupait de l'envoi d'emails et de SMS, du traitement des \u00e9v\u00e9nements, de la g\u00e9n\u00e9ration de flux, de l'importation des prix et des stocks, du traitement des images. Il se trouvait que ce service d\u00e9pendait d'un stockage de fichiers local et qu'il n'existait qu'en un seul exemplaire.\u00a0<\/p>\n

Lorsque le nombre de t\u00e2ches dans la file d'attente du processeur a augment\u00e9 (ce qui est naturellement survenu avec l'augmentation du nombre de commandes), la performance de l'h\u00f4te, sur lequel \u00e9taient h\u00e9berg\u00e9s le processeur et le stockage de fichiers, est devenue un facteur limitant. En cons\u00e9quence, la mise \u00e0 jour de l'assortiment et des prix, ainsi que l'envoi de notifications aux utilisateurs et de nombreuses autres fonctions critiques, se sont retrouv\u00e9es bloqu\u00e9es dans la file d'attente. L'\u00e9quipe Ops a rapidement migr\u00e9 le stockage de fichiers vers un stockage en r\u00e9seau de type S3, ce qui nous a permis de mettre en place plusieurs machines puissantes pour que le processeur de t\u00e2ches en arri\u00e8re-plan puisse \u00eatre \u00e9volutif.<\/p>\n

Conclusion : <\/strong>La r\u00e8gle Stateless doit \u00eatre respect\u00e9e pour tous les composants sans exception, m\u00eame si l'on pense \u00ab qu'ici, cela ne posera pas de probl\u00e8me \u00bb. Mieux vaut passer un peu de temps \u00e0 bien organiser le fonctionnement de tous les syst\u00e8mes que de devoir r\u00e9\u00e9crire du code \u00e0 la h\u00e2te et de r\u00e9parer un service subissant une surcharge.<\/p><\/blockquote>\n

<\/p>\n

7 principes pour une croissance intensive<\/h2>\n

\nMalgr\u00e9 la disponibilit\u00e9 de puissances suppl\u00e9mentaires, au cours de notre croissance, nous avons rencontr\u00e9 plusieurs obstacles. Pendant cette p\u00e9riode, le nombre de commandes a augment\u00e9 de plus de 4 fois. Nous livrons maintenant plus de 17 000 commandes par jour dans 62 villes et pr\u00e9voyons d'\u00e9largir encore notre zone g\u00e9ographique \u2014 au premier semestre 2020, le lancement du service est attendu dans toute la Russie. Afin de faire face \u00e0 la charge croissante, en tenant compte des le\u00e7ons d\u00e9j\u00e0 apprises, nous avons identifi\u00e9 7 principes de base pour travailler dans des conditions de croissance constante :<\/p>\n

    \n
  1. Gestion des incidents<\/strong>. Nous avons cr\u00e9\u00e9 un tableau dans Jira, o\u00f9 chaque incident est refl\u00e9t\u00e9 sous forme de ticket. Cela aidera \u00e0 prioriser effectivement et \u00e0 ex\u00e9cuter les t\u00e2ches li\u00e9es \u00e0 l'incident. Apr\u00e8s tout, il n'est pas vraiment effrayant de faire des erreurs \u2014 ce qui est effrayant, c'est de r\u00e9p\u00e9ter les m\u00eames erreurs. Dans les cas o\u00f9 les incidents se reproduisent avant que nous puissions corriger la cause, une proc\u00e9dure d'action doit \u00eatre pr\u00eate, car pendant une forte charge, il est important de r\u00e9agir instantan\u00e9ment.<\/li>\n
  2. Surveillance <\/strong>n\u00e9cessaire pour tous les \u00e9l\u00e9ments de l'infrastructure sans exception. C'est gr\u00e2ce \u00e0 cela que nous avons pu pr\u00e9voir l'augmentation de la charge et choisir correctement les \u00abgoulots d'\u00e9tranglement\u00bb \u00e0 prioriser pour l'\u00e9limination. En cas de forte charge, tout ce \u00e0 quoi vous n'avez pas pens\u00e9 risque de tomber en panne ou de commencer \u00e0 ralentir. C'est pourquoi il est pr\u00e9f\u00e9rable de cr\u00e9er de nouvelles alertes imm\u00e9diatement apr\u00e8s les premiers incidents, afin de les surveiller et de les anticiper.<\/li>\n
  3. Alertes appropri\u00e9es<\/strong> sont tout simplement n\u00e9cessaires en cas d'augmentation rapide de la charge. Premi\u00e8rement, elles doivent signaler ce qui est r\u00e9ellement tomb\u00e9 en panne. Deuxi\u00e8mement, il ne doit pas y avoir trop d'alertes, car une surabondance d'alertes non critiques m\u00e8ne \u00e0 l'ignorance de toutes les notifications.<\/li>\n
  4. Les applications doivent \u00eatre sans \u00e9tat. <\/strong>Nous avons constat\u00e9 qu'il ne doit pas y avoir d'exceptions \u00e0 cette r\u00e8gle. Une ind\u00e9pendance totale par rapport \u00e0 l'environnement d'ex\u00e9cution est n\u00e9cessaire. Vous pouvez stocker des donn\u00e9es partag\u00e9es dans une base de donn\u00e9es ou, par exemple, directement dans S3. Mieux encore, suivez les r\u00e8gles https:\/\/12factor.net<\/a><\/noindex>. Lors d'une augmentation rapide des temps, il n'y a tout simplement pas de temps pour optimiser le code, et il faudra g\u00e9rer la charge par une augmentation directe des ressources de calcul et un redimensionnement horizontal.<\/li>\n
  5. Quotas et performances des services externes. <\/strong>Lors d'une forte croissance, le probl\u00e8me peut survenir non seulement dans votre infrastructure, mais aussi dans le service externe. Ce qui est frustrant, c'est que cela se produit non pas \u00e0 cause d'une d\u00e9faillance, mais en raison de l'atteinte des quotas ou des limites. Ainsi, les services externes doivent \u00e9voluer aussi bien que vous.\u00a0<\/li>\n
  6. S\u00e9parez les processus et les files d'attente. <\/strong>C'est tr\u00e8s utile lorsque l'un des passerelles rencontre un blocage. Nous ne rencontrerions pas de retard dans le transfert de donn\u00e9es si les files d'attente de l'envoi des SMS ne g\u00eanaient pas l'\u00e9change de notifications entre les syst\u00e8mes d'information. Et le nombre de travailleurs serait plus facile \u00e0 augmenter s'ils fonctionnaient s\u00e9par\u00e9ment.<\/li>\n
  7. R\u00e9alit\u00e9s financi\u00e8res.<\/strong> Lorsque la croissance des flux de donn\u00e9es est explosive, il n'y a pas de temps pour r\u00e9fl\u00e9chir aux tarifs et aux abonnements. Mais il faut y penser, surtout si vous \u00eates une petite entreprise. Une facture importante peut \u00eatre \u00e9mise par le propri\u00e9taire de n'importe quelle API, ainsi que par votre fournisseur d'h\u00e9bergement. Il faut donc lire les contrats attentivement.<\/li>\n<\/ol>\n

    <\/p>\n

    Conclusion<\/h2>\n

    \nAvec quelques pertes, nous avons travers\u00e9 cette \u00e9tape et aujourd'hui, nous nous effor\u00e7ons de respecter tous les principes identifi\u00e9s, chaque machine ayant la possibilit\u00e9 d'augmenter facilement sa performance par un facteur de 4, afin de faire face \u00e0 des impr\u00e9vus.\u00a0<\/p>\n

    Dans les prochains articles, nous partagerons notre exp\u00e9rience sur l'analyse de la baisse de performance dans Apache Solr, ainsi que sur l'optimisation des requ\u00eates et comment la collaboration avec la FNS aide l'entreprise \u00e0 \u00e9conomiser de l'argent. Abonnez-vous \u00e0 notre blog pour ne rien manquer et faites-nous savoir dans les commentaires si vous avez rencontr\u00e9 des probl\u00e8mes similaires lors d'une augmentation de trafic.<\/p>\n

    \"Comment<\/p>\n

    Seuls les utilisateurs enregistr\u00e9s peuvent participer au sondage. Connectez-vous<\/a><\/noindex>, s'il vous pla\u00eet.<\/p>\n

    Avez-vous d\u00e9j\u00e0 rencontr\u00e9 un ralentissement ou une chute de service lors d'une forte augmentation de charge due \u00e0 :<\/h2>\n