{"id":84876,"date":"2020-06-11T13:43:18","date_gmt":"2020-06-11T11:43:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno"},"modified":"2020-06-11T13:43:18","modified_gmt":"2020-06-11T11:43:18","slug":"uskoryaem-internet-zaprosy-i-spim-spokojno","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","title":{"rendered":"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/07e2e32d406b8b5d6d6cb3f627a31c3a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA Netflix \u00e9 a l\u00edder do mercado de streaming \u2014 uma empresa que criou e desenvolve ativamente este segmento. A Netflix \u00e9 conhecida n\u00e3o apenas pelo extenso cat\u00e1logo de filmes e s\u00e9ries dispon\u00edveis em quase qualquer lugar do planeta e em qualquer dispositivo com tela, mas tamb\u00e9m pela sua infraestrutura confi\u00e1vel e pela cultura de engenharia \u00fanica. <\/p>\n<p>Um exemplo claro da abordagem da Netflix ao desenvolvimento e suporte de sistemas complexos foi apresentado <noindex><a rel=\"nofollow\" href=\"https:\/\/sfedov.com\">Sergey Fedorov<\/a><\/noindex> \u2014 diretor de desenvolvimento na Netflix. Formado pela Faculdade de Matem\u00e1tica, Mec\u00e2nica e Ci\u00eancia da Computa\u00e7\u00e3o da Universidade Estatal de Nizhny Novgorod, Sergey \u00e9 um dos primeiros engenheiros da Open Connect \u2014 equipe de CDN da Netflix. Ele construiu sistemas de monitoramento e an\u00e1lise de dados de v\u00eddeo, lan\u00e7ou o popular servi\u00e7o de avalia\u00e7\u00e3o de velocidade de conex\u00e3o \u00e0 Internet FAST.com e, nos \u00faltimos anos, tem trabalhado na otimiza\u00e7\u00e3o de requisi\u00e7\u00f5es de Internet para que o aplicativo da Netflix funcione o mais r\u00e1pido poss\u00edvel para os usu\u00e1rios.<\/p>\n<p>A apresenta\u00e7\u00e3o recebeu os melhores coment\u00e1rios dos participantes da confer\u00eancia, e preparamos para voc\u00ea a vers\u00e3o textual.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"n7Te9WIz1ho\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/n7Te9WIz1ho\/hqdefault.jpg\" alt=\"Por que no hosting comum a administra\u00e7\u00e3o do PrestaShop \u00e9 lenta, e no seu n\u00e3o \u00e9?\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h2>Na apresenta\u00e7\u00e3o, Sergey detalhou<\/h2>\n<p><\/p>\n<ul>\n<li>o que influencia a lat\u00eancia das requisi\u00e7\u00f5es de internet entre o cliente e o servidor;<\/li>\n<li>como reduzir essa lat\u00eancia;<\/li>\n<li>como projetar, manter e monitorar sistemas \u00e0 prova de falhas;<\/li>\n<li>como alcan\u00e7ar resultados em prazos curtos, com o m\u00ednimo de risco para os neg\u00f3cios;<\/li>\n<li>como analisar resultados e aprender com os erros.<\/li>\n<\/ul>\n<p>\nAs respostas a essas perguntas s\u00e3o necess\u00e1rias n\u00e3o s\u00f3 para quem trabalha em grandes corpora\u00e7\u00f5es. <\/p>\n<p>Os princ\u00edpios e t\u00e9cnicas apresentados devem ser conhecidos e praticados por todos que desenvolvem e mant\u00eam produtos na internet.<\/p>\n<p><b>A seguir \u2014 o relato em primeira pessoa do palestrante.<\/b><\/p>\n<h2>A import\u00e2ncia da velocidade da internet<\/h2>\n<p>\nA velocidade das requisi\u00e7\u00f5es de internet est\u00e1 diretamente ligada aos neg\u00f3cios. Vamos considerar a \u00e1rea de compras: a empresa Amazon, em 2009, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.gigaspaces.com\/blog\/amazon-found-every-100ms-of-latency-cost-them-1-in-sales\/\">afirmou<\/a><\/noindex>, que uma lat\u00eancia de 100 ms leva a uma perda de 1% nas vendas.<\/p>\n<p>Cada vez mais dispositivos m\u00f3veis surgem, e com eles, sites e aplicativos m\u00f3veis. Se a sua p\u00e1gina demora mais de 3 segundos para carregar, voc\u00ea perde cerca de metade dos usu\u00e1rios. Desde <noindex><a rel=\"nofollow\" href=\"https:\/\/webmasters.googleblog.com\/2018\/01\/using-page-speed-in-mobile-search.html\">julho de 2018,<\/a><\/noindex> a Google considera a velocidade de carregamento da sua p\u00e1gina nos resultados de busca: quanto mais r\u00e1pida a p\u00e1gina, melhor sua posi\u00e7\u00e3o no Google.<\/p>\n<p>A velocidade de conex\u00e3o \u00e9 igualmente importante nas institui\u00e7\u00f5es financeiras, onde a lat\u00eancia \u00e9 cr\u00edtica. Em 2015, a Hibernia Networks <noindex><a rel=\"nofollow\" href=\"https:\/\/www.submarinenetworks.com\/en\/systems\/trans-atlantic\/project-express\/hibernia-express-connects-new-york-to-london-in-under-58-95ms\">concluiu<\/a><\/noindex> um cabo de fibra \u00f3ptica entre Nova Iorque e Londres custando 400 milh\u00f5es de d\u00f3lares, para reduzir a lat\u00eancia entre as cidades em 6 ms. Imagine, 66 milh\u00f5es de d\u00f3lares para cada 1 ms de redu\u00e7\u00e3o de lat\u00eancia!<\/p>\n<p>De acordo com <noindex><a rel=\"nofollow\" href=\"https:\/\/hpbn.co\/primer-on-web-performance\/\">pesquisa<\/a><\/noindex>, a velocidade da conex\u00e3o acima de 5 Mbit\/s deixa de impactar diretamente a velocidade de carregamento de um site t\u00edpico. No entanto, existe uma rela\u00e7\u00e3o linear entre a lat\u00eancia da conex\u00e3o e a velocidade de carregamento da p\u00e1gina:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/340ca1f2c5bdd6ca95a5caf02f67e3fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo entanto, a Netflix n\u00e3o \u00e9 um produto t\u00edpico. O impacto da lat\u00eancia e da velocidade no usu\u00e1rio \u00e9 uma \u00e1rea ativa de an\u00e1lise e desenvolvimento. Existem carregamentos de aplicativos e sele\u00e7\u00e3o de conte\u00fado que dependem da lat\u00eancia, mas o carregamento de elementos est\u00e1ticos e streaming tamb\u00e9m depende da velocidade da conex\u00e3o. A an\u00e1lise e otimiza\u00e7\u00e3o dos fatores-chave que afetam a qualidade do servi\u00e7o para o usu\u00e1rio \u00e9 uma \u00e1rea ativa de desenvolvimento de v\u00e1rias equipes na Netflix. Uma das tarefas \u00e9 reduzir a lat\u00eancia das solicita\u00e7\u00f5es entre os dispositivos da Netflix e a infraestrutura em nuvem.<\/p>\n<p>Neste relat\u00f3rio, vamos nos concentrar na redu\u00e7\u00e3o da lat\u00eancia, usando a infraestrutura da Netflix como exemplo. Vamos abordar, sob um ponto de vista pr\u00e1tico, como lidar com os processos de design, desenvolvimento e opera\u00e7\u00e3o de sistemas complexos e distribuir nosso tempo em inova\u00e7\u00f5es e resultados, e n\u00e3o em diagn\u00f3sticos de problemas operacionais e falhas.<\/p>\n<h2>Dentro da Netflix<\/h2>\n<p>\nMilhares de dispositivos diferentes suportam os aplicativos da Netflix. Quatro equipes diferentes est\u00e3o envolvidas em seu desenvolvimento, criando vers\u00f5es separadas do cliente para Android, iOS, TV e navegadores da web. E n\u00f3s investimos muito tempo e esfor\u00e7o para melhorar e personalizar a interface do usu\u00e1rio. Para isso, realizamos centenas de testes A\/B em paralelo.<\/p>\n<p>A personaliza\u00e7\u00e3o \u00e9 suportada por cem microsservi\u00e7os na nuvem AWS, fornecendo dados personalizados para o usu\u00e1rio, gerenciamento de solicita\u00e7\u00f5es, telemetria, Big Data e codifica\u00e7\u00e3o. A visualiza\u00e7\u00e3o do tr\u00e1fego aparece assim:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/n7Te9WIz1ho?t=364\">Link para o v\u00eddeo com a demonstra\u00e7\u00e3o (6:04-6:23)<\/a><\/noindex><\/p>\n<p>\u00c0 esquerda est\u00e1 o ponto de entrada, e ent\u00e3o o tr\u00e1fego \u00e9 distribu\u00eddo entre v\u00e1rias centenas de microsservi\u00e7os, mantidos por diferentes equipes de backend.<\/p>\n<p>Mais um componente importante da nossa infraestrutura \u00e9 o Open Connect CDN, que entrega conte\u00fados est\u00e1ticos ao usu\u00e1rio final \u2014 v\u00eddeos, imagens, c\u00f3digos para clientes, etc. O CDN est\u00e1 localizado em servidores personalizados (OCA \u2014 Open Connect Appliance). Dentro deles, existem arrays de discos SSD e HDD, gerenciados por um FreeBSD otimizado, com NGINX e um conjunto de servi\u00e7os. Projetamos e otimizamos os componentes de hardware e software de forma que esse servidor CDN possa enviar o m\u00e1ximo de dados poss\u00edvel para os usu\u00e1rios. <\/p>\n<p>A \"parede\" desses servidores no ponto de troca de tr\u00e1fego de internet (Internet eXchange \u2014 IX) \u00e9 assim:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/8155601c344acb1eb05b925193af8f9a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO Internet Exchange oferece a possibilidade para provedores de internet e fornecedores de conte\u00fado se \"conectarem\" entre si para uma troca de dados mais direta na internet. Em todo o mundo, existem cerca de 70-80 pontos de Internet Exchange, onde nossos servidores est\u00e3o instalados, e realizamos sua instala\u00e7\u00e3o e manuten\u00e7\u00e3o de forma independente.<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/77a2465314e47c0b2c90dbf7a2fb5e6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAl\u00e9m disso, tamb\u00e9m fornecemos servidores diretamente para provedores de internet, que os instalam em suas redes, melhorando a localiza\u00e7\u00e3o do tr\u00e1fego da Netflix e a qualidade do streaming para os usu\u00e1rios:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/63e077d2649bfafea5c7af43a0faaf85.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO conjunto de servi\u00e7os da AWS \u00e9 respons\u00e1vel pela gest\u00e3o das solicita\u00e7\u00f5es de v\u00eddeo dos clientes aos servidores CDN, bem como pela configura\u00e7\u00e3o dos pr\u00f3prios servidores \u2014 atualiza\u00e7\u00e3o de conte\u00fados, c\u00f3digos de programa\u00e7\u00e3o, configura\u00e7\u00f5es, etc. Para isso, tamb\u00e9m constru\u00edmos uma rede backbone, que conecta os servidores nos pontos de Internet Exchange \u00e0 AWS. A rede backbone \u00e9 uma rede global de cabos de fibra \u00f3ptica e roteadores, que podemos projetar e configurar de acordo com nossas necessidades.<\/p>\n<p>De acordo com <noindex><a rel=\"nofollow\" href=\"https:\/\/www.sandvine.com\/hubfs\/Sandvine_Redesign_2019\/Downloads\/Internet%20Phenomena\/Internet%20Phenomena%20Report%20Q32019%2020190910.pdf\">estimativas da Sandvine<\/a><\/noindex>, nossa infraestrutura CDN entrega em hor\u00e1rios de pico cerca de \u215b do tr\u00e1fego de internet mundial e \u2153 do tr\u00e1fego na Am\u00e9rica do Norte, onde a Netflix existe h\u00e1 mais tempo. N\u00fameros impressionantes, mas para mim, uma das realiza\u00e7\u00f5es mais surpreendentes \u00e9 que todo o sistema CDN \u00e9 desenvolvido e mantido por uma equipe de menos de 150 pessoas.<\/p>\n<p>Inicialmente, a infraestrutura CDN foi projetada para entrega de dados de v\u00eddeo. No entanto, com o tempo, percebemos que poder\u00edamos us\u00e1-la tamb\u00e9m para otimizar solicita\u00e7\u00f5es din\u00e2micas dos clientes na nuvem AWS.<\/p>\n<h2>Sobre a acelera\u00e7\u00e3o da internet<\/h2>\n<p>\nHoje, a Netflix possui 3 regi\u00f5es da AWS, e a lat\u00eancia das requisi\u00e7\u00f5es na nuvem depender\u00e1 da dist\u00e2ncia do cliente at\u00e9 a regi\u00e3o mais pr\u00f3xima. Temos muitos servidores CDN que s\u00e3o usados para a entrega de conte\u00fado est\u00e1tico. Existe uma forma de usar essa infraestrutura para acelerar as requisi\u00e7\u00f5es din\u00e2micas? Infelizmente, n\u00e3o \u00e9 poss\u00edvel armazenar em cache essas requisi\u00e7\u00f5es \u2014 as APIs s\u00e3o personalizadas e cada resultado \u00e9 \u00fanico.<\/p>\n<p>Vamos criar um proxy no servidor CDN e come\u00e7ar a direcionar o tr\u00e1fego por ele. Isso ser\u00e1 mais r\u00e1pido?<\/p>\n<h2>Teoria<\/h2>\n<p>\nVamos recordar como funcionam os protocolos de rede. Hoje, a maior parte do tr\u00e1fego na internet utiliza HTTPS, que depende dos protocolos de n\u00edvel inferior TCP e TLS. Para que o cliente se conecte ao servidor, ele realiza um handshake, e para estabelecer uma conex\u00e3o segura, o cliente precisa trocar mensagens com o servidor tr\u00eas vezes, e ainda pelo menos uma vez para transmitir dados. Com uma lat\u00eancia de um round-trip (RTT) de 100 ms, precisaremos de 400 ms para receber o primeiro bit de dados:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/ab12024f5a9940ca470f27821ca3c631.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe os certificados estiverem localizados no servidor CDN, podemos reduzir significativamente o tempo de 'handshake' entre o cliente e o servidor, se o CDN estiver mais pr\u00f3ximo. Suponhamos que a lat\u00eancia at\u00e9 o servidor CDN seja de 30 ms. Ent\u00e3o, para receber o primeiro bit, j\u00e1 levar\u00e1 220 ms:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/d63134bb51592aaa6a5e0c86f1a070e0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMas as vantagens n\u00e3o param por aqui. Ap\u00f3s a conex\u00e3o ser estabelecida, o TCP aumenta a congestion window (a quantidade de informa\u00e7\u00e3o que pode ser transmitida por essa conex\u00e3o simultaneamente). Se um pacote de dados \u00e9 perdido, as implementa\u00e7\u00f5es cl\u00e1ssicas do protocolo TCP (como o TCP New Reno) reduzem a 'janela' aberta pela metade. O aumento da congestion window e a velocidade de sua recupera\u00e7\u00e3o ap\u00f3s uma perda novamente dependem da lat\u00eancia (RTT) at\u00e9 o servidor. Se essa conex\u00e3o vai apenas at\u00e9 o servidor CDN, essa recupera\u00e7\u00e3o ser\u00e1 mais r\u00e1pida. Al\u00e9m disso, a perda de pacotes \u00e9 um fen\u00f4meno comum, especialmente em redes sem fio.<\/p>\n<p>A largura de banda da internet pode diminuir, especialmente durante os hor\u00e1rios de pico devido ao tr\u00e1fego dos usu\u00e1rios, o que pode causar \"congestionamentos\". Nesse sentido, n\u00e3o h\u00e1 como priorizar algumas solicita\u00e7\u00f5es em rela\u00e7\u00e3o a outras na internet. Por exemplo, priorizar pequenas solicita\u00e7\u00f5es que s\u00e3o sens\u00edveis \u00e0 lat\u00eancia em rela\u00e7\u00e3o a grandes fluxos de dados que sobrecarregam a rede. No entanto, no nosso caso, ter uma rede backbone pr\u00f3pria permite fazer isso em parte do caminho da solicita\u00e7\u00e3o \u2014 entre o CDN e a nuvem, e podemos configur\u00e1-la totalmente. \u00c9 poss\u00edvel fazer com que pacotes pequenos e sens\u00edveis \u00e0 lat\u00eancia sejam priorizados, enquanto grandes fluxos de dados sejam processados um pouco mais tarde. Quanto mais pr\u00f3ximo o CDN estiver do cliente, maior ser\u00e1 a efici\u00eancia.<\/p>\n<p>Outra influ\u00eancia sobre a lat\u00eancia vem dos protocolos de n\u00edvel de aplica\u00e7\u00e3o (Camada 7 do OSI). Novos protocolos, como HTTP\/2, permitem otimizar o desempenho de solicita\u00e7\u00f5es paralelas. No entanto, temos clientes da Netflix que possuem dispositivos antigos que n\u00e3o suportam novos protocolos. Nem todos os clientes podem ser atualizados ou configurados de maneira ideal. Entretanto, entre o proxy do CDN e a nuvem, h\u00e1 controle total e a possibilidade de usar novos protocolos e configura\u00e7\u00f5es otimizadas. A parte ineficiente com os protocolos antigos funcionar\u00e1 apenas entre o cliente e o servidor do CDN. Al\u00e9m disso, podemos realizar multiplexa\u00e7\u00e3o de solicita\u00e7\u00f5es em uma conex\u00e3o j\u00e1 estabelecida entre o CDN e a nuvem, melhorando a utiliza\u00e7\u00e3o da conex\u00e3o no n\u00edvel TCP:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/a05b49680734670dcfce9111f3ba1919.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Medindo<\/h2>\n<p>\nApesar de a teoria prometer melhorias, n\u00e3o nos apressamos a colocar o sistema em produ\u00e7\u00e3o imediatamente. Em vez disso, devemos primeiro provar que a ideia funcionar\u00e1 na pr\u00e1tica. Para isso, precisamos responder a algumas perguntas:<\/p>\n<ul>\n<li><b>Velocidade<\/b>: o proxy ser\u00e1 mais r\u00e1pido?<\/li>\n<li><b>Confiabilidade<\/b>: ele falhar\u00e1 com mais frequ\u00eancia?<\/li>\n<li><b>Complexidade<\/b>: como integrar com aplica\u00e7\u00f5es?<\/li>\n<li><b>Custo<\/b>: quanto custa implementar uma infraestrutura adicional?<\/li>\n<\/ul>\n<p>\nVamos analisar detalhadamente nossa abordagem para avaliar o primeiro ponto. Os outros s\u00e3o abordados de forma semelhante.<\/p>\n<p>Para analisar a velocidade das solicita\u00e7\u00f5es, queremos obter dados para todos os usu\u00e1rios, n\u00e3o gastar muito tempo no desenvolvimento e n\u00e3o quebrar a produ\u00e7\u00e3o. Para isso, existem v\u00e1rias abordagens:<\/p>\n<ol>\n<li>RUM, ou medi\u00e7\u00e3o passiva de solicita\u00e7\u00f5es. Medimos o tempo de execu\u00e7\u00e3o das solicita\u00e7\u00f5es atuais dos usu\u00e1rios e garantimos uma cobertura total dos usu\u00e1rios. A desvantagem \u00e9 que o sinal n\u00e3o \u00e9 muito est\u00e1vel devido a v\u00e1rios fatores, como o tamanho vari\u00e1vel das solicita\u00e7\u00f5es, o tempo de processamento no servidor e no cliente. Al\u00e9m disso, n\u00e3o \u00e9 poss\u00edvel testar uma nova configura\u00e7\u00e3o sem efeitos no ambiente de produ\u00e7\u00e3o.<\/li>\n<li>Testes de laborat\u00f3rio. Servidores e infraestrutura especiais que simulam clientes. Com eles, realizamos os testes necess\u00e1rios. Assim, obtemos controle total sobre os resultados das medi\u00e7\u00f5es e um sinal claro. No entanto, n\u00e3o h\u00e1 cobertura total de dispositivos e localidades de usu\u00e1rios (especialmente com um servi\u00e7o global e suporte a milhares de modelos de dispositivos).<\/li>\n<\/ol>\n<p>\nComo podemos combinar as vantagens de ambos os m\u00e9todos?<\/p>\n<p>Nossa equipe encontrou uma solu\u00e7\u00e3o. Escrevemos um pequeno trecho de c\u00f3digo \u2014 um probe \u2014 que incorporamos ao nosso aplicativo. Os probes nos permitem realizar testes de rede totalmente controlados a partir de nossos dispositivos. Funciona da seguinte maneira: <\/p>\n<ol>\n<li>Logo ap\u00f3s o carregamento do aplicativo e a conclus\u00e3o da atividade inicial, iniciamos nossos probes. <\/li>\n<li>O cliente faz uma solicita\u00e7\u00e3o ao servidor e recebe uma \"receita\" de teste. A receita consiste em uma lista de URLs para as quais devem ser feitas solicita\u00e7\u00f5es HTTP(s). Al\u00e9m disso, a receita configura os par\u00e2metros das solicita\u00e7\u00f5es: delays entre as solicita\u00e7\u00f5es, volume de dados solicitados, cabe\u00e7alhos HTTP(s), etc. Dessa forma, podemos testar v\u00e1rios receitas diferentes em paralelo \u2014 quando uma configura\u00e7\u00e3o \u00e9 solicitada, \u00e9 determinado aleatoriamente qual receita fornecer. <\/li>\n<li>O tempo de in\u00edcio do probe \u00e9 escolhido de forma a n\u00e3o entrar em conflito com o uso ativo de recursos de rede pelo cliente. Na verdade, escolhe-se um momento em que o cliente est\u00e1 inativo.<\/li>\n<li>Ap\u00f3s receber a receita, o cliente faz solicita\u00e7\u00f5es para cada um dos URLs, em paralelo. A solicita\u00e7\u00e3o para cada endere\u00e7o pode ser repetida \u2014 os chamados \"pulsos\". No primeiro pulso, medimos quanto tempo foi necess\u00e1rio para estabelecer a conex\u00e3o e baixar os dados. No segundo pulso, medimos o tempo de carregamento dos dados por meio da conex\u00e3o j\u00e1 estabelecida. Antes do terceiro, podemos introduzir um delay e medir a velocidade de reestabelecimento da conex\u00e3o, entre outros.\n<p>Durante o teste, medimos todos os par\u00e2metros que o dispositivo pode obter:<\/p>\n<ul>\n<li>o tempo de consulta DNS;<\/li>\n<li>o tempo para estabelecer conex\u00e3o TCP;<\/li>\n<li>o tempo para estabelecer conex\u00e3o TLS;<\/li>\n<li>o tempo para receber o primeiro byte de dados;<\/li>\n<li>o tempo total de carregamento;<\/li>\n<li>o c\u00f3digo de status do resultado.<\/li>\n<\/ul>\n<\/li>\n<li> Ap\u00f3s a conclus\u00e3o de todos os pulsos, a amostra carrega os resultados de todas as medi\u00e7\u00f5es para an\u00e1lise.<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/fff11d487b7c7725707cdeeca0734296.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOs principais pontos s\u00e3o a m\u00ednima depend\u00eancia da l\u00f3gica no cliente, o processamento de dados no servidor e a medi\u00e7\u00e3o de requisi\u00e7\u00f5es paralelas. Assim, conseguimos isolar e testar a influ\u00eancia de diversos fatores que afetam o desempenho das requisi\u00e7\u00f5es, variando-os dentro de uma \u00fanica receita e obtendo resultados de clientes reais.<\/p>\n<p>Essa infraestrutura se mostrou \u00fatil n\u00e3o apenas para a an\u00e1lise de desempenho das requisi\u00e7\u00f5es. Neste momento, temos 14 receitas ativas, mais de 6000 amostras por segundo, recebendo dados de todos os cantos do mundo e com cobertura completa de dispositivos. Se a Netflix adquirisse um servi\u00e7o semelhante de empresas terceiras, custaria milh\u00f5es de d\u00f3lares por ano, com uma cobertura muito inferior.<\/p>\n<h2>Verificamos a teoria na pr\u00e1tica: prot\u00f3tipo<\/h2>\n<p>\nCom tal sistema, conseguimos avaliar a efic\u00e1cia do proxy CDN na lat\u00eancia das requisi\u00e7\u00f5es. Agora precisamos:<\/p>\n<ul>\n<li>criar um prot\u00f3tipo de proxy;<\/li>\n<li>hospedar o prot\u00f3tipo na CDN;<\/li>\n<li>determinar como direcionar clientes para o proxy em um servidor CDN espec\u00edfico;<\/li>\n<li>comparar o desempenho com requisi\u00e7\u00f5es no AWS sem proxy.<\/li>\n<\/ul>\n<p>\nA tarefa \u00e9 avaliar a efic\u00e1cia da solu\u00e7\u00e3o proposta o mais r\u00e1pido poss\u00edvel. Para implementar o prot\u00f3tipo, escolhemos o Go, devido \u00e0 disponibilidade de boas bibliotecas de rede. Em cada servidor CDN, instalamos o prot\u00f3tipo de proxy como um bin\u00e1rio est\u00e1tico, a fim de minimizar depend\u00eancias e simplificar a integra\u00e7\u00e3o. Na implementa\u00e7\u00e3o inicial, utilizamos ao m\u00e1ximo os componentes padr\u00e3o e pequenas modifica\u00e7\u00f5es para o HTTP\/2 connection pooling e request multiplexing.<\/p>\n<p>Para balancear entre as regi\u00f5es da AWS, usamos um banco de dados DNS geogr\u00e1fico, o mesmo utilizado para balanceamento de clientes. Para escolher o servidor CDN para o cliente, utilizamos TCP Anycast para servidores em Internet Exchange (IX). Neste caso, usamos um \u00fanico endere\u00e7o IP para todos os servidores CDN, e o cliente ser\u00e1 direcionado ao servidor CDN com o menor n\u00famero de saltos IP. Nos servidores CDN instalados nos provedores de internet (ISP), n\u00e3o temos controle sobre o roteador para configurar TCP Anycast, portanto empregamos <noindex><a rel=\"nofollow\" href=\"https:\/\/www.infoq.com\/presentations\/netflix-streaming-arch\/\">a mesma l\u00f3gica<\/a><\/noindex>, segundo a qual os clientes s\u00e3o direcionados para os provedores de internet para streaming de v\u00eddeo.<\/p>\n<p>Assim, temos tr\u00eas tipos de caminhos para a solicita\u00e7\u00e3o: para a nuvem atrav\u00e9s da internet aberta, atrav\u00e9s do servidor CDN no IX ou atrav\u00e9s do servidor CDN localizado no provedor de internet. Nosso objetivo \u00e9 entender qual caminho \u00e9 melhor e qual \u00e9 o benef\u00edcio do proxy, em compara\u00e7\u00e3o com a forma como as solicita\u00e7\u00f5es s\u00e3o direcionadas para a produ\u00e7\u00e3o. Para isso, usamos um sistema de teste da seguinte maneira:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/51b64d5be0aaf0f141484ee0fd373396.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCada um dos caminhos torna-se um alvo separado, e analisamos o tempo que obtivemos. Para a an\u00e1lise, agrupamos os resultados do proxy em um \u00fanico grupo (escolhemos o melhor tempo entre o proxy do IX e o do ISP) e comparamos com o tempo das solicita\u00e7\u00f5es para a nuvem sem proxy:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/ec01690f6a312e61649282b0e6208778.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nComo pode ser visto, os resultados foram amb\u00edguos \u2014 na maioria dos casos, o proxy proporciona um bom aumento de velocidade, mas tamb\u00e9m h\u00e1 um n\u00famero suficiente de clientes para os quais a situa\u00e7\u00e3o piorar\u00e1 significativamente. <\/p>\n<p>No final, fizemos algumas coisas importantes:<\/p>\n<ol>\n<li>Avaliaram a performance esperada das solicita\u00e7\u00f5es dos clientes para a nuvem atrav\u00e9s do proxy CDN.<\/li>\n<li>Obtivemos dados de clientes reais, de todos os tipos de dispositivos.<\/li>\n<li>Entendemos que a teoria n\u00e3o se confirmou 100% e a proposta inicial com o proxy CDN n\u00e3o funcionar\u00e1 para n\u00f3s.<\/li>\n<li>N\u00e3o arriscamos \u2014 n\u00e3o mudamos as configura\u00e7\u00f5es de produ\u00e7\u00e3o para os clientes.<\/li>\n<li>Nada foi quebrado. <\/li>\n<\/ol>\n<p><\/p>\n<h2>Prot\u00f3tipo 2.0<\/h2>\n<p>\nAssim, voltamos \u00e0 prancheta e repetimos o processo novamente.<\/p>\n<p>A ideia \u00e9 \u2014 em vez de 100% de proxy, para cada cliente determinarmos o caminho mais r\u00e1pido e direcionarmos as solicita\u00e7\u00f5es para l\u00e1 \u2014 ou seja, faremos o que chamamos de client steering.<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/780817f48a4d2b292d5545e0aa1ccc50.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nComo implementar isso? N\u00e3o podemos usar a l\u00f3gica do lado do servidor, pois o objetivo \u00e9 conectar-se a esse servidor. Precisamos encontrar uma maneira de fazer isso no lado do cliente. E, idealmente, fazer isso com a m\u00ednima l\u00f3gica complexa, para evitar problemas de integra\u00e7\u00e3o com uma ampla variedade de plataformas do cliente. <\/p>\n<p>A resposta \u00e9 usar DNS. No nosso caso, temos nossa pr\u00f3pria infraestrutura DNS, e podemos configurar a zona de dom\u00ednio para a qual nossos servidores ser\u00e3o autoritativos. Funciona assim:<\/p>\n<ol>\n<li>O cliente faz uma solicita\u00e7\u00e3o ao servidor DNS usando o host, por exemplo, api.netflix.com.<\/li>\n<li>A solicita\u00e7\u00e3o chega ao nosso servidor DNS.<\/li>\n<li>O servidor DNS sabe qual \u00e9 o caminho mais r\u00e1pido para esse cliente e fornece o endere\u00e7o IP correspondente. <\/li>\n<\/ol>\n<p>\nA solu\u00e7\u00e3o apresenta uma complexidade adicional: provedores DNS autoritativos n\u00e3o veem o endere\u00e7o IP do cliente e podem considerar apenas o endere\u00e7o IP do resolvedor recursivo utilizado pelo cliente. <\/p>\n<p>No final, nosso resolvedor autoritativo deve tomar decis\u00f5es n\u00e3o para um \u00fanico cliente, mas para um grupo de clientes com base no resolvedor recursivo. <\/p>\n<p>Para resolver isso, usamos as mesmas amostras, agregamos os resultados das medi\u00e7\u00f5es dos clientes para cada resolvedor recursivo e decidimos para onde direcionar esse grupo - proxy atrav\u00e9s do IX usando TCP Anycast, atrav\u00e9s de proxy de ISP, ou diretamente para a nuvem.<\/p>\n<p>Assim, obtemos o seguinte sistema:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/ad23219938d1cb7b6eef498671c3e151.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO modelo obtido de direcionamento DNS permite direcionar clientes com base em observa\u00e7\u00f5es hist\u00f3ricas sobre a velocidade das conex\u00f5es dos clientes at\u00e9 a nuvem. <\/p>\n<p>Novamente, a quest\u00e3o \u00e9: qu\u00e3o eficaz ser\u00e1 esse m\u00e9todo? Para responder, utilizamos novamente nosso sistema de amostras. Portanto, configuramos uma configura\u00e7\u00e3o recente, onde um dos destinos segue a dire\u00e7\u00e3o do direcionamento DNS, enquanto o outro vai diretamente para a nuvem (produ\u00e7\u00e3o atual).<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/ceb2ded9367ebd0aa0ede46191a89a88.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPor fim, comparamos os resultados e obtivemos uma avalia\u00e7\u00e3o da efic\u00e1cia:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/ca0db88461d5f2cb0f3f7c07eae14f10.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nComo resultado, aprendemos algumas coisas importantes:<\/p>\n<ol>\n<li>Avaliaram o desempenho esperado das solicita\u00e7\u00f5es dos clientes na nuvem usando Direcionamento DNS.<\/li>\n<li>Obtivemos dados de clientes reais, de todos os tipos de dispositivos.<\/li>\n<li>Provamos a efic\u00e1cia da ideia proposta.<\/li>\n<li>N\u00e3o arriscamos \u2014 n\u00e3o mudamos as configura\u00e7\u00f5es de produ\u00e7\u00e3o para os clientes.<\/li>\n<li>Nada foi quebrado.<\/li>\n<\/ol>\n<p><\/p>\n<h2>Agora, a parte dif\u00edcil \u2013 vamos colocar em produ\u00e7\u00e3o.<\/h2>\n<p>\nO mais f\u00e1cil j\u00e1 ficou para tr\u00e1s \u2014 temos um prot\u00f3tipo funcional. Agora a parte dif\u00edcil \u00e9 implementar uma solu\u00e7\u00e3o para todo o tr\u00e1fego da Netflix, implant\u00e1-la para 150 milh\u00f5es de usu\u00e1rios, milhares de dispositivos, centenas de microsservi\u00e7os e um produto e infraestrutura que mudam constantemente. Os servidores da Netflix recebem milh\u00f5es de requisi\u00e7\u00f5es por segundo, e \u00e9 f\u00e1cil quebrar o servi\u00e7o com uma a\u00e7\u00e3o descuidada. Ao mesmo tempo, queremos direcionar dinamicamente o tr\u00e1fego por meio de milhares de servidores CDN, na internet, onde algo est\u00e1 sempre mudando e quebrando, frequentemente no pior momento poss\u00edvel. <\/p>\n<p>E, com tudo isso, na equipe h\u00e1 3 engenheiros respons\u00e1veis pelo desenvolvimento, implanta\u00e7\u00e3o e suporte total do sistema.<\/p>\n<p>Por isso, continuaremos falando sobre um sono tranquilo e saud\u00e1vel.<\/p>\n<p>Como continuar o desenvolvimento sem gastar todo o tempo em suporte? A base da nossa abordagem s\u00e3o 3 princ\u00edpios:<\/p>\n<ol>\n<li>Reduzimos o potencial alcance de falhas (blast radius). <\/li>\n<li>Estamos preparados para surpresas \u2014 esperando que algo quebre, apesar dos testes e da experi\u00eancia pessoal.<\/li>\n<li>Degrada\u00e7\u00e3o gradual (graceful degradation) \u2014 se algo n\u00e3o funciona corretamente, deve ser corrigido automaticamente, mesmo que n\u00e3o da maneira mais eficiente.<\/li>\n<\/ol>\n<p>\nDescobrimos que, no nosso caso, com essa abordagem ao problema, \u00e9 poss\u00edvel encontrar uma solu\u00e7\u00e3o simples e eficaz, simplificando significativamente o suporte ao sistema. Percebemos que podemos adicionar um pequeno trecho de c\u00f3digo ao cliente para monitorar erros de requisi\u00e7\u00f5es de rede, causados por problemas de conex\u00e3o. Com erros de rede, fazemos fallback diretamente para a nuvem. Essa solu\u00e7\u00e3o n\u00e3o exige esfor\u00e7os significativos das equipes de clientes, mas reduz consideravelmente o risco de falhas inesperadas e surpresas para n\u00f3s.<\/p>\n<p>Certamente, apesar do fallback, seguimos uma disciplina rigorosa durante o desenvolvimento:<\/p>\n<ol>\n<li>Teste em amostras.<\/li>\n<li>Teste A\/B ou Canaries.<\/li>\n<li>Lan\u00e7amento progressivo (progressive rollout).<\/li>\n<\/ol>\n<p>\nPara as amostras, a abordagem foi descrita \u2014 as mudan\u00e7as s\u00e3o inicialmente testadas usando uma receita configurada.<\/p>\n<p>Para o teste can\u00e1rio, precisamos obter pares de servidores compar\u00e1veis, onde possamos comparar como o sistema funciona antes e depois das mudan\u00e7as. Para isso, a partir de nossos numerosos sites CDN, fazemos uma amostra de pares de servidores que recebem tr\u00e1fego compar\u00e1vel:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/eef504f5c81aa985b78339fd5f913d14.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEm seguida, colocamos a montagem com as altera\u00e7\u00f5es nos servidores Canary. Para avaliar os resultados, executamos um sistema que compara cerca de 100-150 m\u00e9tricas com um grupo de servidores de Controle:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/898edb0a5bd493d6ef228cd116c1a939.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe o teste Canary for bem-sucedido, fazemos o lan\u00e7amento gradualmente, em ondas. Em cada site, n\u00e3o atualizamos os servidores ao mesmo tempo \u2014 a perda de um site inteiro em caso de problemas tem um impacto mais significativo no servi\u00e7o para os usu\u00e1rios do que a perda do mesmo n\u00famero de servidores em locais diferentes.<\/p>\n<p>No geral, a efic\u00e1cia e a seguran\u00e7a dessa abordagem dependem da quantidade e da qualidade das m\u00e9tricas coletadas. Para o nosso sistema de acelera\u00e7\u00e3o de requisi\u00e7\u00f5es, coletamos m\u00e9tricas de todos os componentes poss\u00edveis: <\/p>\n<ul>\n<li>dos clientes \u2014 n\u00famero de sess\u00f5es e requisi\u00e7\u00f5es, taxas de fallback; <\/li>\n<li>proxy \u2014 estat\u00edsticas sobre o n\u00famero e o tempo das requisi\u00e7\u00f5es;<\/li>\n<li>DNS \u2014 n\u00famero e resultados das requisi\u00e7\u00f5es;<\/li>\n<li>cloud edge \u2014 n\u00famero e tempo de processamento das requisi\u00e7\u00f5es na nuvem.<\/li>\n<\/ul>\n<p>\nTudo isso \u00e9 coletado em um \u00fanico pipeline e, dependendo das necessidades, decidimos quais m\u00e9tricas enviar para a an\u00e1lise em tempo real e quais enviar para Elasticsearch ou Big Data para diagn\u00f3sticos mais detalhados.<\/p>\n<h2>Monitorando<\/h2>\n<p>\n<img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/ff8b00b1239a20f85e96ce23c2d7c2d0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo nosso caso, fazemos altera\u00e7\u00f5es no caminho cr\u00edtico das requisi\u00e7\u00f5es entre o cliente e o servidor. Nesse sentido, o n\u00famero de componentes diferentes no cliente, no servidor e no caminho pela internet \u00e9 enorme. As mudan\u00e7as no cliente e no servidor ocorrem constantemente \u2014 durante o trabalho de dezenas de equipes e mudan\u00e7as naturais no ecossistema. Estamos no meio \u2014 ao diagnosticar problemas, \u00e9 muito prov\u00e1vel que estejamos envolvidos. Portanto, precisamos entender claramente como determinar, coletar e analisar m\u00e9tricas para uma r\u00e1pida localiza\u00e7\u00e3o de problemas. <\/p>\n<p>Idealmente, ter\u00edamos acesso completo a todos os tipos de m\u00e9tricas e filtros em tempo real. Por\u00e9m, h\u00e1 muitas m\u00e9tricas, portanto surge a quest\u00e3o de custo. No nosso caso, separamos m\u00e9tricas e ferramentas de desenvolvimento da seguinte forma:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/0b4a15776f3b44331652adc14ea87390.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPara a detec\u00e7\u00e3o e triagem de problemas, usamos nosso pr\u00f3prio sistema de tempo real de c\u00f3digo aberto <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Netflix\/atlas\">Atlas<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/netflixtechblog.com\/lumen-custom-self-service-dashboarding-for-netflix-8c56b541548c\">Lumen<\/a><\/noindex> \u2014 para visualiza\u00e7\u00e3o. Ele armazena m\u00e9tricas agregadas na mem\u00f3ria, \u00e9 confi\u00e1vel e se integra ao sistema de alertas. Para localiza\u00e7\u00e3o e diagn\u00f3stico, temos acesso aos logs atrav\u00e9s do Elasticsearch e Kibana. Para an\u00e1lise estat\u00edstica e modelagem, utilizamos big data e visualiza\u00e7\u00e3o no Tableau.<\/p>\n<p>Parece que \u00e9 muito dif\u00edcil trabalhar com essa abordagem. No entanto, com uma organiza\u00e7\u00e3o hier\u00e1rquica das m\u00e9tricas e ferramentas, podemos rapidamente analisar o problema, identificar o tipo de problema e, em seguida, nos aprofundar nas m\u00e9tricas detalhadas. Em geral, levamos cerca de 1 a 2 minutos para identificar a fonte da falha. Depois disso, j\u00e1 trabalhamos com uma equipe espec\u00edfica na diagnose \u2014 de dezenas de minutos a v\u00e1rias horas.<\/p>\n<p>Mesmo que a diagnose seja feita rapidamente, n\u00e3o queremos que isso ocorra com frequ\u00eancia. Idealmente, receberemos um alerta cr\u00edtico apenas quando houver um impacto significativo no servi\u00e7o. Para o nosso sistema de acelera\u00e7\u00e3o de requisi\u00e7\u00f5es, temos apenas 2 alertas que nos notificar\u00e3o:<\/p>\n<ul>\n<li>percentual de Client Fallback \u2014 uma avalia\u00e7\u00e3o do comportamento dos clientes;<\/li>\n<li>percentual de Probe errors \u2014 dados sobre a estabilidade dos componentes da rede.<\/li>\n<\/ul>\n<p>\nEsses alertas cr\u00edticos monitoram se o sistema est\u00e1 funcionando para a maioria dos usu\u00e1rios. Observamos quantos clientes utilizaram o fallback caso n\u00e3o tenham conseguido a acelera\u00e7\u00e3o das requisi\u00e7\u00f5es. Temos, em m\u00e9dia, menos de 1 alerta cr\u00edtico por semana, embora ocorram muitas mudan\u00e7as no sistema. Por que isso \u00e9 suficiente para n\u00f3s?<\/p>\n<ol>\n<li>H\u00e1 um client fallback no caso de nossa proxy n\u00e3o funcionar.<\/li>\n<li>H\u00e1 um sistema de steering autom\u00e1tico que reage a problemas.<\/li>\n<\/ol>\n<p>\nSobre o \u00faltimo, vamos nos aprofundar. Nosso sistema de probes e o sistema de determina\u00e7\u00e3o autom\u00e1tica do melhor caminho para as requisi\u00e7\u00f5es do cliente para a nuvem permitem lidar automaticamente com alguns problemas. <\/p>\n<p>Voltando \u00e0 nossa configura\u00e7\u00e3o de probes e \u00e0s 3 categorias de caminhos. Al\u00e9m do tempo de carregamento, podemos observar o fato da entrega em si. Se n\u00e3o conseguirmos carregar os dados, ao observar os resultados dos diferentes caminhos, podemos determinar onde e o que quebrou, e se podemos corrigir isso automaticamente, alterando o caminho da requisi\u00e7\u00e3o.<\/p>\n<p>Exemplos:<\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/7d935da82aaca53af87f05fbdf215c4c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/f74ef9d3de953099921a68fbc65cb187.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/3c77cbd47813d3320efbf339a0690c53.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsse processo pode ser automatizado. Integr\u00e1-lo ao sistema de steering. E ensin\u00e1-lo a reagir a problemas de desempenho e confiabilidade. Se algo come\u00e7a a falhar \u2014 reagir, se houver uma op\u00e7\u00e3o melhor. Nesse caso, a rea\u00e7\u00e3o imediata n\u00e3o \u00e9 cr\u00edtica, gra\u00e7as ao fallback dos clientes.<\/p>\n<p>Assim, os princ\u00edpios de suporte do sistema podem ser formulados da seguinte forma:<\/p>\n<ul>\n<li>reduzimos a escala das falhas;<\/li>\n<li>coletamos m\u00e9tricas;<\/li>\n<li>corrigimos automaticamente falhas, se pudermos;<\/li>\n<li>se n\u00e3o pudermos \u2014 notificamos;<\/li>\n<li>Estamos trabalhando em dashboards e um conjunto de ferramentas de triagem para uma resposta r\u00e1pida.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Li\u00e7\u00f5es aprendidas<\/h2>\n<p>\nN\u00e3o leva muito tempo para escrever um prot\u00f3tipo. No nosso caso, ele estava pronto em apenas 4 meses. Com isso, come\u00e7amos a obter novas m\u00e9tricas, e ap\u00f3s 10 meses desde o in\u00edcio do desenvolvimento, recebemos o primeiro tr\u00e1fego em produ\u00e7\u00e3o. Depois, come\u00e7ou o trabalho \u00e1rduo e muito complexo: gradualmente transformar e escalar o sistema, migrar o tr\u00e1fego principal e aprender com os erros. Al\u00e9m disso, esse processo eficiente n\u00e3o ser\u00e1 linear \u2014 apesar de todos os esfor\u00e7os, n\u00e3o \u00e9 poss\u00edvel prever tudo. \u00c9 muito mais eficaz iterar rapidamente e reagir a novos dados. <\/p>\n<p><img decoding=\"async\" alt=\"Acelerando as requisi\u00e7\u00f5es de internet e dormindo tranquilo\" src=\"\/wp-content\/uploads\/2020\/06\/c9c182a1a4fa048b1f1b2a82a4db65e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCom base em nossa experi\u00eancia, podemos aconselhar o seguinte:<\/p>\n<ol>\n<li>N\u00e3o confie na intui\u00e7\u00e3o.\n<p>Nossa intui\u00e7\u00e3o nos enganava constantemente, apesar da vasta experi\u00eancia dos membros da equipe. Por exemplo, prev\u00edamos incorretamente o aumento esperado com o uso de proxies CDN, ou o comportamento do TCP Anycast.<\/li>\n<li>Obtenha dados da produ\u00e7\u00e3o.\n<p>\u00c9 importante ter acesso o mais r\u00e1pido poss\u00edvel, mesmo que a uma pequena quantidade de dados de produ\u00e7\u00e3o. \u00c9 praticamente imposs\u00edvel obter a quantidade de casos \u00fanicos, configura\u00e7\u00f5es e defini\u00e7\u00f5es em condi\u00e7\u00f5es de laborat\u00f3rio. O acesso r\u00e1pido aos resultados permitir\u00e1 identificar mais rapidamente potenciais problemas e consider\u00e1-los na arquitetura do sistema.<\/li>\n<li>N\u00e3o siga conselhos e resultados de outros \u2014 colete seus pr\u00f3prios dados.\n<p>Siga os princ\u00edpios de coleta e an\u00e1lise de dados, mas n\u00e3o aceite cegamente os resultados e afirma\u00e7\u00f5es dos outros. Apenas voc\u00ea pode saber com precis\u00e3o o que funciona para seus usu\u00e1rios. Seus sistemas e seus clientes podem ser substancialmente diferentes de outras empresas. Felizmente, hoje em dia as ferramentas de an\u00e1lise est\u00e3o dispon\u00edveis e s\u00e3o f\u00e1ceis de usar. Os resultados que voc\u00ea obt\u00e9m podem n\u00e3o coincidir com o que afirmam Netflix, Facebook, Akamai e outras empresas. No nosso caso, o desempenho de TLS, HTTP2 ou as estat\u00edsticas de consultas DNS diferem dos resultados do Facebook, Uber, Akamai \u2014 porque temos dispositivos, clientes e fluxos de dados diferentes.<\/li>\n<li>N\u00e3o corra atr\u00e1s de tend\u00eancias populares sem necessidade e avalia\u00e7\u00e3o de efic\u00e1cia.\n<p>Comece com o simples. \u00c9 melhor criar um sistema funcional simples em pouco tempo do que gastar uma quantidade enorme de tempo desenvolvendo componentes desnecess\u00e1rios. Resolva tarefas e problemas que s\u00e3o importantes com base em suas medi\u00e7\u00f5es e resultados. <\/li>\n<li>Prepare-se para novas aplica\u00e7\u00f5es.\n<p>Assim como \u00e9 dif\u00edcil prever todos os problemas, tamb\u00e9m \u00e9 complicado antecipar os benef\u00edcios e aplica\u00e7\u00f5es. Inspire-se em startups \u2014 sua capacidade de adapta\u00e7\u00e3o \u00e0s necessidades dos clientes. No seu caso, voc\u00ea pode descobrir novos problemas e suas solu\u00e7\u00f5es. Em nosso projeto, nosso objetivo era reduzir a lat\u00eancia das solicita\u00e7\u00f5es. No entanto, durante a an\u00e1lise e discuss\u00f5es, percebemos que os servidores proxy tamb\u00e9m podem ser aplicados:<\/p>\n<ul>\n<li>para balancear o tr\u00e1fego entre regi\u00f5es da AWS e reduzir custos;<\/li>\n<li>para simular a estabilidade de uma CDN;<\/li>\n<li>para configurar o DNS;<\/li>\n<li>para configurar o TLS\/TCP.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p><\/p>\n<h2>Conclus\u00e3o<\/h2>\n<p>\nNo relat\u00f3rio, descrevi como a Netflix aborda a quest\u00e3o de acelerar as solicita\u00e7\u00f5es de internet entre clientes e a nuvem. Como coletamos dados por meio de um sistema de amostras nos clientes e utilizamos os dados hist\u00f3ricos coletados para direcionar as solicita\u00e7\u00f5es de produ\u00e7\u00e3o pelos caminhos mais r\u00e1pidos da internet. Como aplicamos princ\u00edpios de funcionamento de protocolos de rede, nossa infraestrutura de CDN, rede backbone e servidores DNS para atingir esse objetivo.<\/p>\n<p>No entanto, nossa solu\u00e7\u00e3o \u00e9 apenas um exemplo de como implementamos tal sistema na Netflix. O que funcionou para n\u00f3s. A parte pr\u00e1tica do meu relat\u00f3rio para voc\u00eas s\u00e3o os princ\u00edpios de desenvolvimento e manuten\u00e7\u00e3o que seguimos e cujo resultado \u00e9 bem-sucedido.<\/p>\n<p>Nossa solu\u00e7\u00e3o pode n\u00e3o se adequar a voc\u00ea. No entanto, a teoria e os princ\u00edpios de desenvolvimento permanecem, mesmo se voc\u00ea n\u00e3o tiver uma infraestrutura de CDN pr\u00f3pria, ou se ela for substancialmente diferente da nossa. <\/p>\n<p>A import\u00e2ncia da velocidade das solicita\u00e7\u00f5es para os neg\u00f3cios tamb\u00e9m continua. E mesmo para um servi\u00e7o simples, \u00e9 necess\u00e1rio fazer uma escolha: entre provedores \u201cna nuvem\u201d, localiza\u00e7\u00e3o dos servidores, provedores de CDN e DNS. Sua escolha influenciar\u00e1 a efic\u00e1cia das solicita\u00e7\u00f5es de internet para seus clientes. E \u00e9 importante que voc\u00ea me\u00e7a e compreenda essa influ\u00eancia.<\/p>\n<p>Comece com solu\u00e7\u00f5es simples, cuide do modo como voc\u00ea altera o produto. Aprenda no processo e melhore o sistema com base nos dados de seus clientes, de sua infraestrutura e de seu neg\u00f3cio. Pense na possibilidade de falhas inesperadas durante o projeto. Assim, voc\u00ea poder\u00e1 acelerar seu processo de desenvolvimento, melhorar a efic\u00e1cia da solu\u00e7\u00e3o, evitar sobrecargas no suporte e dormir tranquilamente.<\/p>\n<blockquote><p>Este ano <noindex><a rel=\"nofollow\" href=\"http:\/\/devoops-moscow.ru\/?utm_source=habr&amp;utm_medium=506106\">a confer\u00eancia acontecer\u00e1 de 6 a 10 de julho<\/a><\/noindex> em formato online. Ser\u00e1 poss\u00edvel fazer perguntas a um dos pais do DevOps, o pr\u00f3prio John Willis!<\/p><\/blockquote>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/jugru\/blog\/506106\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u0441\u043e\u0437\u0434\u0430\u0432\u0448\u0430\u044f \u0438 \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u044e\u0449\u0430\u044f \u044d\u0442\u043e\u0442 \u0441\u0435\u0433\u043c\u0435\u043d\u0442. Netflix \u0438\u0437\u0432\u0435\u0441\u0442\u0435\u043d \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u043e\u0431\u0448\u0438\u0440\u043d\u044b\u043c \u043a\u0430\u0442\u0430\u043b\u043e\u0433\u043e\u043c \u043a\u0438\u043d\u043e \u0438 \u0441\u0435\u0440\u0438\u0430\u043b\u043e\u0432, \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u044b\u0445 \u0441 \u043f\u043e\u0447\u0442\u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0433\u043e\u043b\u043a\u0430 \u043f\u043b\u0430\u043d\u0435\u0442\u044b \u0438 \u043b\u044e\u0431\u043e\u0433\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u0430 \u0441 \u0434\u0438\u0441\u043f\u043b\u0435\u0435\u043c, \u043d\u043e \u0438 \u043d\u0430\u0434\u0435\u0436\u043d\u043e\u0439 \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u043e\u0439 \u0438 \u0443\u043d\u0438\u043a\u0430\u043b\u044c\u043d\u043e\u0439 \u0438\u043d\u0436\u0435\u043d\u0435\u0440\u043d\u043e\u0439 \u043a\u0443\u043b\u044c\u0442\u0443\u0440\u043e\u0439. \u041d\u0430\u0433\u043b\u044f\u0434\u043d\u044b\u0439 \u043f\u0440\u0438\u043c\u0435\u0440 Netflix \u043f\u043e\u0434\u0445\u043e\u0434\u0430 \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u0438 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u0441\u043b\u043e\u0436\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043d\u0430 DevOops 2019 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u043b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84877,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84876","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0423\u0441\u043a\u043e\u0440\u044f\u0435\u043c \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438 \u0441\u043f\u0438\u043c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-11T11:43:18+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-11T11:43:18+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Aceleramos suas solicita\u00e7\u00f5es na internet e garantimos tranquilidade | ProHoster","description":"A Netflix \u00e9 l\u00edder no mercado de streaming de v\u00eddeo pela internet.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0423\u0441\u043a\u043e\u0440\u044f\u0435\u043c \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0437\u0430\u043f\u0440\u043e\u0441\u044b \u0438 \u0441\u043f\u0438\u043c \u0441\u043f\u043e\u043a\u043e\u0439\u043d\u043e | ProHoster","og:description":"Netflix \u2014 \u043b\u0438\u0434\u0435\u0440 \u0440\u044b\u043d\u043a\u0430 \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442-\u0442\u0435\u043b\u0435\u0432\u0438\u0434\u0435\u043d\u0438\u044f \u2014.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/uskoryaem-internet-zaprosy-i-spim-spokojno","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-11T11:43:18+00:00","article:modified_time":"2020-06-11T11:43:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84876","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:48:22","updated":"2022-09-27 23:34:06","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/84876","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=84876"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/84876\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/84877"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=84876"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=84876"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=84876"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}