Get best of the week

Infrastructure alimentaire: comment nous soutenons Tanuki



Pour paraphraser une figure historique célèbre, le plus important de tous les services pour nous est la livraison. Que ferions-nous dans la situation actuelle sans rouleaux ni pizza à la maison? Je ne veux pas imaginer. Il se trouve qu'il y a 2 ans, nous avons pris en charge l'un des plus grands réseaux - Tanuki . L'audience mensuelle du site est d'environ un million de personnes. C'est maintenant en 2020. En 2018, lorsque le Tanuki a commencé à coopérer avec nous, il était 2 fois plus petit. Nous avons assuré un déménagement indolore vers un nouveau centre de données et refait complètement l'infrastructure - grâce à laquelle, en fait, le site et les applications sont capables de résister à la charge accrue sans problème.

Parfois, nous regrettons fortement d'être géographiquement loin du restaurant Tanuki le plus proche: sinon, tous nos succès (et petits malheurs) seraient bloqués avec de délicieux petits pains.

De manière générale, aujourd'hui, nous voulons vous raconter l'histoire du soutien d'un des plus grands projets Web de «l'industrie hôtelière» nationale.

Nous nous sommes rencontrés fin mars 2018.

La Journée internationale de la femme s'est écoulée depuis longtemps, mais les gars viennent de faire face à ses conséquences. Tout est assez banal: à la veille du 8 mars, le trafic a fortement augmenté, et le site était indisponible depuis longtemps. Vraiment long, pas quelques heures. Parce que le trafic passait non seulement par le site principal, mais provenait également de l'application (disponible pour Android et iOS), ainsi que des agrégateurs (Yandex.Food, Delivery Club, Zaka-Zaka).

Ce que nous avons vu


Techniquement, le projet s'est avéré assez compliqué:

  • Le site est une application React avec SSR (rendu côté serveur).
  • Applications mobiles - pour iOS / Android.
  • API - toutes les applications fonctionnent avec.
  • Systèmes externes, y compris le traitement des commandes.


Le système était un serveur proxy inverse: le trafic vers eux passait par le système de protection contre les attaques DDoS et à partir de là, il était déjà réparti entre les serveurs backend. Au moment de l'acceptation, il y avait un ancien site et une API pour les versions mobiles, et le développement d'un nouveau site a commencé. Le développement de la nouvelle API a été réalisé sur des serveurs séparés.

Le cluster de base de données se composait de deux serveurs avec réplication maître / maître, où la commutation en cas de défaillance était effectuée au niveau du réseau en raison d'une IP flottante. Toutes les applications d'écriture fonctionnaient avec cette IP, tandis qu'il y avait des esclaves MySQL pour la lecture situés sur chaque serveur principal - où l'application, en conséquence, fonctionnait avec localhost.

A la réception, nous avons vu les problèmes suivants:

  • Un mécanisme d'équilibrage insuffisamment fiable dans la configuration de la base de données. Le maître de réplication maître a conduit à des échecs fréquents.
  • Esclaves sur chaque backend - nécessitaient une grande quantité d'espace disque. Et toute manipulation ou ajout de nouveaux serveurs backend coûtait cher.
  • Il n'y avait pas de système de déploiement commun pour les applications - il y avait un système de déploiement autonome via le Web.
  • Il n'existait pas de système de collecte des journaux - à la suite de quoi il est assez difficile d'enquêter sur les incidents, principalement en travaillant avec le système de commande, car il n'y a aucun moyen de déterminer comment une commande a été reçue.
  • Il n'y avait aucun suivi des indicateurs commerciaux - il n'a pas été possible d'enregistrer en temps opportun une diminution ou une absence totale de commandes.

Après l'audit initial des serveurs acceptés pour la surveillance, nous avons commencé par la formation d'une feuille de route opérationnelle. Initialement, deux principaux domaines de travail ont été identifiés:
  1. Stabilisation des applications.
  2. Organisation d'un environnement de développement confortable pour la nouvelle API et le nouveau site.

Les décisions dans la première direction étaient principalement liées à la stabilisation du cluster MySQL. Je ne voulais pas refuser le maître de réplication maître, mais il était impossible de continuer à travailler avec une IP flottante. Des perturbations de la connectivité réseau ont été régulièrement observées, ce qui a entraîné des perturbations dans le fonctionnement du cluster.

Tout d'abord, nous avons décidé d'abandonner l'IP flottante au profit d'un serveur proxy, où l'amont sera contrôlé entre les maîtres, car nous avons utilisé nginx comme proxy pour MySQL. La deuxième étape est l'allocation de deux serveurs distincts pour les esclaves. Le travail avec eux a également été organisé via un serveur proxy. Et depuis la réorganisation, nous avons oublié les problèmes liés au travail avec la base de données.

Ensuite, nous avons surveillé les commandes au niveau de la requête dans la base de données. Tout écart par rapport à la norme - dans une plus ou moins grande mesure - a immédiatement donné lieu à une enquête. Ensuite, au niveau du journal, nous avons formé des métriques de suivi des interactions externes, notamment avec le système de gestion des commandes.

En collaboration avec des collègues, à leur demande, nous avons effectué un ajustement supplémentaire de tous les systèmes pour un fonctionnement stable et rapide. Il s'agissait à la fois de régler MySQL et de mettre à jour les versions de PHP. De plus, des collègues ont introduit un système de mise en cache basé sur Redis, qui a également contribué à réduire la charge sur la base de données.

Tout cela était important ... Mais l'essentiel pour l'entreprise était une augmentation des ventes. Et dans ce contexte, les chefs d'entreprise avaient de grands espoirs pour le nouveau site. Pour les développeurs, il était nécessaire de disposer d'un système stable et pratique pour le déploiement et le contrôle des applications.

