Cómo AWS S3 procesa 1 petabyte por segundo sobre HDD lentos

 (bigdata.2minutestreaming.com)
19 puntos por GN⁺ 2025-09-27 | 2 comentarios | Compartir por WhatsApp
  • AWS S3 es un servicio de almacenamiento de objetos multitenant a gran escala que ofrece alta disponibilidad y durabilidad a bajo costo
  • Aunque utiliza HDD antiguos y lentos (≈120 IOPS), maximiza la economía de un medio de almacenamiento ultrabarato y de gran capacidad
  • S3 diseña su capa de almacenamiento interna (ShardStore) con una estructura log-structured (LSM) para ajustar la ruta de escritura al I/O secuencial, y compensa los problemas de rendimiento en la ruta de lectura con Erasure Coding (5-of-9) y paralelización masiva
  • En todo el recorrido entre cliente, frontend y almacenamiento, reduce la latencia de cola y suma throughput con multipart upload, GET por rango de bytes, connection pooling y solicitudes hedge
  • Con distribución aleatoria, Power of Two Random Choices, rebalancing continuo y decorrelación que aplana la carga a mayor escala, evita hotspots y logra en resultado un throughput de >1 PB/s

Arquitectura de almacenamiento a gran escala de AWS S3

  • Casi todo el mundo sabe qué es AWS S3, pero pocos conocen la enorme escala a la que opera S3 y las innovaciones que lo hicieron posible
  • S3 es un servicio de almacenamiento de objetos multitenant y escalable que permite guardar y recuperar objetos mediante API, y ofrece disponibilidad y durabilidad muy altas a un costo relativamente bajo

  • Escala de S3

    • Almacena más de 400 billones de objetos
    • Procesa 150 millones de solicitudes por segundo
    • Soporta más de 1 PB/s de tráfico en picos
    • Opera decenas de millones de discos duros
  • Presenta como base de la experiencia del usuario una alta disponibilidad y durabilidad (objetivo de diseño de “11 nueves”), junto con un costo relativamente bajo
    • Incluso se ha expandido hasta convertirse en la capa de almacenamiento base para analítica de datos y data lakes de machine learning
  • El objetivo de diseño es manejar patrones de acceso aleatorio y concurrencia masiva manteniendo eficiencia de costos
    • S3 asume cargas de trabajo de acceso aleatorio colectivas en las que cada tenant accede con tamaños y offsets arbitrarios

Tecnología base: discos duros (HDD)

  • La sorprendente escalabilidad y el rendimiento de S3 se sustentan en el medio de almacenamiento tradicional: los HDD
  • Los HDD son una tecnología antigua con alta durabilidad, pero tienen límites en IOPS y latencia debido al movimiento físico
    • Como dependen de movimiento mecánico —rotación por segundo (por ejemplo, 7200 RPM) y búsqueda del actuador—, la latencia es estructuralmente alta e inevitable
    • Búsqueda media de media pista ≈4 ms, media rotación ≈4 ms, transferencia de 0.5 MB ≈2.5 ms → una lectura aleatoria promedio de 0.5 MB ≈11 ms, con throughput aleatorio por disco de alrededor de ≈45 MB/s
  • A diferencia de los SSD, siguen siendo útiles para almacenamiento a gran escala gracias a una curva de largo plazo de más capacidad y menor precio, que asegura una economía “ultrabarata / de gran capacidad”
    • Precio: caída de 6 mil millones de veces por byte (ajustado por inflación)
    • Capacidad: aumento de 7.2 millones de veces
    • Tamaño: reducción de 5 mil veces
    • Peso: reducción de 1,235 veces
  • Sin embargo, durante 30 años los IOPS se han estancado en alrededor de 120, y el rendimiento y la latencia de acceso aleatorio no han mejorado mucho
  • Los SSD son favorables para I/O aleatorio, pero en almacenamiento a escala peta y exa son desfavorables en términos de costo total de propiedad (TCO)

Ruta de escritura optimizada para I/O secuencial

  • Los HDD están optimizados para acceso secuencial: cuando se leen o escriben bytes contiguos, el platter del disco gira naturalmente y permite procesar datos con rapidez
  • Las estructuras de datos basadas en log (log-structured) aprovechan esta característica secuencial
    • ShardStore, la capa de almacenamiento interna de S3, adopta una LSM log-structured para manejar las escrituras como append secuencial en disco
    • De forma similar, el procesamiento por lotes permite maximizar el throughput secuencial del disco

