Get best of the week

Infraestructura alimentaria: cómo apoyamos a Tanuki



Parafraseando a una figura histórica famosa, el más importante de todos los servicios para nosotros es la entrega. ¿Qué haríamos en la situación actual sin rollos o pizza en casa? No me quiero imaginar. Dio la casualidad de que hace 2 años tomamos el apoyo de una de las redes más grandes: Tanuki . La audiencia mensual del sitio es de aproximadamente un millón de personas. Ahora es en 2020. En 2018, cuando Tanuki comenzó a cooperar con nosotros, era 2 veces más pequeño. Aseguramos un traslado sencillo a un nuevo centro de datos y reestructuramos completamente la infraestructura, gracias a lo cual, de hecho, el sitio y las aplicaciones pueden soportar el aumento de carga sin problemas.

A veces, lamentamos mucho que estemos geográficamente lejos del restaurante Tanuki más cercano: de lo contrario, todos nuestros éxitos (y pequeñas desgracias) se verían atascados con deliciosos panecillos.

En general, hoy queremos contarle la historia del apoyo de uno de los proyectos web más grandes de la "industria hotelera" nacional.

Nos conocimos a finales de marzo de 2018.

El Día Internacional de la Mujer ha pasado mucho tiempo, pero los muchachos acaban de hacer frente a sus consecuencias. Todo es bastante banal: en la víspera del 8 de marzo, el tráfico aumentó bruscamente y el sitio no estuvo disponible durante mucho tiempo. Realmente largo, no un par de horas. Debido a que el tráfico voló no solo a través del sitio principal, sino que también provino de la aplicación (disponible para Android e iOS), así como de los agregadores (Yandex. Food, Delivery Club, Zaka-Zaka).

Lo que vimos


Técnicamente, el proyecto resultó ser bastante complicado:

  • El sitio es una aplicación de reacción con SSR (representación del lado del servidor).
  • Aplicaciones móviles: para iOS / Android.
  • API: todas las aplicaciones funcionan con él.
  • Sistemas externos, incluido el procesamiento de pedidos.


El sistema era un servidor proxy inverso: el tráfico hacia ellos atravesaba el sistema de protección contra ataques DDoS y desde allí ya estaba distribuido entre los servidores de back-end. En el momento de la aceptación, había un sitio antiguo y una API para versiones móviles, y comenzó el desarrollo de un nuevo sitio. El desarrollo de la nueva API se llevó a cabo en servidores separados.

El clúster de la base de datos constaba de dos servidores con replicación maestro / maestro, donde el cambio en caso de falla se realizaba a nivel de red debido a una IP flotante. Todas las aplicaciones de escritura funcionaban con esta IP, mientras que había esclavos MySQL para lectura ubicados en cada servidor de fondo, donde la aplicación, en consecuencia, funcionaba con localhost.

En la recepción, vimos los siguientes problemas:

  • Un mecanismo de equilibrio insuficientemente confiable en la configuración de la base de datos. El maestro de replicación maestro condujo a fallas frecuentes.
  • Esclavos en cada backend: se requería una gran cantidad de espacio en disco. Y cualquier manipulación o agregar nuevos servidores de back-end era costoso.
  • No había un sistema de implementación común para las aplicaciones: había un sistema de implementación independiente a través de la web.
  • No había un sistema para recopilar registros, por lo que es bastante difícil investigar los incidentes, en primer lugar, al trabajar con el sistema de pedidos, ya que no hay forma de determinar cómo se recibió un pedido en particular.
  • No hubo monitoreo de los indicadores comerciales; no fue posible registrar oportunamente una disminución o la ausencia total de pedidos.

Después de la auditoría inicial de los servidores aceptados para el monitoreo, comenzamos con la formación de una hoja de ruta operativa. Inicialmente, se identificaron dos áreas principales de trabajo:
  1. Estabilización de aplicaciones.
  2. Organización de un entorno de desarrollo cómodo para la nueva API y sitio.

Las decisiones en la primera dirección se relacionaron principalmente con la estabilización del clúster MySQL. No quería rechazar el maestro de replicación maestro, pero era imposible continuar trabajando con una IP flotante. Se observaron interrupciones en la conectividad de la red periódicamente, lo que condujo a interrupciones en el funcionamiento del clúster.

En primer lugar, decidimos abandonar la IP flotante en favor de un servidor proxy, donde el flujo ascendente se controlará entre los maestros, ya que usamos nginx como proxy para MySQL. El segundo paso es la asignación de dos servidores separados para esclavos. El trabajo con ellos también se organizó a través de un servidor proxy. Y desde la reorganización, nos olvidamos de los problemas asociados con el trabajo con la base de datos.

Luego, monitoreamos los pedidos a nivel de consulta en la base de datos. Cualquier desviación de la norma, en mayor o menor medida, dio lugar inmediatamente a una investigación. Luego, a nivel de registro, formamos métricas para monitorear las interacciones externas, en particular, con el sistema de gestión de pedidos.

Junto con sus colegas, previa solicitud, realizamos un ajuste adicional de todos los sistemas para un funcionamiento estable y rápido. Estaba ajustando MySQL y actualizando versiones de PHP. Además, los colegas introdujeron un sistema de almacenamiento en caché basado en Redis, que también ayudó a reducir la carga en la base de datos.

Todo esto era importante ... Pero lo principal para el negocio era un aumento en las ventas. Y en este contexto, los gerentes de la compañía tenían grandes esperanzas para el nuevo sitio. Para los desarrolladores, era necesario obtener un sistema estable y conveniente para el despliegue y el control de aplicaciones.

