⛹🏿 ☝🏿 💯 Comment nous avons aidé les écoles à passer à l'enseignement à distance et à faire face à la charge 👨🏻‍⚖️ ♈️ ⛔️

Bonjour, Habr! Je m’appelle Alexey Vakhov, je suis le directeur technique d’Uchi.ru. À la mi-mars, lorsque les écoles ont commencé à passer à l'enseignement à distance, nous avons fourni aux enseignants et aux élèves plusieurs services pour les cours en ligne. Selon nos calculs, nous avions une marge de sécurité pour supporter un maximum de 1,5 à 2 fois la charge. À la mi-avril, notre trafic a augmenté 8 fois. J'ai dû faire beaucoup pour rester à flot. Peut-être que quelqu'un aura besoin de notre expérience pour survivre à cette crise ou à une crise future.

Nous ne nous attendions pas à de telles surprises et nous n'étions pas prêts pour elles, probablement pas une seule entreprise en Russie, ni dans le monde, n'était prête pour cela. Habituellement, en mars, l'activité sur Uchi.ru est plus faible par rapport à l'automne en raison du printemps et des vacances d'été à venir, période à laquelle nous nous préparons déjà pour septembre: nous scions des éléments, faisons du refactoring, effectuons des changements architecturaux à grande échelle et faisons une autre routine agréable. Mais cette fois, c'était différent.

Le nombre maximal d'utilisateurs uniques sur le site a atteint à la fois 240 000, nous avons enregistré le maximum précédent de l'année scolaire en cours sur 30 000 personnes. À ce stade, la charge a augmenté chaque jour et nous avons travaillé sans relâche pour stabiliser le site.

Lorsqu'une telle charge tombe sur le site, en règle générale, les applications, les services, les équilibreurs, les bases, le Web, les canaux sont formés. Tous les «goulots d'étranglement» de l'infrastructure sont exposés. Dans de telles conditions, il est difficile de diagnostiquer les problèmes - symptomatiquement, tout est buggé. Il est facile à réparer lorsque le trafic augmente en douceur et qu'une chose tombe en panne. Lorsque la charge passe en rafale, l'un des gros problèmes est de comprendre les causes des pannes.

La stratégie pour travailler dans de telles conditions est d'éliminer ce qui frappe le plus le site, puis de trouver le prochain point le plus douloureux, en même temps de rechercher les problèmes potentiels et de les résoudre, etc. Voici quelques-unes des choses les plus notables que nous avons faites pour stabiliser la plate-forme.

Comptez sur vous-même

Lors d'une crise avant la circulation, vous en tant qu'équipe devenez un. Cela dépendra de vos employés, que vous trouviez des solutions, que vous affrontiez la crise ou non.

Il n'y a personne dans l'industrie qui viendrait, examinerait votre système complexe, ferait immédiatement quelque chose et tout irait bien. Bien sûr, dans le monde, il y a suffisamment de spécialistes qui pourront faire face à la tâche si le temps le permet. Mais lorsqu'une solution fondamentale est nécessaire dès maintenant, vous ne pouvez compter que sur votre équipe, qui connaît le système et ses spécificités. Le résultat et la responsabilité de l'entreprise incombent à l'équipe. Un examen externe est conseillé pour se connecter en point.

La coordination opérationnelle de l'équipe anti-crise dans une conversation spéciale à Slack nous a aidés à naviguer rapidement et à construire du travail - tous les problèmes ont été résolus ici et maintenant. Nous avons divisé les domaines de responsabilité entre les employés afin qu'il n'y ait pas d'intersections et que les gars ne fassent pas un double travail. Les jours les plus difficiles, je devais être en contact littéralement 24 heures sur 24.

Cloud étendu

Vous ne pouvez pas vous assurer contre toutes les crises, mais il est important d'être flexible. La pile de nuages nous a donné une telle plasticité et une chance de rester à flot même avec une augmentation aussi spectaculaire de la charge.

Au départ, nous avons augmenté les ressources sous la charge accrue, mais à un moment donné, nous avons rencontré les quotas de la région de notre fournisseur de cloud. Des problèmes se sont posés à son niveau: nos serveurs virtuels ont été affectés par des voisins, sur lesquels le trafic a également augmenté, ce qui a provoqué des défaillances dans le fonctionnement de nos applications. Cela était attendu: nous dépendons du fournisseur et de son infrastructure, qui à son tour a également connu une charge élevée. Nous avons publié certaines ressources provenant de machines virtuelles non prioritaires pour le site principal. Avec le fournisseur, nous nous sommes mis d'accord sur une ressource dédiée.

Outils de surveillance améliorés

