Reinvención continua: una breve historia del almacenamiento en bloques de AWS
(allthingsdistributed.com)- AWS EBS comenzó como almacenamiento en bloques conectado por red para EC2 y pasó de ser un servicio basado en HDD compartidos a una flota distribuida de SSD que procesa más de 140 billones de operaciones por día
- Las limitaciones iniciales de rendimiento no solo se debían a los 120–150 IOPS de los HDD y a una latencia promedio de 6–8 ms, sino también al problema de noisy neighbor causado por varias cargas de trabajo de clientes compartiendo el mismo disco
- Con la adopción de SSD, los volúmenes Provisioned IOPS de 2012 ofrecían hasta 1,000 IOPS y una latencia promedio de alrededor de 2–3 ms, pero los cuellos de botella se trasladaron a la red, el hipervisor y las colas de software
- El equipo de EBS instrumentó toda la ruta de IO y realizó mejoras capa por capa: colas de Xen, offloading con Nitro, procesamiento de cifrado en hardware, ajuste de TCP y hasta el protocolo de transporte SRD
- Las mejoras de rendimiento avanzaron mediante migraciones sin interrupciones, cambios independientes de equipos pequeños, medición continua y mejoras incrementales con posibilidad de rollback, más que con grandes reescrituras
Del almacenamiento en bloques para EC2 a una flota de SSD a gran escala
- EBS comenzó el 20 de agosto de 2008, unos dos años después del lanzamiento beta de EC2, a partir de la idea de ofrecer almacenamiento en bloques conectado por red para instancias EC2
- En ese momento, el equipo tenía uno o dos especialistas en almacenamiento y algunos ingenieros de sistemas distribuidos, y empezó a construir el servicio con conocimientos de sistemas informáticos y redes
- Con el tiempo, EBS pasó de ser un producto de HDD compartidos a un servicio capaz de ofrecer cientos de miles de IOPS a una sola instancia EC2
- Actualmente, las IOPS que puede ofrecer a una sola instancia superan el nivel que en la etapa inicial basada en HDD se ofrecía a toda una Availability Zone
- En conjunto, EBS procesa más de 140 billones de operaciones por día en una flota distribuida de SSD
- La carga de trabajo principal son los discos de sistema de las instancias EC2; se parece a ofrecer mediante almacenamiento de red el rol que cumpliría un disco duro dentro de un servidor físico
- Los clientes valoran la durabilidad, pero consideran igual de importantes el rendimiento y la disponibilidad, que están directamente conectados con la experiencia de EC2
- Los volúmenes io2 Block Express y los snapshots de volúmenes se ofrecen como componentes básicos para lograr alta durabilidad
- El rendimiento y la disponibilidad de los volúmenes EBS se trasladan casi directamente a la experiencia de las aplicaciones basadas en EC2
Las colas y los HDD crearon las primeras limitaciones
- En los sistemas informáticos, las solicitudes de almacenamiento se procesan pasando por varias colas entre la CPU, los buses y los dispositivos
- En el almacenamiento de red aparecen varias colas entre el kernel del sistema operativo, el adaptador de almacenamiento, la fabric de almacenamiento, el adaptador de almacenamiento de destino y el medio de almacenamiento
- Cuando EBS se creó por primera vez en 2008, el mercado de almacenamiento estaba dominado principalmente por los HDD, y la latencia estaba dominada por el propio medio de almacenamiento
- Los discos duros son dispositivos mecánicos y tienen límites físicos
- Durante décadas, el rendimiento de los HDD se mantuvo aproximadamente en 120–150 operaciones por segundo, con una latencia promedio de IO de 6–8 ms
- Debido al encolamiento y al reordenamiento interno de comandos del disco, la latencia de cola podía aumentar hasta cientos de ms
- Como la latencia end-to-end de EBS en ese momento era de decenas de ms, las decenas de microsegundos adicionales de la red representaban una porción pequeña de la latencia total
- El rendimiento de los HDD se ve muy afectado por otras operaciones acumuladas en la cola
- Las solicitudes aleatorias pequeñas dispersas en el medio tardan más en buscarse y accederse que varias solicitudes grandes cercanas entre sí
- Distribuir clientes entre varios discos reducía la latencia por encima del pico de las cargas de trabajo más intensas, pero propagaba el comportamiento irregular a más clientes
- El noisy neighbor, donde una carga de trabajo afecta a otra, se convirtió en un problema de negocio importante
- AWS consideró que necesitaba un fuerte aislamiento de rendimiento para mejorar la calidad de la experiencia del cliente
- Cambiar los algoritmos de planificación de disco y distribuir las cargas de trabajo entre más spindles solo produjo pequeñas mejoras incrementales
La importancia de la instrumentación revelada tras adoptar SSD
- Hacia 2011, los SSD se volvieron más populares y empezaron a estar disponibles en capacidades que AWS podía considerar
- Los SSD no tienen movimiento físico de brazo para buscar datos; las solicitudes aleatorias son casi tan rápidas como las secuenciales, y tienen varios canales entre el controlador y los chips NAND
- EBS primero creó un nuevo tipo de servidor de almacenamiento basado en SSD y un nuevo tipo de volumen llamado Provisioned IOPS
- Lanzar un nuevo tipo de volumen no fue una tarea menor, y las cargas de trabajo que podían aprovecharlo también eran limitadas
- A diferencia de la expectativa de que cambiar HDD por SSD resolvería casi todos los problemas, el problema de noisy neighbor no desapareció automáticamente
- Provisioned IOPS, lanzado en agosto de 2012, ofrecía hasta 1,000 IOPS
- Era 10 veces más que los volúmenes EBS standard existentes
- La latencia promedio era de alrededor de 2–3 ms, una mejora de 5 a 10 veces
- El control de outliers también mejoró notablemente
- En ese momento, EBS solo tenía telemetría básica, y para decidir qué corregir hacía falta una instrumentación más detallada
- El equipo creó una forma de rastrear cada IO en varios puntos
- El initiator del cliente EBS
- La pila de red
- El motor de durabilidad del almacenamiento
- El sistema operativo
- Además del monitoreo de las cargas de trabajo de los clientes, crearon pruebas canary para verificar continuamente los impactos positivos y negativos de los cambios en cargas de trabajo bien conocidas
Mejoras divididas entre hardware y software
- La nueva telemetría mostró claramente las áreas iniciales de inversión
- Había que reducir la cantidad de colas en todo el sistema
- Había margen para reducir la complejidad de la ruta de IO del hipervisor Xen usado en EC2
- Era necesario optimizar el software de red
- El motor central de durabilidad necesitaba colocación de datos en disco, optimización de líneas de caché y adopción de un modelo de programación asíncrono
- Los problemas de rendimiento de los sistemas de AWS suelen atravesar varias capas del stack de hardware y software al mismo tiempo
- EBS movió en paralelo al equipo de servidores de almacenamiento y al equipo de clientes, con la participación de ingenieros del hipervisor de EC2 y del grupo interno de rendimiento de red de AWS
- La organización de desarrollo también se dividió como un sistema de software, con un enfoque de divide and conquer
- El equipo monolítico de desarrollo de servidores de almacenamiento se reorganizó en pequeños equipos por áreas, como replicación de datos, durabilidad e hidratación de snapshots
- Cada equipo podía iterar y aplicar cambios de forma independiente sobre la base de pruebas rigurosas
- El plan creado en 2013 no era igual a lo que EBS es hoy, pero dio una dirección
- En ese entonces no se esperaba que Amazon algún día fabricara sus propios SSD y tuviera un stack tecnológico adaptado a las necesidades de EBS
Eliminación de cuellos de botella desde Xen hasta Nitro y SRD
- Hasta fines de 2017, todas las instancias EC2 se ejecutaban sobre el hipervisor Xen
- La ruta de dispositivos de Xen tenía una ring queue donde el dominio invitado y dom0, el privileged driver domain, compartían información, y el cliente EBS se ejecutaba como un dispositivo de bloques del kernel en dom0
- Desde la instancia hasta salir del host EC2, una solicitud de IO pasaba por varias colas
- Cola del dispositivo de bloques de la instancia
- Xen ring
- Cola del dispositivo de bloques del kernel de dom0
- Cola de red del cliente EBS
- El equipo de EBS escribió varios dispositivos loopback para aislar el impacto de cada cola
- Incluso cuando la latencia del driver de dispositivo de dom0 era casi nula, se observó que, si varias instancias generaban IO al mismo tiempo, el throughput efectivo de todo el sistema se ralentizaba
- EC2 se lanzó con la cantidad predeterminada de colas de dispositivos de bloques de Xen y de entradas de cola
- Esos valores predeterminados se habían definido tomando como referencia el hardware de almacenamiento limitado del entorno de desarrollo de Xen en el pasado
- Las solicitudes de IO outstanding estaban limitadas a 64 para todo el host, no por dispositivo
- En 2013 estaba en desarrollo la primera tarjeta Nitro de offload dedicada a networking
- Trasladó el procesamiento de redes definidas por software de VPC desde el kernel de Xen dom0 a un pipeline de hardware dedicado
- Separó el plano de datos de procesamiento de paquetes del hipervisor, de modo que no fuera necesario usar ciclos de CPU de las instancias de clientes para procesar tráfico de red
- El mismo enfoque se aplicó al almacenamiento de EBS
- Se trasladó más procesamiento a hardware para reducir las colas del sistema operativo del hipervisor
- Al offloadear trabajos basados en interrupciones, se redujo el tiempo que el hipervisor dedicaba a procesar solicitudes
- La segunda tarjeta Nitro también tenía capacidades de hardware para procesar volúmenes EBS cifrados sin impacto en el rendimiento
- Separar el material de claves de cifrado del hipervisor protegió adicionalmente los datos de los clientes
- Tras mover EBS a Nitro, el cuello de botella pasó a la propia red
- Se revisaron los parámetros modernos de ajuste de TCP en centros de datos y los algoritmos de control de congestión
- En algunos casos, agregar una pequeña latencia aleatoria a las solicitudes de los servidores de almacenamiento produjo un efecto de smoothing en la red que redujo la latencia promedio y los outliers
- Estos ajustes no duraron mucho a medida que el rendimiento y la escala del sistema siguieron aumentando, y se necesitó medición y monitoreo constantes para evitar regresiones
- En 2014 comenzó el trabajo basado en Scalable Reliable Datagram (SRD), con el objetivo de lograr un enfoque mejor que TCP
- El paper relacionado es A Cloud-Optimized Transport Protocol for Elastic and Scalable HPC
- Los requisitos incluían mejor recuperación ante fallas y capacidad de desvío, además de facilidad para offloading en hardware
- En el diseño de SRD fueron importantes dos observaciones
- Podían enfocarse en el diseño de la red de los centros de datos de AWS, no en Internet en general
- En almacenamiento, es posible reordenar el orden de ejecución de las solicitudes de IO en vuelo
- Se podía evitar el costo del estricto in-order delivery de TCP y enviar distintas solicitudes por varias rutas de red para ejecutarlas cuando llegaran
- SRD se usa no solo en almacenamiento, sino también en networking
- En Elastic Network Adapter (ENA) Express, SRD mejora el rendimiento del stack TCP del invitado
- Puede aprovechar varias rutas de red y reducir el overflow y las colas en dispositivos intermedios de la red para lograr una mayor utilización de la red
Caché SSD y migración sin interrupciones
- EBS no se conformó con que solo algunos volúmenes y clientes obtuvieran mejor rendimiento, y buscó ofrecer los beneficios de SSD de forma más amplia
- En ese momento, millones de volúmenes de clientes con IOPS no provisionadas se ejecutaban en miles de servidores de almacenamiento
- Algunos de esos volúmenes todavía existen
- Descartar y reemplazar todo el hardware habría sido muy costoso
- En los chasis de los servidores había espacio libre, pero el único lugar que no interfería con el flujo de aire de enfriamiento era entre la motherboard y los ventiladores
- Los SSD eran pequeños y livianos, pero no podían quedar sueltos dentro del chasis; con ayuda de científicos de materiales y tras prueba y error, encontraron una cinta industrial hook and loop resistente al calor
- Durante varios meses de 2013, EBS instaló manualmente un SSD en cada uno de miles de servidores
- Al software se le agregó un pequeño cambio para staging de nuevas escrituras en el SSD y devolver la finalización a la aplicación, y luego hacer flush asíncrono al HDD más lento
- Este trabajo se realizó sin interrupciones para los clientes
- EBS fue diseñado desde el principio pensando en eventos de mantenimiento sin interrupciones
- Podía retargetear volúmenes EBS a un nuevo servidor de almacenamiento y actualizar o reconstruir los servidores vacíos
- La capacidad de mover volúmenes de clientes a nuevos servidores de almacenamiento resultó útil muchas veces después
- Se usó al introducir estructuras de datos más eficientes para el formato en disco
- También se usó al reemplazar hardware antiguo por hardware nuevo
- Algunos volúmenes creados en los primeros meses tras el lanzamiento de EBS en 2008 siguen activos
- Esos volúmenes probablemente hayan pasado por cientos de servidores distintos y varias generaciones de hardware
- Las actualizaciones y reconstrucciones de la flota se realizaron sin afectar esas cargas de trabajo
Enfoque de liderazgo acorde con la expansión del rendimiento
- La escala de EBS era distinta a la de una empresa pequeña o una startup, no solo en lo técnico sino también en lo organizacional
- Si un experto en sistemas participa en todas las escalaciones, revisiones de commits y revisiones de cambios de diseño, puede convertirse en un cuello de botella de rendimiento para la organización
- Para resolverlo, se experimentó no solo con el código, sino también con la forma de colaborar
- Una herramienta representativa fue el peer debugging
- Varios ingenieros observaban juntos el código y la terminal para rastrear problemas
- Encontraron un caso en el que el problema estaba en dónde y cómo se aplicaba locking para actualizar una critical data structure
- Normalmente el problema no se manifestaba, pero de vez en cuando las respuestas a solicitudes se volvían lentas, y corregirlo eliminó una causa de jitter
- Dar a los ingenieros autoridad para experimentar con seguridad, reducir obstáculos y mantener guardrails podía producir mejores resultados
Mejora continua en lugar de una gran reescritura
- Las mejoras de EBS no fueron un único cambio gigantesco, sino una sucesión de mejoras incrementales a lo largo del tiempo
- Este enfoque permitió entregar valor al cliente más rápido y ajustar la dirección incorporando lo aprendido a medida que cambiaban las cargas de trabajo de los clientes
- La experiencia de latencia de EBS mejoró desde un promedio de más de 10 ms por operación de IO hasta un IO submilisegundo consistente en los volúmenes io2 Block Express de mayor rendimiento
- Este cambio se logró sin poner el servicio offline para entregar una nueva arquitectura
- Los clientes siguen queriendo más rendimiento, y esa demanda es lo que continúa impulsando la innovación y la iteración de EBS
1 comentarios
Opiniones de Hacker News
Me da mucho gusto ver este artículo por aquí. Si te interesa aunque sea un poco los sistemas a gran escala, vale mucho la pena leerlo.
En cargas de trabajo secuenciales, los discos magnéticos modernos pueden dar más de 100 MB/s en lectura/escritura, pero en cargas completamente aleatorias de 4 kB pueden caer hasta 400 kB/s. Aunque el encolamiento y la planificación ayudan a evitar lo peor, el rendimiento real puede variar más de 100 veces según la carga, lo que hace que sea muy difícil de manejar para un sistema multi-tenant. En especial, para las lecturas no existe una salida como “simplemente escribir en otro lugar”.
Lo más importante que aprendí de Marc fue que, para saber qué está roto, primero hay que verlo bien. Él creaba visualizaciones de latencia, por ejemplo series temporales de histogramas como las del artículo, y contaba la historia a partir de esas visualizaciones, haciendo que el equipo viera de una forma totalmente distinta lo que tenía que hacer. Cada pico del histograma tenía su propia causa y su propia optimización, y si no inviertes en mirar los datos de rendimiento en profundidad y de distintas maneras, no ves eficiencias ni oportunidades.
El proyecto de retrofit de 2013, en el que se agregó un SSD a cada uno de miles de servidores, es una de mis historias favoritas de AWS. Fue posible porque, desde el principio, se diseñó pensando en eventos de mantenimiento sin interrupciones, permitiendo reasignar volúmenes EBS a nuevos servidores de almacenamiento y actualizar o reconstruir servidores vacíos. Es un buen ejemplo de que los sistemas distribuidos no son solo para escalar: también permiten tolerar fallas de servidores de forma natural y mover datos sin pérdida, haciendo posible operar a gran escala.
Dick Lyon, de Google, también aplicó el mismo enfoque en los servidores de almacenamiento de Google y, a partir de la diapositiva 62 de https://www.pdl.cmu.edu/SDI/2015/slides/DatacenterComputers...., identificó varias colas y contención de recursos como los principales cuellos de botella del almacenamiento en bloques.
Me trae viejos recuerdos. Reddit fue uno de los primeros usuarios de EBS en 2008, y nos creíamos muy listos por haber descubierto que podíamos aumentar los IOPS creando un RAID por software con 5 volúmenes EBS.
En ese entonces el rendimiento de cada volumen era muy irregular, así que levantábamos 7 u 8, les corríamos cargas de lectura/escritura y elegíamos los 5 con mejor rendimiento para unirlos con RAID por software en Linux. Cuando salía bien, conseguíamos el efecto deseado y a veces obteníamos incluso más IOPS que 5 veces un solo nodo; pero cuando salía mal, era verdaderamente horrible.
No sabíamos que, en un RAID por software, si un nodo era lento, todo el RAID avanzaba a la velocidad del volumen más lento, y el resultado parecía como si la base de datos se hubiera roto. Nos tomó tiempo descubrir que la causa era el RAID, y también era difícil sacar el nodo malo, porque el RAID por software no quería soltarlo hasta terminar de escribir en ese volumen lento.
Había que meter un nuevo volumen EBS y reconstruir el arreglo, lo cual tampoco era bueno porque quedaba limitado por los IOPS del nuevo volumen. Después dejamos de usar ese RAID por software, y en Netflix casi no usamos EBS. Le contaba a todo el que me escuchara sobre los errores que cometimos en Reddit, y Netflix, incluso antes de que yo llegara, ya se había estandarizado en usar solo discos locales.
Como anécdota curiosa, durante la gran caída de EBS en AWS yo trabajaba en Reddit y estaba viendo Netflix mientras esperaba a que EBS volviera para arreglar la base de datos. En la entrevista con Netflix pregunté: “¿Cómo sobrevivieron durante la caída de EBS?”, y me respondieron: “Ah, es que simplemente no usamos EBS”.
Me gustó leer este artículo.
Lo interesante es que, en el periodo del que habla, recuerdo que AWS sufrió una caída de aproximadamente 4 días por EBS, que afectó a EC2, EBS y RDS. Ese incidente sacudió mucho la confianza en AWS.
Como resultado hubo una reorganización, y EBS pasó a recibir una inversión mucho más profunda como servicio independiente. Esa época también coincidió con la llegada de Apple como cliente y con el fuerte crecimiento de AWS en general gracias a la adopción por parte de startups como Netflix, Zynga y Dropbox.
Estas historias técnicas y operativas son interesantes, pero la innovación tecnológica en producción es desordenada y ocurre sobre el trasfondo de necesidades de negocio reales. Ojalá pudiéramos escuchar más de esas historias también.
Pero la rueda volvió a girar y regresamos al desarrollo de funcionalidades. Siempre recordaré ese año como el de menos escalaciones durante mi tiempo ahí.
Me da curiosidad la parte que dice: “agregar una pequeña cantidad de latencia aleatoria a las solicitudes del servidor de almacenamiento redujo tanto la latencia promedio como los valores atípicos, gracias al efecto de aplanar la red”. ¿Alguien puede explicar por qué?
Si les interesa, hay una charla [0] de 2009 sobre la arquitectura interna de Amazon S3. Se preparó con base en material interno del equipo de S3, y mucho de lo que aparece ahí también influyó en la forma en que se desarrolló EBS.
[0]: https://vimeo.com/7330740
Me gustó la parte sobre cómo en 2013 agregaron SSD manualmente a todos los equipos de EBS. Viendo la foto, se parece bastante a un SSD SATA de Samsung
https://www.allthingsdistributed.com/images/mo-manual-ssd.pn...
Tal vez mi memoria me falle, pero creo que usar SSD instalados en blades Dell venía desde mucho antes. Entre 2010 y 2012, más o menos, el rendimiento de I/O era un tema enorme, y fue la época en que se estaba pasando de discos duros giratorios a memoria flash
Recuerdo haber experimentado con dispositivos basados en flash en bruto, sin ningún tipo de manejo de errores ni nivelación de desgaste. Era una locura, pero todos estaban desesperados por el enorme salto en rendimiento de I/O que se obtenía al pasar de discos giratorios a silicio
La velocidad de los discos aumentó tan rápido que el primer SKU quedó obsoleto en seis meses. Me alegra no haber tenido que explicarle personalmente al equipo de activos por qué retirábamos esos racks varios años antes de lo planeado. El valor de esas ubicaciones de rack era mucho mayor si poníamos modelos nuevos, más densos y rápidos
Me recuerda la época en que construíamos infraestructura de almacenamiento como servicio antes de que hubiera open source utilizable. Dejamos atrás Sun SAN, Fibre Channel y Solaris para pasar a GlusterFS sobre servidores de almacenamiento Supermicro con Linux y NFS, y antes de irme en 2007 ya estábamos cerca de los 2 PB
También recuerdo los tiempos en que simplemente tenía sentido romper y reconstruir mdraid a escondidas, con el servidor en ejecución, cambiando discos giratorios por SSD. SATA admitía hasta cierto punto el hot swap de unidades. Al pasar de discos giratorios a SSD, las IOPS del sistema más importante de la plataforma aumentaron 14 veces
Al inicio de mi carrera trabajé cubriendo sistemas de punta a punta en una empresa de internet que era grande en escala técnica y operativa, no en cantidad de personal. La cantidad de lecciones que aprendí en poco tiempo fue absurda. Después de dejar esa empresa, me di cuenta de que la mayoría de la gente casi nunca se enfrenta a esos problemas durante toda su carrera, y por eso tampoco aprende esas lecciones
Por eso creo que debería existir un sistema de certificación profesional. Si se exigiera un aprendizaje bajo ingenieros experimentados, se podrían adquirir en poco tiempo conocimientos y habilidades muy valiosos que solo se aprenden con la experiencia, y luego trabajar de forma mucho más efectiva. Para quien entrevista candidatos, la evidencia de experiencia y la recomendación de un mentor también serían muy valiosas
Me gustó esta frase
“El ideal tan celebrado del ingeniero full-stack también tiene valor, pero en sistemas profundos y complejos, a menudo es más valioso formar un grupo de expertos que puedan colaborar y trabajar creativamente a través de todo el stack y de sus respectivas áreas de especialización profunda”
El primer diagrama del artículo es inexacto o bastante antiguo. En las computadoras modernas, la mayoría de los carriles PCIe se conectan directamente al hub de I/O de la CPU o al área Uncore, en lugar de pasar por un PCH separado como antes
Esto es un avance importante tanto para el throughput de I/O como para la latencia. Por lo demás, es un artículo excelente y muestra muy bien que, al final, todo son colas
Voy a dejar claro en el pie de imagen que la estructura corresponde a esa época