Get best of the week

Infraestrutura de alimentos: como apoiamos a Tanuki



Parafraseando uma famosa figura histórica, o mais importante de todos os serviços para nós é a entrega. O que faríamos na situação atual sem pãezinhos ou pizza em casa? Não quero imaginar. Aconteceu que, há dois anos, assumimos o apoio de uma das maiores redes - a Tanuki . A audiência mensal do site é de cerca de um milhão de pessoas. É agora em 2020. Em 2018, quando o Tanuki começou a cooperar conosco, era 2 vezes menor. Garantimos uma mudança indolor para um novo data center e refizemos completamente a infraestrutura - graças à qual, de fato, o site e os aplicativos são capazes de suportar o aumento da carga sem problemas.

Às vezes, lamentamos vivamente que estejamos geograficamente distantes do restaurante Tanuki mais próximo: caso contrário, todos os nossos sucessos (e pequenos infortúnios) seriam atolados com deliciosos pãezinhos.

Em geral, hoje queremos contar a história do apoio de um dos maiores projetos de web da “indústria da hospitalidade” doméstica.

Nos conhecemos no final de março de 2018.

O Dia Internacional da Mulher já passou, mas os caras acabaram de lidar com suas consequências. Tudo é bastante banal: na véspera de 8 de março, o tráfego aumentou acentuadamente e o site ficou indisponível por um longo tempo. Muito longo, não algumas horas. Porque o tráfego voou não apenas pelo site principal, mas também veio do aplicativo (disponível para Android e iOS), além de agregadores (Yandex. Comida, Clube de Entrega, Zaka-Zaka).

O que vimos


Tecnicamente, o projeto acabou sendo bastante complicado:

  • O site é um aplicativo de reação com SSR (renderização no servidor).
  • Aplicativos móveis - para iOS / Android.
  • API - todos os aplicativos funcionam com ele.
  • Sistemas externos, incluindo processamento de pedidos.


O sistema era um servidor proxy reverso: o tráfego para eles passava pelo sistema de proteção contra ataques DDoS e, a partir daí, já era distribuído para os servidores back-end. No momento da aceitação, havia um site antigo e uma API para versões móveis, e o desenvolvimento de um novo site começou. O desenvolvimento da nova API foi realizado em servidores separados.

O cluster do banco de dados consistia em dois servidores com replicação mestre / mestre, em que a alternância no caso de uma falha era realizada no nível da rede devido ao IP flutuante. Todos os aplicativos de gravação funcionavam com esse IP, enquanto havia escravos do MySQL para leitura localizados em cada servidor de back-end - onde o aplicativo, consequentemente, trabalhava com o host local.

Na recepção, vimos os seguintes problemas:

  • Um mecanismo de balanceamento insuficientemente confiável na configuração do banco de dados. O mestre de replicação principal levou a falhas frequentes.
  • Escravos em cada back-end - exigia uma grande quantidade de espaço em disco. E qualquer manipulação ou adição de novos servidores de back-end era cara.
  • Não havia um sistema de implantação comum para aplicativos - havia um sistema de implantação independente via web.
  • Não havia um sistema para coletar logs - como resultado, é bastante difícil investigar incidentes, antes de tudo, ao trabalhar com o sistema de pedidos, pois não há como determinar como um pedido específico foi recebido.
  • Não houve monitoramento dos indicadores de negócios - não foi possível registrar atempadamente uma diminuição ou completa ausência de pedidos.

Após a auditoria inicial dos servidores aceitos para monitoramento, começamos com a formação de um roteiro operacional. Inicialmente, foram identificadas duas áreas principais de trabalho:
  1. Estabilização de aplicações.
  2. Organização de um ambiente de desenvolvimento confortável para a nova API e site.

As decisões na primeira direção estavam relacionadas principalmente à estabilização do cluster MySQL. Não queria recusar o mestre de replicação principal, mas era impossível continuar trabalhando com um IP flutuante. Periodicamente, foram observadas interrupções na conectividade da rede, o que levou a interrupções na operação do cluster.

Primeiro, decidimos abandonar o IP flutuante em favor de um servidor proxy, onde o upstream será controlado entre os mestres, pois usamos o nginx como proxy para o MySQL. O segundo passo é a alocação de dois servidores separados para escravos. O trabalho com eles também foi organizado por meio de um servidor proxy. E desde a reorganização, esquecemos os problemas associados ao trabalho com o banco de dados.

Em seguida, monitoramos os pedidos no nível da consulta no banco de dados. Qualquer desvio da norma - em maior ou menor grau - imediatamente deu origem a uma investigação. Em seguida, no nível do log, formamos métricas para monitorar interações externas, em particular, com o sistema de gerenciamento de pedidos.

Juntamente com os colegas, mediante solicitação, realizamos um ajuste adicional de todos os sistemas para operação estável e rápida. Estava ajustando o MySQL e atualizando versões do PHP. Além disso, os colegas introduziram um sistema de cache baseado no Redis, que também ajudou a reduzir a carga no banco de dados.

Tudo isso era importante ... Mas o principal para o negócio era um aumento nas vendas. E, nesse contexto, os gerentes da empresa tinham grandes esperanças para o novo site. Para os desenvolvedores, era necessário obter um sistema estável e conveniente para implantação e controle de aplicativos.

Primeiro, pensamos nos pipelines de montagem e entrega do aplicativo de CI / CD, bem como nos sistemas para coletar e trabalhar com logs.

