A Netflix é líder no mercado de televisão pela Internet - a empresa que criou e desenvolve ativamente este segmento. A Netflix é conhecida não apenas por seu extenso catálogo de filmes e séries de TV disponíveis em quase todos os cantos do planeta e em qualquer dispositivo com tela, mas também por sua infraestrutura confiável e cultura de engenharia única.
Um exemplo claro da abordagem da Netflix para desenvolver e oferecer suporte a sistemas complexos foi apresentado no DevOops 2019 - Diretor de Desenvolvimento da Netflix. Graduado pela Faculdade de Matemática Computacional e Matemática da Universidade Estadual de Nizhny Novgorod. Lobachevsky, Sergey, um dos primeiros engenheiros da equipe Open Connect - CDN da Netflix. Ele construiu sistemas para monitorar e analisar dados de vídeo, lançou um serviço popular para avaliar a velocidade de conexão com a Internet, FAST.com, e nos últimos anos tem trabalhado na otimização de solicitações de Internet para que o aplicativo Netflix funcione o mais rápido possível para os usuários.
O relatório recebeu as melhores críticas dos participantes da conferência e preparamos uma versão em texto para você.
Em seu relatório, Sergei falou detalhadamente
- sobre o que afeta o atraso nas solicitações de Internet entre o cliente e o servidor;
- como reduzir esse atraso;
- como projetar, manter e monitorar sistemas tolerantes a erros;
- como alcançar resultados em pouco tempo e com risco mínimo para o negócio;
- como analisar resultados e aprender com os erros.
As respostas a essas perguntas não são necessárias apenas para quem trabalha em grandes corporações.
Os princípios e técnicas apresentados devem ser conhecidos e praticados por todos que desenvolvem e dão suporte a produtos para Internet.
A seguir vem a narração da perspectiva do orador.
A importância da velocidade da internet
A velocidade das solicitações da Internet está diretamente relacionada aos negócios. Considere a indústria de compras: Amazon em 2009 que um atraso de 100 ms resulta em uma perda de 1% das vendas.
Existem cada vez mais dispositivos móveis, seguidos por sites e aplicativos móveis. Se sua página demorar mais de 3 segundos para carregar, você perderá cerca de metade dos usuários. COM O Google leva em consideração a velocidade de carregamento da sua página nos resultados de busca: quanto mais rápida a página, maior será sua posição no Google.
A velocidade da conexão também é importante em instituições financeiras onde a latência é crítica. Em 2015, a Hibernia Networks um cabo de US$ 400 milhões entre Nova York e Londres para reduzir a latência entre as cidades em 6 ms. Imagine US$ 66 milhões por 1 ms de redução de latência!
Conforme , velocidades de conexão acima de 5 Mbit/s não afetam mais diretamente a velocidade de carregamento de um site típico. No entanto, existe uma relação linear entre a latência da conexão e a velocidade de carregamento da página:
No entanto, o Netflix não é um produto típico. O impacto da latência e da velocidade no usuário é uma área ativa de análise e desenvolvimento. Há carregamento de aplicativos e seleção de conteúdo que dependem da latência, mas o carregamento de elementos estáticos e o streaming também dependem da velocidade da conexão. Analisar e otimizar os principais fatores que influenciam a experiência do usuário é uma área ativa de desenvolvimento para diversas equipes da Netflix. Um dos objetivos é reduzir a latência de solicitações entre os dispositivos Netflix e a infraestrutura em nuvem.
No relatório focaremos especificamente na redução da latência usando o exemplo da infraestrutura Netflix. Vamos considerar do ponto de vista prático como abordar os processos de projeto, desenvolvimento e operação de sistemas distribuídos complexos e dedicar tempo à inovação e aos resultados, em vez de diagnosticar problemas operacionais e falhas.
Por dentro da Netflix
Milhares de dispositivos diferentes oferecem suporte a aplicativos Netflix. Eles são desenvolvidos por quatro equipes diferentes, que fazem versões separadas do cliente para Android, iOS, TV e navegadores web. E nos esforçamos muito para melhorar e personalizar a experiência do usuário. Para fazer isso, executamos centenas de testes A/B em paralelo.
A personalização é suportada por centenas de microsserviços na nuvem AWS, fornecendo dados personalizados do usuário, envio de consultas, telemetria, Big Data e codificação. A visualização do tráfego é assim:
À esquerda está o ponto de entrada e, em seguida, o tráfego é distribuído entre centenas de microsserviços suportados por diferentes equipes de back-end.
Outro componente importante da nossa infraestrutura é o Open Connect CDN, que entrega conteúdo estático ao usuário final – vídeos, imagens, código do cliente, etc. O CDN está localizado em servidores customizados (OCA - Open Connect Appliance). Dentro, há conjuntos de unidades SSD e HDD rodando FreeBSD otimizado, com NGINX e um conjunto de serviços. Projetamos e otimizamos componentes de hardware e software para que esse servidor CDN possa enviar o máximo de dados possível aos usuários.
A “parede” desses servidores no ponto de troca de tráfego da Internet (Internet eXchange - IX) fica assim:
O Internet Exchange oferece aos provedores de serviços de Internet e de conteúdo a capacidade de “conectarem-se” entre si para trocar dados mais diretamente na Internet. Existem aproximadamente 70-80 pontos de Internet Exchange em todo o mundo onde nossos servidores estão instalados, e nós os instalamos e mantemos de forma independente:
Além disso, também fornecemos servidores diretamente aos provedores de Internet, que eles instalam em sua rede, melhorando a localização do tráfego Netflix e a qualidade do streaming para os usuários:
Um conjunto de serviços AWS é responsável por despachar solicitações de vídeo de clientes para servidores CDN, bem como configurar os próprios servidores - atualização de conteúdo, código de programa, configurações, etc. Para este último, também construímos uma rede backbone que conecta servidores em pontos de Internet Exchange com AWS. A rede backbone é uma rede global de cabos e roteadores de fibra óptica que podemos projetar e configurar com base em nossas necessidades.
Em , nossa infraestrutura CDN fornece aproximadamente ⅛ do tráfego mundial de Internet durante os horários de pico e ⅓ do tráfego na América do Norte, onde a Netflix existe há mais tempo. Números impressionantes, mas para mim uma das conquistas mais surpreendentes é que todo o sistema CDN é desenvolvido e mantido por uma equipe de menos de 150 pessoas.
Inicialmente, a infraestrutura CDN foi projetada para entregar dados de vídeo. Porém, com o tempo percebemos que também podemos usá-lo para otimizar solicitações dinâmicas de clientes na nuvem AWS.
Sobre acelerar a Internet
Hoje, a Netflix possui 3 regiões AWS, e a latência das solicitações para a nuvem dependerá da distância que o cliente está da região mais próxima. Ao mesmo tempo, temos muitos servidores CDN usados para entregar conteúdo estático. Existe alguma maneira de usar essa estrutura para acelerar consultas dinâmicas? Porém, infelizmente, é impossível armazenar essas solicitações em cache – as APIs são personalizadas e cada resultado é único.
Vamos fazer um proxy no servidor CDN e começar a enviar tráfego por meio dele. Será mais rápido?
Materiel
Vamos lembrar como funcionam os protocolos de rede. Hoje, a maior parte do tráfego na Internet usa HTTPs, que depende dos protocolos de camada inferior TCP e TLS. Para que um cliente se conecte ao servidor, ele faz um handshake, e para estabelecer uma conexão segura, o cliente precisa trocar mensagens com o servidor três vezes e pelo menos mais uma vez para transferir os dados. Com uma latência por ida e volta (RTT) de 100 ms, levaríamos 400 ms para receber o primeiro bit de dados:
Se colocarmos os certificados no servidor CDN, o tempo de handshake entre o cliente e o servidor poderá ser significativamente reduzido se o CDN estiver mais próximo. Vamos supor que a latência do servidor CDN seja de 30 ms. Então levará 220 ms para receber o primeiro bit:
Mas as vantagens não param por aí. Depois que uma conexão é estabelecida, o TCP aumenta a janela de congestionamento (a quantidade de informações que ele pode transmitir nessa conexão em paralelo). Se um pacote de dados for perdido, as implementações clássicas do protocolo TCP (como o TCP New Reno) reduzem a “janela” aberta pela metade. O crescimento da janela de congestionamento e a velocidade de sua recuperação da perda dependem novamente do atraso (RTT) do servidor. Se esta conexão for apenas até o servidor CDN, esta recuperação será mais rápida. Ao mesmo tempo, a perda de pacotes é um fenômeno padrão, especialmente em redes sem fio.
A largura de banda da Internet pode ser reduzida, principalmente nos horários de pico, devido ao tráfego de usuários, o que pode gerar engarrafamentos. No entanto, não há como na Internet dar prioridade a algumas solicitações em detrimento de outras. Por exemplo, dê prioridade a solicitações pequenas e sensíveis à latência em vez de fluxos de dados “pesados” que carregam a rede. Porém, no nosso caso, ter nossa própria rede backbone nos permite fazer isso em parte do caminho da solicitação - entre o CDN e a nuvem, e podemos configurá-la totalmente. Você pode garantir que pacotes pequenos e sensíveis à latência sejam priorizados e que grandes fluxos de dados sejam um pouco mais tarde. Quanto mais próximo o CDN estiver do cliente, maior será a eficiência.
Os protocolos de nível de aplicativo (OSI Nível 7) também têm impacto na latência. Novos protocolos como HTTP/2 otimizam o desempenho de solicitações paralelas. No entanto, temos clientes Netflix com dispositivos mais antigos que não suportam os novos protocolos. Nem todos os clientes podem ser atualizados ou configurados de maneira ideal. Ao mesmo tempo, entre o proxy CDN e a nuvem há controle total e a capacidade de usar protocolos e configurações novos e ideais. A parte ineficaz dos protocolos antigos funcionará apenas entre o cliente e o servidor CDN. Além disso, podemos fazer solicitações multiplexadas em uma conexão já estabelecida entre o CDN e a nuvem, melhorando a utilização da conexão no nível TCP:
Nós medimos
Apesar de a teoria prometer melhorias, não temos pressa em lançar o sistema em produção imediatamente. Em vez disso, devemos primeiro provar que a ideia funcionará na prática. Para fazer isso, você precisa responder a várias perguntas:
- velocidade: um proxy será mais rápido?
- Confiança: Vai quebrar com mais frequência?
- Dificuldade: como integrar com aplicativos?
- de custo: Quanto custa implantar infraestrutura adicional?
Consideremos detalhadamente nossa abordagem para avaliar o primeiro ponto. O resto é tratado de forma semelhante.
Para analisar a velocidade das requisições, queremos obter dados de todos os usuários, sem gastar muito tempo no desenvolvimento e sem interromper a produção. Existem várias abordagens para isso:
- RUM ou medição de solicitação passiva. Medimos o tempo de execução das solicitações atuais dos usuários e garantimos cobertura total dos usuários. A desvantagem é que o sinal não é muito estável devido a vários fatores, por exemplo, devido a diferentes tamanhos de solicitação, tempo de processamento no servidor e no cliente. Além disso, não é possível testar uma nova configuração sem efeito na produção.
- Testes laboratoriais. Servidores e infraestrutura especiais que simulam clientes. Com a ajuda deles realizamos os testes necessários. Desta forma, obtemos controle total sobre os resultados da medição e um sinal claro. Mas não há cobertura completa de dispositivos e localizações de usuários (especialmente com serviço e suporte mundial para milhares de modelos de dispositivos).
Como você pode combinar as vantagens de ambos os métodos?
Nossa equipe encontrou uma solução. Escrevemos um pequeno trecho de código – uma amostra – que incorporamos em nossa aplicação. As sondas nos permitem fazer testes de rede totalmente controlados a partir de nossos dispositivos. Funciona assim:
- Logo após carregar o aplicativo e concluir a atividade inicial, executamos nossos testes.
- O cliente faz uma solicitação ao servidor e recebe uma “receita” do teste. A receita é uma lista de URLs para os quais uma solicitação HTTP(s) precisa ser feita. Além disso, a receita configura parâmetros de solicitação: atrasos entre solicitações, quantidade de dados solicitados, cabeçalhos HTTP(s), etc. Ao mesmo tempo, podemos testar várias receitas diferentes em paralelo - ao solicitar uma configuração, determinamos aleatoriamente qual receita emitir.
- O horário de inicialização do probe é selecionado para não entrar em conflito com o uso ativo dos recursos de rede no cliente. Essencialmente, o horário é selecionado quando o cliente não está ativo.
- Após receber a receita, o cliente faz solicitações para cada uma das URLs, em paralelo. A solicitação para cada um dos endereços pode ser repetida - a chamada. "pulsos". No primeiro pulso, medimos quanto tempo levou para estabelecer uma conexão e baixar os dados. No segundo pulso, medimos o tempo necessário para carregar dados em uma conexão já estabelecida. Antes do terceiro, podemos definir um atraso e medir a velocidade de estabelecimento de uma reconexão, etc.
Durante o teste, medimos todos os parâmetros que o dispositivo pode obter:
- Tempo de solicitação de DNS;
- Tempo de configuração da conexão TCP;
- Tempo de configuração da conexão TLS;
- hora de recebimento do primeiro byte de dados;
- tempo total de carregamento;
- código de resultado de status.
- Após a conclusão de todos os pulsos, a amostra carrega todas as medições para análise.
Os pontos-chave são a dependência mínima da lógica do cliente, o processamento de dados no servidor e a medição de solicitações paralelas. Assim, conseguimos isolar e testar a influência de diversos fatores que afetam o desempenho das consultas, variá-los dentro de uma única receita e obter resultados de clientes reais.
Essa infraestrutura provou ser útil para mais do que apenas análise de desempenho de consultas. Atualmente temos 14 receitas ativas, mais de 6000 amostras por segundo, recebendo dados de todos os cantos do planeta e cobertura total do dispositivo. Se a Netflix comprasse um serviço semelhante de terceiros, custaria milhões de dólares por ano, com uma cobertura muito pior.
Teoria de teste na prática: protótipo
Com esse sistema, conseguimos avaliar a eficácia dos proxies CDN na latência da solicitação. Agora você precisa de:
- crie um protótipo de proxy;
- coloque o protótipo em uma CDN;
- determinar como direcionar clientes para um proxy em um servidor CDN específico;
- Compare o desempenho com solicitações na AWS sem proxy.
A tarefa é avaliar a eficácia da solução proposta o mais rápido possível. Escolhemos Go para implementar o protótipo devido à disponibilidade de boas bibliotecas de rede. Em cada servidor CDN, instalamos o protótipo de proxy como um binário estático para minimizar dependências e simplificar a integração. Na implementação inicial, usamos componentes padrão tanto quanto possível e pequenas modificações para pool de conexões HTTP/2 e multiplexação de solicitações.
Para balancear entre regiões AWS, utilizamos um banco de dados DNS geográfico, o mesmo usado para balancear clientes. Para selecionar um servidor CDN para o cliente, usamos TCP Anycast para servidores no Internet Exchange (IX). Nesta opção, utilizamos um endereço IP para todos os servidores CDN, e o cliente será direcionado para o servidor CDN com menor número de saltos IP. Em servidores CDN instalados por provedores de Internet (ISPs), não temos controle sobre o roteador para configurar o TCP Anycast, por isso usamos , que direciona os clientes a provedores de Internet para streaming de vídeo.
Assim, temos três tipos de caminhos de solicitação: para a nuvem através da Internet aberta, através de um servidor CDN no IX ou através de um servidor CDN localizado em um provedor de Internet. Nosso objetivo é entender qual caminho é melhor e qual a vantagem de um proxy, em comparação com a forma como as solicitações são enviadas para produção. Para fazer isso, usamos um sistema de amostragem como segue:
Cada um dos caminhos se torna um alvo separado e analisamos o tempo que obtivemos. Para análise, combinamos os resultados do proxy em um grupo (selecionamos o melhor horário entre os proxies IX e ISP) e os comparamos com o tempo de solicitações à nuvem sem proxy:
Como você pode ver, os resultados foram mistos - na maioria dos casos o proxy oferece uma boa aceleração, mas também há um número suficiente de clientes para os quais a situação irá piorar significativamente.
Como resultado, fizemos várias coisas importantes:
- Avaliamos o desempenho esperado de solicitações de clientes para a nuvem por meio de um proxy CDN.
- Recebemos dados de clientes reais, de todos os tipos de dispositivos.
- Percebemos que a teoria não estava 100% confirmada e a oferta inicial com um proxy CDN não funcionaria para nós.
- Não corremos riscos – não alteramos as configurações de produção dos clientes.
- Nada foi quebrado.
Protótipo 2.0
Então, volte à prancheta e repita o processo novamente.
A ideia é que ao invés de usarmos um proxy 100%, determinaremos o caminho mais rápido para cada cliente, e enviaremos as solicitações para lá – ou seja, faremos o que chamamos de direcionamento do cliente.
Como implementar isso? Não podemos usar lógica no lado do servidor, porque... O objetivo é conectar-se a este servidor. Precisa haver alguma maneira de fazer isso no cliente. E o ideal é fazer isso com um mínimo de lógica complexa, para não resolver o problema de integração com um grande número de plataformas clientes.
A resposta é usar DNS. No nosso caso, temos a nossa própria infraestrutura DNS e podemos configurar uma zona de domínio para a qual os nossos servidores serão autoritários. Funciona assim:
- O cliente faz uma solicitação ao servidor DNS usando um host, por exemplo api.netflix.xom.
- A solicitação chega ao nosso servidor DNS
- O servidor DNS sabe qual caminho é o mais rápido para este cliente e emite o endereço IP correspondente.
A solução tem uma complexidade adicional: os provedores de DNS autoritários não veem o endereço IP do cliente e só podem ler o endereço IP do resolvedor recursivo que o cliente usa.
Como resultado, o nosso resolvedor autoritário deve tomar uma decisão não para um cliente individual, mas para um grupo de clientes com base no resolvedor recursivo.
Para resolver, usamos as mesmas amostras, agregamos os resultados das medições dos clientes para cada um dos resolvedores recursivos e decidimos para onde enviar esse grupo deles - um proxy através do IX usando TCP Anycast, através de um proxy ISP ou diretamente para a nuvem.
Obtemos o seguinte sistema:
O modelo de direcionamento de DNS resultante permite direcionar clientes com base em observações históricas da velocidade das conexões dos clientes com a nuvem.
Novamente, a questão é: até que ponto esta abordagem funcionará de forma eficaz? Para responder, usamos novamente nosso sistema de sondagem. Portanto, definimos a configuração do apresentador, onde um dos alvos segue a direção do direcionamento do DNS, o outro vai direto para a nuvem (produção atual).
Como resultado, comparamos os resultados e obtemos uma avaliação da eficácia:
Como resultado, aprendemos várias coisas importantes:
- Avaliamos o desempenho esperado de solicitações de clientes para a nuvem usando DNS Steering.
- Recebemos dados de clientes reais, de todos os tipos de dispositivos.
- A eficácia da ideia proposta foi comprovada.
- Não corremos riscos – não alteramos as configurações de produção dos clientes.
- Nada foi quebrado.
Agora, sobre a parte difícil - nós o lançamos em produção
A parte fácil acabou - existe um protótipo funcional. Agora, a parte difícil é lançar uma solução para todo o tráfego da Netflix, implantando-a para 150 milhões de usuários, milhares de dispositivos, centenas de microsserviços e um produto e uma infraestrutura em constante mudança. Os servidores Netflix recebem milhões de solicitações por segundo e é fácil interromper o serviço com ações descuidadas. Ao mesmo tempo, queremos rotear dinamicamente o tráfego através de milhares de servidores CDN na Internet, onde algo muda e quebra constantemente e nos momentos mais inoportunos.
E com tudo isso a equipe conta com 3 engenheiros responsáveis pelo desenvolvimento, implantação e suporte total do sistema.
Portanto, continuaremos falando sobre um sono reparador e saudável.
Como continuar o desenvolvimento e não gastar todo o seu tempo com suporte? Nossa abordagem é baseada em 3 princípios:
- Reduzimos a escala potencial de avarias (raio de explosão).
- Estamos nos preparando para surpresas - esperamos que algo quebre, apesar dos testes e da experiência pessoal.
- Degradação graciosa – se algo não funcionar bem, deve ser corrigido automaticamente, mesmo que não da maneira mais eficiente.
Descobriu-se que no nosso caso, com esta abordagem do problema, podemos encontrar uma solução simples e eficaz e simplificar significativamente o suporte do sistema. Percebemos que poderíamos adicionar um pequeno trecho de código ao cliente e monitorar erros de solicitação de rede causados por problemas de conexão. Em caso de erros de rede, recorremos diretamente à nuvem. Esta solução não exige um esforço significativo das equipas dos clientes, mas reduz muito o risco de avarias inesperadas e surpresas para nós.
É claro que, apesar do recuo, seguimos uma disciplina clara durante o desenvolvimento:
- Teste de amostra.
- Teste A/B ou Canários.
- Lançamento progressivo.
Com amostras, a abordagem foi descrita - as alterações são primeiro testadas usando uma receita personalizada.
Para testes canário, precisamos obter pares de servidores comparáveis nos quais possamos comparar como o sistema funciona antes e depois das alterações. Para fazer isso, em nossos vários sites CDN, selecionamos pares de servidores que recebem tráfego comparável:
Em seguida, instalamos a compilação com as alterações no servidor Canary. Para avaliar os resultados, executamos um sistema que compara aproximadamente 100-150 métricas com uma amostra de servidores de Controle:
Se o teste Canary for bem-sucedido, nós o lançaremos gradualmente, em ondas. Não atualizamos servidores em cada site ao mesmo tempo – perder um site inteiro devido a problemas tem um impacto mais significativo no serviço para os usuários do que perder o mesmo número de servidores em locais diferentes.
Em geral, a eficácia e a segurança desta abordagem dependem da quantidade e da qualidade das métricas recolhidas. Para nosso sistema de aceleração de consultas, coletamos métricas de todos os componentes possíveis:
- de clientes – número de sessões e solicitações, taxas de fallback;
- proxy - estatísticas sobre o número e horário das solicitações;
- DNS - número e resultados das solicitações;
- borda da nuvem – número e tempo para processamento de solicitações na nuvem.
Tudo isso é coletado em um único pipeline e, dependendo da necessidade, decidimos quais métricas enviar para análises em tempo real e quais para Elasticsearch ou Big Data para diagnósticos mais detalhados.
Nós monitoramos
No nosso caso, estamos fazendo alterações no caminho crítico das solicitações entre o cliente e o servidor. Ao mesmo tempo, o número de componentes diferentes no cliente, no servidor e no caminho pela Internet é enorme. Mudanças no cliente e no servidor ocorrem constantemente - durante o trabalho de dezenas de equipes e mudanças naturais no ecossistema. Estamos no meio - ao diagnosticar problemas, há uma boa chance de estarmos envolvidos. Portanto, precisamos entender claramente como definir, coletar e analisar métricas para isolar problemas rapidamente.
Idealmente, acesso total a todos os tipos de métricas e filtros em tempo real. Mas há muitas métricas, então surge a questão do custo. No nosso caso, separamos métricas e ferramentas de desenvolvimento da seguinte forma:
Para detectar e fazer a triagem de problemas, usamos nosso próprio sistema de código aberto em tempo real и - para visualização. Armazena métricas agregadas na memória, é confiável e integra-se ao sistema de alerta. Para localização e diagnóstico, temos acesso aos logs do Elasticsearch e do Kibana. Para análise estatística e modelagem, usamos big data e visualização no Tableau.
Parece que esta abordagem é muito difícil de trabalhar. No entanto, ao organizar métricas e ferramentas hierarquicamente, podemos analisar rapidamente um problema, determinar o tipo de problema e, em seguida, detalhar as métricas detalhadas. Em geral, gastamos cerca de 1 a 2 minutos para identificar a origem da falha. Depois disso, trabalhamos com uma equipe específica de diagnóstico – de dezenas de minutos a várias horas.
Mesmo que o diagnóstico seja feito rapidamente, não queremos que isso aconteça com frequência. Idealmente, só receberemos um alerta crítico quando houver um impacto significativo no serviço. Para nosso sistema de aceleração de consultas, temos apenas 2 alertas que irão notificar:
- Percentual de Fallback do Cliente – avaliação do comportamento do cliente;
- porcentagem de erros de sondagem - dados de estabilidade dos componentes da rede.
Esses alertas críticos monitoram se o sistema está funcionando para a maioria dos usuários. Observamos quantos clientes usaram substituto se não conseguiram obter aceleração de solicitação. Temos em média menos de 1 alerta crítico por semana, embora haja muitas mudanças em andamento no sistema. Por que isso é suficiente para nós?
- Há um substituto do cliente se nosso proxy não funcionar.
- Existe um sistema de direção automática que responde aos problemas.
Mais detalhes sobre este último. Nosso sistema de teste e o sistema para determinar automaticamente o caminho ideal para solicitações do cliente para a nuvem nos permitem lidar automaticamente com alguns problemas.
Vamos retornar ao nosso exemplo de configuração e às 3 categorias de caminho. Além do tempo de carregamento, podemos observar o próprio fato da entrega. Se não foi possível carregar os dados, observando os resultados ao longo de diferentes caminhos, podemos determinar onde e o que quebrou e se podemos corrigi-lo automaticamente alterando o caminho da solicitação.
Примеры:
Este processo pode ser automatizado. Inclua-o no sistema de direção. E ensine-o a responder a problemas de desempenho e confiabilidade. Se algo começar a quebrar, reaja se houver uma opção melhor. Ao mesmo tempo, uma reação imediata não é crítica, graças ao apoio dos clientes.
Assim, os princípios de suporte do sistema podem ser formulados da seguinte forma:
- reduzindo a escala das avarias;
- coleta de métricas;
- Reparamos automaticamente as avarias, se pudermos;
- se não puder, nós o notificaremos;
- Estamos trabalhando em painéis e um conjunto de ferramentas de triagem para uma resposta rápida.
Lições aprendidas
Não leva muito tempo para escrever um protótipo. No nosso caso, ficou pronto após 4 meses. Com ele recebemos novas métricas, e 10 meses após o início do desenvolvimento recebemos o primeiro tráfego de produção. Começou então o trabalho tedioso e muito difícil: produzir e dimensionar gradativamente o sistema, migrar o tráfego principal e aprender com os erros. No entanto, este processo eficaz não será linear – apesar de todos os esforços, nem tudo pode ser previsto. É muito mais eficaz iterar e responder rapidamente a novos dados.
Com base em nossa experiência, podemos recomendar o seguinte:
- Não confie na sua intuição.
A nossa intuição falhou constantemente, apesar da vasta experiência dos membros da nossa equipa. Por exemplo, previmos incorretamente a aceleração esperada ao usar um proxy CDN ou o comportamento do TCP Anycast.
- Obtenha dados da produção.
É importante obter acesso a pelo menos uma pequena quantidade de dados de produção o mais rápido possível. É quase impossível obter o número de casos, configurações e ajustes únicos em condições de laboratório. O acesso rápido aos resultados permitirá que você aprenda rapidamente sobre possíveis problemas e leve-os em consideração na arquitetura do sistema.
- Não siga os conselhos e resultados de outras pessoas – colete seus próprios dados.
Siga os princípios de coleta e análise de dados, mas não aceite cegamente os resultados e declarações de outras pessoas. Só você pode saber exatamente o que funciona para seus usuários. Seus sistemas e seus clientes podem ser significativamente diferentes de outras empresas. Felizmente, as ferramentas de análise já estão disponíveis e são fáceis de usar. Os resultados obtidos podem não ser os que afirmam Netflix, Facebook, Akamai e outras empresas. No nosso caso, o desempenho de TLS, HTTP2 ou estatísticas sobre solicitações de DNS difere dos resultados do Facebook, Uber, Akamai – porque temos dispositivos, clientes e fluxos de dados diferentes.
- Não siga as tendências da moda desnecessariamente e avalie a eficácia.
Comece simples. É melhor criar um sistema simples e funcional em pouco tempo do que gastar muito tempo desenvolvendo componentes desnecessários. Resolva tarefas e problemas importantes com base em suas medições e resultados.
- Prepare-se para novas aplicações.
Assim como é difícil prever todos os problemas, é difícil prever antecipadamente os benefícios e as aplicações. Siga o exemplo das startups: sua capacidade de se adaptar às condições do cliente. No seu caso, você poderá descobrir novos problemas e suas soluções. Em nosso projeto, estabelecemos uma meta de reduzir a latência das solicitações. Porém, durante as análises e discussões, percebemos que também podemos utilizar servidores proxy:
- equilibrar o tráfego entre regiões da AWS e reduzir custos;
- modelar a estabilidade do CDN;
- configurar DNS;
- para configurar TLS/TCP.
Conclusão
No relatório, descrevi como a Netflix resolve o problema de aceleração de solicitações de Internet entre clientes e a nuvem. Como coletamos dados usando um sistema de amostragem nos clientes e usamos os dados históricos coletados para encaminhar solicitações de produção dos clientes pelo caminho mais rápido da Internet. Como usamos os princípios dos protocolos de rede, nossa infraestrutura CDN, rede backbone e servidores DNS para realizar essa tarefa.
No entanto, nossa solução é apenas um exemplo de como nós da Netflix implementamos tal sistema. O que funcionou para nós. A parte aplicada do meu relatório para vocês são os princípios de desenvolvimento e apoio que seguimos e alcançamos bons resultados.
Nossa solução para o problema pode não ser adequada para você. No entanto, a teoria e os princípios de design permanecem, mesmo que você não tenha sua própria infraestrutura CDN ou que seja significativamente diferente da nossa.
A importância da velocidade das solicitações comerciais também continua importante. E mesmo para um serviço simples você precisa fazer uma escolha: entre provedores de nuvem, localização de servidores, provedores de CDN e DNS. Sua escolha influenciará a eficácia das consultas na Internet para seus clientes. E é importante você medir e compreender essa influência.
Comece com soluções simples, preocupe-se em como você muda o produto. Aprenda à medida que avança e melhore o sistema com base nos dados de seus clientes, sua infraestrutura e seus negócios. Pense na possibilidade de falhas inesperadas durante o processo de design. E então você pode acelerar seu processo de desenvolvimento, melhorar a eficiência da solução, evitar cargas de suporte desnecessárias e dormir em paz.
Este ano em formato on-line. Você pode fazer perguntas a um dos pais do DevOps, o próprio John Willis!
Fonte: habr.com