Paralelización y Erasure Coding para la ruta de lectura aleatoria

  • En lectura, las solicitudes del usuario provocan saltos a posiciones arbitrarias (aleatorias), por lo que se enfrentan directamente a esos límites físicos (la latencia promedio del I/O aleatorio es de unos 11 ms)
    • Un HDD puede procesar como máximo 45 MB/s con I/O aleatorio
    • Por eso, aunque los HDD son muy rentables para almacenar grandes volúmenes de datos, su rendimiento de acceso aleatorio es bajo
  • Para superar esta limitación física, S3 adopta paralelización masiva, distribuyendo los datos en muchos discos y leyendo en simultáneo para agregar throughput
    • Los datos se distribuyen en muchísimos HDD y se usa en paralelo la entrada/salida de cada disco para elevar mucho el throughput total
    • Por ejemplo, si un archivo de 1 TB se divide y almacena en 20 mil HDD, se puede leer a escala de TB/s al sumar el throughput de todos los discos

Erasure Coding

  • En los sistemas de almacenamiento es indispensable garantizar redundancia
  • S3 usa Erasure Coding (EC) para dividir los datos en K fragmentos y M fragmentos de paridad
    • De un total de K+M, basta con cualquier K para reconstruirlos
  • S3 encuentra un punto de equilibrio con Erasure Coding (5-of-9) usando una estructura de 9 partes (5 shards de datos y 4 shards de paridad)
    • 5 de datos + 4 de paridad = 9 fragmentos
    • Puede reconstruir incluso con la pérdida de hasta 4 shards, ofreciendo tolerancia a fallos porque bastan cualesquiera 5 fragmentos para recuperar el original
    • El overhead de almacenamiento es de ≈1.8x, más eficiente en capacidad que la replicación triple (3x)
    • Al mismo tiempo, asegura 5 rutas de lectura en paralelo, lo que favorece la paralelización por shard y evitar stragglers
  • Así, S3 supera esa limitación física y ofrece acceso aleatorio a datos a gran escala

Estructura de procesamiento en paralelo

  • S3 usa 3 formas principales de paralelización
    • 1. El usuario divide los datos en varios chunks para subirlos y descargarlos
    • 2. El cliente hace solicitudes simultáneas a varios servidores frontend
    • 3. El servidor distribuye los objetos entre varios servidores de almacenamiento

  • 1. Procesamiento en paralelo a nivel de servidor frontend

    • Usa un pool interno de conexiones HTTP para conectarse simultáneamente a múltiples endpoints distribuidos
    • Evita sobrecargar nodos específicos de infraestructura o caché

  • 2. Procesamiento en paralelo entre discos duros

    • Con base en EC, distribuye los datos en shards pequeños sobre múltiples HDD

  • 3. Procesamiento paralelo de solicitudes PUT/GET

    • El cliente divide los datos en varias partes para subirlos en paralelo
    • PUT: maximiza el paralelismo de escritura nueva con multipart upload
    • GET: soporta GET por rango de bytes (permite leer solo una parte del objeto)
  • Al distribuir y procesar en paralelo, es posible lograr sin dificultad incluso cargas de 1 GB/s

Prevención de hotspots

  • S3 opera en un entorno de decenas de millones de discos, cientos de millones de solicitudes por segundo y cientos de millones de shards en paralelo
  • Si la carga se concentra en un disco o nodo específico, existe el riesgo de degradar el rendimiento del sistema completo
  • Estrategias clave para evitarlo:
    • 1. Distribución aleatoria de la ubicación de los datos
    • 2. Rebalancing continuo
    • 3. Expansión de la escala del sistema

  • 1. Shuffle sharding & Power of Two

    • La ubicación inicial de los datos se distribuye aleatoriamente
    • Se aplica el algoritmo Power of Two Random Choices:
      • Elegir el nodo menos cargado entre dos nodos aleatorios permite un balanceo de carga muy efectivo

  • 2. Rebalancing

    • Temperatura de los datos: aprovechando que los datos nuevos son más calientes (se accede más a ellos), el rebalancing periódico redistribuye espacio e I/O
      • A medida que los datos envejecen, disminuye su frecuencia de acceso y aumenta el margen de I/O en todo el almacenamiento
    • S3 redistribuye datos fríos para maximizar el uso del espacio y los recursos
    • Cuando se incorpora un rack nuevo (por ejemplo, 20 PB/rack, 1000×20 TB), se necesita distribución activa hacia esa capacidad vacía

  • 3. Chill@Scale

    • Efecto de escala: cuanto más independientes son las cargas de trabajo, menor es la concurrencia en ráfagas, lo que produce decorrelación y aplana la carga agregada
    • Cuanto más grande es el sistema, más se reducen las diferencias entre pico y promedio y mejora la predictibilidad
    • Es decir, aunque el uso repita ciclos de auge y reposo, a gran escala estos se compensan entre sí y la carga se mantiene predecible

