Экономим с «Умным хранилищем»: новый класс хранения Yandex Object Storage
Рассказываем, как можно сэкономить на хранении данных с Intelligent Tiering.
22 июня 2026 г.
20 минут чтения
Краткий пересказ YandexGPT
Расходы на хранение данных для крупных компаний могут быть значительными, поэтому важно выбрать оптимальный класс хранилища в Yandex Object Storage.
В сервисе есть несколько классов хранилищ: STANDARD (для частого доступа к данным), COLD (для редкого доступа) и ICE (для очень редкого доступа и длительного хранения, минимум 12 месяцев).
Стоимость хранения данных зависит от платы за непосредственное хранение и платы за доступ к данным.
«Умное хранилище» (Intelligent Tiering) — это инструмент, который автоматически оптимизирует затраты на хранение данных, перемещая их между тремя уровнями хранения («Частый доступ», «Нечастый доступ», «Архивный доступ») в зависимости от частоты обращений к ним.
В «Умном хранилище» движок оптимизации отслеживает операции с каждым объектом и при необходимости «охлаждает» или «прогревает» его, то есть перемещает между уровнями хранения.
Перенести данные в «Умное хранилище» можно с помощью Yandex Cloud CLI, AWS CLI, Terraform и API.
В «Умном хранилище» есть дополнительная плата за анализ обращений к объектам и их перемещение между уровнями хранения, но она компенсируется экономией за счёт более низкой цены хранения данных при их эффективном «охлаждении».
«Умное хранилище» подходит для ситуаций, когда паттерн нагрузки непредсказуем, смешан или меняется со временем.
Для существующих бакетов рекомендуем провести аудит и принять взвешенное решение относительно использования конкретных классов хранения с помощью S3 Inventory.
Расходы на хранение данных для крупных компаний с терабайтами информации могут достигать миллионов рублей в год. В предыдущей статье мы детально рассмотрели классы хранилищ и принципы хранения данных в сервисе Yandex Object Storage. Все классы обеспечивают высокую производительность, а выбор подходящего зависит от требований к сроку хранения и частоте обращений к объектам.
Всегда ли можно однозначно определить и задать паттерн работы с данными и что делать, если в реальной жизни он постоянно изменяется? Спойлер: пользоваться классом «Умное хранилище», первым на российском рынке продуктом, который теперь доступен в Yandex Object Storage. Что он из себя представляет и как с его помощью хранение данных можно сделать экономически более выгодным — в статье рассказывает Александр Киров, технический менеджер Yandex Cloud.
Рассчитываем стоимость хранения данных
Yandex Object Storage позволяет хранить объекты в хранилищах разных классов в зависимости от требований к длительности хранения и частоте операций с объектами. Стоимость этого хранения зависит от двух критериев: платы за непосредственное хранение и платы за доступ к данным.
Низкая — при условии хранения данных не менее 12 месяцев
Из таблицы видно, что если цена запросов низкая, то хранение будет стоить дороже. И наоборот. Мы уже разбирали на примерах, в каком случае выгоден тот или иной класс хранения под конкретный паттерн нагрузки.
Вот как выглядит алгоритм хранения данных, если не пользоваться «Умным хранилищем».
При частом доступе к данным выгоднее использовать STANDARD: он дороже по хранению, но заметно дешевле по операциям. Классы COLD и ICE — для других сценариев: когда чтений мало, а данные хранятся долго.
Если данные архивные и к ним не обращаются, выгоднее хранить их в ICE — для этого класса затраты минимальны. При этом итоговая экономия зависит от объёма данных, частоты доступа и времени их хранения.
Класс ICE отличается от STANDARD и COLD минимальным сроком хранения — один год. Если удалить данные раньше, всё равно придётся оплатить полный год. Поэтому, если вы планируете удалить информацию в течение ближайших месяцев, ICE, скорее всего, не подойдёт.
Производительность уровней хранения «Умного хранилища» соответствует STANDARD, COLD и ICE.
С более мелкими объектами выгоднее работать в более «горячих» классах хранения, потому что операции с объектами там дешевле. Выгода от сокращения затрат на отдельную операцию превышает экономию от использования более «холодного» класса хранения.
Ориентироваться, как лучше хранить данные, в общих чертах можно по такой методике:
Если срок жизни или хранения объекта очень короткий — STANDARD.
Если много работаете с объектом (читаете, листите или изменяете его, например для Geese FS) — STANDARD.
Архив, в котором хранят данные более шести месяцев и никогда или очень редко читают, выгоднее размещать в ICE.
Очень мелкие объекты (до десятков килобайт) тоже, как правило, рационально держать в STANDARD. В этом случае нужно считать индивидуально для каждого размера и срока хранения данных. В нашей прошлой статье были примеры как это делать.
Далеко не все кейсы хранения данных описываются этими четырьмя пунктами. Реальная жизнь отличается от строгих математических моделей и полна неопределённости.
Довольно часто встречается ситуация, когда паттерн нагрузки на данные вам совершенно неизвестен. В такой ситуации выбор чаще всего падает на класс хранения STANDARD.
Паттерн нагрузки может меняться со временем. Например, логи вчерашних транзакций более востребованы средствами анализа данных, чем прошлогодние логи. Или другой пример: у вас есть репозиторий ПО. Актуальная версия из него запрашивается часто. Когда выходит новая версия ПО, старая становится неактуальной и её артефакты можно хранить в более дешёвом классе.
Смешанная нагрузка, когда у данных неоднородный паттерн доступа. Например, одни файлы или объекты в бакете имеют частый доступ, а другие в том же бакете — архивные. В таком случае сложно управлять классом хранения для всех данных единообразно, так как каждый объект требует индивидуального подхода.
Непредвиденная нагрузка на архивные данные. Типичный случай для сценария репозитория ПО: выходит новая версия ПО, которая вдруг начинает использовать старую библиотеку, уже «охлаждённую» до ICE. Это приводит к повышенным расходам на доступ к данным.
Во всех этих случаях есть риск неверно выбрать класс хранения для бакета, неоптимально потратив средства. Избежать потери денег можно с помощью анализа и исследования паттернов работы с данными.
Такой инструмент должен уметь анализировать использование данных в прошлом и на основе текущей нагрузки предсказывать, насколько оптимальным будет продолжать хранить данные в тех же классах. Другими словами, он должен уметь реагировать на изменившийся паттерн доступа к данным, «прогревая» или «охлаждая» их.
В идеале такую аналитику нужно проводить для каждого объекта, чтобы определять оптимальный класс хранения. Принимая во внимание актуальность этого запроса, мы создали «Умное хранилище» (Intelligent Tiering), которое умеет автоматически оптимизировать затраты, перемещая данные между тремя уровнями хранения в зависимости от актуальных паттернов их использования.
Без такого инструмента в базовых классах хранения пользователь делает это самостоятельно вручную. По нашим наблюдениям, проводить такую аналитику и перемещения ресурсозатратно, поэтому зачастую данные хранятся в изначально выбранных классах хранения, а это может приводить к лишним затратам.
Разбираемся, как устроено «Умное хранилище»
Оно полностью избавляет пользователей от ручного управления классами хранения данных. При этом для пользователей сохраняется мгновенный доступ к любым данным за оптимально возможную цену. Производительность «Умного хранилища» независимо от уровнях хранения данных внутри остаётся такой же, как и в STANDARD.
Уровни хранения данных в «Умном хранилище» обозначаются другими названиями, чтобы не возникало путаницы с их аналогами — классами хранения в обычном хранилище. «Частый доступ», «Нечастый доступ», «Архивный доступ» в Intelligent Tiering соответствуют уже известным классам STANDARD, COLD и ICE.
Обычное хранилище
Уровни хранения в «Умном хранилище»
STANDARD
Частый доступ
COLD
Нечастый доступ
ICE
Архивный доступ
Стоимость хранения данных с частым доступом в обоих случаях будет одинаковой. Цена остальных опций, таких как операции с данными или их перемещение, будет различаться. В обычном хранилище нужно самостоятельно управлять переносом данных между классами хранения, а «Умное хранилище» делает это автоматически. Intelligent Tiering с помощью специальной (платной) функциональности определяет, как часто запрашивают объект, и в зависимости от этого «охлаждает» или «прогревает» его, то есть перемещает между тремя классами хранения: «Частый доступ», «Нечастый доступ», «Архивный доступ».
Экономим на редко используемых данных
Вот как работает алгоритм отслеживания паттерна доступа к файлам в бакете.
Отслеживание
Движок оптимизации в течении суток отслеживает для каждого объекта операции получения данных.
Охлаждение
Если объект находится в хранилище «Частый доступ» и за последние 30 дней после его создания не было ни одного дня с количеством обращений более ста, он перемещается в «Нечастый доступ». Автоматически меняется его тариф. Его хранение становится теперь более дешёвым, а операции с ним — более дорогими. Это оптимальная экономика, ведь объект читают мало.
Аналогично идёт охлаждение объектов из «Нечастого доступа» в «Архивный доступ». Если объект лежит в хранилище «Нечастый доступ» и за последние три месяца после его охлаждения количество обращений не превышало ста в день, он переводится в категорию «Архивный доступ». Ценообразование тут происходит аналогично предыдущему кейсу.
Прогрев
Если к объекту было более ста обращений за сутки, он прогревается до «Частого доступа». Это новая функциональность: прогрев не был предусмотрен в правилах жизненного цикла. Класс хранения можно было менять только на более «холодный».
Также в правилах жизненного цикла теперь вы можете настроить перенос данных из классов хранения STANDARD и COLD в Intelligent Tiering. Это инструмент миграции в Intelligent Tiering для уже загруженных данных.
«Умное хранилище»: разбираемся с деталями
В «Умном хранилище» есть дополнительная плата за анализ обращений к объектам и их перемещением между уровнями хранения. Но она компенсируется экономией за счёт более низкой цены хранения данных при их эффективном охлаждении. В типичных случаях выгода может превышать 50% на долгом горизонте хранения.
Здесь также нужно отметить, что за перемещение данных между уровнями хранения в «Умном хранилище» не берётся плата, аналогичная той, которая происходит при их движении между классами хранения по правилам жизненного цикла. Этим «Умное хранилище» выгоднее обычного.
При подсчётах общей стоимости хранения данных нужно учитывать, что за обработку данных в «Умном хранилище» предусмотрена плата, которая берётся за количество объектов, хранящихся в нём. В месяц она составляет 28 копеек за одну тысячу объектов.
Хранение гигабайта данных в хранилище «Частый доступ» стоит 2,376 рубля, а в «Архивном доступе» — 0,6336 рубля.
Тип хранилища
«Умное хранилище» (Intelligent Tiering)
STANDARD
COLD
ICE
Стоимость хранения (за ГБ в месяц)
От 0,6336 ₽/мес до 2,376 ₽/мес
2,376 ₽/мес
1,2672 ₽/мес
0,6336 ₽/мес
Запросы записи данных (PUT/POST/PATCH), 1 тыс. операций
0,5692 ₽
0,5692 ₽
1,39 ₽
2,79 ₽
Запросы получения списка (LIST)
0,5692 ₽
0,5692 ₽
1,39 ₽
2,79 ₽
Запросы чтения данных GET, 10 тыс. операций
От 0,46 ₽ до 2,30 ₽
0,46 ₽
1,15 ₽
2,30 ₽
Обработка данных в «Умном хранилище»
0,28 ₽/мес за 1 тыс. объектов.
За изменение уровня хранения внутри «Умного хранилища» плата не взимается.
—
—
—
Операции переноса данных (Transition) из другого в данный класс хранения
1,39 ₽ за 1 тыс. операций
—
1,39 ₽ за 1 тыс. операций
2,79 ₽ за 1 тыс. операций
Все тарифы по классам хранения можно посмотреть здесь.
Запросы записи данных (PUT/POST/PATCH), 1 тыс. операций
10 тыс. операций
Запросы получения списка (LIST)
10 тыс. операций
Запросы чтения данных GET, 10 тыс. операций
100 тыс. операций
За счёт максимального охлаждения «Частый доступ» → «Архивный доступ» одного гигабайта данных можно сэкономить 1,724 рубля в месяц. Если у вас хранится, например, тысяча объектов по одному мегабайту, то с учётом стоимости обработки данных общая экономия за месяц 1,724 − 0,28 = 0,14624 рубля. Это составляет 61,5% от первоначальной цены хранения в «Частом доступе».
Ещё в «Умном хранилище» есть дополнительная возможность экономить на операциях LIST. В классе хранения ICE такие операции в пять раз дороже, чем в STANDARD. В бакете «Умного хранилища» операции LIST всегда будут стоить максимально дёшево, как в STANDARD, независимо от того, как хранятся объекты внутри этого класса. Кроме того, операции PUT/POST (записи данных в хранилище) тоже будут стоить минимально.
Если использовать выгрузку метаданных объектов S3 Inventory, то можно ещё дополнительно сэкономить по сравнению с использованием операций LIST, а также получить информацию об уровне хранения каждого объекта в «Умном хранилище».
Выбираем оптимальную стратегию хранения
Выбор класса хранения в Yandex Object Storage — это не техническая, а экономическая задача, основанная на анализе паттернов доступа к данным. Ключевой компромисс заключается в балансе стоимости хранения гигабайта данных и стоимости операций доступа к ним.
Если вы точно знаете паттерн использования данных и уверены в его неизменности на протяжении времени, то стоит рассмотреть сразу прямую запись в нужный класс хранения.
«Умное хранилище» — это мощный инструмент для тех, кто хочет автоматизировать экономику хранения данных и минимизировать риски. Он подходит для ситуаций, когда паттерн нагрузки непредсказуем, смешан или меняется со временем. Система самостоятельно на уровне каждого объекта принимает решение о его переводе между доступами «Частый», «Нечастый» и «Архивный», основываясь на реальной частоте обращений и возможной длительности хранения.
Расчёт итоговой стоимости хранения в Intelligent Tiering становится несколько более сложным. Но за счёт охлаждения менее используемых данных эта опция даёт выгоду. При этом если данные начинают активно использоваться, то произойдёт их «прогрев».
Выбирайте «Умное хранилище» по умолчанию для новых проектов и данных с неизвестным паттерном нагрузки.
Используйте «Умное хранилище» для данных со смешанной или изменяющейся со временем нагрузкой.
Для существующих бакетов проведите аудит и примите взвешенное решение относительно использования конкретных классов хранения. В этом поможет S3 Inventory.
Обо всех деталях про новый класс хранения смотрите в документации.