217 подписчиков

💾 Как AWS S3 выдаёт петабайт в секунду с «медленных» HDD

25 сентября 202525 сен 2025

2 мин

Сегодня мы привыкли думать о жёстких дисках (HDD) как о наследии прошлого — медленные, шумные, с крошечным числом IOPS и механическими ограничениями. Но AWS сумела превратить миллионы таких дисков в основу S3, одного из самых масштабных хранилищ данных в мире, которое обрабатывает 1 ПБ/с трафика и 150 миллионов запросов в секунду. Это инженерное чудо, и в его основе не дорогие SSD, а продуманная архитектура. HDD застряли на ~120 IOPS за последние 30 лет — это физический предел из-за механики: 👉 В сумме: одно случайное чтение занимает ~11 мс, что даёт лишь 45 МБ/с на диск при случайном доступе. Решение AWS: использовать HDD только по их сильной стороне — последовательной записи, а слабости компенсировать массивным параллелизмом и кодированием. Эта трёхуровневая схема превращает миллионы медленных дисков в один гигантский «виртуальный SSD». Мне кажется, архитектура S3 — это лучший пример «силы количества» в инженерии. Вместо того чтобы строить систему на дорогих SSD, AWS использует то,

Оглавление

⚙️ Ограничения HDD, превращённые в преимущество
📜 Запись: S3 как «Kafka для дисков»
📖 Чтение: параллелизм и эратур-кодирование

⚙️ Ограничения HDD, превращённые в преимущество

HDD застряли на ~120 IOPS за последние 30 лет — это физический предел из-за механики:

⚙️ Seek — перемещение головки (≈4 мс в среднем).
🔄 Rotational latency — ожидание вращения до нужного сектора (≈4 мс).
⚡ Transfer — чтение/запись данных (≈2,5 мс на 0,5 МБ).

👉 В сумме: одно случайное чтение занимает ~11 мс, что даёт лишь 45 МБ/с на диск при случайном доступе.

Решение AWS: использовать HDD только по их сильной стороне — последовательной записи, а слабости компенсировать массивным параллелизмом и кодированием.

📜 Запись: S3 как «Kafka для дисков»

📝 Используется log-structured merge tree (LSM) — данные пишутся последовательно, что идеально для HDD.
📦 AWS, вероятно, использует батчинг (как Kafka), чтобы минимизировать количество seek-операций.
🎯 Результат: запись дешёвая и быстрая, несмотря на механические ограничения.

📖 Чтение: параллелизм и эратур-кодирование

🔢 AWS применяет Erasure Coding (5-of-9): объект разбивается на 9 шардов, из которых достаточно 5 для восстановления.
💾 Это экономичнее тройной репликации (1,8x вместо 3x) и даёт 9 точек чтения вместо 3.
🌐 Файл в 1 ТБ, разбитый на 20 000 дисков, можно читать с суммарной скоростью всех дисков → терабайты в секунду.

🔀 Балансировка нагрузки

🎲 Power of Two Random Choices — данные при записи отправляются на случайные наборы дисков, что исключает «горячие точки».
♻️ Rebalancing — данные регулярно перетасовываются, особенно при добавлении новых стоек (каждая ≈20 ПБ).
🧊 Chill@Scale — чем больше система, тем предсказуемее нагрузка: пики усредняются за счёт мультиарендности.

📡 Параллелизм на всех уровнях

👨‍💻 Клиент — multipart upload/byte-ranged GET (файл дробится и качается частями).
🌍 Серверы фронтенда — пул соединений вместо одного «горла бутылки».
💽 Диски — данные размазаны по миллионам HDD.

Эта трёхуровневая схема превращает миллионы медленных дисков в один гигантский «виртуальный SSD».

💡 Моё мнение

Мне кажется, архитектура S3 — это лучший пример «силы количества» в инженерии. Вместо того чтобы строить систему на дорогих SSD, AWS использует то, что массово доступно и дёшево, но умножает это на миллионы узлов.

Это напоминает философию распределённых систем:

Каждый элемент слаб, но вместе они образуют устойчивую и быструю структуру.
Ошибки отдельных дисков не важны, пока есть избыточность.
Масштаб парадоксально делает систему надёжнее и предсказуемее.

Неудивительно, что сегодня всё больше проектов в аналитике и ML строятся прямо поверх S3: оно стало новым уровнем абстракции для хранения, где инженерия Amazon скрыла всю сложность за простыми API.

🔗 Источники: