Como o comércio eletrônico sobrevive às promoções em larga escala. Preparando-se para picos de carga na web [Parte 1]

Olá pessoal, estou em contato com Alexey Pristavko, diretor de projetos da Web DataLine.
A Black Friday, o maior evento de comércio eletrônico do mundo, acontece anualmente nos últimos dias de novembro. Este é o momento para descontos recordes, as lojas abrem quase à meia-noite e os sites participantes da ação caem, apesar do forte aumento no fluxo de tráfego.

Portanto, usando o exemplo dela, analisaremos como se preparar para um aumento sério na carga em um site ou aplicativo da web.
Debaixo do gato, falaremos em detalhes sobre como os gerentes de TI, desenvolvedores e administradores de lojas on-line podem sobreviver a eventos de grande escala.

O que ameaça a Black Friday

Como escrevi acima, a Black Friday é um dia que causa muitos problemas para todos os envolvidos na manutenção de sites de comércio eletrônico.

Para sentir isso, considere a tabela abaixo. Isso reflete o aumento no número de solicitações no site durante a Black Friday.



Comparado aos picos diários normais, quando não há ações, o tráfego da Black Friday está crescendo de 100 a 200%, e esse não é o limite.

Se um site grande já tiver muito tráfego, uma loja on-line modesta durante o período da campanha receberá com facilidade o máximo de visitantes e engasgar. Parafraseando um pouco a velha piada: "os negócios fizeram todas as lojas diferentes e a Black Friday on-line igualou a todos".

Ganhou na Black Friday "alimenta" o vendedor no ano que vem. A empresa está extremamente interessada em atrair o número máximo de novos clientes que retornarão ao site para comprar novamente. Porém, para isso, a primeira experiência com o site deve ocorrer sem problemas e garantir que essa seja a tarefa dos especialistas em TI.

Quanto mais clientes estiverem simultaneamente no site, maiores serão os requisitos de estabilidade e velocidade de resposta. Certamente, você percebeu que o site da loja, para o qual você acessou a partir da página de destino do blackfridaysales, funcionou muito devagar ou não funcionou. Duvido que você tenha ficado esperando o download, mas não saiu depois de alguns segundos.

Falaremos sobre como proteger os clientes de experiências negativas e o site contra falhas devido a sobrecarga, abaixo. No entanto, outras dicas são válidas para qualquer pico de carga esperado.

Em geral, existem dois estágios de preparação de um site para aumentar o tráfego: técnico e organizacional. Neste artigo, discutiremos o estágio técnico e descreverei os detalhes da organização em detalhes na segunda parte, que será lançada em uma semana.

Preparação técnica do site

Um pequeno aviso: não espere encontrar aqui instruções detalhadas sobre o que, onde e como reforçá-lo, para que “a felicidade de todos seja em vão e ninguém se ofenda”. Primeiro de tudo, sites e projetos são diferentes para todos. Em segundo lugar, conselhos técnicos específicos sobre um software específico são mais que suficientes. Incluindo Habré. Antes de tudo, quero transmitir aos leitores os princípios fundamentais de trabalhar com projetos da web e mostrar os pontos de partida, introduzir técnicas básicas e nuances independentes de plataforma.

Vamos começar com o axioma: o usuário não gosta de esperar, por isso é extremamente importante trabalhar com horários e velocidade de resposta. Na Black Friday, haverá muito mais solicitações para o site do que o habitual, e você poderá encontrar não apenas uma queda nas conversões devido a uma carga longa, mas também um excesso de tempos limite de HTTP (o site não responde).

Na maioria das vezes, os sites ficam sobrecarregados não devido a falhas físicas, mas porque o tempo de resposta começou a exceder o tempo limite devido à sobrecarga em algum nó. Isso é semelhante a um engarrafamento, e por um tempo você terá que assumir o controle de suas próprias mãos: expandir (escalar) equipamentos, ajustar, cortar e configurar (intervalos), otimizar a carga nos veículos (pacotes e solicitações) e trabalhar com exceções.

Como no contexto do desempenho do site há dois aspectos - velocidade de resposta e número de solicitações processadas simultaneamente, melhoraremos esses parâmetros.

Na maioria das vezes, uma empresa representa a velocidade de resposta como a velocidade do site, de acordo com o Google Analytics, e o número de solicitações simultâneas como o número de usuários simultaneamente no site.

No trabalho técnico, não é muito conveniente operar com esses parâmetros.
A seguir, proponerei uma métrica mais adequada para os cálculos.

Otimizamos a velocidade de resposta

