Object Storage и S3: как устроено, где применять и чем отличается от обычного хранилища

Object storage и интерфейс S3 уже фактически стали стандартом де-факто для хранения бэкапов, статики и больших объёмов данных в облаках. Но на практике до сих пор встречаются проекты, где объектное хранилище используют «как обычный диск» — и потом удивляются задержкам, случайным конфликтам версий и странному поведению при высокой нагрузке.

В этой статье разберёмся, что такое object storage, как устроен протокол S3, чем объектное хранилище принципиально отличается от файловых и блочных систем, и где оно действительно раскрывает себя в продакшене.

Что такое object storage простыми словами

Object storage (объектное хранилище) — это распределённая система хранения данных, в которой основная единица — объект. Каждый объект:

• имеет уникальный ключ (имя), по которому к нему обращаются;
• содержит «тело» (байты данных) и произвольные метаданные;
• хранится внутри бакета (bucket) — логического контейнера объектов.

Ключевой момент — у object storage нет привычной иерархической файловой системы. Каталоги — это всего лишь часть ключа (префикс). «Путь» вида photos/2025/01/image.jpg — просто строка ключа, а не настоящая директория в файловой системе.

Доступ к объектам обычно осуществляется по HTTP(S) API. В случае S3 это REST‑интерфейс с чётко определёнными операциями: PUT, GET, DELETE, LIST и др.

Object storage не предназначен для работы как «сетевой диск» с частыми мелкими изменениями одних и тех же файлов. Его сильная сторона — много больших неизменяемых объектов, которые создаются и читаются целиком.

Чем object storage отличается от файлового и блочного хранилища

Чтобы правильно спроектировать использование object storage в архитектуре, полезно сравнить его с привычными типами хранения.

Файловое хранилище (NFS, SMB и т.п.)

Файловая система оперирует файлами и каталогами. Клиент может:

• открыть файл;
• дочитать или дописать его фрагмент;
• переименовать или переместить файл или каталог;
• управлять правами на уровне файлов и директорий.

Здесь есть понятие дескриптора файла, файловых блокировок, POSIX‑семантики. Для многих приложений это принципиально: например, СУБД ожидают детерминированное поведение при записи блоков. В веб‑проектах NFS часто используют для общих каталогов приложений, сессий и прочего «мелкого стейта». Подробнее плюсы и минусы NFS в проде мы разбирали в материале про выбор общего хранилища NFS и SSHFS.

Блочное хранилище (диски и тома)

Блочное устройство вообще не знает про файлы. Оно предоставляет адресуемое пространство блоков (секторов). Уже поверх него ОС создаёт файловую систему (ext4, XFS и т.п.). Типичные примеры — локальные диски сервера или сетевые блочные устройства (iSCSI, SAN).

Блочное хранилище даёт низкую задержку, последовательный и произвольный доступ к блокам, что удобно для баз данных и нагрузок с интенсивной записью.

Объектное хранилище

Object storage работает на более высоком уровне абстракции:

• нет «частичного обновления» объекта — он записывается целиком (если не использовать специальные механизмы multipart‑загрузки и byte ranges);
• нет жёстких гарантий по моментальной консистентности между запросами, чаще всего используется модель eventual consistency (особенно для операций LIST);
• доступ осуществляется по HTTP(S) с использованием подписи запросов и ACL/политик на уровне бакетов и ключей;
• масштабирование достигается горизонтально: данные автоматически размазываются по множеству узлов с репликацией или кодом исправления ошибок (erasure coding).

Зато object storage значительно лучше масштабируется в объёме: десятки и сотни петабайт, миллиарды объектов, отказоустойчивость «из коробки» и экономия за счёт дешёвых дисковых массивов.

Что такое S3 и «S3‑совместимость»

Amazon S3 — один из первых массовых коммерческих сервисов объектного хранения. Вокруг его API сформировался отраслевой стандарт. Большинство современных object storage‑решений (как облачных, так и on‑premise) декларируют S3‑совместимость.

S3‑интерфейс — это:

• REST‑API поверх HTTP(S) для работы с бакетами и объектами;
• стандартизованный формат аутентификации и авторизации (подпись запросов с помощью access key и secret key);
• набор операций (PUT Object, GET Object, LIST Objects, DELETE Object, Multipart Upload и др.);
• механизм управления правами — ACL и bucket policies;
• метаданные объектов и системные теги;
• дополнительные функции: версии (object versioning), lifecycle‑политики, классы хранения, нотификации о событиях и т.п.

