👩🏻‍⚖️ 🧒 📂 Cargas altas da Copa do Mundo de 2018 💍 👲🏾 🔣

A última Copa do Mundo da FIFA 2018 na Rússia trouxe cargas pesadas não apenas para os centros de transporte do país, mas também para a infraestrutura de TI da maior emissora russa, que disponibilizou as partidas no formato de transmissão on-line. Aceitamos com interesse um novo desafio que chegou aos servidores atendidos, juntamente com a febre do futebol.

Prefácio: altas cargas?

Conversas sobre carga alta geralmente começam com reflexões sobre o tópico, que cargas podem ser consideradas "altas" com razão: milhares de solicitações por segundo de dinâmica? Ou mesmo um pequeno número de solicitações em relação aos recursos disponíveis? Milhões de visitantes por dia? Centenas de nós de carga de trabalho em um cluster?

Para se ter uma idéia da "escala do desastre", o fato de estarmos falando de usuários que visualizam simultaneamente a transmissão, cujo número atingiu a marca de 2 milhões , deve ser suficiente. O que aconteceu se você observar as transmissões de partidas "de dentro" e como conseguiu lidar com o tráfego sem precedentes?

Três baleias

1. Arquitetura do site e sistemas de tradução

O esquema geral de interação entre o usuário final e o sistema de conversão é reduzido ao seguinte esquema:

O usuário chega ao site em que o player é iniciado para assistir ao vídeo. O próprio player é escrito em JavaScript e o carregamento leva a muitos pedidos de estática, além de várias APIs relacionadas a traduções.
Entre outras coisas, há um apelo ao balanceador para uma lista de reprodução para reprodução.
Uma lista de reprodução é um conjunto constantemente atualizado de pequenos fragmentos de vídeo armazenados em cache nos servidores CDN.
Enquanto assiste ao vídeo de um usuário em tempo real, são coletadas várias estatísticas, as quais são levadas em consideração para o balanceamento de carga pela CDN (junto com a largura de banda disponível).

A arquitetura para distribuição direta do vídeo foi projetada e implementada pelas forças internas dos engenheiros do cliente mesmo antes do início de nossa cooperação. Posteriormente, além do próprio serviço, estávamos envolvidos no projeto e no comissionamento da infraestrutura de alguns de seus componentes, bem como do próprio site, que desempenha um papel importante no esquema geral.

O site, lançado em produção há vários anos, está focado na escalabilidade horizontal - incluindo muitos data centers:

O esquema apresentado aqui é simplificado e visa demonstrar a natureza da escalabilidade do site, cujos componentes são distribuídos por diferentes data centers.

2. CDN

Voltando a assistir ao vídeo, é óbvio que a carga principal recai nos servidores da CDN. Nas figuras da Copa do Mundo passada, estamos falando de tráfego constante, medido em terabits por segundo . E, em muitos aspectos, o sucesso do trabalho de traduções com picos de carga se deve ao armazenamento em cache no CDN de tudo o que pode ser transferido para eles e à minimização dos custos de recursos (rede, CPU, RAM, ...) de outras operações.

Além disso, um ponto importante no trabalho com CDN é a interação com sua API para obter informações relevantes sobre a largura de banda total e disponível. No sistema de transmissão, esses dados são usados para distribuir novos visualizadores e redistribuir os atuais.

Portanto, se os servidores CDN podem fornecer largura de banda suficiente para milhões de visualizadores da Internet, quando os problemas podem ocorrer? Durante o campeonato, observamos dois cenários principais:

Por alguma razão, há um atraso na transmissão.

Por exemplo, as configurações do sistema "jogaram" em uma das partidas do campeonato que o serviço de proteção DDoS, que não esperava uma carga repentina, começou a considerar o que estava acontecendo como um ataque, bloqueando a disponibilidade dos servidores CDN um após o outro ... até que foi notificado que a situação estava em um sentido extremo, mas ainda em tempo integral (as conclusões necessárias foram feitas - nas próximas transmissões a situação não se repetiu).

Nesses momentos, todos os usuários que são superados por um grande problema começam a atualizar a página com o player.
Um gol marcado (especialmente o primeiro), via de regra, provoca um enorme fluxo de espectadores em um período limitado de tempo.

Se falamos de números mais específicos, esse influxo atingiu centenas de milhares de usuários em 1 a 1,5 minutos.

Ambos os casos geraram picos acentuados nas solicitações de conteúdo dinâmico do site que precisavam ser tratadas pelos recursos disponíveis. Como esses problemas foram rastreados e resolvidos?

3. Monitoramento e estatísticas em tempo real

É possível brincar com um grau significativo de verdade que durante todo o campeonato tivemos um cargo especial, cujas funções incluíam assistir atentamente o futebol no local de trabalho. É claro que não se tratava tanto de futebol, mas da reação imediata a qualquer incidente provocado por partidas ou outras circunstâncias ...

Quais são as "outras circunstâncias"? Nesses eventos públicos, até a influência do clima é perceptível. Aqui estão dois exemplos do campeonato que encontramos:

Quando uma tempestade começou durante uma das partidas, os fornecedores de TV via satélite tiveram problemas no equipamento (eles não podiam enviar um sinal). Isso levou a um aumento perceptível no tráfego (cerca de 10%) em pouco tempo, porque, em busca de uma solução alternativa urgente, os espectadores começaram a ficar massivamente online e continuar navegando por lá.
Quando começou a chover durante a partida final, foi notado um pequeno salto (cerca de 3%) na desconexão e reconexão dos usuários (após cerca de 5 minutos). Nesse caso, não foram observados problemas na própria transmissão, ou seja, os motivos do salto não tinham base técnica. O pressuposto é que os espectadores que assistiam futebol na rua (como eu próprio) se mudaram para a sala devido à chuva e, por um breve período, foram desconectados da transmissão.