Ao otimizar a velocidade de resposta, estamos interessados ​​em dois indicadores: velocidade de resposta do servidor e tempo de carregamento da página.

O Tempo de carregamento da página consiste nos seguintes links:

• Tempo de geração da página do servidor;
• Tempo de transferência de página do servidor para o cliente;
• O tempo de processamento da página no navegador do cliente.

Quando tudo funciona normalmente, o fator decisivo para o Tempo de carregamento da página não é o tempo em que a página foi gerada pelo servidor e o tempo em que a página foi entregue pela rede, mas a qualidade do front-end e a velocidade do site no navegador. Como o último é totalmente do lado do usuário, você não pode ter medo dos freios na Black Friday. No entanto, podem surgir problemas devido a sobrecargas no canal da Internet ou na entrega de um componente externo (contadores de afiliados, bate-papos on-line, plug-ins de CRM, etc.).
Como lidar com isso? Aqui estão algumas dicas de trabalho:

1. Verifique a carga do canal da Internet. Conte o crescimento estimado. Em caso de dúvida, expanda o canal. Alguns provedores, além de extensões caras em uma base contínua, podem oferecer uma extensão temporária para o período de pico (muito mais barato) ou até permitir que você exceda brevemente a velocidade máxima.
2. Usando uma CDN? Entre em contato com o suporte técnico e avise sobre o crescimento planejado do tráfego. Eles também estão se preparando para o pico geral, e sua previsão será útil. Se a CDN prometer que tudo ficará bem, mas, apesar de tudo, "se deitar", a presença de correspondência ajudará a apresentar pedidos de indenização.
3. Com antecedência, elabore um script para desativar temporariamente os componentes externos em caso de problemas. Alinhe o cenário com os negócios. Não será supérfluo se comunicar com o suporte técnico dos serviços utilizados; de qualquer maneira, é geralmente impossível influenciá-los de alguma forma.
4. Em muitos sites, a estática é renderizada usando o servidor de aplicativos. Sob carga alta, o número de solicitações de estática aumenta muitas vezes e elas começam a competir por recursos com o próprio aplicativo. Certifique-se de configurar o retorno estático diretamente do Nginx. Em primeiro lugar, ele vai lidar muito melhor com isso e, em segundo lugar, haverá um trabalho muito mais útil para os threads do Apache, Tomcat ou Jetty.

Melhorando a velocidade de resposta

A otimização da velocidade de resposta em si refere-se à melhoria geral no desempenho do site. Teoricamente, ajuda a reduzir a quantidade de trabalho realizado pelo aplicativo e, assim, melhora a escala - porque se cada solicitação se tornar "mais barata", você poderá processar mais solicitações com os mesmos recursos.

Mas, na prática, otimizar a velocidade de resposta requer uma grande quantidade de trabalho independente. É impossível otimizar tudo de uma só vez, mas quebrar algo no processo é fácil.

Dica: pense sistematicamente. Digamos que o desempenho do código tenha aumentado e o aplicativo tenha começado a fazer mais consultas simultâneas ao banco de dados. Mas aqui está o problema: o desempenho do banco de dados não permite processar um número tão grande de solicitações e o site como um todo só piorou, e um tempo valioso foi gasto antes do início da ação.

Portanto, é melhor focar na escala e na escalabilidade e executar a otimização geral separadamente da preparação para a Black Friday, para não atrapalhar devido a prazos rígidos. Lembre-se, agora nossa tarefa é garantir que, no pico das cargas, o site não funcione pior do que fora.

A velocidade de geração da página nos interessará apenas em conjunto com outro indicador - a quantidade de carga recebida.

Observe: para o site, apenas o número de solicitações simultâneas criadas pelos usuários é importante, e não o número de usuários online no site. E para calcular com precisão aceitável, o número de solicitações por segundo pelo número de visitantes é bastante difícil (escrevi sobre isso acima). É melhor solicitar à empresa outras métricas - visualizações de página por hora e hora do servidor.

Como resultado, temos um objetivo compreensível: garantir a geração de páginas para o tempo X com o número de solicitações por segundo Y. Tendo métricas numéricas específicas em mãos, é muito mais fácil avaliar o nível de prontidão e o resultado atual.

Aqui está um plano geral de treinamento técnico:

1. Descubra os indicadores atuais (realize o teste de carga da versão atual do site);
2. Para entender exatamente o que está faltando e quantos recursos são necessários para solicitar;
3. Adicionar recursos;
4. Repita o teste de estresse e veja se isso ajuda.

Parece fácil demais? Você está certo, cada ponto é repleto de muitas surpresas.

