Reinvención continua: una breve historia del almacenamiento en bloques de AWS

Reinvención continua: una breve historia del almacenamiento en bloques de AWS

• Introducción

  • Marc Olson ha trabajado en el equipo de Elastic Block Store (EBS) durante más de 10 años.
  • EBS evolucionó de un simple servicio de almacenamiento en bloques a un sistema de almacenamiento en red a gran escala que procesa más de 140 billones de operaciones al día.
  • Este artículo comparte el proceso de evolución de EBS y las lecciones clave.

• Historia temprana de EBS

  • EBS se lanzó el 20 de agosto de 2008 y comenzó con una idea simple: ofrecer almacenamiento en bloques conectado por red para instancias de EC2.
  • Al principio usaba unidades de disco duro compartidas (HDD), y hoy puede ofrecer cientos de miles de IOPS a una sola instancia de EC2.
  • Actualmente, EBS procesa más de 140 billones de operaciones al día mediante una flota distribuida de SSD.

• Teoría de colas

  • La forma en que los sistemas informáticos interactúan con el almacenamiento no ha cambiado de manera fundamental.
  • La CPU coloca solicitudes en una cola, y el dispositivo de almacenamiento toma los datos de la memoria de la CPU para guardarlos en un medio duradero o, a la inversa, los transfiere de vuelta a la memoria de la CPU.
  • La teoría de colas desempeña un papel importante para entender este proceso.

• La transición de HDD a SSD

  • El EBS inicial usaba HDD, lo que limitaba el rendimiento por sus restricciones físicas.
  • Con la llegada de los SSD, incluso las solicitudes aleatorias pudieron procesarse casi tan rápido como las secuenciales.
  • En 2012 se lanzaron un nuevo tipo de servidor de almacenamiento basado en SSD y un nuevo tipo de volumen de EBS llamado Provisioned IOPS.

• Medición y gestión

  • En 2012, EBS solo contaba con telemetría básica.
  • Para mejorar el rendimiento del sistema, era necesario identificar qué estaba fallando y resolverlo según prioridades.
  • Se construyeron métodos para medir IO en varios subsistemas y detectar cambios mediante monitoreo continuo.

• Dividir y conquistar en la organización

  • El equipo de servidores de almacenamiento de EBS se reorganizó en equipos pequeños enfocados en áreas específicas como replicación de datos, durabilidad e hidratación de snapshots.
  • Cada equipo podía iterar y hacer commits de cambios de manera independiente.

• Cuestionar las suposiciones

  • Se descubrió que la configuración predeterminada del hipervisor Xen estaba limitando el rendimiento.
  • Se usaron tarjetas de offload Nitro para descargar al hardware el procesamiento de red y almacenamiento.

• Experimentos de ajuste de red

  • Al mover EBS a Nitro, aumentó la sobrecarga de la propia red.
  • Se desarrolló el protocolo SRD (Scalable Relatable Diagram) en lugar de TCP para mejorar el rendimiento de red.

• Las restricciones impulsan la innovación

  • Para ofrecer a todos los clientes las ventajas de los SSD, se añadieron SSD sin reemplazar el hardware existente.
  • Los SSD se agregaron manualmente a los servidores, las nuevas escrituras se guardaban en SSD y luego se vaciaban de forma asíncrona a HDD.

• Reflexiones sobre la expansión del rendimiento

  • Una historia de crecimiento personal: la transición de una cultura de empresa pequeña a una organización de gran escala.
  • Las sesiones de depuración entre colegas ayudaron a resolver problemas y a mejorar la eficiencia del equipo.

• Conclusión

  • EBS ha evolucionado no por un solo cambio masivo, sino mediante una serie de mejoras graduales.
  • Las necesidades de los clientes seguirán creciendo, y eso impulsa la innovación y la iteración continuas.

# Resumen de GN⁺

• Este artículo ofrece la perspectiva de alguien interno sobre cómo ha evolucionado EBS de AWS.
• Aborda diversos retos técnicos y sus soluciones, como la teoría de colas, la adopción de SSD y el ajuste de red.
• Destaca la importancia de la medición y la gestión continuas para mejorar el rendimiento.
• Productos con funciones similares incluyen Google Cloud Persistent Disk y Microsoft Azure Disk Storage.

[GN⁺]

Opiniones de Hacker News

• Si te interesan los sistemas grandes, vale la pena leer este artículo

  • El rendimiento del disco duro depende de las otras transacciones en la cola
  • En cargas aleatorias de 4 kB, el rendimiento puede caer mucho
  • El encolado y la planificación ayudan, pero el rendimiento real puede variar más de 100 veces según la carga de trabajo
  • En sistemas multiinquilino hay dificultades, especialmente en las operaciones de lectura

• Para resolver un problema, hay que saber qué está saliendo mal

  • La lección más importante que aprendí de Marc fue cambiar la perspectiva del equipo mediante visualizaciones
  • Si analizas los datos de rendimiento de varias maneras, puedes descubrir eficiencias y oportunidades que no se ven a simple vista

• El proyecto de instalar SSD en los servidores de EBS en 2013 es una de las historias interesantes de AWS

  • Desde el principio, el sistema se diseñó pensando en eventos de mantenimiento no disruptivo
  • Si construyes un sistema distribuido, puedes operar a gran escala

• La caída de AWS durante casi 4 días fue causada por EBS, y eso sacudió la confianza en AWS

  • Esto llevó a una mayor inversión en EBS
  • Coincidió con la época en que Apple se estaba convirtiendo en cliente

• Reddit fue uno de los primeros usuarios de EBS en 2008

  • Intentó aumentar los IOPS usando RAID por software, pero el rendimiento no era consistente
  • Tomó tiempo resolver los problemas de RAID
  • Netflix no usaba EBS

• Agregar latencia aleatoria tiene el efecto de reducir la latencia promedio y los valores atípicos

• Se aprendieron muchas lecciones trabajando en grandes empresas de internet

  • A través del aprendizaje práctico se pueden adquirir rápidamente conocimientos y habilidades importantes
  • Durante las entrevistas, la experiencia y la recomendación de un mentor son muy útiles

• Fue interesante la parte en la que en 2013 instalaron manualmente SSD en todas las unidades de EBS

  • Entre 2010 y 2012, el rendimiento de I/O era un tema importante

• En 2009 dio una charla sobre el interior de Amazon S3

  • Esa charla influyó en el desarrollo de EBS

• En los inicios de la nube se usaba hardware de propósito general, pero ahora se usa hardware especializado para servicios individuales

  • AWS usa chips Graviton, Inferentia y Tranium
  • Google usa TPU y la tarjeta de seguridad Titan
  • Azure usa FPGA y Sphere

• El primer diagrama está mal o está desactualizado

  • En las computadoras modernas, la mayoría de los carriles PCIe se conectan directamente al CPU
  • Este es un avance importante para el rendimiento y la latencia de I/O

• Está buscando la mejor manera de proporcionar un directorio de dataset rápido de 256 GB a nuevas instancias de EC2

  • Está usando volúmenes EBS, pero las actualizaciones son engorrosas
  • EFS es demasiado lento
  • El SSD de almacenamiento de instancia es efímero
  • Aún no ha probado FSx Lustre con