Cultura operativa, confiabilidad y otras técnicas

  • Con shuffle sharding a nivel DNS, busca aislamiento entre tenants y distribución uniforme desde la capa del resolvedor de nombres
  • El despliegue de software también se realiza de forma gradual y sin interrupciones, como con EC, y la transición de ShardStore avanzó sin impacto en el servicio
  • Cultura de durabilidad: confiabilidad basada en procesos mediante detección continua de fallas, chain of custody, modelado de amenazas a la durabilidad y verificación formal, entre otros

Por qué importa: tendencias de infraestructura de datos sobre S3

  • Con la expansión de la arquitectura stateless, crece el patrón donde los nodos de aplicación descargan su estado y delegan persistencia, replicación y balanceo de carga a S3
    • Ejemplos: Kafka Diskless (KIP-1150), SlateDB, Turbopuffer, Lucene on S3, e integración de object storage en ClickHouse/OpenSearch/Elastic
  • Las ventajas son escalado elástico, operación más simple y reducción de costos; la desventaja es el posible aumento de latencia, por lo que cada workload debe diseñar el trade-off entre latencia, costo y durabilidad

Resumen

  • AWS S3 es un servicio de almacenamiento multitenant a gran escala que supera las limitaciones de medios lentos mediante paralelismo masivo, balanceo de carga y data sharding
  • Asegura estabilidad y rendimiento con Erasure Coding, distribución aleatoria, rebalancing continuo y solicitudes hedge
  • Al principio se centraba en backup y medios, pero evolucionó hasta convertirse en el almacenamiento principal de infraestructura de big data, como analítica de datos y machine learning
  • La arquitectura basada en S3 permite escalabilidad stateless y delegar eficazmente a AWS los problemas de durabilidad, replicación y balanceo de carga
  • Esto también aporta reducción de costos en la nube y mayor eficiencia operativa

Lecturas relacionadas

2 comentarios

 
shakespeares 2025-10-05

Parece que no sería rentable si la tecnología no fuera buena.
 