Voltando ao tópico do monitoramento em si - durante todo o campeonato, a prática de reuniões regulares (após cada pico de transmissão) foi tomada como norma com os desenvolvedores, que analisaram todas as situações críticas (ou próximas a elas) e suas conseqüências - para minimizar possíveis problemas em da próxima vez Quais servidores / serviços estavam no limite? Quais consultas foram especialmente exigentes? Quais solicitações podem ser removidas (transferidas para a CDN para armazenar em cache por alguns segundos)? Quais solicitações podem ser armazenadas em cache por mais tempo (a cada 3 minutos, não por minuto)? O que acontecerá com o aumento projetado no número de espectadores, porque a Rússia jogará?

Falando da Rússia. Como você pode imaginar, em média várias vezes mais pessoas compareceram à seleção russa do que outras. E quanto mais nossa equipe avançava no grupo de torneios, mais difícil era combinar nossa alegria nesse assunto com o desempenho de tarefas imediatas - porque tudo era complicado pelo crescimento incansável do público. Apesar de o sistema ter sido projetado para suportar cargas enormes, no horário normal de trabalho eles não acontecem com tanta frequência (menos de 10 vezes por ano) ... e no caso da Copa do Mundo, observamos picos quase diários de alta carga por um mês. A vantagem desse modo, no entanto, foram as amplas possibilidades de detectar gargalos reais que são detectados apenas nos momentos de tais cargas.

Portanto, se parte de problemas puramente técnicos foi removida por gráficos padrão dos sistemas de monitoramento, na solução de problemas mais complexos e / ou orientados à lógica de negócios, as realizações do projeto sob o nome interno falante "Estatísticas em tempo real" tiveram um papel importante.

Estatísticas em tempo real

Esse importante componente da infraestrutura de transmissão da Internet foi projetado e implementado por nossos esforços para fornecer uma ferramenta de inteligência de negócios para dados técnicos coletados de players nos quais os usuários assistem a vídeos. Na sua essência, é um sistema de registro que:

coleta todos os tipos de dados disponíveis sobre os usuários (navegador, IP etc.) - para simplificar, podemos dizer que essas são as características que costumávamos observar nas estatísticas do público-alvo do site);
complementa-os com dados técnicos sobre transmissão (taxa de bits, etc.) e eventos / problemas que ocorreram (troca de CDN, falhas de visualização ...);
fornece ao balanceador dados para o balanceamento de carga ideal em servidores CDN (de acordo com as características de cada usuário);
envia alertas necessários aos engenheiros de serviço e cria gráficos de negócios úteis.

O último ponto é o mais interessante, porque:

Os alertas desse sistema estatístico são um componente-chave do monitoramento que permite "manter-se a par" dos indicadores práticos durante as transmissões. Analisando-os (em um local onde a automação não é suficiente), o atendente toma as decisões apropriadas para melhorar a qualidade do serviço em tempo real. Por exemplo:
- Muitos usuários mudaram do mesmo servidor CDN? Ele deve ser desativado temporariamente da rotação (ou entre em contato com o provedor para obter uma resposta rápida).
- Os usuários começaram a ter problemas enormes assistindo vídeos? Hora de uma análise urgente das causas.
Os gráficos são estatísticas de negócios em tempo real que permitem responder perguntas importantes, como:
- Quantos usuários assistiram a transmissão de última hora?
- Qual porcentagem de usuários teve problemas no último minuto e qual foi a natureza deles?
Como eventos semelhantes têm o mesmo perfil de gráfico, o próprio gráfico permite prever o crescimento do número de usuários nos próximos minutos e tomar ações proativas, se necessário.

Como essas estatísticas funcionam em tempo real e são essenciais para a qualidade de todo o serviço, até mesmo a visualização de vídeos simples por milhões de usuários não se resume à distribuição de conteúdo via CDN para eles. O ClickHouse DBMS ajuda a obter uma gravação rápida de novos dados de vários players (estamos falando de dezenas de milhares de solicitações por segundo para gravação em cada servidor), e o Grafana usual é usado para gráficos.

Ilustração da proporção de espectadores de vídeo on-line antes, durante e após a partida

A propósito : Uma solução interessante durante os picos de carga foi desabilitar o HTTPS (a favor do HTTP) para solicitações do sistema de estatísticas, o que levou a uma redução dupla na carga da CPU em alguns servidores.

Sumário

O sucesso das transmissões on-line de um evento tão grande (até o YouTube TV nem sempre lidou com as cargas!) Foi fornecido por três fatores principais:

arquitetura competente (para o sistema de transmissão e site), que, mesmo sem o uso de sistemas modernos como o Kubernetes, foi inicialmente orientada para altas cargas, escalabilidade e prontidão para explosões significativas;
Servidores CDN com largura de banda suficiente;
monitoramento especializado, que permitiu: a) rastrear problemas em tempo real; b) fornecer as informações necessárias para evitá-los no futuro.

Embora houvesse realmente mais fatores ... e um deles, talvez, seja capaz de superar todos os técnicos - humanos. O papel mais importante foi desempenhado por especialistas que não apenas foram capazes de fazer e amarrar tudo o que é tecnicamente necessário, mas também alcançaram incansavelmente resultados, os quais quero destacar especialmente os méritos da gestão do cliente.

PS sobre os Kubernetes mencionados ... uma história que muitos leitores do nosso blog podem esperar ver. O processo de migração do sistema de transmissão para ele já começou, mas durante a Copa do Mundo esses desenvolvimentos ainda não estavam envolvidos.

Cargas altas da Copa do Mundo de 2018