Объяснение классов хранения S3: выбор оптимального варианта для экономии

Amazon Simple Storage Service (S3) является хранилищем объектов по умолчанию для многих рабочих нагрузок AWS, поскольку оно хорошо масштабируется и предоставляет несколько классов хранения для различных шаблонов доступа. Однако не все данные используются одинаково. Хранение часто используемых критически важных данных в том же классе, что и редко используемые архивные данные, может привести к значительным и ненужным расходам на облачные ресурсы. Понимание нюансов между различными классами хранения S3 имеет решающее значение для проектирования архитектуры с оптимизированными затратами.

Понимание надежности и доступности S3

Прежде чем углубляться в классы, важно определить две основные метрики для S3:

• Надежность: Вероятность того, что ваши данные останутся нетронутыми с течением времени. S3 обеспечивает 99,999999999% (11 девяток) надежности в инфраструктуре, используемой для данного класса.
• Доступность: Процент времени, в течение которого ваши данные доступны для извлечения. Обычно измеряется ежегодно (например, 99,9%).

Эти метрики незначительно варьируются в зависимости от выбранного класса хранения.

Основные классы хранения S3: подробное сравнение

AWS предлагает несколько классов хранения, оптимизированных для разной частоты доступа и допустимого времени простоя. Вот подробный обзор наиболее распространенных вариантов.

1. S3 Standard

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

• Вариант использования: Активные данные, распространение контента, динамически генерируемый контент, мобильные и игровые приложения.
• Надежность: 11 девяток.
• Доступность: 99,99% (высокая доступность).
• Время извлечения: Миллисекунды.
• Ценообразование: Самая высокая стоимость хранения среди уровней с частым доступом, но без платы за извлечение.

Рекомендация: Используйте для данных, требующих немедленного доступа с минимальной задержкой.

2. S3 Intelligent-Tiering (S3-IT)

S3 Intelligent-Tiering предназначен для данных с неизвестными или меняющимися шаблонами доступа. Он автоматически перемещает объекты между двумя или более уровнями доступа в зависимости от использования, оптимизируя затраты на хранение без операционных накладных расходов.

• Вариант использования: Озера данных, данные с непредсказуемыми шаблонами доступа или когда вы хотите обеспечить немедленный доступ, оптимизируя затраты с течением времени.
• Как это работает: Он отслеживает доступ. Если к объекту не обращались в течение 30 последовательных дней, он перемещается на уровень нечастого доступа (IA). При повторном обращении он возвращается на уровень частого доступа.
• Включенные уровни: Частый доступ, Нечастый доступ, Архивный мгновенный доступ (опционально).
• Фактор стоимости: Включает небольшую ежемесячную плату за мониторинг и автоматизацию за объект, в дополнение к стоимости хранения, которая меняется в зависимости от уровня, на котором находится объект.

Практический совет: Если вы не уверены, как часто данные будут использоваться, S3 Intelligent-Tiering часто обеспечивает наилучший баланс между экономией средств и стабильностью производительности.

3. S3 One Zone-Infrequent Access (S3 One Zone-IA)

Этот класс идеально подходит для данных, к которым обращаются нечасто, но которые требуют быстрого извлечения, аналогично S3 Standard-IA, но с существенным отличием в доступности.

• Вариант использования: Вторичные резервные копии, воссоздаваемые данные (например, данные, которые можно регенерировать из источника) или хранение данных, которые не являются критически важными для бизнеса, чтобы оправдать избыточность в нескольких зонах доступности.
• Надежность: 11 девяток.
• Доступность: 99,5% (более низкая доступность, чем Standard).
• Местоположение хранения: Данные хранятся избыточно в одной зоне доступности (AZ) AWS, в отличие от других классов, которые охватывают несколько AZ.
• Фактор стоимости: Значительно более низкая стоимость хранения, чем Standard, но извлечение данных влечет за собой плату.

⚠️ Предупреждение о One Zone-IA: Поскольку данные находятся только в одной AZ, в случае катастрофического события в этой конкретной AZ (например, крупного сбоя питания или стихийного бедствия) ваши данные в этом уровне могут быть потеряны. Вот почему этот класс подходит только для некритичных, легко заменяемых данных.

4. Классы хранения S3 Glacier (Архивные)

Классы хранения Glacier оптимизированы для долгосрочного архивирования, где приемлемо время извлечения от минут до часов.

S3 Glacier Instant Retrieval (S3 Glacier IR)

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

• Вариант использования: Данные, к которым обращаются раз в квартал или реже, но которые требуют извлечения за миллисекунды при необходимости (например, медицинские изображения, архивы новостных медиа).
• Время извлечения: Миллисекунды (аналогичная задержка классам IA).
• Фактор стоимости: Очень низкая стоимость хранения с платой за извлечение.

