Когда имеет смысл использовать Glacier или другие “холодные” классы хранения
Junior
Когда имеет смысл использовать Glacier или другие “холодные” классы хранения?
Ответ для собеседования
Холодные классы хранения (например, S3 Glacier, Glacier Deep Archive, Nearline/Coldline, Archive) используют для больших объемов данных, к которым обращаются крайне редко и могут подождать минуты или часы до выдачи. Это архивы, бэкапы, данные для аудита и регуляторных требований, где важнее минимальная цена за гигабайт, чем скорость доступа. В обмен вы принимаете ограничения: плату за извлечение, задержку при "разморозке" и минимальный срок хранения.
Подробный ответ
Холодные классы хранения (S3 Glacier, S3 Glacier Deep Archive, Nearline/Coldline в GCP, Archive в Azure и аналоги в on-prem-решениях) оптимизированы под максимально дешевое длительное хранение с редким и заранее прогнозируемым доступом. Они выгодны, когда данные должны лежать месяцами и годами, но читаются эпизодически, а бизнес готов мириться с задержкой на восстановление и дополнительной платой за доступ. Важная идея: вы платите копейки за каждый гигабайт в месяц, но заметно дороже за операции извлечения и исходящий трафик.Имеет смысл использовать Glacier и другие холодные классы, когда выполняются следующие условия:
Данные нужны "на всякий случай": для аудита, регуляторных и юридических запросов, расследования инцидентов (логи, журналы транзакций, архивы отчетности, CCTV-записи и т.п.).
Доступ к этим данным редкий и предсказуемый: не чаще нескольких раз в год, и вы можете подождать от минут до часов, пока завершится восстановление (restore/unfreeze).
Объем данных большой (терабайты/петабайты), стоимость горячего хранения становится существенной статьей расходов, и задача — минимизировать цену за объем.
Требования к RTO/RPO для этих данных достаточно мягкие: можно подождать с восстановлением, нет критичного требования к мгновенной доступности.
Необходимы длительные WORM-сценарии (Write Once Read Many) и соответствие нормам: хранение документов 5–10 лет и дольше, невозможность тихо подменить или удалить данные задним числом.
Типичные практические сценарии:
Долгосрочные резервные копии баз данных и приложений, к которым обращаются только при Disaster Recovery или расследовании редких инцидентов.
Архивы логов и телеметрии старше N месяцев/лет, которые нужны для ретроспективного анализа, безопасности или комплаенса, но почти никогда не читаются оперативно.
Медиаархивы (видео, RAW-фотографии, записи трансляций), которые обязаны храниться годами, но используются эпизодически.
Исторические слепки (snapshots) данных и моделей, которые сохраняют состояние системы на определенный момент для возможного пересчета или экспертиз в будущем.
Важно учитывать ограничения и подводные камни холодного хранения:
Высокая задержка на чтение: доступ не мгновенный, перед скачиванием объект нужно восстановить, это может занимать от нескольких минут до часов в зависимости от класса и выбранного режима.
Плата за операции извлечения и трафик: вы экономите на ежемесячном хранении, но платите за чтение, особенно при массовом восстановлении больших объемов.
Минимальный срок хранения: объекты должны пролежать не меньше заданного периода, иначе при раннем удалении взимается дополнительная плата.
Не подходит для частого доступа: если данные нужно читать регулярно, "прыгание" между горячим и холодным классом быстро сделает решение дороже, чем хранение в стандартном или "теплом" классе (Standard, Standard-IA, One Zone-IA и аналоги).
На практике холодные классы почти всегда используют в рамках многоуровневой (tiered) стратегии хранения. Типичный подход: данные сначала живут в стандартном классе (`Standard`), затем по политике жизненного цикла автоматически переводятся в более дешевый "теплый" класс (`Standard-IA` или аналогичный), а еще через несколько месяцев или лет — в `S3 Glacier` или `Glacier Deep Archive` либо аналогичный холодный класс в другом облаке. Это позволяет оптимизировать стоимость без изменений в коде приложений: вы просто настраиваете политики жизненного цикла. Нашли ошибку? Выделите ее