Pendant la crise, alert n'a pas réellement rempli sa fonction. Tous les membres de l'équipe surveillaient déjà tous les systèmes 24 heures sur 24 et la gestion des incidents a été réduite à un travail constant sur tous les fronts. Pour diagnostiquer pleinement les problèmes que nous avons rencontrés, nous avions trop peu de données. Par exemple, pour surveiller les machines virtuelles, nous utilisons l'exportateur de nœuds standard pour Prometheus. Il est bon de voir la situation dans son ensemble, pour regarder de plus près une seule machine virtuelle a commencé à utiliser NetData.

Stockage de cache optimisé

Un problème s'est également posé avec les magasins de valeurs-clés. Dans l'une des applications, Redis ne pouvait pas faire face - en une seule copie, il ne pouvait fonctionner que sur un seul cœur. Par conséquent, ils ont utilisé un fork Redis appelé KeyDB, qui peut fonctionner dans plusieurs threads.

Pour augmenter la bande passante dans une autre application, nous avons levé 10 Redis'ov indépendants. Ils sont mandatés par notre Service Mesh, qui partage également des clés. Même si un ou deux Redis plantent, cela ne causera pas de problèmes en raison d'un hachage cohérent. De plus, ils n'ont pratiquement pas besoin d'être administrés.

Extension du réseau

Comme vous le savez, 640 Ko suffisent à tout le monde. Nous avons toujours utilisé des sous-réseaux privés / 24, mais dans le contexte de la quarantaine, nous avons dû nous étendre d'urgence à / 22. Maintenant que le réseau héberge quatre fois plus de serveurs, nous espérons que cela suffira à coup sûr.

PgBouncer réalisé séparément

En tant que base de données relationnelle, nous utilisons PostgreSQL partout, quelque part dans de petites instances virtuelles et quelque part - l'installation de plusieurs grands serveurs dédiés pour le maître et les répliques. Le goulot d'étranglement évident de cette architecture est le maître qui, dans le cas idéal, n'est utilisé que pour l'enregistrement et n'est pas mis à l'échelle horizontalement. Avec la croissance du trafic, nous avons commencé à nous reposer sur le CPU.

Dans le même temps, nous utilisons PgBouncer, qui a été installé sur l'assistant et sur chaque réplique, pour gérer les connexions. Sur un port, il ne peut pas utiliser plus d'un cœur de processeur, donc sur chaque serveur, nous avions plusieurs videurs. À un moment donné, il est devenu clair que PgBouncer lui-même a retiré la partie tangible du CPU de la base, et à la charge maximale, nous avons connu une augmentation rapide de la moyenne de charge et une baisse des performances du système.

Nous avons déplacé les videurs vers un serveur distinct, ce qui nous a permis d'économiser 20 à 25% du processeur sur chaque serveur de base de données.

Face aux surprises

Un seul outil n'est pas fiable, surtout en temps de crise. Au contraire, la redondance des outils est utile, car elle permet de voir une image plus objective. Les outils familiers commencent à échouer pour diverses raisons. Par exemple, généralement pour estimer le nombre de personnes sur un site, nous utilisons généralement un rapport Google Analytics en temps réel, il s'agit d'une mesure sensible et précise. Mais parfois, c'est buggé et cette fois, nous avons dû examiner des mesures internes comme le nombre d'événements de consultation de page et le nombre de demandes par seconde.

Pour la journalisation centralisée, nous utilisons ELK. Notre pipeline de livraison de journaux est basé sur Apache Kafka et Elastic Filebeat. Sous une charge élevée, le convoyeur de livraison de journaux a cessé de fonctionner, les journaux ont commencé à se perdre ou à prendre du retard. Nous avons augmenté la vitesse de transfert des journaux et l'indexation du stockage en manipulant les index Elasticsearch, en augmentant le nombre de partitions dans Kafka et Filebeat et en optimisant la compression à toutes les étapes. Étant donné que le pipeline de collecte des journaux est distinct de la production, les problèmes liés à l'augmentation du trafic vers les journaux n'ont eu aucun effet sur le fonctionnement du site.

Accepté les règles du jeu

Il est impossible de se préparer à l'avance à chaque crise, mais vous pouvez d'abord essayer de construire un système flexible. Startups ou entreprises qui cessent progressivement d'être des startups, dans un temps calme, il n'est pas toujours rationnel de se préparer à une croissance anormale du trafic: les ressources de l'équipe sont limitées. Si nous mettons de côté leur préparation pour quelque chose qui ne se produira peut-être jamais, il n'y aura plus de force pour le produit principal. Il est beaucoup plus important de réagir correctement sur le moment et de ne pas avoir peur des décisions audacieuses. En règle générale, la sortie de leur crise est une sortie vers un niveau qualitativement nouveau.

Voici un printemps si amusant cette année. Quand il semble que tout a été fait, il s'avère parfois que ce n'est que le début.

Comment nous avons aidé les écoles à passer à l'enseignement à distance et à faire face à la charge