Классы хранения и lifecycle-правила: как снизить расходы на хранилище

Короткий ответ

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

Правила жизненного цикла (lifecycle rules) автоматически переносят объекты между классами и удаляют их по возрасту, префиксу или версии. При правильной настройке они снижают счёт без ручной работы. При небрежной — создают плату за извлечение и досрочное удаление, которая превышает экономию.

Три уровня хранения

• Горячий: самая высокая цена хранения, без платы за извлечение и без минимального срока. Для часто читаемых данных.
• Редкий доступ: хранение дешевле, но есть плата за извлечение за каждый ГБ и минимальный срок хранения. Для бэкапов и старых файлов, которые иногда всё же читают.
• Архив: самое дешёвое хранение, самое дорогое извлечение и самые длинные минимальные сроки. В Azure Archive и S3 Glacier Flexible Retrieval или Deep Archive объект перед чтением нужно восстановить (rehydrate), и это может занять часы.

Есть и автоматические варианты: S3 Intelligent-Tiering и GCS Autoclass переносят объекты по фактическому доступу. Они подходят для данных с непредсказуемым характером обращений.

Плата за извлечение и минимальные сроки

Именно эти два параметра чаще всего дают неожиданные счета.

Минимальный срок хранения: если удалить, перезаписать или перенести объект раньше, вы всё равно заплатите за весь минимальный срок. Типичные значения на момент написания:

Перед проектированием правил сверьтесь с актуальной страницей цен вашего провайдера.

Другие факторы стоимости:

• Плата за извлечение каждого ГБ из негорячих классов.
• Цена запросов в холодных классах часто выше, а каждый lifecycle-переход — это тоже запрос.
• Мелкие объекты: некоторые классы тарифицируют минимальный размер объекта или добавляют накладные метаданные на каждый объект. Миллионы крошечных файлов после переноса могут стоить дороже, а не дешевле.

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

Как спроектировать lifecycle-правила

1. Сгруппируйте данные по префиксу или тегу: logs/, backups/, uploads/. Одно правило на тип данных, а не одно на весь бакет.
2. Поймите характер доступа: сколько данные активно читают? Когда они нужны только для аудита?
3. Задайте переходы от горячего к холодному, соблюдая минимальные сроки.
4. Задайте удаление (expiration), если после определённого возраста данные не нужны.
5. Учтите версионирование: удаляйте неактуальные версии, иначе удалённые объекты продолжат стоить денег.
6. Прерывайте незавершённые multipart-загрузки: оборванные большие загрузки оставляют невидимые части, за которые начисляется хранение.

Пример lifecycle-конфигурации для S3:

{
  "Rules": [
    {
      "ID": "logs-tiering",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 120, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 730 }
    },
    {
      "ID": "versions-and-uploads-cleanup",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30, "NewerNoncurrentVersions": 3 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Здесь логи через 30 дней переходят в Standard-IA, через 120 дней — в Glacier Flexible Retrieval и удаляются через два года. Второе правило удаляет старые версии через 30 дней после того, как они перестали быть текущими, но всегда сохраняет три самые свежие из них, и через неделю очищает остатки multipart-загрузок.

В Google Cloud Storage и Azure идеи те же, синтаксис другой: в GCS — действия SetStorageClass, Delete и AbortIncompleteMultipartUpload с условиями по age или версиям, в политиках lifecycle management Azure — действия tierToCool, tierToArchive и delete. Все поля описаны в официальной документации S3 по lifecycle.

Частые ошибки

• Перенести всё в архив, а потом восстанавливать данные для каждой аналитической задачи.
• Короткоживущие данные в холодных классах: временные файлы, удалённые через неделю, всё равно оплачиваются за 30 или 90 дней.
• Версионирование без очистки: бакет бесконечно растёт за счёт скрытых старых версий и delete markers.
• Забытые multipart-загрузки: объём растёт, хотя список объектов не меняется.
• Правила на весь бакет, когда они нужны только одному префиксу.
• Без теста: включите новые правила на тестовом префиксе и посмотрите отчёт о расходах, прежде чем раскатывать на всё.