Каждый год объем данных в мире растет на 24.4%. По прогнозам IDC, в 2025 году человечество должно было сгенерировать 175 зеттабайт данных. Исследование показывает, что значительный рост хранения данных за последние годы приходится на публичные облака.

В облаках стандартом для хранения этих массивов стал S3 (Simple Storage Service). Он подкупает своей простотой и дешевизной на старте. Но в этом и кроется ловушка: как только объем данных переваливает за терабайты, а количество запросов — за миллионы, счета начинают «кусаться».

Разберем на примере Яндекс Облака, какие рычаги управления стоимостью (FinOps) у нас есть и как навести порядок в бакетах, пока они не съели ваш бюджет. 

Горячо — холодно. Где хранятся ваши данные?

Выбор класса хранения — самый мощный инструмент оптимизации. В Яндекс Облаке их три, и разница в стоимости хранения между классами может быть почти четырехкратной.

Чтобы проиллюстрировать, за счет чего может случиться или не случиться экономия, я приведу таблицу сравнительной стоимости. Т.е. это таблица коэффициентов цен классов относительно цены Стандартного хранилища. Сам прайс-лист Яндекс Облака вы найдете на сайте. 

По таблице можно вывести простое правило: если к данным обращаются часто — выбираем Стандарт. Если редко — Холодное. Если это долгосрочный архив или данные, которые вы обязаны хранить, — Ледяное.

Важно: Переход в Ледяное хранилище накладывает обязательство по оплате хранения на 12 месяцев вперед. Удалите или измените объект раньше — все равно заплатите за оставшийся срок. 

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

Автоматизация: политики управления жизненным циклом

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

Вы можете настроить правила на основе:

• Срока хранения (количество дней с момента создания объекта)

• Размера файлов

• Версии файлов

• Префиксов и тегов.

Правила можно назначить как из графического интерфейса в настройках бакета, так и через S3 CLI или YС CLI.

Скрытые «пожиратели» бюджета

Есть два фактора, которые раздувают бакеты незаметно для мониторинга.

А. Части многосоставных загрузок (Multipart Uploads)

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

Решение: Настройте политику автоматического удаления незавершенных составных загрузок (например, через 7 дней).

Б. Версионирование без контроля

Версионирование — это важный инструмент для защиты от ошибок и для обеспечения комплаенса. Но если вы перезаписываете файл весом 10 МБ сто раз в день, у вас в бакете незаметно вырастет почти до 1 ГБ данных. 

Решение: Используйте параметр NoncurrentVersionExpiration для автоматического архивирования или удаления старых версий (например, через 7–30 дней).

Цена запросов

Для анализа ценообразования операций приведем нормированную таблицу цен. В оригинальном прайс-листе Яндекс Облака цены могут быть указаны за 1 тыс. или 10 тыс. запросов. В таблице ниже цены нормированы к 10 000 операций для удобства сравнения цен транзакций.

Цена в рублях за 10 000 операций (после нетарифицируемого лимита)

Часто S3 используют как базу данных или очередь, постоянно вызывая операцию LIST для проверки наличия новых или поиска старых файлов. Это анти-паттерн.

Почему это плохо:

• Операция LIST обладает низкой производительностью и плохо масштабируется при росте числа объектов в бакете.

• Операции типа LIST стоят в разы дороже, чем GET.

• В холодном и ледяном классах стоимость этих операций возрастает в 2.5 и 5 раз соответственно.

Рекомендация экспертов, как быть: переносить логику отслеживания файлов (Control Plane) на сторону приложения или используйте очереди сообщений. Доклад о том, как избежать распространенных ошибок.

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

План аудита Object Storage: 6 шагов к экономии

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

Яндекс Облако предлагает разнообразный набор инструментов для анализа бакетов, это и консоль облака, aws s3api, Yandex Cloud CLI, браузерные решения, S3 Inventory и многие другие. Информацию часто можно получить более чем одним способом.

Шаг 1. Инвентаризация активов

Прежде всего нужно понять масштаб инфраструктуры. Собираем список всех бакетов в каталоге.

В консоли: Раздел Object Storage -> Список бакетов.

YC CLI:

yc storage bucket list

Пример результата:

+------------------+----------------------+-------------+-----------------------+---------------------+

| NAME             | FOLDER ID            | MAX SIZE    | DEFAULT STORAGE CLASS | CREATED AT          |

+------------------+----------------------+-------------+-----------------------+---------------------+

| first-bucket     | b1gmit33ngp6******** | 53687091200 | STANDARD              | 2022-12-16 13:58:18 |

+------------------+----------------------+-------------+-----------------------+---------------------+