Под «S3‑совместимостью» обычно понимают, что хранилище поддерживает тот же API и схему аутентификации, чтобы с ним могли работать существующие инструменты и библиотеки: aws-cli, SDK для разных языков, бэкап‑решения, клиенты синхронизации и прочие утилиты.

На практике «совместимость» бывает разной глубины: базовый набор операций совпадает, но расширенные функции (например, специфические классы хранения или заголовки) могут работать иначе или не поддерживаться.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Базовые сущности object storage: бакеты, объекты, ключи

Чтобы уверенно работать с S3‑совместимым хранилищем, достаточно понять три базовые сущности.

Бакет (bucket)

Бакет — логический контейнер объектов:

• имя бакета уникально в рамках провайдера или аккаунта;
• на бакет задаются глобальные настройки: регион, политика версий, lifecycle‑правила, публичность доступа;
• часто бакеты используют как единицы изоляции между проектами, окружениями или командами.

Объект (object)

Объект — это данные плюс метаданные:

• байтовый поток произвольного размера (от килобайтов до сотен гигабайт и более);
• набор заголовков (Content-Type, Cache-Control, Content-Disposition и др.);
• пользовательские метаданные (user metadata) в формате пар «ключ‑значение»;
• при включённом versioning у объекта может быть несколько версий с разными ID.

Ключ (object key)

Ключ — это строка, которая однозначно идентифицирует объект в бакете. Часто её делают похожей на путь:

images/2025/01/banner.png
backups/db/prod/2025-01-01.sql.gz
logs/app1/2025/01/01/00.gz

Буквально это просто имя. Хранилище не знает, где у вас «директория», а где часть имени файла.

Это особенно заметно при операциях LIST: вы указываете префикс (например, images/2025/01/) и получаете список всех ключей, которые начинаются с этого префикса. При необходимости можно «эмулировать» каталоги с помощью разделителя (delimiter=/).

Сильные стороны object storage

Если использовать object storage там, где он силён, он существенно упрощает жизнь админам и девопсам.

Масштабируемость по объёму и числу объектов

Архитектура объектного хранилища изначально рассчитана на рост:

• данные размазываются по множеству узлов, зачастую по нескольким дата‑центрам;
• репликация и erasure coding обеспечивают устойчивость к выходу из строя узлов и целых стоек;
• нет жёстких ограничений на количество файлов в «каталоге» — это лишь количество записей в распределённом key-value‑индексе.

Для проектов, где количество объектов растёт как «лог‑поток» (логи, бэкапы, медиафайлы пользователей), object storage даёт практически неограниченный рост без щепетильной ручной разбивки каталогов и самостоятельного шардирования.

Надёжность и доступность

Большинство S3‑совместимых хранилищ декларируют очень высокую долговечность (durability) — порядка 99.999999999% (11 девяток) за счёт:

• многократной репликации данных; или
• использования erasure coding (например, схема 6+3, 8+4 и т.д.).

При этом система сама занимается восстановлением недоступных фрагментов с живых реплик. Для администратора это выглядит как «чёрный ящик» с весьма надёжным хранилищем, на котором можно держать критичные данные (особенно при включённом versioning и грамотных lifecycle‑политиках).

Гибкая политика хранения и стоимости

Почти во всех object storage есть классы хранения:

• горячие (частый доступ, минимальная задержка, дороже за GB‑месяц);
• «холодные» или архивные (дешёвое хранение, платный или медленный доступ);
• региональные и мультизональные (одна зона против нескольких AZ/ДЦ).

Переезд между классами обычно автоматизируется lifecycle‑правилами: старые бэкапы — в архив; неиспользуемые версии — удалять через N дней; лог‑файлы — хранить не более 90 дней и т.п.

Простой доступ по HTTP(S)

В отличие от NFS и блочного хранилища, object storage доступен по HTTP(S). Это даёт:

• простую интеграцию с любыми языками и фреймворками (SDK, curl, сторонние CLI);
• возможность выдавать объекты напрямую клиенту (через CDN или сразу из бакета);
• удобный доступ из CI/CD, систем резервного копирования, менеджеров артефактов.

Если вы разворачиваете инфраструктуру на VDS или смешиваете несколько окружений (on‑premise и облако), унифицированный S3‑интерфейс сильно упрощает миграции и гибридные схемы.

Слабые стороны и ограничения object storage

Чтобы не разочароваться, важно понимать, где object storage «не волшебная таблетка».

Не POSIX и не «сетевой диск»

Object storage не предоставляет файловой семантики:

• нет атомарных операций на уровне каталогов (типа mv каталога);
• нет блокировок файлов, к которым привыкли приложения под POSIX;
• нет понятия «открытого файла» и дозаписи по смещению.

