Чек-лист: как посчитать эффективность и учесть все расходы облачного проекта

Два проекта могут хранить одинаковые 10 ТБ и получать совершенно разные счета, ведь на итог влияют количество объектов и API-запросов, исходящий трафик, версии, жизненный цикл, репликация, извлечение из архива и стоимость эксплуатации. В статье разберем, как составить честную модель TCO и не выбрать «дешевое» хранилище, которое окажется дорогим на реальной нагрузке.

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

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

Например, Yandex Object Storage, Selectel и AWS S3 включают отдельные компоненты для операций и сетевого трафика, а кто-то из провайдеров не тарифицирует прямой исходящий трафик, но учитывает классы операций. В горячем S3-хранилище PC-Storage тарификация строится вокруг занятого объема без отдельной платы за запросы и исходящий трафик. Поэтому правильнее рассчитывать стоимость с учетом количества ваших объектов, характера чтения и записи, а также требованиями к выдаче, резервированию и срокам восстановления.

Формула следующая:

• TCO месяц = хранение + операции + извлечение + трафик + надстройки + эксплуатация + амортизация миграции + стоимость риска

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

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

1. Средний размер объекта

• Средний размер объекта = физический объем / количество объектов

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

Если средний объект меньше 128 КиБ или количество объектов измеряется сотнями миллионов, отдельно смоделируйте стоимость операций, lifecycle-переходов, листинга, инвентаризации и минимального тарифицируемого размера. Порог 128 КиБ не универсален, но удобен как первый индикатор риска.

2. Чтения на объект

• Чтения на объект = (GET + HEAD) / среднее количество объектов

Этот показатель отделяет «лежалые» данные от активно обслуживаемого каталога. В публичной модели, где GET и HEAD тарифицируются, десять миллионов запросов к маленьким файлам могут стоить заметнее, чем их хранение. Стоимость API-запроса может не зависеть от размера объекта, а может учитываться GET на 1 КиБ и GET на 1 МиБ по-разному.

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

3. Коэффициент выдачи

• Коэффициент выдачи = исходящий трафик за месяц / средний объем данных

Коэффициент показывает, сколько раз за месяц условно «выдается весь объем». Значение 0,02 характерно для малоиспользуемого архива: из 100 ТБ читается около 2 ТБ. Значение 5 означает, что при среднем объеме 20 ТБ наружу передается 100 ТБ. Для публичного каталога, мобильного приложения или дистрибуции обновлений трафик может превысить хранение по экономическому влиянию.

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

4. Интенсивность изменений

• Интенсивность изменений = (PUT + COPY + DELETE) / среднее количество объектов

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

5. Множитель версий

• Множитель версий = физический объем всех версий / объем актуальных данных

Версионирование защищает от случайной перезаписи и удаления, но меняет экономику. Например, если логический объем актуальных данных равен 10 ТБ, ежемесячно обновляется 20% массива, а старые версии сохраняются шесть месяцев, упрощенная модель дает еще около 12 ТБ неактуальных версий. Физический объем становится примерно 22 ТБ, а множитель версий = 2,2. Реальный результат зависит от повторного изменения одних и тех же объектов и правил удаления, однако направление эффекта очевидно.

В расчет также должны попадать delete markers, временные копии, результаты обработки и части незавершенных multipart-загрузок. Важно, что незавершенные части занимают место до завершения или прерывания загрузки.

6. Доля холодного извлечения

• Доля холодного извлечения = объем чтения из холодного класса / объем данных в холодном классе

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

Сценарий 1. Сто терабайт резервных копий

Компания хранит 100 ТБ резервных копий, ежедневно добавляет инкременты и раз в месяц создает полную копию. В обычном режиме данные почти не читаются, но раз в квартал проводится проверка восстановления. Здесь количество пользовательских GET невелико, а исходящий трафик близок к нулю. Основными факторами становятся средний физический объем за расчетный период, длительность восстановления, число копий и стоимость аварийного извлечения.

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

Что вы должны знать о бэкап-системе:

• средний размер полного и инкрементального бэкапа;
• коэффициент дедупликации;
• число точек восстановления;
• объем ежемесячного тестового восстановления;
• ожидаемый RTO;
• срок неизменяемости;
• долю неуспешных и незавершенных заданий.