Шаг 2. Анализ объемов и структуры данных

Оцениваем общее использование ресурсов и лимиты. Для визуализации постройте график, где X — средний размер объекта, Y — количество объектов, а размер пузырька — общий объем бакета.

Такую визуализацию легко можно повторить подручными средствами (Excel, DataLens или Python).

Как получить данные:

yc storage bucket stats <имя_бакета> 

Пример результата: 

name: first-bucket

max_size: "5368709120"

used_size: "621552"

storage_class_used_sizes:

  - storage_class: STANDARD

    class_size: "607467"

  - storage_class: COLD

    class_size: "14085"

storage_class_counters:

  - storage_class: STANDARD

    counters:

      simple_object_size: "607467"

      simple_object_count: "41"

  - storage_class: COLD

    counters:

      simple_object_size: "14085"

      simple_object_count: "16"

default_storage_class: ICE

anonymous_access_flags:

  read: false

  list: false

  config_read: false

created_at: "2023-04-10T19:41:30.266075Z"

updated_at: "2023-08-02T04:05:44.564924Z"

Далее можно применить следующую эвристику для определения наиболее перспективных кандидатов на оптимизацию:

Шаг 3. Анализ паттернов доступа (Мониторинг vs Биллинг)

Сопоставьте объем хранилища и количество запросов. Если данных много, а запросов мало — пора переходить на «холодные» классы (Cold/Ice Storage).

Как может выглядеть визуализация паттерна доступа к данным: 

• Источники данных:

  1. Секция мониторинга на странице бакета: Стандартные дашборды. 

  2. Биллинг: Ищем строки с service_name: Object Storage и отдельно анализируем трафик VPC. Важно: для точного сопоставления используем resource id для определения конкретных бакетов, генерирующих трафик и запросы. Поля pricing_quantity показывают количество тарифицируемых единиц запросов и скачанных ГБ.

  3. Логирование: Если нужен более детальный анализ (к каким именно файлам, кто и как обращался), включите сбор логов в отдельный бакет. Делается на странице бакета во вкладке “Логирование”.

Внимание: хранение логов при больших объемах само по себе может стать статьей расходов.

Шаг 4. Проверка жизненного цикла (Lifecycle Policies)

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

Как проверить:

• В консоли: Страница настроек бакета -> Жизненный цикл.

• AWS CLI (совместимый метод):

aws s3api get-bucket-lifecycle-configuration \

  --bucket <имя_бакета> \

  --endpoint-url https://storage.yandexcloud.net

Пример результата: 

{

    "Rules": [

        {

            "Expiration": {

                "Days": 30

            },

            "Filter": {

                "And": {

                    "Prefix": ""

                }

            },

            "Status": "Enabled",

            "AbortIncompleteMultipartUpload": {

                "DaysAfterInitiation": 7

            }

        }

    ]

}

Шаг 5. Контроль версионирования и незавершенных загрузок

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

• Чек-лист:

  1. Статус версионирования: Проверяем через yc storage bucket get <имя_бакета> --full. Если версионирование включено, будет виден параметр versioning: VERSIONING_ENABLED. Тогда проверяем, а настроены ли политики управления жизненным циклом версий.

  2. Multipart Uploads: Убедитесь, что части прерванных загрузок не копятся месяцами. Для их очистки обязательно должна быть настроена Lifecycle-политика AbortIncompleteMultipartUpload.

Команда  вернет список частично загруженных объектов:

yc storage s3api list-multipart-uploads \

  --bucket <имя_бакета>

Шаг 6. Оптимизация трафика и типов операций

Последний штрих — анализ того, как приложение общается с хранилищем.

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

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

• Форматы данных: Рассмотрите переход на аналитические форматы (например, Parquet). Это позволит использовать S3 не просто как «диск», а как основу для аналитики (S3 Select / Yandex Query), экономя на объеме считываемых данных.

• Объединение файлов небольшого размера в единый архив может сократить расходы на хранение и перемещение между классами.

Вывод

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

1. Оптимизация хранения: Выбирайте класс хранения (Стандартное, Холодное, Ледяное) в зависимости от частоты доступа.

2. Автоматизация и очистка: Используйте политики жизненного цикла (Lifecycle Policies) для автоматического перевода данных в более дешевые классы и обязательной очистки старых версий файлов и незавершенных многосоставных загрузок.

3. Контроль операций и трафика: Минимизируйте количество низко производительных операций типа LIST, перенося логику отслеживания на сторону приложения, и следите за трафиком, идущим через интернет, который является ключевым фактором в итоговой стоимости запросов.