Em 2016, conversamos sobre como o MegaFon.TV lidava com todos que queriam assistir a nova temporada de Game of Thrones. O desenvolvimento do serviço não parou por aí e, em meados de 2017, tivemos que lidar com cargas várias vezes mais. Neste post, contaremos como esse crescimento rápido nos inspirou a mudar radicalmente a abordagem de organização da CDN e como essa nova abordagem foi testada pela Copa do Mundo.
Brevemente sobre MegaFon.TV
O MegaFon.TV é um serviço OTT para visualizar vários conteúdos de vídeo - filmes, programas de TV, canais de TV e programas gravados. Através do MegaFon.TV, o acesso ao conteúdo pode ser obtido em praticamente qualquer dispositivo: em telefones e tablets com iOS e Android, em TVs inteligentes LG, Samsung, Philips, Panasonic de diferentes anos de lançamento, com todo um zoológico de SO (Apple TV, Android TV), em navegadores de desktop no Windows, MacOS, Linux, em navegadores móveis no iOS e Android e até em dispositivos exóticos, como STB e projetores infantis para Android. Praticamente não há restrições para os dispositivos - apenas a Internet com uma largura de banda de 700 Kbps é importante. Sobre como organizamos o suporte para tantos dispositivos, haverá um artigo separado no futuro.
A maioria dos usuários do serviço é assinante MegaFon, o que é explicado por ofertas favoráveis (e geralmente gratuitas) incluídas no plano tarifário do assinante. Embora também notemos um aumento significativo de usuários de outras operadoras. De acordo com esta distribuição, 80% do tráfego do MegaFon.TV é consumido na rede MegaFon.
Arquitetonicamente, desde o lançamento do serviço, o conteúdo foi distribuído via CDN. Temos um
post separado dedicado ao trabalho deste CDN. Nele, falamos sobre como isso nos permitiu lidar com o pico de tráfego que foi para o serviço no final de 2016, durante o lançamento da nova temporada de Game of Thrones. Neste post, falaremos sobre o desenvolvimento do MegaFon.TV e sobre novas aventuras que caíram no serviço junto com a Copa do Mundo de 2018.
Crescimento do serviço. E problemas
Comparado aos eventos do último post, até o final de 2017 o número de usuários do Megafon.TV aumentou várias vezes, filmes e séries também se tornaram uma ordem de magnitude maior. Novas funcionalidades foram lançadas, novos pacotes apareceram, disponíveis “por assinatura”. Os picos de tráfego desde o "Game of Thrones" que hoje vemos todos os dias, a proporção de filmes e programas de TV no fluxo total aumentam constantemente.
Junto com isso, os problemas começaram com a redistribuição do tráfego. Nosso monitoramento, configurado para baixar trechos para diferentes tipos de tráfego em diferentes formatos, começou a produzir cada vez mais erros ao baixar trechos de vídeo por tempo limite. No serviço MegaFon.TV, a duração do pedaço é de 8 segundos. Se o pedaço não tiver tempo para carregar em 8 segundos, poderão ocorrer erros.
Esperava-se que o pico de erros ocorresse nas horas mais ocupadas. Como isso deve afetar os usuários? No mínimo, eles poderiam observar uma deterioração na qualidade do vídeo. Nem sempre é perceptível a olho nu, devido a um número suficientemente grande de perfis com várias taxas de bits. Na pior das hipóteses, o vídeo congela.
A busca pelo problema começou. Quase imediatamente, ficou claro que ocorre um erro de propina nos servidores EDGE da CDN. Aqui, precisamos fazer uma pequena digressão e informar como os servidores funcionam com tráfego ao vivo e VOD. O esquema é um pouco diferente. Um usuário que acessa o servidor EDGE em busca de conteúdo (uma lista de reprodução ou parte), se houver conteúdo no cache, o obtém a partir daí. Caso contrário, o servidor EDGE procurará o conteúdo no Origin, carregando o canal principal. Juntamente com uma lista de reprodução ou parte, é fornecido o cabeçalho
Cache-Control: max-age , que informa ao servidor EDGE quanto armazenar em cache uma determinada unidade de conteúdo. A diferença entre LIVE e VOD está no tempo que leva para armazenar em cache os pedaços. Para os live-chunks, é definido um tempo de armazenamento em cache curto, geralmente de 30 segundos a vários minutos - isso se deve ao pouco tempo de relevância do conteúdo ao vivo. Esse cache é armazenado na RAM, porque você precisa constantemente fornecer pedaços e reescrever o cache. Para partes do VOD, é definido mais tempo, de várias horas a semanas e até meses - dependendo do tamanho da biblioteca de conteúdo e da distribuição de suas visualizações entre os usuários. Quanto às listas de reprodução, elas geralmente são armazenadas em cache em não mais de dois segundos ou não são armazenadas em cache. Vale esclarecer que estamos falando apenas do chamado modo PULL da CDN, no qual nossos servidores funcionavam. Usar o modo PUSH no nosso caso não seria totalmente justificado.
Mas voltando a encontrar o problema. Como já observamos, todos os servidores trabalharam simultaneamente no retorno dos dois tipos de conteúdo. Ao mesmo tempo, os próprios servidores tinham uma configuração diferente. Como resultado, algumas máquinas foram sobrecarregadas usando IOPS. Os chunks não tiveram tempo de escrever / ler devido ao pequeno desempenho, quantidade, volume de discos, grande biblioteca de conteúdo. Por outro lado, máquinas mais poderosas que receberam mais tráfego começaram a falhar no uso da CPU. Os recursos da CPU foram gastos no serviço de tráfego SSL e em pedaços entregues via https, enquanto o IOPS em discos mal atingiu 35%.
O que era necessário era um esquema que, a um custo mínimo, tornasse possível o uso das capacidades disponíveis da maneira ideal. Além disso, seis meses depois, a Copa do Mundo deveria começar e, de acordo com cálculos preliminares, os picos no tráfego ao vivo deveriam ter aumentado seis vezes ...
Nova abordagem para CDN
Após analisar o problema, decidimos separar o VOD e o tráfego ao vivo de acordo com diferentes PADs compostos por servidores com configurações diferentes. E também crie uma função de distribuição de tráfego e seu equilíbrio entre diferentes grupos de servidores. Havia três desses grupos no total:
- Servidores com um grande número de discos de alto desempenho que são mais adequados para armazenar em cache o conteúdo do VOD. De fato, os discos SSD RI com capacidade máxima seriam mais adequados, mas não havia, e seria necessário muito orçamento para comprar a quantidade certa. No final, foi decidido usar o melhor que estava disponível. Cada servidor continha oito discos SAS de 1 TB 10k no RAID5. A partir desses servidores, o VOD_PAD foi compilado.
- Servidores com uma grande quantidade de RAM para armazenar em cache todos os formatos possíveis para a entrega de partes dinâmicas, com processadores capazes de lidar com tráfego SSL e interfaces de rede "grossas". Usamos a seguinte configuração: 2 processadores de 8 núcleos / 192 GB de RAM / 4 interfaces de 10 GB. A partir desses servidores, o EDGE_PAD foi compilado.
- O grupo de servidores restante não consegue lidar com o tráfego VOD, mas é adequado para pequenos volumes de conteúdo ao vivo. Eles podem ser usados como reserva. A partir dos servidores RESERVE_PAD foi compilado.
A distribuição foi a seguinte:
Um módulo lógico especial foi responsável por escolher o PAD do qual o usuário deveria receber o conteúdo. Aqui estão as tarefas dele:
- Analise a URL, aplique o esquema acima para cada solicitação de fluxo e emita o PAD necessário
- Para remover a carga das interfaces EDGE_PAD a cada 5 minutos ( e esse foi o nosso erro ) e, quando o limite for atingido, mude o excesso de tráfego para RESERVE_PAD. Para aliviar a carga, foi gravado um pequeno script perl que retornava os seguintes dados:
- timestamp - data e hora da atualização dos dados de carregamento (no formato RFC 3339);
- total_bandwidth - carga atual da interface (total), Kbps;
- rx_bandwidth - carga atual da interface (tráfego de entrada), Kbps;
- tx_badwidth - carga atual da interface (tráfego de saída), Kbps.
- Direcione o tráfego no modo manual para qualquer servidor PAD ou Origin em caso de situações imprevistas ou, se necessário, trabalhe em um dos PAD. A configuração estava no servidor no formato yaml e permitiu levar todo o tráfego para o PAD desejado ou o tráfego de acordo com um dos parâmetros:
- Tipo de Conteúdo
- criptografia de tráfego
- Tráfego pago
- tipo de dispositivo
- Tipo de lista de reprodução
- Região
Os servidores de origem receberam SSD insuficiente. Infelizmente, ao mudar o tráfego para o Origin, os HIT_RATE nos pedaços de VOD deixaram muito a desejar (cerca de 30%), mas eles executaram sua tarefa; portanto, não observamos nenhum problema com os pacotes na CNN.
Como havia poucos servidores para a configuração do EDGE_PAD, decidiu-se alocá-los nas regiões com maior participação de tráfego - Moscou e a região do Volga. Com a ajuda do GeoDNS, o tráfego foi enviado para a região do Volga a partir das regiões dos distritos federais do Volga e Ural. O centro de Moscou serviu o resto. Não gostamos muito da ideia de entregar tráfego para a Sibéria e o Extremo Oriente a partir de Moscou, mas no total essas regiões representam cerca de 1/20 de todo o tráfego, e os canais da MegaFon se mostraram suficientemente amplos para esses volumes.
Após o desenvolvimento do plano, foi realizado o seguinte trabalho:
- Em duas semanas, desenvolveu a funcionalidade de alternar CDN
- Demorou um mês para instalar e configurar os servidores EDGE_PAD, bem como expandir os canais para eles
- Demorou duas semanas para dividir o grupo de servidores atual em duas partes, além de outras duas semanas para aplicar as configurações a todos os servidores na rede e no equipamento do servidor
- E, finalmente, a semana foi gasta em testes (infelizmente, não sob carga, o que mais tarde afetou)
Paralelou parte do trabalho e, no final, levou seis semanas.
Primeiros Resultados e Planos Futuros
Após o ajuste, o desempenho geral do sistema foi de 250 Gb / s. A solução com a transferência do tráfego de VOD para servidores separados imediatamente mostrou sua eficácia após o lançamento na produção. Desde o início da Copa do Mundo, não houve problemas com o tráfego de VOD. Várias vezes, por várias razões, tive que mudar o tráfego do VOD para o Origin, mas, em princípio, eles também lidaram. Talvez esse esquema não seja muito eficaz devido ao uso muito pequeno do cache, pois forçamos os SSDs a substituir constantemente o conteúdo. Mas o circuito funciona.
Quanto ao tráfego ao vivo, os volumes correspondentes para testar nossa decisão apareceram com o início da Copa do Mundo. Os problemas começaram quando, pela segunda vez, enfrentamos a troca de tráfego quando atingimos o limite durante a partida Rússia-Egito. Quando a troca de tráfego funcionou, tudo foi derramado no PAD de backup. Nesses cinco minutos, o número de solicitações (curva de crescimento) foi tão grande que o CDN de backup entupiu completamente e começou a gerar erros. Ao mesmo tempo, o PAD principal foi lançado durante esse período e começou a ficar um pouco ocioso:
Três conclusões foram tiradas disso:
- Cinco minutos ainda é demais. Foi decidido reduzir o período de descarga para 30 segundos. Como resultado, o tráfego no PAD em espera parou de crescer espasmodicamente:
- É necessário, no mínimo, transferir usuários entre PADs toda vez que o comutador é acionado. Isso deve fornecer suavidade adicional de comutação. Decidimos atribuir um cookie a cada usuário (ou melhor, ao dispositivo), segundo o qual o módulo responsável pela distribuição entende se o usuário deve ser deixado no PAD atual ou se a alternância deve ser realizada. Aqui a tecnologia pode estar a critério de quem a implementa. Como resultado, não descartamos tráfego no PAD principal.
- O limite para a troca foi definido muito baixo, como resultado, o tráfego no PAD de backup cresceu como uma avalanche. No nosso caso, isso foi um resseguro - não tínhamos certeza absoluta de que fizemos o ajuste correto do servidor (a idéia pela qual, a propósito, foi tirada da Habr). O limite foi aumentado para o desempenho físico das interfaces de rede.
As melhorias levaram três dias e, já na partida Rússia-Croácia, verificamos se nossa otimização funcionou. Em geral, o resultado nos agradou. No auge, o sistema processava 215 Gbit / s de tráfego misto. Este não era um limite teórico para o desempenho do sistema - ainda tínhamos uma margem substancial. Se necessário, agora podemos conectar qualquer CDN externa, se necessário, e "lançar" o excesso de tráfego lá. Esse modelo é bom quando você não deseja pagar muito dinheiro todo mês pelo uso da CDN de outra pessoa.
Nossos planos incluem o desenvolvimento adicional da CDN. Para começar, gostaria de estender o esquema EDGE_PAD a todos os distritos federais - isso levará a um menor uso de canais. Também estão sendo realizados testes de circuito de redundância do VOD_PAD, e alguns dos resultados agora parecem bastante impressionantes.
Em geral, tudo o que foi feito no ano passado me leva a pensar que o CDN do serviço que distribui conteúdo de vídeo é obrigatório. E nem mesmo porque permite economizar muito dinheiro, mas porque a CDN se torna parte do próprio serviço, afeta diretamente a qualidade e a funcionalidade. Em tais circunstâncias, entregá-lo nas mãos erradas é pelo menos irracional.