Как посчитать реальную стоимость хранения данных в разрезе 3–5 лет?

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

Разберем, какие цифры для этого нужны.

Начать можно с простого вопроса: сколько данных компания хранит сейчас? Для этого нужно еще понять, что именно считать. Например, считается, что в компании 500 ТБ данных, при этом инфраструктурная команда может видеть:

В результате фактически оплачивается уже 800 ТБ, поэтому для расчета лучше разделить данные хотя бы на несколько групп:

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

Второй параметр, который сильно влияет на долгосрочный бюджет, это скорость роста. Самый простой способ понять какая цифра будет в разрезе ближайшего года – посмотреть объем хранилища в двух точках, например год назад (было, допустим, 800 ТБ) и сейчас (скажем, 920 ТБ).

То есть за год объем увеличился на 120 ТБ, или на 15%.

Но одного сравнения за год иногда недостаточно. У того же интернет-магазина объем может резко расти перед сезоном, у медиапроекта после запуска нового сервиса, а у компании с резервными копиями объем вырастит после изменения политики их хранения. Поэтому лучше взять данные хотя бы за последние 6-12 месяцев и посмотреть прирост по месяцам.

Например:

Следовательно, средний прирост составляет около 9,5 ТБ в месяц. Такой показатель уже можно использовать для прогноза.

При этом важно считать чистый прирост, а не количество записанных за месяц данных. Если за месяц в хранилище загрузили 50 ТБ, но 40 ТБ старых данных удалили, фактический рост составит только 10 ТБ.

Если компания выросла на 30% за последний год и сразу закладывает такой же рост на следующие пять лет, то в итоге она получит красивый, нереалистичный расчет, который не даст точную цифру. Лучше сделать три сценария:

Например, если сегодня хранится 1 ПБ, можно отдельно посмотреть сценарии роста на 10%, 20% и 30% в год. Так компания получает не одну цифру бюджета, а диапазон, и для планирования на 3-5 лет он будет полезнее.

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

Поэтому важно установить для каждой категории данных срок хранения (для каких-то – 30 дней, для каких-то – год). Конкретные сроки зависят от задач бизнеса и требований законодательства, это не так уж важно, главное чтобы у данных был понятный жизненный цикл, по истечению которого их точно удалят.

Это позволит понимать и влиять на расходы без смены поставщика или инфраструктуры.

Если у вас «1 ПБ данных» это еще не значит, что вам понадобится ровно 1 ПБ хранилища.

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

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

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

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

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

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

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

Есть параметр, который редко появляется в первой версии финансового расчета – пропускная способность. Даже если вас устраивает стоимость хранения большого архива данных, нужно понимать, сколько будет стоить «вернуть» эти данные из облачного хранилища?

При ограниченной пропускной способности восстановление сотен терабайт может занять дни и даже недели, поэтому со стоимостью оценивайте также:

И бывает, что именно требуемое время восстановления определяет архитектуру хранилища.

Для первого приблизительного просчета достаточно семи параметров:

После этого можно построить прогноз по каждому году. Например: сейчас 1 ПБ; через год = текущий объем + чистый годовой прирост; через два года = предыдущий результат + новый прирост и так далее.

Для более аккуратной модели стоит учитывать и удаление данных, и срок хранения резервных копий и перевод старой информации в архив.

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

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

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

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