Сценарий 2. Десять терабайт изображений и публичных файлов

Представим, что интернет-магазин хранит 10 ТБ изображений, инструкций и статических файлов. Каталог ежедневно просматривают миллионы пользователей. Логический объем невелик по сравнению с бэкапом, но каждое открытие страницы создает десятки обращений. Без CDN главной строкой расходов может стать исходящий трафик; а при высокой доле раздачи данных через кэширующие сервера – запросы к CDN и origin-трафик.

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

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

Сценарий 3. Десять терабайт логов по одному килобайту

Те же 10 ТиБ при среднем объекте в 1 КиБ – это около 10,7 млрд объектов. Каждая запись становится отдельным PUT, инвентаризация и lifecycle могут выполнять действия на миллиардах ключей, а переход в класс с минимальным тарифицируемым размером способен увеличить расчетный объем на порядки.

Здесь оптимизация завязана на архитектуре данных: буферизации, пакетной записи, «уплотнение» данных, форматов Parquet/ORC для аналитических сценариев, разумной гранулярности префиксов и отказа от перехода каждого микрофайла между классами.

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

Низкая ставка за хранение в архивном классе компенсируется ограничениями:

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

Минимальная длительность зависит от класса и, как правило, составляет от 30 до 365 дней; раннее удаление может тарифицироваться как хранение до окончания минимального срока. Например, в AWS для ряда классов действуют сроки 30, 90 или 180 дней и минимальный размер объекта. А вот в PlatformCraft платы за срок хранения нет.

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

Правило выбора класса

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

CDN не заменяет хранилище, но меняет профиль обращений к нему. При попадании в кэш пользователь получает файл с edge-узла, поэтому origin не обслуживает повторный GET и не передает весь объем данных. Экономический эффект зависит от четырех параметров:

1. Коэффициент попадания в кэш (cache hit ratio);
2. Размера объекта;
3. Срока кэширования;
4. Модели тарификации трафика между CDN и origin.

Высокий процент попаданий (hit ratio) не возникает автоматически. Его снижают слишком короткий TTL, уникальные query-параметры в URL, частая перезапись объектов по одному ключу, персонализированные заголовки и отсутствие прогрева перед пиком. Поэтому в модели нужно иметь две строки: «трафик пользователям через CDN» и «трафик от хранилища к CDN».

• Исходный трафик = пользовательский трафик × (1 – коэффициент попадания в кэш)

Например, при пользовательской выдаче 100 ТБ и cache hit ratio 95% хранилище передаст около 5 ТБ, не считая обновлений и принудительного очищения. Если провайдер не тарифицирует исходящий трафик, CDN по-прежнему может быть необходима для задержки, географии и защиты origin, но экономический аргумент смещается с трафика на производительность и устойчивость.

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

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

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

Метрики эффективности

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

Пилот важнее калькулятора

Пилот покажет, какие запросы действительно генерирует приложение, насколько эффективен CDN-кэш, сколько частей оставляют неуспешные multipart-загрузки и какую скорость обеспечивает реальная сеть. Поэтому до долгосрочного договора полезно провести короткий тест на репрезентативной выборке:

1. Выберите один рабочий набор – каталог изображений, недельный поток бэкапов или фрагмент логов.
2. Перенесите структуру ключей и метаданных без искусственного укрупнения или упрощения.
3. Включите версионирование, lifecycle, аудит и CDN так, как они будут работать в production.
4. Снимите фактические объемы, количество GET/PUT/HEAD/LIST, трафик, коэффициент попадания в кэш и незавершенные multipart-загрузки.
5. Смоделируйте пик и восстановление, а не только спокойную ежедневную работу.
6. Пересчитайте месячный бюджет на фактических коэффициентах и добавьте запас роста.

Результатом должен стать понятный перечень нагрузки, подтвержденная совместимость, измеренная производительность, тест восстановления и прогноз счета с понятной погрешностью.