Todos os repositórios de clientes foram hospedados em uma solução de bitbucket auto-hospedada . Para a organização dos gasodutos, a Jenkins foi escolhida.

Para começar, era costume implementar pipelines em ambientes de desenvolvimento - isso nos permitia aumentar significativamente a velocidade de desenvolvimento. Em seguida, foi introduzido em circuitos de produção, onde a implantação automática nos permitiu evitar erros frequentes, geralmente causados ​​pelo fator humano.

Após a implementação, o CI / CD começou a organizar a coleção de logs e a trabalhar com eles. A pilha ELK foi escolhida como a principal, o que permitiu ao cliente conduzir investigações mais rapidamente e melhor no caso de um incidente. E, como resultado, o desenvolvimento de aplicativos foi mais rápido.

"Mais terrível do que dois incêndios ..."


Depois de resolver tarefas bastante complexas, mas ainda assim padronizadas, os Tanuki nos disseram o que queriam dizer há muito tempo: "E vamos em frente!"

A mudança no CD foi causada por fatores econômicos. Além disso, o cliente expandiu sua infraestrutura com serviços adicionais que já estavam no novo controlador de domínio, o que também influenciou a decisão de mudar.

A migração de qualquer sistema, muito menos de um sistema complexo, é um processo que requer amplo planejamento e grandes recursos.

A mudança foi realizada iterativamente: no primeiro estágio, servidores proxy reversos foram criados no novo controlador de domínio. E como apenas eles têm IP público, eles também atuaram como pontos de acesso ao sistema para administradores.

Em seguida, lançamos todos os serviços de infraestrutura - log e CI / CD. Um cônsulpermissão para organizar um serviço conveniente, gerenciável e razoavelmente confiável de interação entre aplicativos clientes.

Os seguintes bancos de dados migraram, Redis e o broker da fila - RabbitMQ. Aqui era importante organizar tudo para que eles fossem registrados corretamente no protocolo de descoberta de serviço, que, por sua vez, controlava a operação do DNS. Observe que os aplicativos não funcionaram diretamente com o banco de dados, mas através do Haproxy, que permite o equilíbrio conveniente entre os bancos de dados e a alternância em caso de falha.

No estágio preparatório, a replicação do banco de dados entre os data centers não aumentou. Eu apenas tive que transferir os backups. Em seguida, começamos a configurar os aplicativos diretamente, e essa é a organização de toda a interação por meio do DNS interno - a interação entre o aplicativo e os serviços externos do banco de dados / Redis / RabbitMQ / externo (por exemplo, serviços de pedidos). Naturalmente, no mesmo estágio, todos os mecanismos de CI / CD foram imediatamente conectados - e, em seguida, surgiu uma segunda mudança na arquitetura. Anteriormente, não era possível alterar as configurações do aplicativo por meio da interface - apenas através da edição de arquivos diretamente no console. Introduzimos imediatamente uma solução que permite gerenciar convenientemente as configurações - por meio da interface da web. Foi baseado no cofre Hashicorp (o Consul atuou como um back-end), o que nos permitiu criar mecanismos convenientes para gerenciar variáveis ​​de ambiente.

O próximo passo é mudar os serviços para o novo controlador de domínio. Como o trabalho de todos os sistemas foi organizado usando o protocolo http, e todos os domínios passaram por um sistema de proteção contra ataques DDoS, a mudança passou para a manipulação de upstream diretamente na interface desse sistema.

Anteriormente, as réplicas necessárias eram organizadas do controlador de domínio antigo para o novo. E foi feita uma mudança para a janela de trabalho acordada.

Como é a infraestrutura agora





  • Todo o tráfego vai para os balanceadores. O tráfego para a API vai do aplicativo Tanuki (no Android / iOS) não diretamente, mas através do Qrator.
  • Em um servidor estático, é o site principal do projeto tanuki.ru, um servidor com páginas de entrada.
  • O cluster de back-end agora consiste em servidores: front-end, estático, servidores para aplicativos.

Esquema de aprovação de pedidos O
pedido recebido passa pelo Qrator (imediatamente filtramos os ataques) e chega à API. Então ele vai até Raiden para entregar o pedido, vai para Redis e vai para o nginx, após o qual parte para o banco de dados.

O que mudou para o cliente


  • Confiabilidade do sistema: problemas foram observados em julho de 2019 - os pedidos não foram emitidos dentro de uma hora. Mas isso foi antes da mudança global. Nenhum incidente importante foi observado posteriormente.
  • A vida dos desenvolvedores: eles têm um ambiente de desenvolvimento conveniente, CI / CD.
  • Tolerância a falhas: a infraestrutura agora suporta muito tráfego. Por exemplo, durante as férias, o RPS atingiu o pico de 550 unidades.

Qual é o próximo


Em condições modernas, as vendas online vêm à tona. O projeto deve fornecer confiabilidade e acessibilidade para os clientes do serviço. Mas o desenvolvimento também é um componente muito importante: os lançamentos de produtos devem ser o mais rápido e invisível possível para os usuários finais.

Outra questão importante é a utilização de recursos e a redução do custo de manutenção do sistema.

Tudo isso leva à necessidade de revisar o sistema como um todo. O primeiro passo é organizar a conteinerização do aplicativo. Em seguida, planeja organizar um cluster Kubernetes. Mas falaremos sobre isso no próximo artigo. Enquanto isso - bon appetit :-)

More articles:


All Articles