Если попытаться смонтировать S3 как файловую систему и использовать под базу данных или как shared‑хранилище с частыми изменениями маленьких файлов, производительность и устойчивость будут слабые. S3‑FS и похожие решения — это костыль ради удобства, а не рецепт производительного хранилища.

Eventual consistency

Многие object storage работают по модели eventual consistency, особенно для операций LIST:

• вы выполняете PUT объекта, а следующий LIST может его ещё не увидеть некоторое время;
• при массовом удалении и параллельных записях возможны временные несоответствия;
• при проектировании нужно избегать логики «сначала LIST, потом делаю вывод, что объект не существует».

Для большинства сценариев (бэкапы, статика, логи) это некритично. Но при построении сложных workflow, завязанных на состояние объектов, нюанс стоит учитывать.

Задержка и стоимость операций

Object storage хорошо масштабируется по объёму, но:

• задержка доступа выше, чем к локальному диску или даже NFS;
• у многих провайдеров тарифицируются не только объём, но и операции (PUT/LIST/GET) и исходящий трафик;
• много мелких объектов и частые листинги могут неожиданно оказаться дорогими.

Это ещё одна причина избегать сценариев «миллионы мелких файлов с постоянными обновлениями».

Типовые сценарии применения object storage и S3

Рассмотрим, где object storage отлично подходит для типичных веб‑проектов и сервисов.

1. Резервные копии (бэкапы)

Object storage идеально ложится на задачу бэкапов:

• объекты большого размера, которые редко читаются;
• логически неизменяемые файлы (каждый бэкап — новый объект);
• возможность хранить несколько копий в разных регионах;
• lifecycle‑автоматизация: «горячие» бэкапы 7 дней, затем перевод в «холодный» класс, потом удаление.

Многие современные бэкап‑системы (restic, Borg через rclone, Veeam, Bacula и др.) уже умеют писать напрямую в S3‑совместимое хранилище. Про практику бэкапов в S3‑хранилища мы подробно писали в статье про бэкапы в S3 с restic и Borg.

2. Статические файлы и медиа для сайтов и приложений

Классический сценарий — хранение статики (CSS, JS, изображения) и пользовательского контента:

• объекты читаются чаще, чем записываются;
• идеально сочетаются с CDN и кэшированием браузера;
• можно изолировать пользовательский контент в отдельном бакете с собственными политиками доступа;
• простая интеграция с фреймворками (Django, Laravel, Rails, Node.js и др.) через S3‑библиотеки.

Для high‑load проектов это часто удобнее и дешевле, чем масштабировать «традиционный» NFS‑кластер или держать большие RAID‑массивы под статику, особенно если фронтенд крутится на кластере виртуального хостинга или нескольких инстансах VDS.

3. Логи и аналитика

Object storage отлично подходит для хранения логов и сырых данных для аналитики:

• подходит модель «append-only»: каждый час или день появляются новые объекты логов;
• хранилище масштабируется по мере роста объёма логов;
• анализ можно делать через внешние системы (ClickHouse, Presto/Trino, Spark и др.), читающие данные прямо из S3‑совместимого бакета;
• lifecycle‑политики позволяют автоматически удалять старые логи.

4. Хранение артефактов CI/CD

Результаты сборок (артефакты) удобно складывать в object storage:

• имена ключей можно организовать по схеме project/env/build-id/...;
• просто отдавать артефакты на скачивание из CI или по API;
• управлять временем жизни артефактов через lifecycle;
• использовать S3 как backend для docker‑регистри, Helm‑чартов и т.п. (через соответствующие решения).

5. User‑generated content (UGC) в SaaS‑проектах

Если у вас сервис с пользовательскими файлами (фото, видео, документы), object storage даёт:

• масштабируемый бэкенд для хранения;
• гибкость в управлении правами доступа (приватные объекты, временные ссылки);
• возможность отдавать файлы напрямую пользователю из S3 или через CDN, разгружая backend‑сервера.

Часто встречающаяся архитектура: приложение получает файл от клиента, пишет его в object storage, а дальше работает только с ссылкой или ключом в бакете.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Ключевые особенности S3‑API, про которые нельзя забывать

При интеграции приложений с S3‑совместимым хранилищем есть несколько важных нюансов.

Аутентификация и подпись запросов

S3 использует схему подписи запросов с помощью пары access key и secret key (Signature Version 4 и её вариации). На практике это означает:

