O streaming de qualidade de vídeo depende de milhões de coisas a correr bem, como gerir uma carga de trabalho constantemente flutuante ou lidar com “multidões de flash” quando um grande número de espetadores entra numa transmissão ao mesmo tempo. É por isso que fornecer um fluxo de vídeo confiável e de alta qualidade como parte de um serviço pago – onde os espetadores esperam uma experiência semelhante à TV – requer ferramentas e métricas para articular com precisão os desafios de desempenho para que você possa saber onde e como corrigir problemas.
Os CDNs são uma solução indispensável em streaming de vídeo porque fornecem escalabilidade de baixa latência sob demanda em todo o mundo. Além das otimizações que melhoram a maneira, a CDN equilibra o crescimento caótico da audiência que pode acompanhar um fluxo ao vivo, oferecendo um ótimo desempenho ao usuário final requer uma camada adicional de visibilidade, métricas, ferramentas e automação.
Neste post, vamos rever exemplos de otimizações de desempenho recentes que fizemos para um grande serviço de streaming vMVPD norte-americano, incluindo:
- Métricas que usamos para melhorar/corrigir problemas de desempenho
- Como definir o desempenho e como medi-lo
- Otimizações contínuas que tomamos para melhorar o desempenho do vídeo
Números de Sistema Autônomo: A complexidade por trás da cortina
A web moderna é construída em torno de múltiplas camadas interligadas de redes conhecidas como ASNs (números de sistema autónomos), cada uma composta por grandes grupos de endereços IP acoplados a CDNs ( redes de distribuição de conteúdo ) que reduzem o congestionamento ao disponibilizar o conteúdo na borda. Essencialmente, como mostrado abaixo, a Internet consiste numa rede de redes, cada uma com o seu modelo de negócio único e prioridades.
Fonte: Portão de Investigação
Juntamente com a complexidade inerente de ASNs interagindo uns com os outros é o seu grande alcance e escala. A ferramenta vizAS tenta visualizar as interconexões entre os muitos ASNs em uma base país a país. Por exemplo, só nos EUA, há 16 979 ASNs e 24 905 relações de peering entre as redes. Globalmente, existem mais de 90 000 ASNs.
https://stats.apnic.net/vizas/index.html
Da nossa perspetiva como um provedor de CDN, a complexidade envolvida na conexão com milhares de ASNs é agravada pela necessidade de acomodar os requisitos de desempenho de cada cliente, perfil de uso, tipo de tráfego e muitos outros fatores. Por exemplo, um serviço como o Twitter terá um perfil de uso muito diferente do que uma empresa de jogos que está a promover uma grande atualização. Da mesma forma, uma emissora que transmite um evento desportivo ao vivo tem um perfil diferente de um serviço de streaming a pedido. Mesmo dois serviços de transmissão ao vivo provavelmente têm perfis diferentes, cada um exigindo uma otimização de desempenho personalizada.
Nos bastidores, temos um grande número de configurações que podemos ajustar e ajustar para ajudar os clientes a atingir os seus objetivos e requisitos de desempenho. Para alguns, o desempenho pode ser o que eles esperavam (ou melhor) desde o primeiro lugar, e não precisamos mudar nada. Outros podem ter objetivos específicos, como o TTFB mais rápido (Time to First Byte), uma métrica importante para serviços de streaming, que precisam ser abordados.
Dada a complexidade e o tamanho da Internet, é impossível fornecer melhorias de desempenho úteis e consistentes através de abordagens de “pancada” ou de dispersão. Os ganhos reais vêm através de uma recolha abrangente de dados e análise intensiva de dados para identificar a causa raiz do problema ou obter proativamente informações sobre as alterações de configuração da rede que irão beneficiar o cliente mais.
Fornecendo insights de RTT com Stargazer
Uma das métricas mais importantes para determinar a latência da rede e a integridade geral do desempenho é o RTT (tempo de ida e volta). Isto é definido como a duração, medida em milissegundos, é preciso um pacote para viajar da origem para o destino e uma resposta para ser enviada de volta para a origem. Pode ser usado para diagnosticar e melhorar o desempenho da rede em vários vetores, incluindo congestionamento, problemas de hardware, configurações erradas e problemas de roteamento.
Dada a importância desta métrica, construímos um sistema interno chamado Stargazer que usamos para agregar dados RTT de várias fontes, incluindo os nossos sensores, dados que importamos de clientes e terceiros que também monitoram informações RTT. O Stargazer monitoriza os tempos de resposta de saída para o cliente. Outras fontes de dados podem incluir tabelas BGP (Border Gateway Protocol) de roteadores, mapeamento de roteadores para localizações geográficas, logs RTT para conexões de clientes e informações de volume de tráfego. Além disso, o sistema pode executar sondas ativas, como traceroutes e pings, quando necessário.
Por trás da atividade de monitorização, o Stargazer, em conjunto com outras ferramentas que desenvolvemos, permite-nos consultar todos os dados que recolhemos e realizar análises aprofundadas que abrem a porta para melhorias contínuas. Os nossos administradores de rede podem usar estas informações para isolar problemas e identificar rotas ou configurações de rede para otimizar o desempenho para objetivos e requisitos específicos dos clientes. E, como será discutido mais tarde, também é útil para entender o efeito que as novas tecnologias, como o protocolo BBR (largura de banda de gargalo e tempo de propagação de ida e volta), têm no desempenho.
Otimizando um servidor de origem
Para fornecer mais informações sobre como a otimização de desempenho funciona na prática, vamos ver um exemplo envolvendo um cliente de streaming de vídeo ao vivo recentemente adicionado que precisava de otimizar para uma arquitetura multi-CDN . Numa arquitetura de cliente CDN tradicional, o cliente faz uma solicitação a um dos nossos POPs, e o cache pop é preenchido a partir da origem, conforme mostrado abaixo.
No entanto, este cliente optou por tirar partido de uma arquitetura multi-CDN para aumentar a redundância e a resiliência e potencialmente aumentar o desempenho. Isto é permitido pela nossa Arquitetura Origin Shield mostrada na Figura 4. O Origin Shield oferece mais controle sobre como o tráfego de vários clientes pode ser encaminhado para o melhor desempenho.
Ao contrário de uma relação CDN tradicional, todo o tráfego, incluindo o servido pela segunda CDN, flui de volta para um dos nossos POPs (AGA) localizados em Atlanta para preenchimento de cache. O Aga Pop serve então como a origem, ou mais especificamente, o que é conhecido como escudo de origem, aliviando a carga considerável do servidor de origem do cliente. O AGA Pop foi escolhido como o local do escudo de origem devido à sua maior taxa de acerto de cache e desempenho do que a segunda CDN. Uma grande preocupação, no entanto, foi otimizar o desempenho entre as duas CDNs.
O primeiro passo do processo foi analisar a otimização das rotas tomadas pela segunda CDN para a AGA, com ela atuando como escudo de origem. Um problema imediatamente aparente foi o mau desempenho entre os CDNs e um grande número de tempos de conexão que impactam o TTFB. Para investigar os problemas de desempenho, usamos o Stargazer para enviar um traceroute da AGA para o destino pretendido e capturar os ASNs usados para cada salto.
Como mostrado no resumo abaixo, um traceroute foi enviado do AGA para um endereço IP na segunda CDN, simulando o caminho do cliente.
Notámos que vários saltos estavam dentro do ASN 7018, o que não era o caminho preferido porque envolvia mais lúpulo e tinha mais congestão. Usando o Stargazer, rapidamente confirmámos o problema e fizemos as mudanças de rede apropriadas. Como mostra o resumo traceroute, depois de fazer a mudança de rede, diminuímos a contagem de saltos e melhoramos o RTT mudando para ASN 7922, o que também resolveu o problema com os tempos limite do TTFB.
Em outro exemplo, usamos a ferramenta Stargazer para determinar o melhor caminho de escudo de origem para o servidor de origem de um cliente localizado na costa leste. Para reduzir eficazmente a carga na origem de um cliente e melhorar o desempenho da entrega, o escudo de origem deve estar próximo da origem. Às vezes, não é necessariamente o pop físico mais próximo que funciona melhor. É uma combinação do menor número de ASNs, a menor quantidade de congestionamento e baixos tempos de RTT. Como podem ver no antes e depois do gráfico abaixo, um traceroute Stargazer mostrou que a mudança do pop NYA (Nova Iorque) para o pop DCC (Washington, D.C.) reduziu a contagem de saltos para três, resultando numa melhoria geral no desempenho da RTT.
Análise mais profunda com o Sweeper Fish
Com mais de 7 000 interconexões e mais de 300 pops na nossa CDN globalmente, há muito trabalho de otimização contínuo. Para não fazer girar as rodas em tarefas que podem não fazer muita diferença, precisávamos de uma maneira eficiente de priorizar as ações tomadas pelas nossas equipas operacionais. Esta necessidade levou ao desenvolvimento de uma ferramenta de companhia para Stargazer chamada Sweeper Fish que pontuou os locais onde existem problemas e nos permite bolha-los de uma forma priorizada.
O peixe varredor também é útil para determinar se uma rota está congestionada e se é provável causar problemas. Voltando ao exemplo de multi-CDN, usamos o Sweeper Fish para descobrir quais rotas tinham congestionamento. Para fazer isso, o Sweeper Fish mediu o delta entre o percentil 25 e 75 para dados DE rum (Real User Measurement) para todos os clientes em todos os caminhos para o AGA Pop, focando no segundo caminho da CDN para nós, ASN7922. O desvio padrão para todo o tráfego ao longo deste ASN é mostrado abaixo.
Também confirmámos que a configuração anterior através do ASN7018 não era o caminho a percorrer. A análise dos peixes varredor mostrou que o IQR (Interquartil Range) aumentou para 20-60 a milissegundos (ver figura 9) devido ao congestionamento nesta rota. O IQR, também chamado de midspread ou médio 50%, fornece uma maneira útil de analisar uma rota e sinalizar problemas rapidamente. Quanto menor o IQR, melhor.
Em contraste, o Aga Pop estava consistentemente entre 10-22 milissegundos na rota que acabámos por usar, ASN7922, como mostrado abaixo. Ao comparar diferentes ASNs, o Sweeper Fish permite-nos escolher a melhor rota menos congestionada e/ou identificar problemas para a remediação.
Sintonização de TCP
O congestionamento também faz com que os pacotes sejam descartados e retransmitidos. Isto ocorre quando os caminhos entre os POPs estão distantes e o algoritmo de TCP não é otimizado. Como a AGA foi a origem do nosso exemplo, foi possível que os POPs distantes que chegaram à AGA tivessem este problema. Embora espalhado por muitos POPs, os logs de CDN agregados abaixo nos permitiram identificar áreas problemáticas conforme indicado pelas caixas.
Figura 11. Os logs de servidor agregados identificam rapidamente áreas problemáticas onde os pacotes estão sendo descartados e retransmitidos.
Avaliar a BBR
Largura de banda de gargalo e Tempo de Propagação de ida e volta (BBR) é um algoritmo alternativo de controle de congestionamento do TCP desenvolvido pelo Google que começou a ganhar alguma tração. Difere dos algoritmos de controlo de congestionamento baseados em perdas, como o ubíquo tcp-cubic, e introduz um paradigma de operação diferente. Ele atualiza continuamente a quantidade de dados que podem estar em voo com base no RTT mínimo que a sessão viu até agora para evitar bloat de buffer.
A nossa análise descobriu que a BBR é útil para melhorar o desempenho da TTR, mas fica aquém de uma solução universal. Há algumas vezes em que você quer usá-lo e outras vezes em que você não o usa. O Stargazer ajuda-nos a determinar quando queremos usá-lo rastreando o perfil consistente das RTTs para destinos durante períodos. Isto permite-nos determinar os melhores locais para aplicar o BBR para ajudar a reduzir as retransmissões e melhorar o controlo do fluxo.
Com base na análise mostrada nos gráficos abaixo, concluímos que mudar para BBR melhoraria ligeiramente o desempenho do AGA Pop para a segunda CDN e origem do cliente. O primeiro conjunto de gráficos mostra que mudar de tcp-cúbico para tcp bb resultou em uma diminuição nas retransmissões, enquanto o segundo conjunto de gráficos indica que a mudança para bb proporcionou um ligeiro aumento na taxa de transferência média.
Figura 12. Neste exemplo, mudar de tcp-cúbico para tcp bb resultou em uma diminuição nas retransmissões
Figura 13. Neste exemplo, mudar para BBR para o controlo de fluxo de tcp-cubic para o AGA Pop reduziu as retransmissões e melhorou ligeiramente a taxa de transferência média.
Conclusão
A Internet é vasta e complexa – é essencialmente uma rede de redes. Para o Edgecast, agora o Edgio, otimizar o desempenho para casos de uso do cliente seria quase impossível sem análises detalhadas para obter informações sobre áreas problemáticas e testar possíveis mudanças de configuração. Para melhorar o desempenho dos nossos clientes, desenvolvemos um conjunto robusto de ferramentas para monitorizar RTTs continuamente para que possamos fazer melhorias de forma rápida e eficiente em toda a nossa rede. Para um serviço de transmissão de vídeo ao vivo, encontrámos formas de otimizar o desempenho para os seus requisitos únicos, ao mesmo tempo que avaliamos o uso do BBR para a sua aplicação. O resultado foi uma solução de streaming de alto desempenho que alavancava dois CDNs. E ainda não terminámos. À medida que o congestionamento da rede continua a aumentar, nunca deixaremos de otimizar a nossa rede para garantir que os nossos clientes e os seus clientes tenham a melhor experiência online possível.