S3 Glacier Flexible Retrieval (ранее S3 Glacier)

Это вариант долгосрочного архивирования, когда приемлемо извлечение от минут до часов.

• Вариант использования: Архивы для соблюдения нормативных требований, данные аварийного восстановления, которые редко или никогда не требуются.
• Варианты извлечения (и задержка):
  • Expedited: 1–5 минут
  • Standard: 3–5 часов
  • Bulk: 5–12 часов
• Фактор стоимости: Чрезвычайно низкая стоимость хранения, но взимается плата за извлечение, и оно занимает время.

S3 Glacier Deep Archive

Самый дешевый вариант хранения в AWS S3.

• Вариант использования: Данные, к которым могут обращаться только один или два раза в год, обычно для соблюдения нормативных требований.
• Варианты извлечения (и задержка):
  • Standard: 12 часов
  • Bulk: 48 часов
• Фактор стоимости: Самая низкая ставка хранения, самая высокая плата за извлечение и самые длительные требуемые окна извлечения.

Как выбрать: структура принятия решений

Выбор правильного класса зависит от ответов на три ключевых вопроса о жизненном цикле ваших данных:

Вопрос	Основное соображение	Рекомендуемый путь класса
Как часто к ним обращаются?	Частота доступа	Частый $\rightarrow$ Standard; Нечастый $\rightarrow$ IA или Glacier
Какое время простоя/потери приемлемо?	Надежность/Доступность	Критично $\rightarrow$ Standard/Intelligent-Tiering; Заменяемо $\rightarrow$ One Zone-IA
Как быстро я должен их извлечь?	Требование к задержке	Миллисекунды $\rightarrow$ Standard/Intelligent-Tiering/Glacier IR; Часы $\rightarrow$ Glacier Flexible/Deep Archive

Пример сценария: Медиа-активы компании

Маркетинговая команда ежедневно загружает сотни исходных видеофайлов:

1. Текущие правки/промо (последние 30 дней): S3 Standard (Высокий доступ, низкая задержка).
2. Старые активы, требующие периодического просмотра (от 30 дней до 1 года): S3 Intelligent-Tiering (Для экономии средств после начального горячего периода).
3. Завершенные, проверенные финальные мастер-копии (старше 1 года): S3 Glacier Deep Archive (Самая низкая стоимость, нужны только для аудита соответствия).

Пример сценария: Логи, резервные копии и загрузки пользователей

В одной компании часто встречаются три совершенно разных шаблона S3.

Для логов приложений недавние данные ценны, потому что инженеры ищут в них информацию во время инцидентов. После того как окно инцидента проходит, большинство логов становятся данными для соответствия или трендов. Разумный жизненный цикл может хранить 30–90 дней в Standard или Standard-IA, перемещать более старые логи в архивный уровень и удалять малозначимые отладочные логи после фиксированного периода хранения. Точные цифры должны исходить из вашей политики хранения и того, как часто люди действительно запрашивают старые префиксы.

Для резервных копий баз данных класс хранения должен соответствовать обещанию восстановления. Если команда говорит, что восстановление production должно начаться в течение минут, храните самые новые резервные копии в классе с немедленным извлечением. Более старые ежемесячные или ежегодные копии можно переместить в более холодный класс, если они предназначены для аудита, а не для быстрого восстановления. Тестируйте восстановление из выбранного класса; политика резервного копирования, которая никогда не восстанавливалась, — это в основном правило выставления счетов.

Для загрузок пользователей доступ предсказать сложнее. Фото профиля может быть крошечным, но загружаться постоянно. Большое исходное видео может быть загружено один раз, транскодировано и больше никогда не использоваться. Храните производные активы и оригиналы под отдельными префиксами, чтобы правила жизненного цикла могли обрабатывать их по-разному. Не заставляйте политику миниатюр наследовать то же правило архивирования, что и многогигабайтные оригиналы, если это действительно не требуется продуктом.

Вопросы, которые нужно задать перед изменением корзины

Прежде чем добавить правило жизненного цикла, спросите, кто читает данные, как они их читают и что произойдет, если извлечение будет отложено. Инженеры часто лучше знают путь записи, чем путь чтения, потому что загрузки являются частью приложения, а чтение происходит позже через аналитику, инструменты поддержки, экспорт для соответствия или ручное реагирование на инциденты.