Muitas vezes, a adição de recursos melhora parcialmente a situação, mas não salva tudo. Ou, em um ambiente de teste, o site funciona como um relógio e, no impulso - novamente os freios.

Em seguida, mostrarei como identificar problemas em potencial e corrigir fraquezas. Vamos começar como realizar testes de estresse e obter um resultado realista.

Realizamos testes de carga corretamente

Onde testar?

Freqüentemente, testes de estresse são realizados em um sistema produtivo. Isso pode ser bom para controlar a situação como um todo, mas não para resolver iterativamente problemas específicos. Lembre-se, geralmente após problemas recém-descobertos após a eliminação, novos podem aparecer. Balas de prata raramente atingem o alvo.

Um teste de carga com falha pode causar transtornos aos usuários do site ou até "interrompê-lo" por um tempo. É melhor usar uma área dedicada como um coelho experimental.

Ele deve atender aos seguintes requisitos:

• A área dedicada deve ser completamente independente e isolada da produtiva;
  
• Idealmente, uma área dedicada deve ser consistente com o tamanho do produto. Um modelo em larga escala também é adequado, mas reduzirá a qualidade e o significado dos testes. Se a carga em um recurso aumentar de maneira não linear (como normalmente acontece), seu modelo não mostrará que, sob carga total, o recurso se esgotará antes do tempo;
  
• É melhor usar exatamente o mesmo (mas não o mesmo!) Equipamento para testes como no prod. Caso contrário, mesmo que os valores quantitativos dos recursos sejam observados, não será possível fornecer qualidade. Pode fazer uma piada cruel no momento crucial. Se isso não for possível, teste o desempenho do equipamento sob sua carga e determine o coeficiente de ajuste.
  

Agora vamos falar sobre maneiras de gerar uma carga de teste. Vou dar algumas técnicas básicas, cada uma com seus prós e contras.

Como gerar uma carga?

1. Teste em solicitações dos logs

É possível emular o fluxo de tráfego através dos logs do servidor de batalha. Uma vantagem óbvia dessa abordagem é que você não precisa se preocupar com análises, modelagem estatística e um perfil de tráfego sintético.

Mas você ainda precisa limpar os logs de solicitações que não podem ser feitas ou não são necessárias.
Por exemplo, você não precisa "comprar" mercadorias no produtivo, isso causará problemas com o conteúdo do produto no banco de dados.

Será difícil reproduzir atrasos realistas entre solicitações.
Emular sessões do usuário também é extremamente difícil, esse método está muito próximo do teste baseado em resultados.

2. Usando Yandex.Tank e Phantom

O tanque em conjunto com o Phantom é uma ferramenta muito conveniente e popular para testes baseados em resultados. Possui uma interface inteligente e permite gerenciar a carga. Para começar a descascar em um tanque, você deve preparar “cartuchos” - arquivos especiais que contêm solicitações de gerador.

Mas, apesar de toda a conveniência, o Tank tem uma grande desvantagem: ele não sabe como usar as sessões do usuário.

Você pode esquecer a autorização, o trabalho completo com cookies e os atrasos variáveis. Um tanque só pode "bicar" solicitações de um único endereço.

Servirá para você se:

• Não há diferença no tempo de resposta do servidor para usuários autorizados e não autorizados ou é insignificante;
• Testando API sem sessões HTTP explicitamente;
• Essa abordagem geralmente é consistente com a lógica do seu site (geralmente não é adequada para lojas online).

3. Usando o Apache JMeter

Essa é a ferramenta mais flexível que permite emular sessões de usuário em detalhes. Assim, com sua ajuda, você ainda pode responder à pergunta da empresa "quantos usuários o site suporta?" Além disso, o JMeter pode trabalhar em conjunto com o Yandex.Tank.
Seu ponto negativo é o consumo de recursos e a complexidade da preparação de testes.

O principal conselho diretamente no JMeter: tente evitar a análise dos corpos das páginas com suas forças; é melhor usar conjuntos de dados pré-preparados para reproduzir a lógica da sessão. Em princípio, é melhor minimizar o trabalho realizado pelo JMeter em geral. Como o Tank, é possível conectar "cartuchos" pré-gerados a ele. É aqui que eles precisam levar em consideração a distribuição de páginas específicas em um tipo, a variabilidade de solicitações e assim por diante.

No próprio JMeter, os modelos de comportamento do usuário precisam ser programados. Se a tarefa é testar não apenas a parte do servidor, mas também o retorno do conteúdo estático, execute esse teste separadamente usando o Phantom, se necessário simultaneamente com o teste JMeter. Isso ajudará a reduzir significativamente o consumo de recursos do gerador de carga e a aumentar a reprodutibilidade do teste.

