Las nubes son como una caja mágica: preguntas qué necesitas y los recursos aparecen de la nada. Máquinas virtuales, bases de datos, redes: todo esto le pertenece sólo a usted. Hay otros inquilinos de la nube, pero en tu Universo tú eres el único gobernante. Estás seguro de que siempre recibirás los recursos necesarios, no tienes en cuenta a nadie y determinas de forma independiente cómo será la red. ¿Cómo funciona esta magia que hace que la nube asigne recursos de manera elástica y aísle completamente a los inquilinos entre sí?
La nube de AWS es un sistema megasúper complejo que ha ido evolucionando evolutivamente desde 2006. Parte de este desarrollo tuvo lugar Vasily Pantyukhin - Arquitecto de Servicios Web de Amazon. Como arquitecto, obtiene una visión interna no solo del resultado final, sino también de los desafíos que supera AWS. Cuanto mayor sea la comprensión de cómo funciona el sistema, mayor será la confianza. Por lo tanto, Vasily compartirá los secretos de los servicios en la nube de AWS. A continuación se muestra el diseño de servidores físicos de AWS, la escalabilidad elástica de la base de datos, una base de datos personalizada de Amazon y métodos para aumentar el rendimiento de las máquinas virtuales y al mismo tiempo reducir su precio. El conocimiento de los enfoques arquitectónicos de Amazon le ayudará a utilizar los servicios de AWS de forma más eficaz y puede brindarle nuevas ideas para crear sus propias soluciones.
Sobre el orador: Vasily Pantyukhin () comenzó como administrador de Unix en empresas .ru, trabajó en hardware Sun Microsystem de gran tamaño durante 6 años y predicó un mundo centrado en datos en EMC durante 11 años. Naturalmente, evolucionó hacia nubes privadas y, en 2017, pasó a las públicas. Ahora brinda asesoramiento técnico para ayudar a vivir y desarrollarse en la nube de AWS.
Descargo de responsabilidad: todo lo que aparece a continuación es la opinión personal de Vasily y puede no coincidir con la posición de Amazon Web Services. El informe en el que se basa el artículo está disponible en nuestro canal de YouTube.
¿Por qué hablo del dispositivo de Amazon?
Mi primer coche tenía transmisión manual. Fue genial por la sensación de que podía conducir el coche y tener control total sobre él. También me gustó que al menos entendí aproximadamente el principio de su funcionamiento. Naturalmente, imaginé que la estructura de la caja era bastante primitiva, algo así como la caja de cambios de una bicicleta.
Todo fue genial, excepto una cosa: atrapado en los atascos. Parece que estás sentado y no haces nada, pero estás constantemente cambiando de marcha, presionando el embrague, el acelerador, el freno; eso realmente te cansa. El problema del atasco se resolvió parcialmente cuando la familia adquirió un coche automático. Mientras conducía, tuve tiempo de pensar en algo y escuchar un audiolibro.
Otro misterio apareció en mi vida, porque dejé por completo de entender cómo funciona mi coche. Un coche moderno es un dispositivo complejo. El coche se adapta simultáneamente a decenas de parámetros diferentes: pisar el acelerador, frenar, estilo de conducción, calidad de la carretera. Ya no entiendo cómo funciona.
Cuando comencé a trabajar en la nube de Amazon, también era un misterio para mí. Solo que este misterio es un orden de magnitud mayor, porque en el automóvil hay un conductor y en AWS hay millones. Todos los usuarios giran, pisan el acelerador y frenan simultáneamente. Es sorprendente que vayan a donde quieran. ¡Es un milagro para mí! El sistema se adapta, escala y ajusta elásticamente automáticamente a cada usuario para que le parezca que está solo en este Universo.
La magia desapareció un poco cuando comencé a trabajar como arquitecto en Amazon. Vi qué problemas enfrentamos, cómo los solucionamos y cómo desarrollamos los servicios. A medida que se comprende mejor cómo funciona el sistema, aparece más confianza en el servicio. Por eso quiero compartir una imagen de lo que hay bajo el capó de la nube de AWS.
De qué deberíamos hablar
Elegí un enfoque diversificado: seleccioné 4 servicios interesantes de los que vale la pena hablar.
Optimización del servidor. Nubes efímeras con encarnación física: centros de datos físicos donde hay servidores físicos que zumban, se calientan y parpadean con luces.
Funciones sin servidor (Lambda) es probablemente el servicio más escalable en la nube.
Escalado de base de datos. Te contaré cómo construimos nuestras propias bases de datos escalables.
Escalado de red. La última parte en la que abriré el dispositivo de nuestra red. Esto es algo maravilloso: cada usuario de la nube cree que está solo en la nube y no ve a otros inquilinos en absoluto.
Nota. Este artículo analizará la optimización del servidor y el escalado de la base de datos. Consideraremos el escalado de la red en el próximo artículo. ¿Dónde están las funciones sin servidor? Se publicó una transcripción separada sobre ellos “" Habla de varios métodos de escalado diferentes y analiza en detalle la solución Firecracker, una simbiosis de las mejores cualidades de una máquina virtual y contenedores.
Servidores
La nube es efímera. Pero esta efímera todavía tiene una encarnación física: los servidores. Inicialmente, su arquitectura era clásica. Chipset x86 estándar, tarjetas de red, Linux, hipervisor Xen en el que se ejecutaban máquinas virtuales.
En 2012, esta arquitectura cumplió bastante bien sus tareas. Xen es un gran hipervisor, pero tiene un gran inconveniente. el tiene suficiente alta sobrecarga para la emulación de dispositivos. A medida que aparecen nuevas tarjetas de red o unidades SSD más rápidas, esta sobrecarga se vuelve demasiado alta. ¿Cómo afrontar este problema? Decidimos trabajar en dos frentes a la vez: optimizar tanto el hardware como el hipervisor. La tarea es muy seria.
Optimización de hardware e hipervisor
Hacer todo de una vez y hacerlo bien no funcionará. Al principio tampoco estaba claro qué era “bueno”.
Decidimos adoptar un enfoque evolutivo: cambiamos un elemento importante de la arquitectura y lo lanzamos a producción.
Pisamos todos los rastrillos, escuchamos quejas y sugerencias. Luego cambiamos otro componente. Entonces, en pequeños incrementos, cambiamos radicalmente toda la arquitectura según los comentarios de los usuarios y el soporte.
La transformación comenzó en 2013 con lo más complejo: la red. EN S3 En algunos casos, se agregó una tarjeta aceleradora de red especial a la tarjeta de red estándar. Estaba conectado literalmente con un cable loopback corto en el panel frontal. No es bonito, pero no se ve en la nube. Pero la interacción directa con el hardware mejoró fundamentalmente la fluctuación y el rendimiento de la red.
A continuación decidimos mejorar el acceso al almacenamiento de datos en bloque EBS - Elastic Block Storage. Es una combinación de red y almacenamiento. La dificultad es que, si bien existían tarjetas Network Accelerator en el mercado, no había opción de simplemente comprar hardware Storage Accelerator. Entonces recurrimos a una startup Laboratorios de Annapurna, quien desarrolló chips ASIC especiales para nosotros. Permitieron montar volúmenes EBS remotos como dispositivos NVMe.
En casos C4 Resolvimos dos problemas. La primera es que implementamos una base para el futuro de la prometedora, pero nueva en ese momento, tecnología NVMe. En segundo lugar, descargamos significativamente el procesador central transfiriendo el procesamiento de solicitudes a EBS a una nueva tarjeta. Resultó bien, por lo que ahora Annapurna Labs es parte de Amazon.
En noviembre de 2017, nos dimos cuenta de que era hora de cambiar el hipervisor.
El nuevo hipervisor se desarrolló basándose en módulos del kernel KVM modificados.
Hizo posible reducir fundamentalmente la sobrecarga de la emulación de dispositivos y trabajar directamente con nuevos ASIC. Instancias S5 Fueron las primeras máquinas virtuales con un nuevo hipervisor ejecutándose bajo el capó. le pusimos nombre Nitro.
Evolución de instancias en la línea de tiempo.
Todos los nuevos tipos de máquinas virtuales que han aparecido desde noviembre de 2017 se ejecutan en este hipervisor. Las instancias Bare Metal no tienen hipervisor, pero también se les llama Nitro, ya que utilizan tarjetas Nitro especializadas.
Durante los dos años siguientes, el número de tipos de instancias Nitro superó un par de docenas: A1, C5, M5, T3 y otras.
Tipos de instancia.
Cómo funcionan las máquinas Nitro modernas
Tienen tres componentes principales: el hipervisor Nitro (analizado anteriormente), el chip de seguridad y las tarjetas Nitro.
chip de seguridad Integrado directamente en la placa base. Controla muchas funciones importantes, como controlar la carga del sistema operativo host.
tarjetas nitro - Hay cuatro tipos de ellos. Todos ellos están desarrollados por Annapurna Labs y se basan en ASIC comunes. Parte de su firmware también es común.
Cuatro tipos de tarjetas Nitro.
Una de las tarjetas está diseñada para funcionar con la redVPC. Esto es lo que se ve en las máquinas virtuales como tarjeta de red ENA - Adaptador de red elástica. También encapsula el tráfico cuando se transmite a través de una red física (hablaremos de esto en la segunda parte del artículo), controla el firewall de los grupos de seguridad y es responsable del enrutamiento y otras cosas de la red.
Algunas tarjetas funcionan con almacenamiento en bloque EBS y discos integrados en el servidor. Aparecen ante la máquina virtual invitada como Adaptadores NVMe. También son responsables del cifrado de datos y la supervisión del disco.
El sistema de tarjetas Nitro, hipervisor y chip de seguridad está integrado en una red SDN o Red definida por software. Responsable de gestionar esta red (Plano de Control) tarjeta controladora.
Por supuesto, seguimos desarrollando nuevos ASIC. Por ejemplo, a finales de 2018 lanzaron el chip Inferentia, que permite trabajar de forma más eficiente con tareas de aprendizaje automático.
Chip procesador de aprendizaje automático Inferentia.
Base de datos escalable
Una base de datos tradicional tiene una estructura en capas. Para simplificar mucho, se distinguen los siguientes niveles.
- SQL — el cliente y los despachadores de solicitudes trabajan en ello.
- Provisiones actas - Aquí todo está claro, ACID y todo eso.
- almacenamiento en caché, que es proporcionado por grupos de buffer.
- Inicio sesión — proporciona trabajo con registros de rehacer. En MySQL se llaman Bin Logs, en PosgreSQL, Write Ahead Logs (WAL).
- Almacenamiento – grabación directa en disco.
Estructura de base de datos en capas.
Hay diferentes formas de escalar bases de datos: fragmentación, arquitectura Shared Nothing, discos compartidos.
Sin embargo, todos estos métodos mantienen la misma estructura de base de datos monolítica. Esto limita significativamente el escalado. Para resolver este problema, desarrollamos nuestra propia base de datos: Aurora amazónica. Es compatible con MySQL y PostgreSQL.
Aurora amazónica
La idea arquitectónica principal es separar los niveles de almacenamiento y registro de la base de datos principal.
De cara al futuro, diré que también hicimos que el nivel de almacenamiento en caché sea independiente. La arquitectura deja de ser un monolito y ganamos grados adicionales de libertad al escalar bloques individuales.
Los niveles de registro y almacenamiento están separados de la base de datos.
Un DBMS tradicional escribe datos en un sistema de almacenamiento en forma de bloques. En Amazon Aurora, creamos almacenamiento inteligente que puede hablar idiomas rehacer registros. En el interior, el almacenamiento convierte los registros en bloques de datos, monitorea su integridad y realiza copias de seguridad automáticamente.
Este enfoque le permite implementar cosas tan interesantes como clonación. Funciona fundamentalmente de forma más rápida y económica porque no requiere la creación de una copia completa de todos los datos.
La capa de almacenamiento se implementa como un sistema distribuido. Consta de una gran cantidad de servidores físicos. Cada registro de rehacer se procesa y guarda simultáneamente seis nudos. Esto garantiza la protección de datos y el equilibrio de carga.
El escalado de lectura se puede lograr utilizando réplicas apropiadas. El almacenamiento distribuido elimina la necesidad de sincronización entre la instancia de la base de datos principal, a través de la cual escribimos datos, y las réplicas restantes. Se garantiza que los datos actualizados estarán disponibles para todas las réplicas.
El único problema es almacenar en caché datos antiguos en réplicas de lectura. Pero este problema se está solucionando. transferencia de todos los registros de rehacer a réplicas a través de la red interna. Si el registro está en la caché, se marca como incorrecto y se sobrescribe. Si no está en la caché, simplemente se descarta.
Resolvimos el almacenamiento.
Cómo escalar niveles de DBMS
Aquí, el escalado horizontal es mucho más difícil. Así que vayamos por el camino trillado escala vertical clásica.
Supongamos que tenemos una aplicación que se comunica con el DBMS a través de un nodo maestro.
Al escalar verticalmente asignamos un nuevo nodo que tendrá más procesadores y memoria.
A continuación, cambiamos la aplicación del antiguo nodo maestro al nuevo. Surgen problemas.
- Esto requerirá un tiempo de inactividad significativo de la aplicación.
- El nuevo nodo maestro tendrá caché en frío. El rendimiento de la base de datos será máximo sólo después de que el caché se haya calentado.
¿Cómo mejorar la situación? Configure un proxy entre la aplicación y el nodo maestro.
¿Qué nos dará esto? Ahora no es necesario redirigir manualmente todas las aplicaciones al nuevo nodo. El cambio se puede realizar bajo un proxy y es fundamentalmente más rápido.
Parece que el problema se ha resuelto. Pero no, todavía sufrimos la necesidad de calentar el caché. Además, ha aparecido un nuevo problema: ahora el proxy es un punto potencial de fallo.
Solución final con Amazon Aurora sin servidor
¿Cómo resolvimos estos problemas?
Dejó un proxy. No se trata de una instancia separada, sino de toda una flota distribuida de servidores proxy a través de los cuales las aplicaciones se conectan a la base de datos. En caso de avería, cualquiera de los nodos se puede sustituir casi al instante.
Se agregó un grupo de nodos cálidos de varios tamaños.. Por lo tanto, si es necesario asignar un nuevo nodo de mayor o menor tamaño, estará disponible de inmediato. No es necesario esperar a que se cargue.
Todo el proceso de escalado está controlado por un sistema de monitoreo especial. El monitoreo monitorea constantemente el estado del nodo maestro actual. Si detecta, por ejemplo, que la carga del procesador ha alcanzado un valor crítico, notifica al grupo de instancias calientes sobre la necesidad de asignar un nuevo nodo.
Proxies distribuidos, instancias cálidas y monitoreo.
Se dispone de un nodo con la potencia requerida. Los grupos de búfer se copian en él y el sistema comienza a esperar un momento seguro para cambiar.
Normalmente el momento de cambiar llega bastante rápido. Luego se suspende la comunicación entre el proxy y el antiguo nodo maestro y todas las sesiones se cambian al nuevo nodo.
Se reanuda el trabajo con la base de datos.
El gráfico muestra que la suspensión es realmente muy corta. El gráfico azul muestra la carga y los pasos rojos muestran los momentos de escala. Las caídas a corto plazo en el gráfico azul son precisamente ese breve retraso.
Por cierto, Amazon Aurora te permite ahorrar dinero por completo y apagar la base de datos cuando no está en uso, por ejemplo, los fines de semana. Después de detener la carga, el DB reduce gradualmente su potencia y se apaga por un tiempo. Cuando la carga regrese, volverá a subir suavemente.
En la siguiente parte de la historia sobre el dispositivo de Amazon, hablaremos sobre la ampliación de la red. Suscribir y estad atentos para no perderos el artículo.
En Vasily Pantyukhin dará un informe "" Qué patrones de diseño para sistemas distribuidos utilizan los desarrolladores de Amazon, cuáles son las razones de las fallas del servicio, qué es la arquitectura basada en celdas, el trabajo constante, la fragmentación aleatoria, será interesante. Menos de un mes hasta la conferencia. . 24 de octubre aumento de precio final.
Fuente: habr.com