🥕 🌇 🧀 Como ajudamos as escolas a mudar para o ensino a distância e lidamos com a carga 👩🏻‍🤝‍👨🏼 ⏺️ 🏇🏻

Olá Habr! Meu nome é Alexey Vakhov, sou o diretor técnico do Uchi.ru. Em meados de março, quando as escolas começaram a mudar para o ensino a distância, fornecemos aos professores e alunos vários serviços para aulas on-line. De acordo com nossos cálculos, tínhamos uma margem de segurança para suportar no máximo de 1,5 a 2 vezes a carga. Em meados de abril, nosso tráfego cresceu 8 vezes. Eu tive que fazer muito para me manter à tona. Talvez alguém precise de nossa experiência para sobreviver a essa ou a uma crise futura.

Não esperávamos tais surpresas e não estávamos preparados para elas, provavelmente nem uma única empresa na Rússia, nem no mundo, estava pronta para isso. Geralmente em março, a atividade no Uchi.ru é mais baixa em relação ao outono devido à primavera e às próximas férias de verão, quando já estamos nos preparando para setembro: estamos vendo recursos, refatorando, realizando mudanças arquitetônicas em larga escala e realizando outra rotina agradável. No entanto, desta vez foi diferente.

O número máximo de usuários únicos no site chegou a 240 mil, registramos o máximo anterior do ano letivo atual em 30 mil pessoas. Nesse ponto, a carga aumentava todos os dias e trabalhamos o tempo todo para estabilizar o site.

Quando essa carga cai no site, geralmente são formados aplicativos, serviços, balanceadores, bases, web e canais. Todos os "gargalos" da infraestrutura estão expostos. Em tais condições, é difícil diagnosticar problemas - sintomaticamente, tudo está com erros. É fácil reparar quando o tráfego cresce sem problemas e uma coisa falha. Quando a carga ocorre rapidamente, um dos grandes problemas é entender as causas das falhas.

A estratégia para trabalhar nessas condições é eliminar o que mais atinge o site e, em seguida, encontrar o próximo ponto mais doloroso, ao mesmo tempo, procurar problemas em potencial e corrigi-los, e assim por diante. Aqui estão algumas das coisas mais notáveis que fizemos para estabilizar a plataforma.

Confie em si mesmos

Durante uma crise antes do trânsito, você, como equipe, se torna um. Depende de seus funcionários se você encontrará soluções, lidará com a crise ou não.

Não há pessoas no setor que entrem, examinem seu sistema complexo, façam algo imediatamente e tudo ficará bem. Obviamente, no mundo existem especialistas suficientes que lidarão com a tarefa se houver tempo. Mas quando uma solução fundamental é necessária no momento, você pode confiar apenas em sua equipe, que conhece o sistema e suas especificidades. O resultado e a responsabilidade para o negócio estão com a equipe. O exame externo é aconselhável para conectar no sentido horário.

A coordenação operacional da equipe anti-crise em um bate-papo especial no Slack nos ajudou a navegar rapidamente e a criar trabalho - todos os problemas foram resolvidos aqui e agora. Dividimos as áreas de responsabilidade entre os funcionários para que não houvesse cruzamentos e os rapazes não fizessem o dobro do trabalho. Nos dias mais difíceis, eu tinha que estar em contato o tempo todo.

Nuvem expandida

Você não pode segurar todas as crises, mas é importante ser flexível. A pilha de nuvens nos deu tanta plasticidade e uma chance de permanecer à tona mesmo com um aumento tão dramático na carga.

Inicialmente, aumentamos os recursos com o aumento da carga, mas em algum momento atingimos as cotas da região do nosso provedor de nuvem. Os problemas surgiram em seu nível: nossos servidores virtuais foram afetados por vizinhos, nos quais o tráfego também cresceu, o que causou falhas na operação de nossos aplicativos. Isso era esperado: dependemos do provedor e de sua infraestrutura, que também sofreram uma carga alta. Liberamos alguns recursos de máquinas virtuais não prioritárias para o site principal. Com o provedor, concordamos com um recurso dedicado.

Ferramentas de monitoramento atualizadas

