Блочное и файловое хранилище: EBS, EFS и instance store
EBS, EFS и instance store — три модели подключения, а не три скорости. EBS — блок одной AZ для одного инстанса; EFS — NFS на много AZ для многих; instance store — эфемерный локальный NVMe, который можно потерять. Выбирай по подключению и долговечности, а не по сырым IOPS.
Команда гоняет самостоятельно поднятый Postgres на инстансе i3, потому что «локальный NVMe безумно быстрый» — и он правда такой: сотни тысяч IOPS при микросекундной латентности. Два года ни одного промаха. Потом плановая чистка по оптимизации затрат помечает инстанс как избыточный, и инженер жмёт Stop, собираясь уменьшить размер и запустить обратно. Stop криптографически стирает каждый блок instance store. Том возвращается пустым. Снапшота не было, потому что instance store снапшотить нельзя, а ночной логический дамп тихо падал три недели подряд. Быстрый диск никогда не был проблемой. Проблема в том, что «быстрый локальный диск» и «долговечные данные» — это разные оси, и команда поставила production-базу на том, который платформа намеренно проектирует как выбрасываемый. Выбор хранилища в AWS — сначала про подключение и долговечность, и только потом про скорость.
Блок против файла против объекта, затем три сервиса
Прежде чем выбрать сервис, нужно понять, какую абстракцию ты вообще покупаешь — потому что подключить не ту к своей нагрузке — ровно так команды получают быстрый диск, который стирает себя сам, или файловую систему там, где должен стоять том базы.
В каждом дизайне AWS всплывают три абстракции хранения. Блочное хранилище отдаёт ОС сырые блоки фиксированного размера; ОС кладёт сверху файловую систему (ext4, xfs), и устройство выглядит как локальный диск, с которого можно грузиться и держать базу. Файловое хранилище отдаёт общее иерархическое пространство имён по сетевому протоколу (NFS, SMB), так что многие машины монтируют одно дерево и видят записи друг друга. Объектное хранилище (S3) держит целые неизменяемые блобы за HTTP-API без семантики файловой системы — отлично для ассетов и бэкапов, бесполезно как том базы, потому что нет частичной записи на месте. Этот урок — про блочную и файловую половину: тома, которые EC2-инстанс реально монтирует.
В этой половине AWS даёт три сервиса, и ловушка — ранжировать их по IOPS. Ранжируй их по модели подключения и долговечности:
- EBS — сетевой блок, живёт в одной зоне доступности (AZ), подключается к одному инстансу за раз (с узким исключением Multi-Attach). Долговечен: переживает инстанс.
- EFS — управляемая файловая система NFS (Network File System, сетевая файловая система), охватывает несколько AZ, многие инстансы монтируют её одновременно, автомасштабирует ёмкость. Долговечна и общая.
- Instance store — эфемерный локальный NVMe, физически подключённый к хосту. Самый быстрый, но данные исчезают при stop, hibernate, terminate или отказе диска.
Вместе эти три варианта закрывают все модели подключения: одиночный долговечный узел, множество узлов с общим доступом и ультрабыстрый scratch. Аварии происходят, когда один вариант используют для задачи другого — чаще всего скорость instance store принимают за замену долговечности EBS.
EBS: сетевой блок, который тюнишь числом
EBS — диск по умолчанию для одиночного stateful-узла: базы, брокера сообщений, загрузочного тома. Он сетевой, поэтому переживает инстанс: завершишь EC2-машину — том (если не delete-on-termination) всё ещё на месте, готов к повторному подключению. Он однозональный и привязан к одному инстансу за раз; исключение — Multi-Attach на io1/io2, который позволяет до 16 Nitro-инстансов в одной AZ делить один том, но только если приложение приносит собственную кластеризацию и I/O-fencing — это не «общее хранилище», а строительный блок для кластерного ПО.
Типы тома — настоящий рычаг сеньорского уровня, ведь gp3 отвязал производительность от размера. Том gp3 включает базу в 3000 IOPS и 125 МиБ/с бесплатно при любом размере, и ты выделяешь больше независимо — до 80 000 IOPS и 2000 МиБ/с — не наращивая диск. Это и есть ключевой фикс относительно gp2, где производительность была приварена к размеру по 3 IOPS/ГиБ, а маленькие тома опирались на баланс burst-кредитов: том gp2 меньше 1 ТиБ мог бёрстить до 3000 IOPS лишь пока были I/O-кредиты, и занятый маленький том, исчерпавший BurstBalance, проваливался обратно к крошечной базе (база gp2 на 100 ГиБ — всего 300 IOPS) — классический инцидент с обрывом латентности в 2 часа ночи. Для устойчиво высоких IOPS с жёсткой латентностью есть io1/io2 (provisioned IOPS, io2 Block Express до 256 000 IOPS при средней латентности менее 500 микросекунд и долговечности 99,999%). Для дешёвых последовательных нагрузок на пропускную способность — большие логи, дата-лейки — выигрывают по цене HDD-типы st1 (throughput-optimized, до 500 МиБ/с) и sc1 (cold, самый дешёвый).
Тома EBS также меняют размер онлайн: можно нарастить ёмкость, сменить тип и поменять IOPS/пропускную способность через Elastic Volumes, пока инстанс работает. А снапшоты — инкрементальные бэкапы в S3; восстановление тома из снапшота — ленивая загрузка: том готов сразу, но блоки подтягиваются из S3 при первом обращении, поэтому свежее восстановление кажется медленным, пока не прогреется (инициализируй его или используй Fast Snapshot Restore, если нужна полная производительность с нулевого блока).
# gp3 с базой 3000 IOPS / 125 МиБ/с, включённой бесплатно при любом размере
aws ec2 create-volume \
--volume-type gp3 --size 200 --availability-zone us-east-1a
# Поднять IOPS и пропускную способность независимо от размера — онлайн, без отключения
aws ec2 modify-volume \
--volume-id vol-0abc123 --iops 9000 --throughput 500
# Снапшоты — инкрементальные бэкапы в S3; восстановление лениво грузит блоки при первом чтении
aws ec2 create-snapshot --volume-id vol-0abc123 \
--description "nightly db volume backup"▸Почему это работает
Почему свежий том, восстановленный из снапшота, медленный при первом доступе? Снапшот лежит в S3 как набор блоков. Когда ты создаёшь из него том, EBS не копирует всё заранее — он предъявляет том сразу и лениво подгружает каждый блок из S3 при первом чтении. Поэтому первый проход по восстановленной базе (полный скан таблицы, переиндексация) платит S3-round-trip за каждый холодный блок и ощущается куда медленнее, чем подсказывают выделенные IOPS тома. Как только блок тронут — он локальный и быстрый. Чтобы избежать обрыва при реальном восстановлении, либо прогрей том, прочитав его целиком, либо включи Fast Snapshot Restore, чтобы блоки были доступны на полной производительности с самого начала.
EFS и instance store: общий файл против выбрасываемого локального
EFS — ответ, когда многим инстансам нужны одни и те же файлы одновременно: парк веб-серверов, отдающих одни загрузки, кластер CMS, контейнерные таски с общим персистентным состоянием. Это управляемая файловая система NFS, которая охватывает несколько AZ, эластично автомасштабирует ёмкость по мере записи (без выделения размера) и принимает тысячи одновременных соединений. Цена — физика: достучаться до неё по NFS через сеть значит более высокую латентность, чем у локального тома EBS (примерно единицы миллисекунд на первый байт чтения на классе Standard и десятки мс на классе Infrequent Access), и за ГБ она дороже EBS. У пропускной способности есть режимы — Elastic (автомасштаб, оплата за перемещённые байты, лучше для всплесковой/непредсказуемой нагрузки) и Provisioned (фиксируешь нижнюю границу пропускной способности независимо от размера) — а lifecycle-политика может состаривать холодные файлы до классов Infrequent Access (IA) и Archive, срезая стоимость. Ошибка, которой надо избегать, — тянуться к EFS как к тому одиночной базы: латентность NFS и отсутствие блочной семантики делают его неверным инструментом там, где место EBS.
Instance store — противоположный размен: эфемерный локальный NVMe, физически подключённый к хосту, поэтому он даёт самые высокие IOPS и самую низкую латентность из всего здесь — и AWS сотрёт его без церемоний. Данные переживают перезагрузку (reboot), но криптографически стираются при stop, hibernate или terminate и просто исчезают при отказе нижележащего диска. Его нельзя снапшотить, нельзя отключить и переподключить, нельзя добавить после запуска. Это делает его верным ровно для одной категории: данные, которые можно позволить себе потерять, — кэши, scratch-пространство, spill/temp-файлы, буферы или данные, уже реплицированные по парку (узел Cassandra или Kafka, чья долговечность идёт от репликации, а не от диска). Положи на него основную базу или единственную копию чего-либо — и ты собрал ту самую военную историю из начала урока.
| Измерение | EBS | EFS | Instance store |
|---|---|---|---|
| Тип | Сетевой блок | Файл NFS (общий) | Локальный блок (эфемерный) |
| Охват | Одна AZ | Несколько AZ (Regional) | Один хост |
| Подключатели | Один инстанс (io2 Multi-Attach: до 16) | Многие, одновременно | Один, фиксирован при запуске |
| Долговечность | Переживает инстанс; снапшоты в S3 | Переживает инстанс; мультизональна | Теряется при stop/terminate/отказе диска |
| Латентность / IOPS | Низкие мс; тюнинг до 256k IOPS (io2) | Выше (NFS через сеть) | Самая низкая латентность, высшие IOPS |
Парк контейнерных веб-серверов за балансировщиком должен читать и писать одни и те же загруженные пользователями файлы, и загрузка с одного узла должна стать видна остальным за секунды. Выбери хранилище.
Нужно 9000 устойчивых IOPS с тома 200 ГиБ для одноузловой базы, с низкой латентностью и без сюрпризов-обрывов. Что подходит лучше всего?
Узел Cassandra хранит данные на NVMe instance store и год отлично работает. Почему это может быть разумным дизайном, а не военной историей из хука?
- 01Сравни EBS, EFS и instance store по модели подключения и долговечности и скажи, когда верен каждый.
- 02Назови три классических режима отказа — потеря данных instance store, EFS-там-где-место-EBS и исчерпание бёрста gp2 — и фикс каждого.
EBS, EFS и instance store — три модели подключения, а не три точки на регуляторе скорости — ранжируй их сперва по подключению и долговечности. EBS — сетевой блок в одной AZ, привязанный к одному инстансу за раз (io2 Multi-Attach — узкое исключение для кластерного ПО), который переживает инстанс, инкрементально снапшотится в S3 с ленивой загрузкой при восстановлении, меняет размер онлайн, а с gp3 позволяет тюнить IOPS до 80 000 и пропускную способность до 2000 МиБ/с независимо от размера поверх бесплатной базы 3000 IOPS / 125 МиБ/с — фикс обрыва на burst-кредитах gp2. EFS — управляемая мультизональная NFS-файловая система, которую многие инстансы монтируют одновременно и которая автомасштабирует ёмкость, разменивая выше латентность и стоимость за ГБ на шаринг по всему парку, с режимами пропускной способности Elastic или Provisioned и lifecycle в Infrequent Access. Instance store — эфемерный локальный NVMe с высшими IOPS и низшей латентностью, но каждый блок стирается при stop, hibernate, terminate или отказе диска, и снапшотить его нельзя, так что он только для кэшей, scratch или реплицированных данных. Правило выбора: том одноузловой базы идёт на EBS; общий контент на парк идёт на EFS; ультранизколатентный scratch, который можно позволить себе потерять, идёт на instance store. Режимы отказа — потеря базы из-за Stop на instance store, оплата латентности NFS там, где место EBS, и провал маленького gp2 при исчерпании burst-кредитов — все идут от выбора по сырой скорости вместо подключения и долговечности. Указанные цены (gp3 около 0,08 USD за ГБ-месяц, снапшоты около 0,05 USD за ГБ-месяц в US-East-1) иллюстративны и зависят от региона — сверяйся со страницей цен EBS. Теперь, когда на ревью увидишь решение о хранилище, первые вопросы — переживёт ли оно Stop и нужен ли общий доступ на весь парк; IOPS идут третьим.
Практика
Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.