{"id":39302,"date":"2019-10-31T22:29:40","date_gmt":"2019-10-31T19:29:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh\/"},"modified":"2019-10-31T22:29:40","modified_gmt":"2019-10-31T19:29:40","slug":"kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-aws-varit-svoi-elastichnye-servisy-masshtabirovanie-serverov-i-bazy-dannyh","title":{"rendered":"C\u00f3mo AWS \"cocina\" sus servicios el\u00e1sticos. Escalado de servidores y bases de datos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Las nubes son como una caja m\u00e1gica: pides lo que necesitas y los recursos simplemente aparecen de la nada. M\u00e1quinas virtuales, bases de datos, redes: todo esto te pertenece solo a ti. Existen otros inquilinos en la nube, pero en tu universo t\u00fa eres el \u00fanico gobernante. Est\u00e1s seguro de que siempre obtendr\u00e1s los recursos requeridos, no cuentas con nadie y decides por ti mismo c\u00f3mo ser\u00e1 la red. \u00bfC\u00f3mo funciona esta magia que hace que la nube asigne recursos de manera el\u00e1stica y a\u00edsle completamente a los inquilinos entre s\u00ed?<\/p>\n

\"C\u00f3mo
\n
\nLa nube de AWS es un sistema megas\u00faper complejo que ha estado evolucionando desde 2006. Parte de esta evoluci\u00f3n fue Vasili Pantiukhyn<\/strong> \u2014 arquitecto de Amazon Web Services. Como arquitecto, ve no solo el resultado final, sino tambi\u00e9n las complejidades que AWS supera. Cuanto m\u00e1s entiendes c\u00f3mo funciona el sistema, m\u00e1s confianza tienes. Por eso, Vasili compartir\u00e1 secretos sobre los servicios de la nube de AWS. M\u00e1s abajo, la estructura de los servidores f\u00edsicos de AWS, la escalabilidad el\u00e1stica de las bases de datos, la base de datos personalizada de Amazon y m\u00e9todos para aumentar el rendimiento de las m\u00e1quinas virtuales mientras se reduce su costo. Conocer los enfoques arquitect\u00f3nicos de Amazon ayudar\u00e1 a utilizar los servicios de AWS de manera m\u00e1s eficaz y, posiblemente, aportar\u00e1 nuevas ideas para construir tus propias soluciones.
\n<\/a><\/noindex>
\nSobre el ponente: Vasili Pantiukhyn (Hen<\/a><\/noindex>) comenz\u00f3 como administrador de Unix en empresas .ru, pas\u00f3 6 a\u00f1os trabajando con grandes equipos de Sun Microsystems y 11 a\u00f1os abogando por un mundo centrado en los datos en EMC. Evolucion\u00f3 naturalmente hacia nubes privadas y, en 2017, se uni\u00f3 a las p\u00fablicas. Ahora ayuda a vivir y desarrollarse en la nube de AWS con consejos t\u00e9cnicos.<\/p>\n

Descargo de responsabilidad: todo lo que sigue es la opini\u00f3n personal de Vasili y puede no coincidir con la posici\u00f3n de Amazon Web Services. La grabaci\u00f3n del<\/a><\/noindex> discurso en el que se basa este art\u00edculo est\u00e1 disponible en nuestro canal de YouTube.<\/i><\/p>\n

Por qu\u00e9 hablo sobre la estructura de Amazon<\/h2>\n

\nMi primer auto era con 'cambio manual' \u2014 en una transmisi\u00f3n mec\u00e1nica. Era genial porque sent\u00eda que pod\u00eda controlar el coche y ten\u00eda el control total de \u00e9l. Tambi\u00e9n me gustaba que al menos entend\u00eda aproximadamente c\u00f3mo funcionaba. Naturalmente, conceb\u00eda la estructura de la caja de cambios de manera bastante primitiva \u2014 m\u00e1s o menos como la de una bicicleta.<\/p>\n

\"C\u00f3mo
\n
\nTodo fue maravilloso, excepto por una cosa: estar atrapado en el tr\u00e1fico. Pasas tiempo sentado sin hacer nada, pero constantemente cambias de marcha, presionas el clutch, acelera, frenas; de verdad se cansa uno. El problema del tr\u00e1fico se solucion\u00f3 parcialmente cuando en la familia apareci\u00f3 un coche autom\u00e1tico. Al volante, ahora tengo tiempo para pensar en algo o escuchar un audiolibro.<\/p>\n

Tambi\u00e9n apareci\u00f3 un misterio en mi vida, porque dej\u00e9 de entender c\u00f3mo funciona mi coche. Un coche moderno es un dispositivo complejo. Se adapta simult\u00e1neamente a decenas de par\u00e1metros diferentes: la presi\u00f3n del acelerador, el freno, el estilo de conducci\u00f3n, la calidad de la carretera. Ya no entiendo c\u00f3mo funciona.<\/p>\n

Cuando empec\u00e9 a trabajar con la nube de Amazon, para m\u00ed tambi\u00e9n era un secreto. Solo que este secreto es mucho m\u00e1s grande, porque en un coche hay un conductor, y en AWS hay millones. Todos los usuarios maniobran al mismo tiempo, aceleran y frenan. Es sorprendente que lleguen a donde quieren \u2014 para m\u00ed eso es un milagro. El sistema se adapta autom\u00e1ticamente, se escala y se ajusta de manera el\u00e1stica a cada usuario, de tal manera que parece que est\u00e1 solo en este universo.<\/p>\n

La magia se desvaneci\u00f3 un poco cuando m\u00e1s tarde vine a trabajar como arquitecto en Amazon. Vi los problemas que enfrentamos, c\u00f3mo los resolvemos, c\u00f3mo desarrollamos los servicios. A medida que crece la comprensi\u00f3n del funcionamiento del sistema, aumenta la confianza en el servicio. Por eso, quiero compartir la imagen de lo que hay bajo el cap\u00f3 de la nube de AWS.<\/p>\n

De qu\u00e9 hablaremos<\/h2>\n

\nEleg\u00ed un enfoque diversificado \u2014 seleccion\u00e9 4 servicios interesantes de los que vale la pena hablar.<\/p>\n

Optimizaci\u00f3n de servidores<\/strong>. Nubes ef\u00edmeras con representaci\u00f3n f\u00edsica: centros de datos f\u00edsicos donde hay servidores f\u00edsicos que zumban, se calientan y parpadean.<\/p>\n

Funciones sin servidor <\/strong>(Lambda) \u2014 probablemente, el servicio m\u00e1s escalable en la nube.<\/p>\n

Escalabilidad de bases de datos<\/strong>. Hablar\u00e9 sobre c\u00f3mo construimos nuestras propias bases de datos escalables.<\/p>\n

Escalabilidad de red<\/strong>. La \u00faltima parte, en la que abrir\u00e9 la estructura de nuestra red. Es una maravilla: cada usuario de la nube siente que est\u00e1 solo en la nube y en realidad no ve a otros inquilinos.<\/p>\n

Nota. En este art\u00edculo se abordar\u00e1 la optimizaci\u00f3n de servidores y el escalado de bases de datos. El escalado de la red se tratar\u00e1 en el pr\u00f3ximo art\u00edculo. \u00bfD\u00f3nde est\u00e1n las funciones serverless? Acerca de esto se public\u00f3 una transcripci\u00f3n separada \u00abPeque\u00f1o, pero potente. Unboxing de la microvirtualizaci\u00f3n Firecracker<\/a><\/noindex>\u00bb. En ella se comentan varios m\u00e9todos de escalado y se detalla la soluci\u00f3n Firecracker: la simbiosis de las mejores cualidades de las m\u00e1quinas virtuales y los contenedores.<\/i><\/p><\/blockquote>\n

<\/p>\n

Servidores<\/h2>\n

\nLa nube es ef\u00edmera. Pero esta ef\u00edmera existencia tiene una representaci\u00f3n f\u00edsica: los servidores. Inicialmente, su arquitectura era cl\u00e1sica. Chipset x86 est\u00e1ndar, tarjetas de red, Linux, hipervisor Xen, en el que se ejecutaban las m\u00e1quinas virtuales.<\/p>\n

\"C\u00f3mo
\n
\nEn 2012, esta arquitectura cumpl\u00eda adecuadamente con sus tareas. Xen es un gran hipervisor, pero tiene una desventaja importante. Tiene un costo alto en la emulaci\u00f3n de dispositivos.<\/strong>Con la llegada de nuevas tarjetas de red m\u00e1s r\u00e1pidas o discos SSD, estos costos se vuelven demasiado altos. \u00bfC\u00f3mo se puede solucionar este problema? Decidimos trabajar en dos frentes: optimizar tanto el hardware como el hipervisor.<\/strong>La tarea es muy seria.<\/p>\n

Optimizaci\u00f3n del hardware y del hipervisor<\/h3>\n

\nNo se puede hacer todo a la vez y bien. Lo que significa \"bien\" no estaba claro al principio.<\/p>\n

Decidimos aplicar un enfoque evolutivo: cambiamos un elemento importante de la arquitectura y lo lanzamos a producci\u00f3n.<\/p><\/blockquote>\n

Cometemos errores, escuchamos quejas y sugerencias. Luego cambiamos otro componente. As\u00ed, mediante peque\u00f1os incrementos, transformamos toda la arquitectura bas\u00e1ndonos en la retroalimentaci\u00f3n de usuarios y soporte.<\/p>\n

Las transformaciones comenzaron en 2013 con lo m\u00e1s complicado: la red. En C3<\/strong> se a\u00f1adieron a la tarjeta de red est\u00e1ndar una tarjeta especial llamada Network Accelerator. Se conectaba mediante un corto cable loopback en el panel frontal. No es bonito, pero en la nube no se ve. Sin embargo, la conexi\u00f3n directa con el hardware mejor\u00f3 significativamente el jitter y la capacidad de la red.<\/p>\n

Luego decidimos mejorar el acceso al almacenamiento en bloque EBS \u2014 Elastic Block Storage. Esta es una combinaci\u00f3n de red y almacenamiento. La dificultad radica en que, aunque en el mercado hab\u00eda tarjetas Network Accelerator, no hab\u00eda forma de comprar hardware Storage Accelerator. Por eso nos dirigimos a la startup Annapurna Labs<\/strong>, que desarroll\u00f3 para nosotros chips ASIC especiales. Esto permiti\u00f3 conectar vol\u00famenes EBS remotos como dispositivos NVMe.<\/p>\n

En las instancias C4<\/strong> resolvimos dos problemas. El primero fue preparar el camino para una tecnolog\u00eda NVMe prometedora pero nueva en ese momento. El segundo fue aliviar significativamente la carga del procesador central trasladando el procesamiento de las solicitudes a EBS a una nueva tarjeta. Result\u00f3 exitoso, por lo que ahora Annapurna Labs es parte de Amazon.<\/p>\n

Para noviembre de 2017, entendimos que era hora de cambiar el hipervisor.<\/p>\n

El nuevo hipervisor fue desarrollado sobre la base de m\u00f3dulos del n\u00facleo KVM mejorados.<\/p><\/blockquote>\n

Permiti\u00f3 reducir radicalmente los costos de emulaci\u00f3n de dispositivos y trabajar directamente con los nuevos ASIC. Las instancias C5<\/strong> fueron las primeras m\u00e1quinas virtuales que operan con el nuevo hipervisor. Lo llamamos Nitro<\/strong>.<\/p>\n

\"C\u00f3moEvoluci\u00f3n de las instancias en la l\u00ednea de tiempo.<\/em><\/p>\n

Todos los nuevos tipos de m\u00e1quinas virtuales que surgieron desde noviembre de 2017 funcionan en este hipervisor. Las instancias Bare Metal no tienen hipervisor<\/strong>, pero tambi\u00e9n se les llama Nitro, ya que utilizan tarjetas Nitro especializadas.<\/p>\n

En los siguientes dos a\u00f1os, el n\u00famero de tipos de instancias Nitro super\u00f3 la docena: A1, C5, M5, T3 y otros.<\/p>\n

\"C\u00f3mo
\nTipos de instancias.<\/em><\/p>\n

C\u00f3mo est\u00e1n construidas las modernas m\u00e1quinas Nitro<\/h3>\n

\nTienen tres componentes principales: el hipervisor Nitro (mencionado anteriormente), un chip de seguridad y tarjetas Nitro.<\/p>\n

El chip de seguridad<\/strong> est\u00e1 integrado directamente en la placa base. Controla muchas funciones importantes, como el control de arranque del sistema operativo host.<\/p>\n

Las tarjetas Nitro<\/strong> son de cuatro tipos. Todas fueron desarrolladas por Annapurna Labs y se basan en ASIC comunes. Parte de su firmware tambi\u00e9n es com\u00fan.<\/p>\n

\"C\u00f3mo
\nCuatro tipos de tarjetas Nitro.<\/em><\/p>\n

Una de las tarjetas est\u00e1 destinada a trabajar con la red<\/strong>VPC<\/strong>. Es la que se ve en las m\u00e1quinas virtuales como una tarjeta de red ENA \u2014 Elastic Network Adaptor<\/strong>. Tambi\u00e9n encapsula el tr\u00e1fico al transferirlo a trav\u00e9s de la red f\u00edsica (hablaremos de esto en la segunda parte del art\u00edculo), controla el firewall de Security Groups, se encarga del enrutamiento y otras cuestiones de red.<\/p>\n

Tarjetas separadas trabajan con almacenamiento en bloque EBS<\/strong> y discos que est\u00e1n integrados en el servidor. Para la m\u00e1quina virtual hu\u00e9sped, se presentan como adaptadores NVMe<\/strong>. Tambi\u00e9n se encargan del cifrado de datos y la supervisi\u00f3n de discos.<\/p>\n

El sistema de las tarjetas Nitro, el hipervisor y el chip de seguridad est\u00e1 integrado en una red SDN o Software Defined Network<\/strong>. La gesti\u00f3n de esta red (Control Plane) est\u00e1 a cargo de la tarjeta controladora<\/strong>.<\/p>\n

Por supuesto, seguimos desarrollando nuevos ASIC. Por ejemplo, a finales de 2018 lanzamos el chip Inferentia, que permite trabajar de manera m\u00e1s eficiente con tareas de aprendizaje autom\u00e1tico.<\/p>\n

\"C\u00f3mo
\nChip Inferentia Procesador de Aprendizaje Autom\u00e1tico.<\/em><\/p>\n

Base de datos escalable<\/h2>\n

\nUna base de datos tradicional tiene una estructura en capas. Si simplificamos bastante, podemos identificar los siguientes niveles.<\/p>\n