Durante a crise, o alerta não cumpriu sua função. Todos os membros da equipe já monitoravam todos os sistemas o tempo todo, e o gerenciamento de incidentes era reduzido ao trabalho constante em todas as frentes. Para diagnosticar completamente os problemas que encontramos, tínhamos poucos dados. Por exemplo, para monitorar máquinas virtuais, usamos o Node Exporter padrão para Prometheus. Ele é bom em ver o quadro geral, pois uma análise mais detalhada de uma única máquina virtual começou a usar o NetData.

Armazenamento em cache otimizado

Também surgiu um problema com os armazenamentos de valores-chave. Em um dos aplicativos, o Redis não conseguiu lidar - em uma única cópia, ele pode funcionar em apenas um núcleo. Portanto, eles usaram um fork Redis chamado KeyDB, que pode funcionar em vários threads.

Para aumentar a largura de banda em outro aplicativo, aumentamos 10 Redis'ov independentes. Eles são enviados por proxy pelo nosso Service Mesh, que também fragmenta as chaves. Mesmo se um ou dois Redis travarem, isso não causará problemas devido ao hash consistente. Além disso, eles praticamente não precisam ser administrados.

Expandiu a rede

Como você sabe, 640 Kb é suficiente para todos. Sempre usamos sub-redes privadas / 24, mas no contexto da quarentena, tivemos que expandir urgentemente para / 22. Agora, a rede acomoda quatro vezes mais servidores, esperamos que seja suficiente.

PgBouncer realizado separadamente

Como banco de dados relacional, usamos o PostgreSQL em qualquer lugar, em pequenas instâncias virtuais e em algum lugar - a instalação de vários grandes servidores dedicados para o mestre e as réplicas. O gargalo óbvio dessa arquitetura é o mestre, que, no caso ideal, é usado apenas para gravação e não é dimensionado horizontalmente. Com o crescimento do tráfego, começamos a descansar na CPU.

Ao mesmo tempo, usamos o PgBouncer, que foi instalado no assistente e em cada réplica, para gerenciar as conexões. Em uma porta, ele pode usar não mais que um núcleo de processador; portanto, em cada servidor, tínhamos vários bouncers. Em algum momento, ficou claro que o próprio PgBouncer retirou a parte tangível da CPU da base e, com carga máxima, experimentamos um rápido aumento na média de carga e uma queda no desempenho do sistema.

Movemos os seguranças para um servidor separado, o que nos ajudou a economizar 20 a 25% da CPU em cada servidor de banco de dados.

Diante de surpresas

Apenas uma ferramenta não pode ser confiável, especialmente em tempos de crise. Pelo contrário, a redundância de ferramentas ajuda, porque permite ver uma imagem mais objetiva. As ferramentas familiares começam a falhar por vários motivos. Por exemplo, geralmente para estimar o número de pessoas em um site, geralmente usamos um relatório do Google Analytics em tempo real, que é uma métrica sensível e precisa. Mas, às vezes, é um erro e, dessa vez, tivemos que analisar métricas internas, como o número de eventos de exibição de página e o número de solicitações por segundo.

Para registro centralizado, usamos ELK. Nosso pipeline de entrega de logs é baseado no Apache Kafka e Elastic Filebeat. Sob alta carga, o transportador de entrega de logs parou de gerenciar, os logs começaram a se perder ou atrasar. Aumentamos a velocidade da transferência de log e da indexação de armazenamento, manipulando os índices Elasticsearch, aumentando o número de partições no Kafka e no Filebeat e otimizando a compactação em todos os estágios. Devido ao fato de o pipeline de coleta de logs ser separado da produção, os problemas com o aumento do tráfego dos logs não afetaram o funcionamento do site.

Aceitou as regras do jogo

É impossível se preparar com antecedência para cada crise, mas você pode inicialmente tentar construir um sistema flexível. Startups ou empresas que deixam de ser gradualmente startups, em um período silencioso, nem sempre é racional se preparar para um crescimento anormal do tráfego: os recursos da equipe são limitados. Se deixarmos de lado sua preparação para algo que nunca pode acontecer, não haverá mais força para o produto principal. É muito mais importante reagir corretamente no momento e não ter medo de decisões ousadas. Como regra, a saída da crise é uma saída para um nível qualitativamente novo.

Aqui está uma primavera tão divertida este ano. Quando parece que tudo foi feito, às vezes acontece que isso é apenas o começo.

Como ajudamos as escolas a mudar para o ensino a distância e lidamos com a carga