• для доступа из бэкенда вы храните ключи в переменных окружения, конфиге или системе секретов;
• нельзя жёстко зашивать секретные ключи в фронтенд и мобильные приложения;
• для прямой загрузки из браузера используют pre‑signed URLs или специальные upload‑policy‑механизмы.

Приватные и публичные бакеты, политики доступа

По умолчанию бакеты и объекты обычно приватные. Публичный доступ делают двумя способами:

• делают бакет публичным целиком (или по префиксу) с помощью bucket policy;
• или генерируют pre‑signed URL с ограниченным временем жизни для конкретного объекта.

В продакшене чаще комбинируют: бакет остаётся приватным, а прямой доступ пользователям обеспечивается через временные ссылки или backend‑прокси.

Версионирование объектов (versioning)

Versioning даёт возможность хранить несколько версий одного и того же ключа. Это полезно для:

• защиты от случайных удалений и перезаписи данных;
• возможности «откатить» состояние бакета на определённую дату;
• аудита изменений.

Но включение versioning увеличивает занимаемый объём: старые версии нужно либо лимитировать lifecycle‑правилами, либо принимать рост стоимости хранения.

Lifecycle‑правила

Lifecycle‑конфигурации управляют жизненным циклом объектов:

• перевод из «горячего» класса в «холодный» через N дней;
• удаление неактуальных версий через M дней после создания новой;
• удаление «мусорных» неполных multipart‑загрузок.

Грамотная lifecycle‑политика — ключ к контролю стоимости и упрощению ручной «уборки» старых данных.

Практические рекомендации по проектированию схемы ключей

Одна из типичных ошибок при работе с object storage — неподходящая схема именования ключей. Это влияет и на производительность LIST, и на удобство эксплуатации.

Используйте префиксы

Планируйте ключи так, чтобы по префиксу легко находить нужную группу объектов:

• env/app/module/... (например, prod/web/uploads/...);
• project/date/... для бэкапов и логов;
• user-id/... для пользовательских файлов.

Это упростит листинг и операции вроде выборочного удаления целых логических групп объектов.

Избегайте «горячих префиксов»

В некоторых реализациях object storage при очень большом количестве операций по одному и тому же префиксу могут возникать «горячие» шард‑точки. Чтобы снизить риск, можно:

• добавлять рандомный или хеш‑префикс в начало (например, первые 2 символа от SHA‑1 или MD5 контента);
• разбивать ключи по датам или часам, а не складывать всё в один префикс вроде logs/.

На небольших и средних объёмах это редко становится проблемой, но в high‑load системах планирование префиксов заранее спасает от «узких мест».

Храните важные атрибуты в метаданных

Не пытайтесь кодировать слишком много информации в сам ключ. Для атрибутов, которые меняются, используйте:

• пользовательские метаданные (user metadata);
• отдельные индексы в базе данных приложения;
• теги объектов, если они поддерживаются в вашем хранилище.

Ключ должен быть устойчивым идентификатором объекта, а не «всё и сразу».

Как выбирать: object storage vs NFS vs блочные тома

Кратко сформулируем, когда что использовать в инфраструктуре веб‑проекта.

Object storage (S3)

• бэкапы, снапшоты, архивы;
• статические файлы и медиа;
• логи и сырые данные для аналитики;
• артефакты CI/CD;
• пользовательские файлы, которые редко обновляются, но активно читаются.

NFS и сетевое файловое хранилище

• совместный доступ к файлам с POSIX‑семантикой;
• наследованные приложения, ожидающие локальную файловую систему;
• сценарии с частым обновлением большого числа небольших файлов.

Блочные тома

• базы данных (MySQL, PostgreSQL и т.п.);
• высоконагруженные приложения с интенсивной записью;
• файловые системы, критичные к задержке (например, под очередь сообщений на диске).

На практике в продакшене комбинируются все три типа: базы на блочных томах, общие файлы и «state» — на NFS или локальных дисках, статика, бэкапы и логи — в object storage.

Итого

Object storage с S3‑интерфейсом — мощный инструмент, который хорошо решает задачи хранения больших объёмов данных: от бэкапов и логов до пользовательского контента и статики. Его сильные стороны — масштабируемость, надёжность, гибкие lifecycle‑политики и простой HTTP‑доступ.

При этом object storage — не замена файловым и блочным системам, а дополнение. Важно учитывать:

• отсутствие POSIX‑семантики;
• eventual consistency для некоторых операций;
• стоимость операций и исходящего трафика;
• правильное проектирование схемы ключей и бакетов.

Если учесть эти особенности на этапе проектирования архитектуры, object storage станет надёжным и предсказуемым элементом инфраструктуры, а не «чёрным ящиком» с сюрпризами на проде.