Tout d'abord, nous avons pensé aux pipelines d'assemblage et de livraison de l'application CI / CD, ainsi qu'aux systèmes de collecte et de travail des logs.

Tous les référentiels clients étaient hébergés sur une solution bitbucket auto-hébergée . Pour l'organisation des pipelines, jenkins a été choisi.

Pour commencer, il était habituel de mettre en œuvre des pipelines sur des environnements de développement - cela nous a permis d'augmenter considérablement la vitesse de développement. Ensuite, il a été introduit sur les circuits de production, où le déploiement automatique a évité les erreurs fréquentes, généralement causées par le facteur humain.

Après la mise en œuvre, CI / CD a commencé à organiser la collecte des journaux et à travailler avec eux. La pile ELK a été choisie comme principale, ce qui a permis au client de mener des enquêtes plus rapidement et mieux en cas d'incident. Et en conséquence, le développement d'applications est allé plus vite.

"Plus terrible que deux incendies ..."


Après avoir résolu des tâches assez complexes mais néanmoins standard, les Tanuki nous ont dit ce qu'ils voulaient dire depuis longtemps: «Bougeons!»

Le changement de DC a été causé par des facteurs économiques. De plus, le client a étendu son infrastructure avec des services supplémentaires qui étaient déjà dans le nouveau DC, ce qui a également influencé la décision de déménager.

La migration de tout système, et encore moins d'un système complexe, est un processus qui nécessite une planification approfondie et de grandes ressources.

Le déménagement a été réalisé de manière itérative: lors de la première étape, des serveurs proxy inverses ont été créés dans le nouveau DC. Et comme seuls ils ont une adresse IP publique, ils ont également servi de points d'accès au système pour les administrateurs.

Ensuite, nous avons lancé tous les services d'infrastructure - journalisation et CI / CD. Un consula permis d'organiser un service d'interaction pratique, gérable et assez fiable entre les applications clientes.

Les bases de données suivantes ont migré, Redis et le courtier de files d'attente - RabbitMQ. Il était important de tout organiser pour qu'ils soient correctement enregistrés dans le protocole de découverte de service, qui, à son tour, contrôlait le fonctionnement du DNS. Notez que les applications ne fonctionnaient pas directement avec la base de données, mais via Haproxy, ce qui vous permet de facilement et équilibrer les bases de données et de basculer en cas de panne.

Au stade préparatoire, la réplication de la base de données entre les centres de données n'a pas augmenté. Je devais juste transférer les sauvegardes. Ensuite, nous avons commencé à configurer les applications directement, et c'est l'organisation de toutes les interactions via le DNS interne - l'interaction entre l'application et la base de données / Redis / RabbitMQ / les services externes (par exemple, les services de commande). Naturellement, au même stade, tous les mécanismes CI / CD ont été immédiatement connectés - puis un deuxième changement d'architecture s'est produit. Auparavant, il n'était pas possible de modifier les paramètres de l'application via l'interface - uniquement en modifiant les fichiers directement dans la console. Immédiatement, nous avons introduit une solution qui vous permet de gérer facilement les paramètres - via l'interface Web. Il était basé sur le coffre Hashicorp (Consul a agi comme backend pour cela), ce qui nous a permis de construire des mécanismes pratiques pour gérer les variables d'environnement.

L'étape suivante consiste à basculer les services vers le nouveau contrôleur de domaine. Comme le travail de tous les systèmes était organisé en utilisant le protocole http, et que tous les domaines étaient passés par un système de protection contre les attaques DDoS, la commutation est passée à la manipulation en amont directement dans l'interface de ce système.

Auparavant, les répliques nécessaires étaient organisées de l'ancien DC au nouveau. Et un changement a été fait à la fenêtre de travail convenue.

À quoi ressemble l'infrastructure maintenant





  • Tout le trafic va aux équilibreurs. Le trafic vers l'API provient de l'application Tanuki (sur Android / iOS) non pas directement, mais via Qrator.
  • Sur un serveur statique se trouve le site principal du projet tanuki.ru, un serveur avec des pages de destination.
  • Le cluster principal se compose désormais de serveurs: frontaux, statiques, serveurs d'applications.

Schéma de passage des commandes L'
ordre reçu passe par Qrator (immédiatement nous filtrons les attaques) et arrive à l'API. Il se rend ensuite chez Raiden pour livrer la commande, se rend chez Redis et se rend chez nginx, après quoi il part pour la base de données.

Ce qui a changé pour le client


  • Fiabilité du système: des problèmes ont été observés en juillet 2019 - aucune commande n'a été émise dans l'heure. Mais c'était avant le mouvement mondial. Aucun incident majeur n'a été observé par la suite.
  • La vie des développeurs: ils ont un environnement de développement pratique, CI / CD.
  • Tolérance aux pannes: l'infrastructure résiste désormais à un trafic important. Par exemple, pendant les vacances, le RPS a culminé à 550 unités.

Et après


Dans les conditions modernes, les ventes en ligne prennent le dessus. Le projet devrait fournir fiabilité et accessibilité aux clients du service. Mais le développement est également un élément très important: les versions des produits doivent être aussi rapides et invisibles que possible pour les utilisateurs finaux.

Un autre problème important est l'utilisation des ressources et la réduction des coûts de maintenance du système.

Tout cela conduit à la nécessité de revoir le système dans son ensemble. La première étape consiste à organiser la conteneurisation des applications. Il prévoit ensuite d'organiser un cluster Kubernetes. Mais nous en parlerons dans le prochain article. En attendant - bon appétit :-)

More articles:


All Articles