Корпоративное хранилище данных (КХД) — один из ключевых компонентов любой ИТ-системы, который необходим для безопасного хранения и использования всех данных компании. Но построение КХД нередко превращается в «задачу со звездочкой» еще на этапе выбора платформы для развертывания: многим компаниям сложно определить, какой из вариантов будет не только надежнее, но и дешевле.
В этой статье попробуем в деталях и на примерах разобрать, какой вариант развертывания экономически рентабельнее и что стоит учитывать при выборе платформы для построения КХД.
Материал подготовлен директором центра бизнес-решений VK Tech Константином Дудниковым и директором по развитию облачного бизнеса Группы Arenadata Антоном Близгаревым @beton55
Немного «базы»
Облачная платформа — виртуальная ИТ-инфраструктура, которая принадлежит провайдеру, а компании-клиенту предоставляется в аренду в нужном объеме. В облаке каждый сервис, инструмент и даже компонент ИТ-инфраструктуры — услуга, которая оплачивается либо по факту потребления (модель Pay-as-you-go), либо по подписке (например, на месяц за одну инсталляцию).
On-premise — локальная инфраструктура, которая строится на базе серверов компании и полностью ей контролируется. Вместе с полным контролем On-premise предполагает и полную ответственность за обслуживание мощностей: покупку оборудования, его замену, модернизацию, обслуживание, расширение пула дисков и процессоров.
Таким образом, облако — это больше про операционные расходы (OPEX), а On-premise-реализации — про капитальные вложения (CAPEX).
Суть сравнения
ИТ-инфраструктура компаний строится не на один месяц и даже не на один год, поэтому сравнивать затраты в формате «здесь и сейчас» не совсем рационально — куда интереснее и объективнее сравнивать затраты в разрезе хотя бы нескольких лет. И с этим у компаний часто возникают трудности.
Чтобы получить наглядную картину, предлагаю сравнить общую стоимость владения (ТСО) локальной и облачной инфраструктурой с учетом стоимости аппаратного и программного обеспечения. Чтобы исключить влияние разницы цен у разных вендоров, как для On-premise-реализации, так и для облачных инсталляций будем рассматривать компоненты от компании Arenadata, одинаково доступные и там и там.
Примечание: Суммы, указанные в статье, рассчитаны при цене доллара в 91,64 р. Он может отличаться от текущего, но не повлияет на общую картину — соотношение останется прежним.
Итак, начнем с локальной инфраструктуры.
Локальная инфраструктура
Начнем с аппаратной спецификации Arenadata DB (ADB).
Здесь возможно несколько конфигураций.
Узел кластера Arenadata DB: Master Server, конфигурация которого состоит:
из CPU: 36/48 cores (2 x 18 или 2 x 24, 2.4+ GHz) HT enabled, Intel Cascade Lake (R) Gold;
RAM: не менее 512 GB;
Storage: 2 x 480 GB HDD / SSD RAID1 for OS + 2 x 3.84TB SAS12G SSD MixedUse RAID1;
Network: 2 x 10/25 Gbps (PCIe Gen3 x4) + 2 x 50 Gbps (PCIe Gen3 x8);
Bare Metal.
Узел кластера Arenadata DB: Segment Server, «под капотом» у которой:
CPU: 48 cores (2 x 24, 2.4+ GHz) HT enabled, Intel Cascade Lake (R) Gold;
RAM: не менее 768 GB;
Storage: 2 x 480 GB HDD / SSD RAID1 for OS + 24 x 1.6 TB SAS12G SSD MixedUse RAID0;
Network: 2 x 10/25 Gbps (PCIe Gen3 x4) + 2 x 50 Gbps (PCIe Gen3 x8);
Bare Metal.
Узел кластера Arenadata DB: Master Server с конфигурацией:
CPU: 4-6 vCores (1 pCore with HT enabled = 2 vCore), Intel Cascade Lake (R) 62xx;
RAM: 48 GB;
SDS / Storage: 250 GB HDD for OS + 1.2 TB SSD for Data;
Network: 1 x 10 Gbps;
Virtual.
Узел кластера Arenadata DB: Segment Server, конфигурация которого включает:
CPU: 8 vCores (1 pCore with HT enabled = 2 vCore), Intel Cascade Lake (R) 62xx;
RAM: 64 GB;
SDS / Storage: 250 GB HDD for OS + 4 TB SSD/NVME for Data;
Network: 1 x 10 Gbps.
Расчет стоимости конфигурации
С учетом доступных типов узлов кластера и конфигураций аппаратного обеспечения узлов, можно рассчитать примерную стоимость локальной ИТ-инфраструктуры под кластер Arenadata DB для развертывания корпоративного хранилища данных для условного Enterprise-ритейлера.
При расчете учитываем стоимость каждого отдельного продукта.
Программное обеспечение:
Название | Тип | Программа | Ед. изм. | Период лицензии | Цена с НДС, ₽ | Кол-во ядер | Сумма без НДС, ₽ |
|---|---|---|---|---|---|---|---|
ADB | Prod | PL | 1 ядро | Бессрочная | 345 000 | 864 | 298 080 000 |
ADB | Prod | Supp PL 24x7 | 1 ядро | 3 года | 248 400 | 864 | 214 617 600 |
ADB | Dev | PL | 1 ядро | Бессрочная | 172 500 | 8 | 1 380 000 |
ADB | Dev | Supp PL 8x5 | 1 ядро | 3 года | 62 100 | 8 | 496 800 |
Итого | 514 574 400 |
Аппаратное обеспечение
Название | Количество | Цена за единицу, ₽ | Общая сумма, ₽ | |
|---|---|---|---|---|
Группа 1 | master_PowerEdge R650 - Full Configuration - [EMEA_R650] | 2 | 3 827 547,64 | 7 655 095,28 |
Группа 1 | segment_PowerEdge R750 - Full Configuration - [EMEA_R750] | 18 | 9 360 968,80 | 168 252 238,08 |
Группа 1 | virt-dev_PowerEdge R650 - Full Configuration - [EMEA_R650] | 1 | 2 747 747,84 | 2 747 747,84 |
Группа 1 | adcc_PowerEdge R650 - Full Configuration - [EMEA_R650] | 1 | 2 213 735,87 | 2 213 735,87 |
Итого | 181 869 817,07 |
Таким образом, КХД с 18 узлами на локальной инфраструктуре может обойтись компании в 700 млн рублей уже на старте.
Облачная инфраструктура
При развертывании КХД в облаке под аналогичные задачи условного крупного ритейлера подойдет следующая целевая конфигурация.
Тип узла | vCPU | SSD, Тб | RAM, Гб | Количество |
|---|---|---|---|---|
Prod. — выделенные серверы | ||||
Мастер | 48 | 7,5 | 64 | 2 |
Сегмент-нода | 104 | 175,6 | 624 | 8 |
Dev. виртуальные машины | ||||
Мастер | 8 | 0,5 | 64 | 2 |
Сегмент-нода | 48 | 7,5 | 624 | 2 |
Итого | 208 | 30,8 | 1340 | 14 |
При этом:
стоимость 1 Тб SSD — 14 300 ₽;
стоимость 1 Гб RAM — 1 200 ₽;
стоимость 1 ВЧ — 765 ₽ в месяц.
Исходя из этого целевая конфигурация будет обходиться компании-клиенту в 104,083,200 ₽ в год с НДС.
Отдельно оплачивается программное обеспечение. Здесь также учитываем, что нужно выстроить конфигурацию, которая будет аналогична рассмотренной выше реализации под локальную инфраструктуру.
Продукт | Версия | Тип | Программа | Ед. изм. | Период | Цена с НДС, ₽ | Кол-во ядер | Сумма с НДС, ₽ |
|---|---|---|---|---|---|---|---|---|
ADB | Enterprise | Prod | Временная лицензия с гарантийной поддержкой | 1 Тб | 1 месяц | 27 500 | 300 | 9 250 000 |
ADB | Enterprise | Dev | Временная лицензия с гарантийной поддержкой 8x5 | 1 Тб | 1 месяц | 10 600 | 8 | 84 800 |
Итого | 9 084 800 |
То есть развертывание и использование аналогичного КХД в облаке будет стоить нашему условному Enterprise-ритейлеру около 200 млн рублей в год.
Неочевидные факторы
В большинстве случаев компании делают выводы именно на основании приведенных выше расчетах или подобных им. Тут вроде как логично: за 3,5 года суммарные затраты на реализацию в облаке достигают значения CAPEX при построении локальной инфраструктуры и дальше преимущество экономии нивелируется. Но на практике это не так — есть много факторов, которые могут существенно повлиять на итоговую стоимость, удобство и безопасность работы с данными.
Неиспользование оборотных средств
Облачная модель позволяет компаниям не «замораживать» значительные суммы в собственном оборудовании и лицензиях, а направлять их в основные бизнес-процессы с более быстрой оборачиваемостью.
Одновременно с этим, в On-premise закупка и установка «железа» требуют крупных единовременных инвестиций, которые могли бы приносить дополнительную прибыль, оставаясь в обороте.
Причем объем упущенной выгоды вполне можно посчитать, используя формулу:
где:
а — коэффициент оборачиваемости средств за год (сколько можно заработать с одного рубля);
y — стоимость локальной инфраструктуры;
X — стоимость облака в месяц;
N — количество месяцев, после которых расходы на облако сравняются с затратами на локальную инфраструктуру.
При среднегодовой оборачиваемости 20% (0,2) инвестированные в «железо» средства за 1 год могли бы принести незаработанные 98 307 361 ₽, за 2 года — 57 493 761 ₽, а за 3 года — 16 680 161 ₽, суммарно 172 481 282 ₽.
Эти суммы приблизительно соответствуют 10 месяцам использования облака при равной производительности.
Инфляция
В условиях инфляции в диапазоне 7–15% в год (что за четыре года может достигать совокупных 40%) крупные разовые инвестиции в собственное оборудование и лицензии рискуют обесцениться.
Более того, сопутствующие услуги (запчасти, электричество, сервисные контракты) обычно дорожают быстрее, чем растет базовый уровень инфляции. Это увеличивает итоговые расходы на владение локальной инфраструктурой.
Причем итоговое «подорожание владения» при постоянном росте цен на протяжении трех лет (упомянутая окупаемость инвестиций за 3,5 года) часто эквивалентно нескольким месяцам потребления облачного сервиса аналогичной мощности.
Одновременно с этим при использовании облака значительная часть инфляционных рисков ложится на провайдера: пользователь платит лишь по мере потребления услуг, а цена аренды возрастает плавно и прозрачнее, чем единовременные расходы на модернизацию собственного «железа».
Обеспечение отказоустойчивости
Чтобы обеспечить высокую доступность и защиту данных в On-premise-реализациях, компаниям нужен резервный сервер с репликацией и полноценная система бэкапа. Нередко это означает, что надо поднимать три аналогичные инфраструктуры и умножать на три все соответствующие затраты. К примеру, при исходных затратах в 181 030 403 ₽ итоговая стоимость может достигать 543 091 209 ₽. И это еще без учета увеличения стоимости владения за счет инфляции и сопутствующих затрат.
При аренде облака механизмы резервирования и репликации зачастую уже включены или оплачиваются по модели pay-as-you-go, что позволяет избежать кратного увеличения капитальных затрат и упростить обеспечение отказоустойчивости.
Обеспечение безопасности данных
При построении On-premise-инсталляции КХД компании самостоятельно управляют данными, в том числе отвечают за разработку и внедрение мер защиты. Это важно для обработки данных, подпадающих под строгие нормативные требования (гостайна, критическая инфраструктура). Но затраты на сертификацию, обеспечение соответствия требованиям корпоративных регламентов и регуляторов, и другие аспекты могут достигать 100 млн рублей. Это эквивалентно примерно 6 месяцам потребления облачного сервиса.
В случае облака провайдеры предоставляют встроенные механизмы защиты, включая сертифицированные системы информационной безопасности, такие как защита от DDoS-атак, резервирование и управление угрозами. Например, облачные провайдеры в России часто соответствуют стандартам PCI DSS и 152-ФЗ на высшем уровне защищенности (УЗ-1) для работы с персональными данными, что закрывает большинство потребностей стандартных клиентов.
Неиспользуемые мощности
Локальная инфраструктура работает круглосуточно, даже если фактическая нагрузка на нее составляет лишь малую часть времени. Например, при стандартном графике работы с 9:00 до 18:00 с понедельника по пятницу общее количество рабочих часов в месяц составляет 196, то есть всего 26% от всего времени. Остальные 74% времени ресурсы остаются неиспользованными, но продолжают потреблять электроэнергию и требуют поддержки, поскольку в On-premise невозможно «выключить» серверы на выходные или ночью.
В облаке оплачиваются только фактически затраченные мощности, то есть можно гибко регулировать потребление, снижая затраты в нерабочие часы.
Зависимость от квалифицированных специалистов
Локальная инфраструктура требует наличия целой команды специалистов, которые будут управлять кластерами, обслуживать оборудование и устранять сбои. Средняя зарплата таких специалистов, включая налоговую нагрузку, может достигать 18–30 миллионов рублей в год для команды из пяти человек.
При развертывании КХД в облаке эти затраты существенно ниже, поскольку вендор предоставляет уже готовую инфраструктуру и техническую поддержку, что позволяет компаниям минимизировать внутренние затраты на фонд оплаты труда.
Масштабируемость и гибкость
Облачные решения предоставляют возможность масштабирования инфраструктуры без значительных затрат времени и ресурсов. Например, увеличивать или уменьшать количество узлов в аналитическом контуре можно практически мгновенно, оплачивая только те ресурсы, которые реально используются.
В отличие от этого, локальная инфраструктура требует дополнительных инвестиций в новое оборудование, его физическую установку и настройку. И его еще нужно суметь закупить и привезти — локальное оборудование не умеет появляться по нажатию кнопки, как это происходит в облачных сервисах.
Уровень автоматизации и готовые инструменты
Облако предлагает встроенные сервисы для управления ресурсами, мониторинга и аналитики, что значительно сокращает время на внедрение и эксплуатацию. В On-premise такие функции требуют разработки или интеграции, что увеличивает затраты времени и денег.
Например, в облаке можно быстро получить доступ к инструментам аналитики или биллинга, которые уже настроены провайдером, тогда как локальные решения часто требуют дополнительных инвестиций в ПО и лицензии.
Таким образом, с учетом всех неочевидных факторов и дополнительных затрат (как обязательных, так и необязательных) КХД, развернутое On-premise может оказаться еще дороже. В большинстве случаев окупаемость инвестиций может вырасти с 3,5 до 6 и более лет. Иногда даже до 10–12 лет, если посчитать все затраты на геораспределенное резервирование, информационную безопасность и ФОТ квалифицированных инженеров. При этом средняя окупаемость по-хорошему не должна превышать 5 лет — далее физическое оборудование устаревает и требует повторных капитальных инвестиций.
«Что еще, кроме денег»: нефинансовые критерии выбора между облаком и On-premise
Стоимость развертывания, владения и использования инфраструктуры — фундаментальный, но далеко не единственный критерий при выборе платформы для реализации КХД. Помимо этого, есть ряд нефинансовых аспектов.
Структура издержек — выбор между капитальными затратами (CapEx) и операционными расходами (OpEx).
Прогнозируемость затрат — возможность точно планировать финансовые обязательства и понимать, какие платежи предстоят в будущем.
Уровень контроля над инфраструктурой — владение физическим оборудованием или аренда мощностей у облачного провайдера.
Способность оперативно увеличивать или уменьшать вычислительные ресурсы в зависимости от потребностей бизнеса.
Простота эксплуатации — насколько легко управлять инфраструктурой и поддерживать ее, требует ли она сложных настроек и администрирования.
Время, необходимое для развертывания новых серверов, хранилищ или вычислительных мощностей.
Соответствие требованиям безопасности, доступность инструментов защиты данных и соблюдение нормативных стандартов.
Соответствие инфраструктуры требованиям в части обработки чувствительной информации, в том числе государственной тайны или данных критической информационной инфраструктуры.
Доступность встроенного ПО и сервисов или необходимость самостоятельной разработки и установки необходимых инструментов.
Гибкость в настройке прав пользователей и возможность контроля использования ресурсов.
Требования к уровню компетенций сотрудников, необходимых для обслуживания инфраструктуры.
Простота проведения проверок безопасности, соответствия требованиям и оценки эффективности инфраструктуры.
Наличие инструментов для создания резервных копий и защиты данных от потерь.
Стоит понимать, что универсального набора требований нет — для каждой компании, в зависимости от ее масштаба, области деятельности, специфики и других нюансов, критерии выбора будут различаться. Приведенный перечень — лишь незначительная часть из них. Соответственно, подход к выбору платформы для развертывания корпоративного хранилища будет индивидуальным для каждой компании.
Но если в вашей организации пока нет принятой методики выбора платформы, можете посмотреть, как это возможно организовать в формате матрицы. Пример — под катом.
Пример матрицы для выбора платформы для развертывания
Чтобы упростить выбор варианта развертывания, сделать его более аргументированным и структурированным, можно воспользоваться матрицей.
Логика ее построения довольно простая и понятная:
в первую графу выносим критерий;
во второй графе по пятибалльной шкале указываем важность каждого критерия для компании;
в третьей и четвертой графе — показатель того, насколько тот или иной критерий характерен для варианта в облаке или On-premise (также по пятибалльной шкале);
в пятой и шестой графе — взвешенная оценка, которая получается путем перемножения показателей, отражающих важность критерия для компании и характеристику каждого из вариантов.
При этом важность для компании — полностью индивидуальный показатель, который каждая организация определяет самостоятельно на основе экспертной оценки.
То, насколько тот или иной критерий выполняется для каждого из вариантов, также оценивается экспертно, и в этом можно ориентироваться на представленные в таблице данные. Они отражают общий подход к сравнению облака и On-premise с учетом их ключевых особенностей.
Например, облако — это в чистом виде операционные затраты, а On-premise — преимущественно капитальные. Поэтому можно применить «зеркальное» распределение баллов: для Capex 1–5, а для Opex 5–1. Однако, если в конкретной компании текущие затраты на On-Premise (зарплаты, содержание инфраструктуры) составляют значительную долю от капитальных, можно адаптировать оценки, например изменить их на 2–5 и 5–2.
Есть и менее очевидные критерии — например, простота эксплуатации и возможность проведения аудита инфраструктуры. В данном примере облачное решение получило преимущество, но в реальных условиях это может варьироваться в зависимости от специфики компании. Такой подход помогает объективизировать выбор и наглядно визуализировать его при расчетах.
Критерий | Важность | Баллы (облако) | Баллы (On-premise) | Взвешенная оценка (облако) | Взвешенная оценка (On-premise) |
|---|---|---|---|---|---|
Цена | 5 | 5 | 2 | 25 | 10 |
CAPEX+ | 1 | 1 | 5 | 1 | 5 |
OPEX+ | 5 | 5 | 1 | 25 | 5 |
Прогнозируемость расходов | 2 | 5 | 3 | 10 | 6 |
100%-я управляемость | 5 | 2 | 5 | 10 | 25 |
Быстрая масштабируемость | 5 | 5 | 1 | 25 | 5 |
Простота эксплуатации | 3 | 4 | 2 | 12 | 6 |
Скорость выделения новых ресурсов | 1 | 5 | 1 | 5 | 1 |
Наличие СЗИ и сертификатов по безопасности | 3 | 5 | 2 | 15 | 6 |
Зависимость от внешних подключений, автономность | 5 | 1 | 5 | 5 | 25 |
Типы данных (гостайна, критическая инфраструктура) | 5 | 2 | 5 | 10 | 25 |
Набор готовых инструментов и сервисов | 1 | 5 | 1 | 5 | 1 |
Управление квотами и бюджетами в разрезе проектов, команд | 3 | 5 | 1 | 15 | 3 |
Незагруженность внутренних команд | 5 | 5 | 1 | 25 | 5 |
Потребность в высококвалифицированных инженерах | 5 | 3 | 1 | 15 | 5 |
Аудит инфраструктуры | 1 | 4 | 3 | 4 | 3 |
Резервирование | 3 | 5 | 3 | 15 | 9 |
Итого | 207 | 144 |
Например, при таком распределении оценок получаем, что для компании предпочтительнее облачный вариант развертывания.
Выводы и рекомендации
Облако vs On-premise — это спор не о текущих затратах, а о стратегии. On-premise фиксирует инфраструктуру на годы, но в условиях инфляции, сопутствующих затрат и развития технологий это может стать обузой. Облако адаптируется под изменения: масштабируется за минуты, снижает стартовые затраты и не требует содержания штата инженеров. Безусловно, со временем теоретически расходы сравняются, но к этому моменту On-premise-оборудование морально устареет, а облако позволит перейти на новые технологии без дополнительных инвестиций.
Таким образом, для бизнеса облако становится страховкой от рисков устаревания и кадрового дефицита, а также еще от множества издержек.
При этом компаниям совсем необязательно сразу переносить всю ИТ-инфраструктуру в облако. Чтобы сделать вход в работу с облаком более мягким, можно следовать некоторым рекомендациям.
Начните с малого. Например, первой в облаке можно развернуть тестовую среду с соответствующими сервисами. Это даст возможность проверить процессы деплоя, совместимость с инструментами CI/CD и оценить удобство управления. Также можно развернуть небольшую dev-среду для анализа доступных ресурсов, затрат, возможностей масштабирования. Такой подход поможет комплексно протестировать облако небольшой командой без сложных манипуляций и любого влияния на прод.
Рассмотрите гибридные архитектуры для баланса контроля и гибкости. Для компаний, которые не готовы к полному переходу в облако, гибридные модели позволят распределить нагрузки: критически важные данные хранить On-premise, а аналитику и тестовые среды перенести в облако. Это снизит единовременные капитальные инвестиции, но сохранит контроль над чувствительными активами. Например, можно развернуть ядро КХД локально, а обработку Big Data выполнять в облаке с оплатой по факту использования. Такой подход также упростит постепенную миграцию.
Внедрите FinOps-практики. Используйте FinOps-инструменты контроля и детализации затрат по проектам и отделам. Настройте алерты при превышении лимитов — это предотвратит «распухание» бюджетов из-за забытых тестовых инстансов.
Пересматривайте подход каждые 3–5 лет. Построение ИТ-инфраструктуры, особенно для больших компаний, — это «игра вдолгую». Но условия рынка динамично меняются. Поэтому, чтобы не терять конкурентные преимущества, нужно гибко подстраиваться под эти изменения. Тут надо понимать, что совсем необязательно, что через 5 лет придется менять облако на On-premise (с учетом инфляции — скорее наоборот). Но вполне возможно, что появятся другие облачные сервисы (в том числе у используемого вендора), которые позволят решать бизнес-задачи дешевле и эффективнее.
И помните: облака ближе, чем кажутся!