GN⁺ 2025-09-27
Opinión de Hacker News

  • Hay algunos errores de hecho, pero no afectan demasiado el hilo general del artículo. Por ejemplo, la afirmación de que S3 usa un esquema de sharding 5:9; en realidad S3 usa varios esquemas de sharding y, hasta donde sé, 5:9 no es uno de ellos. La proporción de 1.8 bytes físicos por 1 byte lógico es realmente mala desde la perspectiva del costo de HDD. Sí existen formas de reducir más esa proporción, ampliando el paralelismo y mejorando la disponibilidad. Por ejemplo, hay que pensar cuántos shards se pueden perder antes de que un objeto quede imposible de obtener con GET cuando una AZ completa se cae

    • Entendí en este video, en el minuto 42:20, que S3 usa ese esquema de sharding. Si sabes más al respecto, me interesa

    • Me cuesta verlo de forma intuitiva: bajar la proporción de 1.8x y al mismo tiempo aumentar la disponibilidad. Si hay menos réplicas, ¿no crece el riesgo de pérdida de datos ante una falla de AZ? Yo entendía que AWS ofrecía réplicas completamente independientes en 3 AZ. Y todavía me sorprende la explicación de que, para leer un chunk de 16MB, en realidad sea más rápido leer 4MB desde 5 discos duros distintos

    • VAST Data usa un esquema 146+4. (enlace)

  • Disfruté leer este texto, pero la respuesta a la pregunta del título es demasiado obvia: paralelismo

    • Normalmente casi nunca pienso en la velocidad de I/O de almacenamiento a esa escala. Hace mucho usé RAID0 para escribir más rápido en discos duros, pero eso fue hace años. Al principio pensé que usarían algo interesante como caché o tiering. Solo después de leerlo caí en que el paralelismo era la respuesta obvia, aunque no había pensado en los detalles de implementación de S3 ni en la corrección de errores. La palabra clave es paralelismo, pero los detalles me parecieron muy reveladores. Supongo que minio también tendrá una historia de escalabilidad parecida: otra vez, paralelismo

    • Creo que el título del artículo confunde un poco porque solo se enfoca en el throughput pico de S3 en su conjunto. La pregunta realmente interesante sería: "¿cómo es posible un throughput de GET que supere el throughput máximo de un HDD?" Si fuera simple replicación, puedes asignar varios HDD y paralelizar los GET, así que desde la perspectiva de S3 total el throughput sube, pero al final seguirías limitado por el throughput individual de cada HDD * la cantidad de requests GET. El punto secreto e interesante es que S3 no tiene esa limitación

    • Si juntas millones de discos duros, obtienes un ancho de banda de IO enorme

    • Suena como una lógica tipo "la forma de llegar a la luna es obvia: viajar"

  • full-platter seek time: ~8ms; half-platter seek time (avg): ~4ms
    En promedio, si dos puntos están distribuidos uniformemente en el intervalo [0,1], el valor esperado de su distancia no es 0.5 sino 1/3. Si el tiempo de seek de platter completo es 8ms, entonces el tiempo de seek promedio es 2.666ms

    • En discos modernos, un seek completo está más cerca de 25ms que de 8ms. Si quieres probarlo tú mismo y tienes un disco duro y permisos de root, puedes usar fio con la opción --readonly y hacer lecturas alternadas en ambos extremos del disco. También hay un buen paper(aquí) que explica por qué ese valor de 1/3 no es exacto en discos modernos. Si tienes más preguntas sobre mecánica o rendimiento de disk drives, puedo responder

    • Al moverse entre tracks, el cabezal acelera. Cuanto más corta es la distancia, menor es la velocidad máxima, y también hay latencias constantes como el tiempo de asentamiento, así que en la práctica el promedio puede ser 4ms

    • Como el platter es circular, no deberías usar una distribución uniforme en [0, 1] sino la distribución de un círculo unitario en [0, 2π], y como el platter gira en una sola dirección, la distancia siempre debe calcularse solo en sentido horario.
      Simplificando el problema: si el punto de inicio está en 0 grados y el objetivo es un punto aleatorio, ¿cuál es la distancia promedio? Como los arcos 0-180 grados y 180-360 grados tienen la misma longitud, la distancia promedio es 180 grados. Es decir, el half-platter seek es exactamente la mitad del full-platter seek

  • Si quieres estimar si S3 todavía usa HDD como servicio base, se puede inferir viendo el precio y convirtiéndolo en términos de IOPS. El costo por requests GET/PUT de S3 es lo bastante alto como para que AWS pueda darse el lujo de dejar capacidad de disco sin usar para tenants de alto rendimiento. Pero no mucho más que eso

  • Me pregunto si una parte de S3 opera sobre SSD. Yo pensaba que incluso el S3 estándar estaría basado en SSD y que solo las capas lentas usarían HDD o sistemas más lentos

    • El KeyMap Index de S3 usa SSD. A estas alturas, supongo que los SSD ya forman parte del caché de objetos calientes o de alguna parte del nuevo producto one zone

    • Es muy probable que los datos almacenados realmente estén casi todos en HDD. Pero supongo que metadatos, índices y similares usan almacenamiento flash mucho más rápido. Los servidores MDS de clústeres Ceph pequeños suelen funcionar así, y S3 opera a una escala muchísimo mayor

    • Ya lo mencioné una vez arriba, pero en el tier estándar el costo por request es lo bastante alto como para que, incluso si un cliente tiene una proporción alta de IOPS/TB, siga siendo rentable dejar ociosa parte de la capacidad del disco. Pero más caro que eso ya no conviene. Los HDD modernos almacenan alrededor de 30TB, y aunque no sé cuánto paga AWS realmente, calculo algo en el rango de 300 a 500 dólares. Sigue siendo mucho más barato que un SSD de 30TB. Además, estos HDD pueden montarse en sistemas de alta densidad (por ejemplo, 100 drives en 4U) con solo un 25% adicional en costo total. En cambio, los chasis que soportan grandes cantidades de SSD tienen un costo por slot mucho más alto

    • Supongo que S3 Express One Zone sí debe estar basado en SSD. Pero no parece que Amazon lo haya confirmado públicamente

    • Doy por hecho que los metadatos sí se guardan en SSD. Y es posible que los objetos calientes, leídos con frecuencia, se cacheen en SSD

  • Me sorprende que, aunque el precio de los HDD siga bajando, la tarifa de S3 haya sido la misma durante al menos 8 años. La falta de competencia en rebajas de precio ha mantenido una estructura de tarifas alta. Da para imaginar cuánto beneficio le deja esto a AWS

    • La política de precios de AWS es parecida en todos sus servicios. Por ejemplo, una instancia EC2 m7a.medium cuesta 50 dólares al mes on-demand y 35 dólares con reserva de 1 año. Incluso comparada con servicios de otras empresas con especificaciones similares, no destaca por ser competitiva

    • También hay que considerar la inflación, así que aunque la tarifa nominal sea igual, en términos reales sí ha bajado. Aun así, coincido en que la inflación se refleja mucho más lento que el avance tecnológico

    • Creo que reducir costos no es el objetivo de los incentivos. Si ves empresas como Splunk o CrowdStrike, que almacenan cantidades enormes de datos en AWS, hay muchísimos datos repetitivos; simplemente trasladan el cobro al cliente y aplican una deduplicación mínima. Si bajas costos, en realidad generas el incentivo de aumentar todavía más un uso innecesario

    • Me pregunto si la caída en el precio de los HDD realmente ha sido tan grande. En los últimos años, la velocidad de caída del precio por GB de los discos duros se ha desacelerado bastante, así que parece probable que pronto los SSD los alcancen

  • Como lectura aún más interesante sobre S3, recomiendo "Building and operating a pretty big storage system called S3"

  • Me da curiosidad cuál será el rendimiento real de rustfs

  • Al ver la mención de que se usan decenas de millones de HDD, se puede estimar que la capacidad total de AWS S3 está en el rango de cientos de exabytes, si asumimos discos enterprise de 10~20TB. Probablemente sea el sistema de almacenamiento más grande del planeta

    • Si el hardware se actualizó desde 2013, cierto centro de datos en Utah podría superar esa capacidad (artículo relacionado)

    • Los HDD enterprise actuales son de 30TB, y pronto podrían llegar incluso a 50TB

  • Me gustaría conocer un servicio open source optimizado para HDD que logre un rendimiento similar. Los proyectos principales (MinIO, Swift, Ceph+RadosGW, SeaweedFS) recomiendan despliegues solo con flash. Últimamente estoy viendo un proyecto llamado Garage, pero su diseño es bastante distinto, por ejemplo no usa EC

    • Ceph+RadosGW también funciona bastante bien con HDD. Solo que el pool de índices debe ir en SSD y hace falta una visión realista de cuántos IOPS puedes esperar del pool HDD. Del lado del cliente, los IOPS terminan multiplicándose varias veces en la práctica, y S3 resuelve eso con muchísimos HDD. Para almacenamiento masivo de streaming de 4MB no es un gran problema, pero si haces muchas lecturas y escrituras aleatorias de claves pequeñas, o mucho acceso distribuido sobre una sola clave, el rendimiento del backend sí importa

    • Lustre/ZFS también puede lograr velocidades similares. Pero si necesitas IOPS altos, en el caso de Lustre hace falta flash en el MDS, y en ZFS un SSD dedicado para logs

    • Todos estos servicios solo logran el mismo rendimiento si tienen muchos drives a escala de gran data center. Muy pocas instalaciones pueden manejar ese nivel de escala. Por eso el flash es más eficiente, en términos de espacio/costo, para acceso rápido

    • SeaweedFS ha mejorado mucho en los últimos años y ya incorporó soporte para RDMA y también EC

    • En un trabajo anterior operábamos almacenamiento de objetos basado en SwiftStack, con metadatos en SSD y datos de objetos en HDD comunes. Funcionaba bastante bien