![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/5e4fece0f5039f0fb1af5ead9e0e0089.jpg\")
<\/p>\n
<\/a><\/p>\n Configurar el frontend para un solo sitio, aunque sea muy grande, es sencillo. Tomamos nginx o haproxy o lighttpd, configuramos seg\u00fan las gu\u00edas y nos olvidamos. Si es necesario hacer alg\u00fan cambio, realizamos un reload y nuevamente nos olvidamos.<\/p>\n Todo cambia cuando procesas grandes vol\u00famenes de tr\u00e1fico en tiempo real, eval\u00faas la legitimidad de las solicitudes, comprimes y cacheas contenido de usuario, y adem\u00e1s modificas par\u00e1metros varias veces por segundo. El usuario quiere ver el resultado en todos los nodos externos inmediatamente despu\u00e9s de cambiar la configuraci\u00f3n en su panel de control. Adem\u00e1s, el usuario puede cargar a trav\u00e9s de la API varios miles (y a veces decenas de miles) de dominios con par\u00e1metros de procesamiento de tr\u00e1fico individuales. Todo esto tambi\u00e9n debe funcionar de inmediato en Am\u00e9rica, Europa y Asia; la tarea no es trivial, teniendo en cuenta que en Mosc\u00fa hay varios nodos de filtrado distribuidos f\u00edsicamente.<\/p>\n Las configuraciones de los servicios deben distribuirse lo m\u00e1s r\u00e1pido posible (idealmente de forma instant\u00e1nea) en todos los nodos frontales. No se puede simplemente modificar los archivos de texto de configuraci\u00f3n y reiniciar los demonios en cada cambio \u2014 el mismo nginx mantiene procesos en cierre (worker shutting down) durante varios minutos (y a veces horas si hay largas sesiones de websocket).<\/p>\n Al reiniciar la configuraci\u00f3n, es bastante normal observar lo siguiente:<\/p>\n Sobre la utilizaci\u00f3n de memoria:<\/p>\n Los trabajadores antiguos consumen memoria, la cual no depende linealmente del n\u00famero de conexiones, \u2014 eso es normal. Cuando las conexiones del cliente se cierren, esta memoria se liberar\u00e1.<\/p>\n \u00bfPor qu\u00e9 no fue un problema cuando nginx comenz\u00f3 a desarrollarse? No hab\u00eda ni HTTP\/2, ni WebSocket, ni conexiones keep-alive largas en masa. El 70% de nuestro tr\u00e1fico web es HTTP\/2, lo que implica conexiones muy prolongadas.<\/p>\n La soluci\u00f3n es simple: no usar nginx, no gestionar los frontales bas\u00e1ndose en archivos de texto, y definitivamente no enviar configuraciones de texto comprimidas a trav\u00e9s de canales transoce\u00e1nicos. Los canales, por supuesto, son garantizados y reservados, pero eso no los hace menos transcontinentales.<\/p>\n Tenemos nuestro propio servidor de equilibrio de carga en el front-end, del cual hablar\u00e9 en art\u00edculos posteriores. Lo principal que puede hacer es aplicar miles de cambios de configuraci\u00f3n por segundo en tiempo real, sin reinicios, recargas, picos en el consumo de memoria y todo eso. Es muy similar al Hot Code Reload, por ejemplo, en Erlang. Los datos se almacenan en una base de datos key-value geodistribuida y son le\u00eddos de inmediato por los mecanismos ejecutores del front-end. Es decir, has subido un certificado SSL a trav\u00e9s de la interfaz web o API en Mosc\u00fa, y en unos pocos segundos ya est\u00e1 listo para funcionar en nuestro centro de limpieza en Los \u00c1ngeles. Si por alguna raz\u00f3n ocurre una guerra mundial y se interrumpe el internet en todo el mundo, nuestras nodos seguir\u00e1n funcionando de manera aut\u00f3noma y arreglar\u00e1n el split-brain tan pronto como se habilite uno de los canales dedicados Los \u00c1ngeles-\u00c1msterdam-Mosc\u00fa, Mosc\u00fa-\u00c1msterdam-Hong Kong-Los \u00c1ngeles o al menos uno de los reservados de GRE superpuestos.<\/p>\n Este mismo mecanismo nos permite emitir y renovar certificados Let’s Encrypt.<\/a> Funciona de manera muy simplificada as\u00ed:<\/p>\n Justo ahora estamos rotando en tiempo real 350k certificados de manera completamente transparente para los usuarios.<\/p>\n En los pr\u00f3ximos art\u00edculos del ciclo hablar\u00e9 sobre otras caracter\u00edsticas del procesamiento en tiempo real de grandes vol\u00famenes de tr\u00e1fico web \u2014 por ejemplo, sobre el an\u00e1lisis de RTT con datos incompletos para mejorar la calidad del servicio de clientes de tr\u00e1nsito y sobre la protecci\u00f3n del tr\u00e1fico de tr\u00e1nsito contra ataques de terabits, sobre la entrega y agregaci\u00f3n de informaci\u00f3n sobre el tr\u00e1fico, sobre WAF, una CDN casi ilimitada y numerosos mecanismos de optimizaci\u00f3n de la entrega de contenido.<\/p>\n Solo los usuarios registrados pueden participar en la encuesta. Inicie sesi\u00f3n<\/a>, por favor.<\/p>\n\u00bfPor qu\u00e9 tener muchos nodos grandes y confiables en todo el mundo?<\/h3>\n
\n
\u00bfC\u00f3mo gestionar todo esto?<\/h3>\n
![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/6a1ffc01ad9bac1e51d46c3130ea2a37.jpg\")
<\/p>\n![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/d356134b0866b8c92a3d5f7a3a8df208.jpg\")
<\/p>\n\n
![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/20830ee7c4ea57ec1d0833f0bc25412d.jpg\")
<\/li>\n![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/1c8b295065f27c1b69c810ff74ce4018.jpg\")
<\/li>\n![\"Web-HighLoad](\"\/wp-content\/uploads\/2020\/04\/e4fc349089fbf7cbe7824ea539865daf.jpg\")
<\/li>\n\u00bfSobre qu\u00e9 le gustar\u00eda saber primero?<\/h2>\n