Обратите внимание на пакетные задания, которые сканируют старые префиксы. Ночное задание, которое перечисляет каждый объект, открывает метаданные или выбирает образцы старых файлов, может свести на нет часть экономии от более холодного класса. Если заданию нужен только манифест, S3 Inventory может быть лучше, чем многократное перечисление корзины. Если аналитики запрашивают логи с помощью Athena, рассмотрите макет разделов и сжатие перед перемещением данных в класс, требующий шагов восстановления.

Обратите внимание на размер объекта. Классы хранения с минимальным оплачиваемым размером объекта могут плохо подходить для огромного количества крошечных файлов. В таких случаях уплотнение данных в более крупные объекты, использование Parquet для аналитики или удаление ненужных объектов могут быть эффективнее смены класса хранения.

Наконец, пишите правила жизненного цикла так, чтобы их можно было объяснить во время инцидента. Правило префикса с именем archive-old-logs-after-90-days легче понять, чем правило для всей корзины, которое незаметно перемещает все через 30 дней. Оптимизация затрат должна делать систему дешевле, не делая восстановление загадочным.

Еще одна практическая проверка — право собственности. В реальных аккаунтах владелец корзины, загружающий аккаунт, роль репликации и аккаунт аналитики не всегда совпадают. Прежде чем перемещать данные в архивный класс, подтвердите, кто может их восстановить и кто платит за извлечение. Межаккаунтные корзины с шифрованием KMS могут выйти из строя при восстановлении, если роль, которой нужен объект, может перечислить корзину, но не может использовать ключ. Это неприятный сюрприз во время аудита.

Версионность также меняет расчеты. Правила жизненного цикла могут по-разному перемещать или удалять текущие и не текущие версии. Если приложение перезаписывает один и тот же ключ каждый час, не текущие версии могут стать самой большой частью корзины. Просматривайте их отдельно, вместо того чтобы предполагать, что количество текущих объектов рассказывает всю историю.

Реализация политик жизненного цикла

Ручное перемещение объектов между классами неэффективно. Наиболее эффективный способ управления затратами на этих уровнях — использование политик жизненного цикла S3.

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

Пример правила жизненного цикла (перемещение):

<Rule>
    <ID>Move_to_IA_After_30_Days</ID>
    <Status>Enabled</Status>
    <Filter>
        <Prefix>logs/</Prefix>
    </Filter>
    <Transition>
        <Days>30</Days>
        <StorageClass>GLACIER_IR</StorageClass>
    </Transition>
</Rule>

Эта конфигурация автоматически перемещает любой объект в префиксе logs/ в Glacier Instant Retrieval через 30 дней после создания, значительно снижая долгосрочные затраты на хранение, сохраняя при этом возможность быстрого извлечения при необходимости.

Ловушки затрат, которые упускают из виду

Решение о классе хранения — это не просто ежемесячное сравнение гигабайт. Плата за извлечение, плата за запросы, минимальный срок хранения, минимальный оплачиваемый размер объекта, репликация, запросы на перемещение жизненного цикла и плата за мониторинг могут изменить ответ. Архив с крошечными объектами и миллионами ключей может вести себя совершенно иначе, чем небольшое количество больших файлов резервных копий.

Например, логи приложений часто записываются один раз и редко читаются, поэтому правило жизненного цикла от Standard до Glacier Instant Retrieval или Glacier Flexible Retrieval может иметь смысл. Но если ваш процесс инцидентов часто сканирует старые логи с помощью Athena, агрессивное архивирование может привести к медленному восстановлению и неожиданным затратам на извлечение. В этом случае разбиение логов по датам, удаление шумных малозначимых префиксов и хранение последних месяцев в классе, удобном для запросов, может сэкономить больше денег, чем слепое перемещение всего в холод через 30 дней.

Резервные копии имеют другую форму. Дамп базы данных, который вы тестируете раз в месяц, требует предсказуемого поведения восстановления. Если ваша цель времени восстановления измеряется минутами, Deep Archive, вероятно, неподходящее место для единственной восстанавливаемой копии, даже если она дешева в хранении. Если тот же дамп является третьей копией, хранящейся только для аудита, Deep Archive может быть разумным.

Медиа-командам часто нужны старые активы непредсказуемо. Intelligent-Tiering может быть хорошим выбором по умолчанию для этих неизвестных шаблонов, особенно когда объекты достаточно велики, чтобы плата за мониторинг не была решающим фактором. Для большого количества крошечных миниатюр плата и поведение минимального размера объекта заслуживают более пристального внимания, прежде чем включать его везде.

Практический способ выбора — взять образец одной корзины, экспортировать S3 Inventory, сгруппировать по префиксу, количеству объектов, общему объему байтов, дате последнего изменения и известному шаблону доступа, а затем написать правила жизненного цикла для каждого префикса. Избегайте одного правила для всей корзины, если только корзина действительно не содержит один тип данных.