Netflix é o líder no mercado de televisión por Internet, a empresa que creou e desenvolve activamente este segmento. Netflix é coñecida non só polo seu amplo catálogo de películas e series de televisión dispoñibles en case todos os recunchos do planeta e calquera dispositivo con pantalla, senón tamén pola súa infraestrutura fiable e a súa cultura de enxeñería única.
En DevOops 2019 presentouse un claro exemplo do enfoque de Netflix para desenvolver e soportar sistemas complexos. - Director de Desenvolvemento en Netflix. Graduado na Facultade de Matemáticas Computacionais e Matemáticas da Universidade Estatal de Nizhny Novgorod. Lobachevsky, Sergey un dos primeiros enxeñeiros en Open Connect - equipo CDN en Netflix. Construíu sistemas de seguimento e análise de datos de vídeo, lanzou un popular servizo para avaliar a velocidade de conexión a Internet FAST.com e, durante os últimos anos, traballa na optimización das solicitudes de Internet para que a aplicación Netflix funcione o máis rápido posible para os usuarios.
O informe recibiu as mellores críticas dos participantes da conferencia e preparamos unha versión de texto para ti.
No seu informe, Sergei falou en detalle
- sobre o que afecta o atraso das solicitudes de Internet entre o cliente e o servidor;
- como reducir este atraso;
- como deseñar, manter e supervisar sistemas tolerantes a erros;
- como conseguir resultados en pouco tempo, e cun risco mínimo para o negocio;
- como analizar os resultados e aprender dos erros.
As respostas a estas preguntas non só necesitan aqueles que traballan en grandes corporacións.
Os principios e técnicas presentados deben ser coñecidos e practicados por todos os que desenvolven e apoian produtos de Internet.
A continuación é a narración desde a perspectiva do falante.
A importancia da velocidade de internet
A velocidade das solicitudes de Internet está directamente relacionada coa empresa. Considere a industria das compras: Amazon en 2009 que un atraso de 100 ms provoca unha perda do 1 % das vendas.
Cada vez hai máis dispositivos móbiles, seguidos dos sitios e aplicacións móbiles. Se a túa páxina tarda máis de 3 segundos en cargarse, estás perdendo preto da metade dos teus usuarios. CON Google ten en conta a velocidade de carga da túa páxina nos resultados de busca: canto máis rápida sexa a páxina, maior será a súa posición en Google.
A velocidade de conexión tamén é importante nas institucións financeiras onde a latencia é fundamental. En 2015, Hibernia Networks un cable de 400 millóns de dólares entre Nova York e Londres para reducir a latencia entre as cidades en 6 ms. Imaxina 66 millóns de dólares por 1 ms de redución da latencia.
Conforme , as velocidades de conexión superiores a 5 Mbit/s xa non afectan directamente á velocidade de carga dun sitio web típico. Non obstante, hai unha relación lineal entre a latencia da conexión e a velocidade de carga da páxina:
Non obstante, Netflix non é un produto típico. O impacto da latencia e da velocidade no usuario é unha área activa de análise e desenvolvemento. Hai carga de aplicacións e selección de contido que dependen da latencia, pero a carga de elementos estáticos e a transmisión tamén dependen da velocidade da conexión. Analizar e optimizar os factores clave que inflúen na experiencia do usuario é unha área activa de desenvolvemento para varios equipos de Netflix. Un dos obxectivos é reducir a latencia das solicitudes entre os dispositivos Netflix e a infraestrutura na nube.
No informe centrarémonos especificamente na redución da latencia co exemplo da infraestrutura de Netflix. Consideremos desde un punto de vista práctico como abordar os procesos de deseño, desenvolvemento e funcionamento de sistemas distribuídos complexos e dedicar tempo á innovación e aos resultados, en lugar de diagnosticar problemas operativos e avarías.
Dentro de Netflix
Miles de dispositivos diferentes admiten as aplicacións de Netflix. Están desenvolvidos por catro equipos diferentes, que fan versións separadas do cliente para Android, iOS, TV e navegadores web. E dedicamos moito esforzo a mellorar e personalizar a experiencia do usuario. Para iso, realizamos centos de probas A/B en paralelo.
A personalización é compatible con centos de microservizos na nube de AWS, que proporcionan datos de usuarios personalizados, envío de consultas, telemetría, Big Data e codificación. A visualización do tráfico ten o seguinte aspecto:
Á esquerda está o punto de entrada, e despois o tráfico distribúese entre varios centos de microservizos que son compatibles con diferentes equipos de backend.
Outro compoñente importante da nosa infraestrutura é o Open Connect CDN, que ofrece contido estático ao usuario final: vídeos, imaxes, código de cliente, etc. O CDN está situado en servidores personalizados (OCA - Open Connect Appliance). No seu interior hai matrices de unidades SSD e HDD que executan FreeBSD optimizado, con NGINX e un conxunto de servizos. Deseñamos e optimizamos compoñentes de hardware e software para que un servidor CDN deste tipo poida enviar a maior cantidade de datos posible aos usuarios.
O "muro" destes servidores no punto de intercambio de tráfico de Internet (Internet eXchange - IX) ten o seguinte aspecto:
Internet Exchange ofrece aos provedores de servizos de Internet e provedores de contido a posibilidade de "conectarse" entre eles para intercambiar datos máis directamente en Internet. Hai aproximadamente entre 70 e 80 puntos de Internet Exchange en todo o mundo onde están instalados os nosos servidores, e instalámolos e mantemos de forma independente:
Ademais, tamén proporcionamos servidores directamente aos provedores de Internet, que instalan na súa rede, mellorando a localización do tráfico de Netflix e a calidade do streaming para os usuarios:
Un conxunto de servizos de AWS encárgase de enviar as solicitudes de vídeo dos clientes aos servidores CDN, así como de configurar os propios servidores: actualizar o contido, o código do programa, a configuración, etc. Para este último, tamén construímos unha rede troncal que conecta servidores en puntos de intercambio de Internet con AWS. A rede troncal é unha rede global de cables e enrutadores de fibra óptica que podemos deseñar e configurar en función das nosas necesidades.
En , a nosa infraestrutura CDN ofrece aproximadamente ⅛ do tráfico de Internet do mundo durante as horas punta e ⅓ do tráfico en América do Norte, onde Netflix leva máis tempo. Uns números impresionantes, pero para min un dos logros máis sorprendentes é que todo o sistema CDN está desenvolvido e mantido por un equipo de menos de 150 persoas.
Inicialmente, a infraestrutura CDN foi deseñada para ofrecer datos de vídeo. Non obstante, co paso do tempo decatámonos de que tamén podemos usalo para optimizar as solicitudes dinámicas dos clientes na nube de AWS.
Sobre a aceleración de Internet
Hoxe, Netflix ten 3 rexións AWS e a latencia das solicitudes á nube dependerá da distancia que estea o cliente da rexión máis próxima. Ao mesmo tempo, temos moitos servidores CDN que se utilizan para entregar contido estático. Hai algunha forma de usar este marco para acelerar as consultas dinámicas? Non obstante, desafortunadamente, é imposible almacenar estas solicitudes na caché: as API son personalizadas e cada resultado é único.
Imos facer un proxy no servidor CDN e comezar a enviar tráfico a través del. Será máis rápido?
Material
Lembremos como funcionan os protocolos de rede. Hoxe, a maior parte do tráfico en Internet usa HTTPs, que depende dos protocolos de capa inferior TCP e TLS. Para que un cliente se conecte ao servidor, fai un apretón de mans e, para establecer unha conexión segura, o cliente necesita intercambiar mensaxes co servidor tres veces e polo menos unha vez máis para transferir datos. Cunha latencia por ida e volta (RTT) de 100 ms, tardaríamos 400 ms en recibir o primeiro bit de datos:
Se colocamos os certificados no servidor CDN, entón o tempo de conexión entre o cliente e o servidor pode reducirse significativamente se o CDN está máis preto. Supoñamos que a latencia do servidor CDN é de 30 ms. Despois tardará 220 ms en recibir o primeiro bit:
Pero as vantaxes non rematan aí. Unha vez establecida unha conexión, TCP aumenta a xanela de conxestión (a cantidade de información que pode transmitir a través desa conexión en paralelo). Se se perde un paquete de datos, as implementacións clásicas do protocolo TCP (como TCP New Reno) reducen a "xanela" aberta á metade. O crecemento da xanela de conxestión e a velocidade da súa recuperación da perda de novo depende do atraso (RTT) do servidor. Se esta conexión só chega ata o servidor CDN, esta recuperación será máis rápida. Ao mesmo tempo, a perda de paquetes é un fenómeno estándar, especialmente para as redes sen fíos.
O ancho de banda de Internet pode reducirse, especialmente nas horas punta, debido ao tráfico dos usuarios, o que pode provocar atascos. Non obstante, non hai xeito en Internet de dar prioridade a unhas solicitudes sobre outras. Por exemplo, dá prioridade ás solicitudes pequenas e sensibles á latencia fronte aos fluxos de datos "pesados" que cargan a rede. Non obstante, no noso caso, ter a nosa propia rede troncal permítenos facelo nunha parte da ruta de solicitude, entre a CDN e a nube, e podemos configurala completamente. Podes asegurarte de que se priorizan os paquetes pequenos e sensibles á latencia e que os grandes fluxos de datos van un pouco máis tarde. Canto máis preto estea a CDN do cliente, maior será a eficiencia.
Os protocolos de nivel de aplicación (OSI Level 7) tamén teñen un impacto na latencia. Novos protocolos como HTTP/2 optimizan o rendemento das solicitudes paralelas. Non obstante, temos clientes de Netflix con dispositivos máis antigos que non admiten os novos protocolos. Non todos os clientes poden actualizarse ou configurarse de forma óptima. Ao mesmo tempo, entre o proxy CDN e a nube hai un control total e a posibilidade de utilizar protocolos e configuracións novos e óptimos. A parte ineficaz con protocolos antigos só funcionará entre o cliente e o servidor CDN. Ademais, podemos facer solicitudes multiplex nunha conexión xa establecida entre a CDN e a nube, mellorando a utilización da conexión a nivel TCP:
Medimos
A pesar de que a teoría promete melloras, non nos apresuramos inmediatamente a lanzar o sistema en produción. En vez diso, primeiro debemos demostrar que a idea funcionará na práctica. Para iso, debes responder a varias preguntas:
- Acelerar: un proxy será máis rápido?
- Confianza: romperase con máis frecuencia?
- Complexidade: como integrarse coas aplicacións?
- Custa: Canto custa implantar infraestrutura adicional?
Consideremos en detalle o noso enfoque para avaliar o primeiro punto. O resto trátase dun xeito similar.
Para analizar a velocidade das solicitudes, queremos obter datos para todos os usuarios, sen gastar moito tempo no desenvolvemento e sen romper a produción. Hai varios enfoques para iso:
- RUM, ou medición de solicitude pasiva. Medimos o tempo de execución das solicitudes actuais dos usuarios e aseguramos unha cobertura total dos usuarios. A desvantaxe é que o sinal non é moi estable debido a moitos factores, por exemplo, debido a diferentes tamaños de solicitude, tempo de procesamento no servidor e no cliente. Ademais, non pode probar unha nova configuración sen efecto na produción.
- Ensaios de laboratorio. Servidores especiais e infraestrutura que simulan clientes. Coa súa axuda realizamos as probas necesarias. Deste xeito, obtemos un control total sobre os resultados da medición e un sinal claro. Pero non hai unha cobertura completa dos dispositivos e das localizacións dos usuarios (especialmente cun servizo e soporte mundial para miles de modelos de dispositivos).
Como podes combinar as vantaxes de ambos os métodos?
O noso equipo atopou unha solución. Escribimos un pequeno anaco de código -unha mostra- que incorporamos na nosa aplicación. As sondas permítennos facer probas de rede totalmente controladas desde os nosos dispositivos. Funciona así:
- Pouco despois de cargar a aplicación e completar a actividade inicial, executamos as nosas sondas.
- O cliente fai unha solicitude ao servidor e recibe unha "receita" para a proba. A receita é unha lista de URL aos que se debe realizar unha solicitude HTTP(s). Ademais, a receita configura os parámetros de solicitude: atrasos entre solicitudes, cantidade de datos solicitados, cabeceiras HTTP(s), etc. Ao mesmo tempo, podemos probar varias receitas diferentes en paralelo; ao solicitar unha configuración, determinamos de forma aleatoria que receita emitir.
- Selecciónase o momento de lanzamento da sonda para non entrar en conflito co uso activo dos recursos da rede no cliente. Esencialmente, se selecciona o momento cando o cliente non está activo.
- Despois de recibir a receita, o cliente realiza solicitudes a cada un dos URL, en paralelo. A solicitude a cada un dos enderezos pódese repetir - o chamado. "pulsos". No primeiro pulso, medimos o tempo que tardou en establecer unha conexión e descargar datos. No segundo pulso, medimos o tempo que tarda en cargar datos a través dunha conexión xa establecida. Antes da terceira, podemos establecer un atraso e medir a velocidade de establecemento dunha reconexión, etc.
Durante a proba, medimos todos os parámetros que pode obter o dispositivo:
- hora de solicitude de DNS;
- Tempo de configuración da conexión TCP;
- Tempo de configuración da conexión TLS;
- hora de recepción do primeiro byte de datos;
- tempo total de carga;
- código de resultado de estado.
- Despois de completar todos os pulsos, a mostra carga todas as medicións para a análise.
Os puntos clave son a mínima dependencia da lóxica do cliente, o procesamento de datos no servidor e a medición de solicitudes paralelas. Así, podemos illar e probar a influencia de varios factores que afectan o rendemento das consultas, varialos dentro dunha única receita e obter resultados de clientes reais.
Esta infraestrutura resultou útil para algo máis que a análise do rendemento das consultas. Actualmente temos 14 receitas activas, máis de 6000 mostras por segundo, recibindo datos de todos os recunchos da terra e cobertura total do dispositivo. Se Netflix comprase un servizo similar a un terceiro, custaría millóns de dólares ao ano, cunha cobertura moito peor.
Testing teórico na práctica: prototipo
Con tal sistema, puidemos avaliar a eficacia dos proxies CDN na latencia de solicitude. Agora necesitas:
- crear un prototipo de proxy;
- colocar o prototipo nun CDN;
- determinar como dirixir os clientes a un proxy nun servidor CDN específico;
- Compare o rendemento coas solicitudes en AWS sen un proxy.
A tarefa é avaliar a eficacia da solución proposta o máis rápido posible. Escollemos Ir para implementar o prototipo debido á dispoñibilidade de boas bibliotecas en rede. En cada servidor CDN, instalamos o proxy prototipo como un binario estático para minimizar as dependencias e simplificar a integración. Na implementación inicial, utilizamos compoñentes estándar na medida do posible e modificacións menores para a agrupación de conexións HTTP/2 e a multiplexación de solicitudes.
Para equilibrar as rexións de AWS, utilizamos unha base de datos DNS xeográfica, a mesma que se utiliza para equilibrar os clientes. Para seleccionar un servidor CDN para o cliente, usamos TCP Anycast para servidores en Internet Exchange (IX). Nesta opción, usamos un enderezo IP para todos os servidores CDN e o cliente dirixirase ao servidor CDN que teña o menor número de saltos IP. Nos servidores CDN instalados por provedores de Internet (ISP), non temos control sobre o router para configurar TCP Anycast, polo que usamos , que dirixe aos clientes a provedores de Internet para a transmisión de vídeo.
Así, temos tres tipos de rutas de solicitude: á nube a través de Internet aberta, a través dun servidor CDN en IX ou a través dun servidor CDN situado nun provedor de Internet. O noso obxectivo é comprender cal é mellor e cal é o beneficio dun proxy en comparación coa forma en que as solicitudes se envían á produción. Para iso utilizamos un sistema de mostraxe do seguinte xeito:
Cada un dos camiños convértese nun obxectivo separado, e miramos o tempo que chegamos. Para a análise, combinamos os resultados do proxy nun grupo (seleccionamos o mellor momento entre os proxies IX e ISP) e comparámolos co tempo das solicitudes á nube sen proxy:
Como podes ver, os resultados foron mixtos: na maioría dos casos o proxy dá unha boa aceleración, pero tamén hai un número suficiente de clientes para os que a situación empeorará significativamente.
Como resultado, fixemos varias cousas importantes:
- Avaliamos o rendemento esperado das solicitudes dos clientes á nube mediante un proxy CDN.
- Recibimos datos de clientes reais, de todo tipo de dispositivos.
- Démonos conta de que a teoría non estaba confirmada ao 100% e que a oferta inicial cun proxy CDN non funcionaría para nós.
- Non asumimos riscos, non cambiamos as configuracións de produción dos clientes.
- Non se rompeu nada.
Prototipo 2.0
Entón, volve ao taboleiro e repite o proceso de novo.
A idea é que, en lugar de usar un proxy 100 %, determinaremos o camiño máis rápido para cada cliente e enviaremos solicitudes alí, é dicir, faremos o que se chama dirección do cliente.
Como implementar isto? Non podemos usar a lóxica no lado do servidor, porque... O obxectivo é conectarse a este servidor. Debe haber algún xeito de facelo no cliente. E, idealmente, facelo cunha lóxica complexa mínima, para non resolver o problema da integración cunha gran cantidade de plataformas de clientes.
A resposta é usar DNS. No noso caso, temos a nosa propia infraestrutura DNS, e podemos configurar unha zona de dominio para a que os nosos servidores serán autoritarios. Funciona así:
- O cliente fai unha solicitude ao servidor DNS mediante un servidor, por exemplo api.netflix.xom.
- A solicitude chega ao noso servidor DNS
- O servidor DNS sabe cal é a ruta máis rápida para este cliente e emite o enderezo IP correspondente.
A solución ten unha complexidade adicional: os provedores de DNS autoritarios non ven o enderezo IP do cliente e só poden ler o enderezo IP do resolvedor recursivo que usa o cliente.
Como resultado, o noso resolvedor autoritario debe tomar unha decisión non para un cliente individual, senón para un grupo de clientes baseado no resolvedor recursivo.
Para resolver, utilizamos as mesmas mostras, agregamos os resultados das medicións dos clientes para cada un dos solucionadores recursivos e decidimos onde enviar este grupo deles: un proxy a través de IX mediante TCP Anycast, a través dun proxy ISP ou directamente á nube.
Temos o seguinte sistema:
O modelo de dirección DNS resultante permítelle dirixir clientes en función de observacións históricas da velocidade das conexións dos clientes á nube.
De novo, a pregunta é con que eficacia funcionará este enfoque? Para responder, usamos de novo o noso sistema de sonda. Polo tanto, configuramos a configuración do presentador, onde un dos obxectivos segue a dirección da dirección do DNS, o outro vai directamente á nube (produción actual).
Como resultado, comparamos os resultados e obtemos unha valoración da eficacia:
Como resultado, aprendemos varias cousas importantes:
- Avaliamos o rendemento esperado das solicitudes dos clientes á nube mediante DNS Steering.
- Recibimos datos de clientes reais, de todo tipo de dispositivos.
- Probouse a eficacia da idea proposta.
- Non asumimos riscos, non cambiamos as configuracións de produción dos clientes.
- Non se rompeu nada.
Agora sobre a parte difícil: lanzámolo en produción
A parte fácil xa rematou: hai un prototipo funcionando. Agora o máis difícil é lanzar unha solución para todo o tráfico de Netflix, implementando a 150 millóns de usuarios, miles de dispositivos, centos de microservizos e un produto e unha infraestrutura en constante cambio. Os servidores de Netflix reciben millóns de solicitudes por segundo e é fácil romper o servizo cunha acción descoidada. Ao mesmo tempo, queremos enrutar de forma dinámica o tráfico a través de miles de servidores CDN en Internet, onde algo cambia e rompe constantemente e no momento máis inoportuno.
E con todo isto, o equipo conta con 3 enxeñeiros responsables do desenvolvemento, implantación e soporte total do sistema.
Por iso, seguiremos falando de sono reparador e saudable.
Como continuar o desenvolvemento e non gastar todo o tempo no apoio? O noso enfoque baséase en 3 principios:
- Reducimos a escala potencial de avarías (raio de explosión).
- Estamos preparándonos para sorpresas; esperamos que algo se rompa, a pesar das probas e da experiencia persoal.
- Degradación graciosa: se algo non funciona ben, debería solucionarse automaticamente, aínda que non sexa da forma máis eficiente.
Resultou que no noso caso, con este enfoque do problema, podemos atopar unha solución sinxela e eficaz e simplificar significativamente o soporte do sistema. Démonos conta de que podíamos engadir un pequeno anaco de código ao cliente e supervisar os erros de solicitude de rede causados por problemas de conexión. En caso de erros na rede, realizamos un regreso directamente á nube. Esta solución non require un esforzo importante para os equipos de clientes, pero reduce moito o risco de avarías e sorpresas inesperadas para nós.
Por suposto, a pesar do retroceso, seguimos unha disciplina clara durante o desenvolvemento:
- Proba de mostra.
- Test A/B ou Canarias.
- Lanzamento progresivo.
Con mostras, o enfoque foi descrito - os cambios son probados primeiro usando unha receita personalizada.
Para as probas canarias, necesitamos obter pares de servidores comparables nos que poidamos comparar como funciona o sistema antes e despois dos cambios. Para iso, entre os nosos moitos sitios CDN, seleccionamos pares de servidores que reciben tráfico comparable:
Despois instalamos a compilación cos cambios no servidor Canary. Para avaliar os resultados, executamos un sistema que compara aproximadamente 100-150 métricas cunha mostra de servidores de Control:
Se as probas de Canary teñen éxito, soltámolas gradualmente, en ondas. Non actualizamos os servidores de cada sitio ao mesmo tempo; perder un sitio completo debido a problemas ten un impacto máis significativo no servizo para os usuarios que perder o mesmo número de servidores en diferentes localizacións.
En xeral, a eficacia e seguridade deste enfoque depende da cantidade e calidade das métricas recollidas. Para o noso sistema de aceleración de consultas, recompilamos métricas de todos os compoñentes posibles:
- dos clientes: número de sesións e solicitudes, taxas de recuperación;
- proxy - estatísticas sobre o número e o tempo de solicitudes;
- DNS - número e resultados das solicitudes;
- borde da nube: número e hora de procesamento de solicitudes na nube.
Todo isto recóllese nun único pipeline e, dependendo das necesidades, decidimos que métricas enviar ás analíticas en tempo real e cales a Elasticsearch ou Big Data para diagnósticos máis detallados.
Seguimos
No noso caso, estamos a facer cambios no camiño crítico das solicitudes entre o cliente e o servidor. Ao mesmo tempo, o número de compoñentes diferentes no cliente, no servidor e no camiño a través de Internet é enorme. Os cambios no cliente e no servidor ocorren constantemente durante o traballo de decenas de equipos e os cambios naturais no ecosistema. Estamos no medio: ao diagnosticar problemas, hai moitas posibilidades de que esteamos implicados. Polo tanto, necesitamos comprender claramente como definir, recoller e analizar métricas para illar rapidamente os problemas.
Idealmente, acceso total a todo tipo de métricas e filtros en tempo real. Pero hai moitas métricas, polo que xorde a cuestión do custo. No noso caso, separamos as métricas e as ferramentas de desenvolvemento do seguinte xeito:
Para detectar e clasificar problemas utilizamos o noso propio sistema de código aberto en tempo real и - para visualización. Almacena métricas agregadas na memoria, é fiable e intégrase co sistema de alerta. Para localización e diagnóstico, temos acceso aos rexistros de Elasticsearch e Kibana. Para análises estatísticas e modelado, usamos big data e visualización en Tableau.
Parece que este enfoque é moi difícil de traballar. Non obstante, ao organizar xerarquicamente as métricas e as ferramentas, podemos analizar rapidamente un problema, determinar o tipo de problema e, a continuación, analizar as métricas detalladas. En xeral, pasamos uns 1-2 minutos para identificar a orixe da avaría. Despois diso, traballamos cun equipo específico en diagnósticos, desde decenas de minutos ata varias horas.
Aínda que o diagnóstico se realice rapidamente, non queremos que isto suceda a miúdo. O ideal é que só recibamos unha alerta crítica cando exista un impacto significativo no servizo. Para o noso sistema de aceleración de consultas, só temos 2 alertas que notificarán:
- Client Fallback percentage - avaliación do comportamento do cliente;
- porcentaxe de erros da sonda: datos de estabilidade dos compoñentes da rede.
Estas alertas críticas supervisan se o sistema funciona para a maioría dos usuarios. Observamos cantos clientes utilizaron a alternativa se non puideron obter a aceleración da solicitude. Facemos unha media de menos dunha alerta crítica por semana, aínda que hai moitos cambios no sistema. Por que é suficiente para nós?
- Hai un cliente alternativo se o noso proxy non funciona.
- Hai un sistema de dirección automático que responde aos problemas.
Máis detalles sobre este último. O noso sistema de proba, e o sistema para determinar automaticamente o camiño óptimo para as solicitudes do cliente á nube, permítenos xestionar automaticamente algúns problemas.
Volvamos á nosa configuración de mostra e ás 3 categorías de camiños. Ademais do tempo de carga, podemos ver o feito da propia entrega. Se non foi posible cargar os datos, mirando os resultados por diferentes camiños podemos determinar onde e que se rompeu, e se podemos solucionalo automaticamente cambiando o camiño da solicitude.
Exemplos:
Este proceso pódese automatizar. Inclúeo no sistema de dirección. E ensínalle a responder aos problemas de rendemento e fiabilidade. Se algo comeza a romper, reacciona se hai unha mellor opción. Ao mesmo tempo, unha reacción inmediata non é crítica, grazas á recuperación dos clientes.
Así, os principios do soporte do sistema pódense formular do seguinte xeito:
- reducindo a escala das avarías;
- recollendo métricas;
- Reparamos automaticamente as avarías se podemos;
- se non pode, avisámosche;
- Estamos traballando en paneis e ferramentas de clasificación para unha resposta rápida.
Leccións aprendidas
Non leva moito tempo escribir un prototipo. No noso caso, estaba listo despois de 4 meses. Con el recibimos novas métricas, e 10 meses despois do inicio do desenvolvemento recibimos o primeiro tráfico de produción. Entón comezou o traballo tedioso e moi difícil: producir e escalar gradualmente o sistema, migrar o tráfico principal e aprender dos erros. Non obstante, este proceso efectivo non será lineal; a pesar de todos os esforzos, non se pode prever todo. É moito máis eficaz iterar e responder rapidamente aos novos datos.
Segundo a nosa experiencia, podemos recomendar o seguinte:
- Non confíes na túa intuición.
A nosa intuición fallounos constantemente, a pesar da ampla experiencia dos membros do noso equipo. Por exemplo, predicimos incorrectamente a aceleración esperada debido ao uso dun proxy CDN ou o comportamento de TCP Anycast.
- Obter datos da produción.
É importante ter acceso a polo menos unha pequena cantidade de datos de produción o máis rápido posible. É case imposible obter o número de casos únicos, configuracións e axustes en condicións de laboratorio. O acceso rápido aos resultados permitirá coñecer rapidamente os posibles problemas e telos en conta na arquitectura do sistema.
- Non sigas os consellos e os resultados doutras persoas: recolle os teus propios datos.
Siga os principios de recollida e análise de datos, pero non acepte cegamente os resultados e as declaracións doutras persoas. Só ti podes saber exactamente o que funciona para os teus usuarios. Os teus sistemas e os teus clientes poden ser significativamente diferentes dos demais empresas. Afortunadamente, agora están dispoñibles ferramentas de análise e fáciles de usar. Os resultados que obtén quizais non sexan os que afirman Netflix, Facebook, Akamai e outras compañías. No noso caso, o rendemento de TLS, HTTP2 ou estatísticas sobre as solicitudes de DNS difire dos resultados de Facebook, Uber, Akamai, porque temos diferentes dispositivos, clientes e fluxos de datos.
- Non sigas as tendencias da moda innecesariamente e avalía a eficacia.
Comeza sinxelo. É mellor facer un sistema de traballo sinxelo en pouco tempo que dedicar unha gran cantidade de tempo a desenvolver compoñentes que non necesitas. Resolve tarefas e problemas importantes en función das túas medicións e resultados.
- Prepárate para novas aplicacións.
Do mesmo xeito que é difícil prever todos os problemas, é difícil predecir os beneficios e as aplicacións con antelación. Tome un exemplo das startups: a súa capacidade de adaptarse ás condicións dos clientes. No seu caso, pode descubrir novos problemas e as súas solucións. No noso proxecto, marcamos o obxectivo de reducir a latencia das solicitudes. Non obstante, durante a análise e as discusións, decatámonos de que tamén podemos usar servidores proxy:
- para equilibrar o tráfico entre as rexións de AWS e reducir os custos;
- modelar a estabilidade da CDN;
- para configurar DNS;
- para configurar TLS/TCP.
Conclusión
No informe, describín como Netflix resolve o problema de acelerar as solicitudes de Internet entre os clientes e a nube. Como recollemos datos mediante un sistema de mostraxe dos clientes e usamos os datos históricos recollidos para encamiñar as solicitudes de produción dos clientes polo camiño máis rápido de Internet. Como usamos os principios dos protocolos de rede, a nosa infraestrutura CDN, a rede troncal e os servidores DNS para conseguir esta tarefa.
Non obstante, a nosa solución é só un exemplo de como en Netflix implementamos tal sistema. O que funcionou para nós. A parte aplicada do meu informe para ti son os principios de desenvolvemento e apoio que seguimos e logramos bos resultados.
A nosa solución ao problema quizais non che conveña. Non obstante, a teoría e os principios de deseño permanecen, aínda que non teñas a túa propia infraestrutura CDN, ou se difire significativamente da nosa.
A importancia da rapidez das solicitudes comerciais tamén segue sendo importante. E mesmo para un servizo sinxelo cómpre escoller: entre provedores de nube, localización do servidor, provedores de CDN e DNS. A súa elección influirá na eficacia das consultas de Internet para os seus clientes. E é importante que midas e comprendas esta influencia.
Comeza con solucións sinxelas, preocúpate de como cambias o produto. Aprende a medida que avanzas e mellora o sistema en función dos datos dos teus clientes, da túa infraestrutura e da túa empresa. Pense na posibilidade de avarías inesperadas durante o proceso de deseño. E entón podes acelerar o teu proceso de desenvolvemento, mellorar a eficiencia da solución, evitar a carga de apoio innecesaria e durmir tranquilo.
Este ano en formato en liña. Podes facerlle preguntas a un dos pais de DevOps, o propio John Willis!
Fonte: www.habr.com