Las nubes son como una caja mágica: preguntas lo que necesitas y los recursos simplemente aparecen de la nada. Máquinas virtuales, bases de datos, una red: todo esto solo le pertenece a usted. Hay otros inquilinos de la nube, pero en su universo usted es el único gobernante. Está seguro de que siempre recibirá los recursos necesarios, no tiene en cuenta a nadie y determina independientemente cuál será la red. ¿Cómo es esta magia que hace que la nube asigne recursos elásticamente y aísle completamente a los inquilinos unos de otros?
AWS Cloud es un sistema mega sofisticado que ha evolucionado desde 2006. Parte de este desarrollo fue encontrado por
Vasily Pantyukhin , arquitecto de Amazon Web Services. Como arquitecto, ve desde adentro no solo el resultado final, sino también los desafíos que supera AWS. Cuanto más comprensión del sistema, más confianza. Por lo tanto, Vasily compartirá los secretos de los servicios en la nube de AWS. Debajo del corte se encuentra el dispositivo para servidores físicos de AWS, escalabilidad flexible de la base de datos, base de datos personalizada de Amazon y métodos para aumentar el rendimiento de las máquinas virtuales y reducir su precio. El conocimiento de los enfoques arquitectónicos de Amazon lo ayudará a hacer un mejor uso de los servicios de AWS y puede proporcionar nuevas ideas para crear sus propias soluciones.
Acerca del orador: Vasily Pantyukhin ( Hen ) comenzó como un administrador de Unix en empresas ru, pasó 6 años trabajando en glándulas Sun Microsystem grandes, y durante 11 años predicó la centralización de datos del mundo en EMC. Evolucionó naturalmente a nubes privadas, y en 2017 se convirtió en nubes públicas. Ahora con consejos técnicos, ayuda a vivir y desarrollarse en la nube de AWS.
Descargo de responsabilidad: todo lo que se muestra a continuación es la opinión personal de Vasily, y puede no coincidir con la posición de los servicios web de Amazon. Un video del informe en base al cual se creó el artículo está disponible en nuestro canal de YouTube.¿Por qué estoy hablando de un dispositivo Amazon?
Mi primer automóvil fue con una "manija", en una caja de cambios manual. Fue genial por la sensación de que podía controlar la máquina y controlarla por completo. También me gustó que al menos entiendo el principio de su trabajo. Naturalmente, imaginé el dispositivo de caja de manera bastante primitiva, más o menos como una caja de cambios en una bicicleta.
Todo fue maravilloso, excepto por una cosa: pararse en atascos. Parece que estás sentado y sin hacer nada, pero constantemente cambias de marcha, presionas el embrague, el acelerador, el freno, realmente te cansas. El problema de los atascos se resolvió parcialmente cuando apareció una máquina en la máquina de la familia. Al volante había tiempo para pensar en algo, escuchar un audiolibro.
Un misterio apareció en mi vida, porque generalmente dejé de entender cómo funciona mi automóvil. Un automóvil moderno es un dispositivo complejo. El automóvil se adapta simultáneamente a docenas de parámetros diferentes: presionar el acelerador, frenar, estilo de conducción, calidad de la carretera. Ya no entiendo cómo funciona esto.
Cuando comencé a hacer Amazon Cloud, eso también fue un misterio para mí. Solo este secreto es un orden de magnitud mayor, porque hay un conductor en el automóvil y hay millones en AWS. Todos los usuarios dirigen simultáneamente, presionan el acelerador y frenan. Es sorprendente que vayan a donde quieran, ¡para mí es un milagro! El sistema se adapta, escala y ajusta de manera flexible a cada usuario de manera automática, de modo que le parece que está solo en este universo.
La magia se disipó un poco cuando más tarde llegué a trabajar como arquitecto en Amazon. Vi a qué problemas nos enfrentamos, cómo los resolvemos, cómo desarrollamos los servicios. Con un aumento en la comprensión del sistema, hay más confianza en el servicio. Así que quiero compartir una imagen de lo que está bajo el capó de la nube de AWS.
¿De qué hablaremos?
Elegí un enfoque diversificado: seleccioné 4 servicios interesantes de los que vale la pena hablar.
Optimización del servidor . Nubes efímeras con una realización física: centros de datos físicos, donde hay servidores físicos que emiten zumbidos, se calientan y parpadean las bombillas.
Las funciones sin servidor (Lambda) son probablemente el servicio más escalable en la nube.
Escalado de bases de datos . Hablaré sobre 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 se centrará en la optimización del servidor y el escalado de la base de datos. El escalado de la red se discutirá en el próximo artículo. ¿Dónde están las funciones sin servidor? Una transcripción separada salió sobre ellos: “ Mal, sí, audaz. Anboxing de microvirtuales Firecracker ". Habla sobre varias formas diferentes de escalado, y la solución Firecracker se analiza en detalle: 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: servidores. Inicialmente, su arquitectura era clásica. Chipset x86 estándar, tarjetas de red, Linux, hipervisor Xen, que ejecuta máquinas virtuales.
En 2012, dicha arquitectura hizo bien su trabajo. Xen es un gran hipervisor, pero con un gran defecto. Tiene una
sobrecarga bastante
alta para emular dispositivos . Con el advenimiento de nuevas tarjetas de red o SSD más rápidas, estos gastos generales se vuelven demasiado altos. ¿Cómo lidiar con este problema? Decidimos trabajar en dos frentes a la vez, para
optimizar tanto el hardware como el hipervisor . La tarea es muy seria.
Optimización de hierro e hipervisor.
Hacer todo de una vez y bien no funcionará. Lo que es "bueno" fue inicialmente incomprensible.
Decidimos aplicar un enfoque evolutivo: cambiamos un elemento importante de la arquitectura y lo lanzamos a la producción.
Pisamos todos los rastrillos, escuchamos quejas y sugerencias. Luego cambiamos otro componente. Por lo tanto, en pequeños incrementos, cambiamos radicalmente toda la arquitectura en función de los comentarios y el soporte del usuario.
La transformación comenzó en 2013 con lo más difícil: la red. En casos
C3 , se agregó una tarjeta especial Acelerador de red a la tarjeta de red estándar. Estaba conectado con un cable de bucle literalmente corto en el panel frontal. Feo, pero no visible en la nube. Pero la interacción directa con el hardware mejoró considerablemente el jitter y el ancho de banda de la red.
Luego decidimos centrarnos en mejorar el acceso al almacenamiento en bloque de EBS: Elastic Block Storage. Esta es una combinación de red y almacenamiento. La dificultad es que si las tarjetas de Network Accelerator existieran en el mercado, no habría forma de comprar hardware de Storage Accelerator. Por lo tanto, recurrimos a la startup
Annapurna Labs , que desarrolló chips ASIC especiales para nosotros. Le permitieron conectar volúmenes EBS remotos como dispositivos NVMe.
En casos de
C4 , resolvimos dos problemas. Primero, implementamos las bases para el futuro con tecnología NVMe prometedora, pero nueva en ese momento. El segundo: descargó significativamente el procesador central al transferir el procesamiento de solicitudes a EBS a una nueva tarjeta. Resultó bien, así que ahora Annapurna Labs es parte de Amazon.
Para noviembre de 2017, nos dimos cuenta de que era hora de cambiar el hipervisor en sí.
El nuevo hipervisor se desarrolló sobre la base de módulos de kernel KVM modificados.
Permitió reducir fundamentalmente los costos generales de emular dispositivos y trabajar directamente con los nuevos ASIC.
Las instancias
C5 fueron las primeras máquinas virtuales bajo las cuales se está ejecutando un nuevo hipervisor. Lo llamamos
Nitro .
La evolución de las instancias en la línea de tiempo.Todos los nuevos tipos de máquinas virtuales que aparecieron desde noviembre de 2017 funcionan en este hipervisor.
Las instancias de Iron Bare Metal no tienen un hipervisor , pero también se llaman Nitro, ya que usan tarjetas Nitro especializadas.
En los próximos dos años, el número de tipos de instancias Nitro superó un par de docenas: A1, C5, M5, T3 y otros.
Tipos de instancias.Como funcionan los autos nitro modernos
Tienen tres componentes principales: un hipervisor Nitro (discutido anteriormente), un chip de seguridad y tarjetas Nitro.
El chip de seguridad está integrado directamente en la placa base. Controla muchas funciones importantes, por ejemplo, controlar la carga del sistema operativo host.
Tarjetas Nitro : hay cuatro tipos de ellas. Todos 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
una red VPC . Es ella quien es visible en
las máquinas virtuales como una tarjeta de red
ENA: Elastic Network Adapter . También encapsula el tráfico cuando se transmite a través de la red física (hablaremos de esto en la segunda parte del artículo), controla el firewall de los Grupos de Seguridad, es responsable del enrutamiento y otras cosas de la red.
Las tarjetas separadas funcionan con el almacenamiento en bloque de
EBS y los discos integrados en el servidor. Se presentan a las máquinas virtuales invitadas como
adaptadores NVMe . También son responsables del cifrado de datos y la supervisión del disco.
El sistema de tarjetas Nitro, un hipervisor y un chip de seguridad están integrados en una
red definida por software o SDN. La
tarjeta de control es responsable de administrar esta red (Plano de control).
Por supuesto, continuamos desarrollando nuevos ASIC. Por ejemplo, a fines de 2018, lanzaron el chip Inferentia, que permite un trabajo más eficiente con tareas de aprendizaje automático.
Chip de procesador de aprendizaje automático Inferentia.Base de datos escalable
La base de datos tradicional tiene una estructura en capas. Si se simplifica enormemente, se distinguen los siguientes niveles.
- SQL : los despachadores de clientes y consultas trabajan en ello.
- Asegurar transacciones : todo está claro aquí, ACID y todo eso.
- Almacenamiento en caché proporcionado por agrupaciones de almacenamiento intermedio.
- Registro : proporciona trabajo con redo-logs. En MySQL se llaman Bin Logs, en PosgreSQL se llaman Write Ahead Logs (WAL).
- Almacenamiento : escriba directamente en el disco.
Estructura de base de datos en capas.Hay diferentes formas de escalar bases de datos: fragmentación, arquitectura Shared Nothing, unidades compartidas.
Sin embargo, todos estos métodos conservan la misma estructura de base de datos monolítica. Esto limita significativamente la escala. Para resolver este problema, desarrollamos nuestra propia base de datos:
Amazon Aurora . Es compatible con MySQL y PostgreSQL.
Aurora amazónica
La idea arquitectónica principal es dividir los niveles de almacenamiento y registro de la base de datos principal.
Mirando hacia el futuro, diré que también hicimos que el nivel de caché sea independiente. La arquitectura deja de ser un monolito, y obtenemos 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 el sistema de almacenamiento en forma de bloques. En Amazon Aurora, creamos un repositorio "inteligente" que puede hablar el idioma de
redo-logs . En el interior, el repositorio convierte los registros en bloques de datos, supervisa su integridad y realiza copias de seguridad automáticamente.
Este enfoque le permite implementar cosas tan interesantes como la
clonación . Funciona fundamentalmente más rápido y más económico debido al hecho de que no requiere la creación de una copia completa de todos los datos.
El nivel de almacenamiento se implementa como un sistema distribuido. Consiste en una gran cantidad de servidores físicos. Cada redo-log es procesado y almacenado simultáneamente por
seis nodos . Esto proporciona protección de datos y equilibrio de carga.
La escala de lectura se puede lograr utilizando réplicas apropiadas. El almacenamiento distribuido elimina la necesidad de sincronización entre la instancia de base de datos principal a través de la cual escribimos datos y otras réplicas. Se garantiza que los datos actuales estarán disponibles para todas las réplicas.
El único problema es el almacenamiento en caché de datos antiguos en las réplicas de lectura. Pero este problema se resuelve
transfiriendo todos los registros de rehacer a las réplicas en la red interna. Si el registro está en la memoria caché, se marca como no válido y se sobrescribe. Si no está en el caché, simplemente se descarta.
Descubrimos el almacenamiento.
Cómo escalar niveles de DBMS
Aquí la escala horizontal es mucho más difícil de hacer. Por lo tanto, vamos al camino trillado del
escalamiento vertical clásico .
Supongamos que tenemos una aplicación que se comunica con un DBMS a través de un nodo maestro.
Con la escala vertical, seleccionamos un nuevo nodo que tendrá más procesadores y memoria.
A continuación, cambie la aplicación del nodo maestro anterior al nuevo. Hay problemas
- Esto requerirá un tiempo de inactividad notable de la aplicación.
- El nuevo nodo maestro tendrá un caché frío. El rendimiento de la base de datos será máximo solo después de que la caché se haya calentado.
¿Cómo mejorar la situación? Ponga un proxy entre la aplicación y el nodo maestro.
¿Qué nos dará? Ahora todas las aplicaciones no necesitan ser redirigidas manualmente a un nuevo nodo. El cambio se puede hacer bajo un proxy y al mismo tiempo fundamentalmente más rápido.
El problema parece estar resuelto. Pero no, todavía sufrimos la necesidad de calentar el caché. Además, ha aparecido un nuevo problema: ahora el proxy es un posible punto de falla.
Solución final con Amazon Aurora Serverless
¿Cómo resolvimos estos problemas?
Dejó un proxy . Esta no es una instancia separada, sino 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 falla, cualquiera de los nodos puede ser reemplazado casi instantáneamente.
Agregamos un grupo de nodos cálidos de varios tamaños . Por lo tanto, si es necesario asignar un nuevo nodo de un tamaño mayor o menor, está disponible de inmediato. No es necesario esperar a que se cargue.
Todo el proceso de escalado está controlado por un sistema de monitoreo especial. La supervisión supervisa 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 de la necesidad de asignar un nuevo nodo.
Proxies distribuidos, instancias cálidas y monitoreo.Un nodo de potencia requerida está disponible. Las agrupaciones de almacenamientos intermedios se copian y el sistema comienza a esperar un momento seguro para cambiar.
Por lo general, el momento de cambiar llega lo suficientemente rápido. Luego se suspende la comunicación entre el proxy y el antiguo nodo maestro, todas las sesiones 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. En el gráfico azul, la carga y en los escalones rojos, los momentos de escala. Las caídas a corto plazo en el cuadro azul son precisamente ese breve retraso.
Por cierto, Amazon Aurora le permite guardar y apagar completamente la base de datos cuando no está en uso, por ejemplo, el fin de semana. Después de detener la carga, la base de datos disminuye gradualmente su potencia y se apaga por un tiempo. Cuando la carga regrese, volverá a subir suavemente.
En la siguiente parte de la charla del dispositivo Amazon, hablaremos sobre el escalado de la red. Suscríbase al boletín y esté atento para no perderse el artículo.
En HighLoad ++, Vasily Pantyukhin dará una presentación: “ Houston, tenemos un problema. Diseño de sistemas con fallas, patrones de desarrollo de servicios internos en la nube de Amazon ". Lo que los desarrolladores de diseño de Amazon usan patrones de diseño de sistema distribuido, cuáles son las razones de las fallas del servicio, qué es la arquitectura basada en Celdas, Trabajo constante, Fragmentación aleatoria, será interesante. Menos de un mes antes de la conferencia: reserve sus entradas . 24 de octubre, el aumento de precio final.