PC-Storage – S3-совместимое объектное хранилище PlatformCraft. В хранилище реализованы IAM, multipart upload, lifecycle, ACL, Bucket Policy, Versioning, Object Lock и предподписанные ссылки; конкретную совместимость требуемых методов следует подтверждать на тесте, но так как ПО полностью написано разработчиками компании, интеграция возможна практически с любым решением.

Горячее объектное хранилище PC-Storage ориентировано на активно используемые данные с оплатой за объем хранения без отдельного учета запросов, трафика и внутренних операций. А вот PC-Storage Cold предназначено для «холодных» данных с редким доступом и тарификацией по исходящему трафику и запросам.

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

А для медиаконтента PlatformCraft предлагает PC-Media, это платформа для обработки и раздачи контента (через CDN).

Не забудьте перед расчетом:

1. Мы знаем объем и количество объектов и их распределение по размерам.
2. Мы различаем логический объем полезных данных и физический объем с версиями, репликами и временными объектами.
3. Мы измерили или оценили PUT, GET, HEAD, LIST, COPY и lifecycle операции.
4. Мы посчитали исходящий трафик до CDN и origin-трафик после кэширования.
5. Мы смоделировали массовое восстановление из холодного класса.
6. Мы проверили минимальный размер объекта, минимальный срок хранения и раннее удаление.
7. Мы включили в модель версионирование, Object Lock, soft delete и multipart parts.
8. Мы сравниваем решения с одинаковыми SLA, RPO, RTO и режимом поддержки.
9. Мы учли миграцию, период двойной эксплуатации и стоимость выхода.
10. Мы проверили, какие надстройки тарифицируются отдельно: репликация, аналитика, аудит, инвентаризация.
11. Мы нормализовали НДС, валюту, округление, бесплатные лимиты и скидки.
12. Мы рассчитали минимум три сценария: базовый, рост и аварийный пик.
13. Мы провели пилот на реальном профиле, а не только тест загрузки одного файла.
14. Мы назначили владельца данных и правила удаления неиспользуемых объектов.
15. Мы контролируем коэффициент предсказуемости: фактический счет относительно прогноза.

Что сильнее всего влияет на стоимость объектного хранилища?

Это зависит от профиля. В архиве обычно доминирует физический объем и срок хранения, в публичном каталоге – трафик и GET, в системе с миллиардами маленьких файлов – количество операций и минимальный тарифицируемый размер, а при активном версионировании – объем старых версий.

Можно ли сравнивать провайдеров по цене за гигабайт?

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

Почему количество файлов влияет на стоимость, если общий объем не меняется?

Многие действия тарифицируются или выполняются на каждый объект: PUT, GET, LIST, lifecycle transition, инвентаризация. Кроме того, некоторые классы используют минимальный тарифицируемый размер или служебные метаданные на объект.

Какие запросы чаще всего забывают посчитать?

HEAD и LIST. Их генерируют панели управления, синхронизация, бэкап-системы, SDK и алгоритмы проверки существования. Также пропускают COPY, multipart parts и lifecycle transitions.

Как версионирование увеличивает расходы?

При перезаписи старая версия остается в хранилище. Без срока удаления noncurrent versions физический объем может в несколько раз превысить размер актуальных данных.

Всегда ли холодное хранение дешевле?

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

Как CDN снижает затраты хранилища?

CDN обслуживает повторные запросы с edge-кэша. Origin-трафик примерно равен пользовательскому трафику, умноженному на единицу минус cache hit ratio. Однако конкретная экономия зависит от тарифов CDN и хранилища.

Что такое множитель версий?

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

Нужно ли учитывать незавершенные multipart-загрузки?

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

Как оценить стоимость миграции?

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

Какой период брать для прогноза?

Минимум 12 месяцев с помесячным ростом и сезонностью. Для закупки или on-premise-сравнения полезен горизонт 3-5 лет, но тарифные предположения нужно регулярно пересматривать.

Зачем проводить пилот, если есть калькулятор?

Калькулятор не знает реальное число HEAD/LIST, поведение SDK, cache hit ratio, долю ошибок и физический множитель версий. Пилот превращает предположения в измеренные коэффициенты.

В чем особенность расчета горячего PC—Storage?

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

Когда холодный PC—Storage может быть предпочтительнее?

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

Какой главный KPI у хорошей модели стоимости?

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