Recomendações para teste de estresse

Um bom teste de carga é baseado em uma análise de tráfego competente e na preparação de alta qualidade de um modelo estatístico e perfis para emulação.

Destaque 5-7 tipos principais de páginas (não se esqueça também das páginas de destino dos estoques), calcule a porcentagem do tráfego total distribuído entre eles. Lembre-se de que pode haver várias solicitações de conteúdo dinâmico por página. Para você, a página é o grupo inteiro de tais solicitações. Analise quanto tempo os usuários gastam em cada tipo de página: média, média mínima, média máxima.

Se a página for criada em várias solicitações, considere o atraso entre elas. Veja quantas páginas um usuário geralmente visita por sessão, qual é a distribuição desse número. Destaque de 5 a 10 dos caminhos de usuário mais comuns por tipo de página.

Usando os dados obtidos, construa os cenários de forma a reproduzir com extrema precisão todos os parâmetros estatísticos descritos. Não se esqueça da variabilidade dos cenários, eles devem variar tanto no número quanto na composição dos cliques.

Em cada tipo de página, realce endereços individuais. Quanto mais, melhor, mas alguns milhares dos endereços mais populares já estarão sobre os olhos. Você pode preparar listas de consultas a partir deles, adicionando cada endereço à lista quantas vezes for necessário.

Se houver muitas páginas, divida-as em vários grupos de acordo com a porcentagem de tráfego.

Os perfis desempenham uma função apenas para o JMeter, mas, ao criar listas de consultas, você pode equipar cartuchos "tanque".

E novamente: ao usar o JMeter no modo de emulação do usuário, não se esqueça dos atrasos entre as solicitações. Se você não os adicionar, sua carga gerada será muitas vezes maior que o planejado!

Após uma avaliação, verifique os logs do servidor da web para ver se o tráfego emulado é produtivo.

As acrobacias preparam scripts com antecedência para levar o banco de dados do site ao estado que você precisa. Geralmente, os dados preparados da maneira descrita acima funcionam apenas com o estado do banco de dados para o qual as informações sobre mercadorias foram coletadas. Pode ser proibitivamente longo recarregar o despejo de SQL sempre. Além disso, é muito desejável aprender como gerenciar estoques em execução usando scripts na área de teste. Frequentemente, são importantes para a operação do sistema, e você precisa entender com que conjunto e como exatamente os estoques em funcionamento são testados.

Está tudo pronto? Ótimo, vá em frente!

Usamos monitoramento em testes

Por isso, realizamos testes competentes e obtivemos os resultados. Se tudo estiver bem e o seu site estiver enfrentando uma carga alta, nenhuma sexta-feira negra é assustadora para você. Mas este artigo ficaria incompleto se não considerássemos um triste cenário realista.

Imagine que um site possa suportar uma velocidade aceitável ... bem, mesmo que seja apenas um quinto do que a empresa deseja obter. É realmente necessário ligar para o hoster em pânico e pedir cinco vezes mais capacidade?

Em princípio, o host gostará dessa abordagem. Você pode até obter o status de um cliente de ouro.

Mas antes de agir precipitadamente, vamos tentar descobrir o que exatamente deu errado.

Sua bóia de vida no mar de possíveis causas é um sistema de monitoramento.



Portanto, recuamos e instalamos o maior número possível de amostras antes do teste. Idealmente, todos os recursos esgotáveis ​​devem ser monitorados.

Abaixo está uma lista para ajudar você a começar:

• Carga da CPU (uso da CPU, carga da CPU);
• Carregamento de RAM;
• Carregamento de disco (IOPS, latência);
• Número de conexões de rede (espera em tempo, espera final, espera próxima, estabelecida);
• O número de soquetes abertos;
• O número de processos do usuário;
• O número de arquivos abertos;
• Tráfego de rede (em megabits e em pacotes, mais erros e quedas).

E também:

• O número de consultas, respostas e conexões com o banco de dados e outros componentes;
• Velocidade de resposta do componente (banco de dados, servidor de pesquisa, caches, etc.);
• Todos os logs disponíveis para erros.

. , « ». , «» , .

, , .

- , : , HDD SSD. -, .

. .

: , , ? , , , 2- , - (, 0,5 ) 1,5 . - «, ».

1 , . , . , . , ( ) , .

, , , .

«» , . 2-3 , , .

, : . , . , , , , .

. . , SLA, , , , , «» .

. , . .

, , . , , .

, .
-, ( ), -, . .

, . - , .

, , , « e-commerce. », 16 . .