En primer lugar, pensamos en las tuberías de montaje y entrega de la aplicación CI / CD, así como en los sistemas para recopilar y trabajar con registros.

Todos los repositorios de clientes se alojaron en una solución de bitbucket autohospedada . Para la organización de las tuberías, se eligió a Jenkins.

Para empezar, era costumbre implementar tuberías en entornos de desarrollo; esto nos permitió aumentar significativamente la velocidad de desarrollo. Luego se introdujo en los circuitos de producción, donde el despliegue automático nos permitió evitar errores frecuentes, generalmente causados ​​por el factor humano.

Después de la implementación, CI / CD comenzó a organizar la recopilación de registros y a trabajar con ellos. La pila ELK fue elegida como la principal, lo que permitió al cliente realizar investigaciones más rápido y mejor en caso de un incidente. Y como resultado, el desarrollo de aplicaciones fue más rápido.

"Más terrible que dos incendios ..."


Después de resolver tareas bastante complejas, pero no obstante estándar, los Tanuki nos dijeron lo que habían querido decir durante mucho tiempo: "¡Muévanse!"

El cambio en DC fue causado por factores económicos. Además, el cliente amplió su infraestructura con servicios adicionales que ya estaban en el nuevo DC, lo que también influyó en la decisión de mudarse.

La migración de cualquier sistema, por no hablar de uno complejo, es un proceso que requiere una amplia planificación y grandes recursos.

El movimiento se realizó de forma iterativa: en la primera etapa, se crearon servidores proxy inversos en el nuevo DC. Y dado que solo tienen IP pública, también actuaron como puntos de acceso al sistema para los administradores.

Luego lanzamos todos los servicios de infraestructura: registro y CI / CD. Un cónsulpermitido organizar un servicio de interacción conveniente, manejable y bastante confiable entre las aplicaciones del cliente.

Migraron las siguientes bases de datos, Redis y el intermediario de colas: RabbitMQ. Aquí era importante organizar todo para que estuvieran correctamente registrados en el protocolo de descubrimiento de servicios, que a su vez controlaba el funcionamiento del DNS. Tenga en cuenta que las aplicaciones no funcionaron directamente con la base de datos, sino a través de Haproxy, que le permite convenientemente y equilibrar las bases de datos y cambiar en caso de falla.

En la etapa preparatoria, la replicación de bases de datos entre centros de datos no aumentó. Solo tuve que transferir las copias de seguridad. A continuación, comenzamos a configurar las aplicaciones directamente, y esta es la organización de toda interacción a través del DNS interno: la interacción entre la aplicación y la base de datos / Redis / RabbitMQ / servicios externos (por ejemplo, servicios de pedidos). Naturalmente, en la misma etapa, todos los mecanismos de CI / CD se conectaron inmediatamente, y luego surgió un segundo cambio en la arquitectura. Anteriormente, no era posible cambiar la configuración de la aplicación a través de la interfaz, solo a través de la edición de archivos directamente en la consola. Inmediatamente, presentamos una solución que le permite administrar convenientemente la configuración, a través de la interfaz web. Se basó en la bóveda Hashicorp (el Cónsul actuó como un back-end para ello), lo que nos permitió construir mecanismos convenientes para administrar las variables de entorno.

El siguiente paso es cambiar los servicios al nuevo DC. Dado que el trabajo de todos los sistemas se organizó utilizando el protocolo http, y todos los dominios pasaron por un sistema de protección contra ataques DDoS, cambiando a manipulación directa en la interfaz de este sistema.

Anteriormente, las réplicas necesarias se organizaban desde la antigua DC a la nueva. Y se hizo un cambio a la ventana de trabajo acordada.

Cómo se ve la infraestructura ahora





  • Todo el tráfico va a los equilibradores. El tráfico a la API va desde la aplicación Tanuki (en Android / iOS) no directamente, sino a través de Qrator.
  • En un servidor estático es el sitio principal del proyecto tanuki.ru, un servidor con páginas de destino.
  • El clúster de fondo ahora consta de servidores: frontend, estáticos, servidores para aplicaciones.

Esquema de aprobación de la orden La
orden recibida pasa a través de Qrator (inmediatamente filtramos los ataques) y llega a la API. Luego va a Raiden para entregar el pedido, va a Redis y va a nginx, después de lo cual se va a la base de datos.

Lo que ha cambiado para el cliente.


  • Fiabilidad del sistema: se observaron problemas en julio de 2019; los pedidos no se emitieron en una hora. Pero eso fue antes del movimiento global. No se observaron incidentes mayores posteriormente.
  • La vida de los desarrolladores: tienen un entorno de desarrollo conveniente, CI / CD.
  • Tolerancia a fallas: la infraestructura ahora soporta mucho tráfico. Por ejemplo, durante las vacaciones, el RPS alcanzó un máximo de 550 unidades.

Que sigue


En las condiciones modernas, las ventas en línea se destacan. El proyecto debe proporcionar confiabilidad y accesibilidad para los clientes del servicio. Pero el desarrollo también es un componente muy importante: los lanzamientos de productos deben ser lo más rápidos posible e invisibles para los usuarios finales.

Otra cuestión importante es la utilización de recursos y la reducción del costo de mantenimiento del sistema.

Todo esto lleva a la necesidad de revisar el sistema en su conjunto. El primer paso es organizar la contenedorización de aplicaciones. Luego planea organizar un clúster de Kubernetes. Pero hablaremos de esto en el próximo artículo. Mientras tanto, buen provecho :-)

More articles:


All Articles