Как бизнесу выбрать базу данных под свой проект? Сравниваем on-premise и управляемую БД

Компании, которые создают ИТ-проект с нуля или ищут альтернативное решение, рано или поздно отвечают себе на вопрос: выбрать базы данных on-premise (то есть самостоятельная установка и обслуживание на своей территории) или же управляемая БД в облаке?

Дмитрий Павлов, менеджер по развитию Data Platform в Yandex.Cloud, рассказывает подробно о каждом из вариантов с цифрами и подводными камнями.

Современный бизнес в практически любой индустрии немыслим без обработки больших объёмов данных. Повысить конверсию в интернет-магазине с помощью рекомендаций, отслеживать LTV и MAU/DAU/WAU в интернет-сервисах, обрабатывать транзакции и платежи в финтехе, предсказывать простой оборудования в промышленности — для этих и других задач необходимо хранить и обрабатывать реляционные структурированные данные. Вот уже 60 лет компаниям помогают в этом реляционные системы управления базами данных (СУБД).

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

• Классический: разместить СУБД на собственном или арендованном оборудовании
• Появившийся относительно недавно: использовать управляемую СУБД в облачном провайдере

На первый взгляд кажется, что всегда лучше держать свое, что называется, под боком. По моему опыту, практически все компании изначально рассматривают вариант on-premise (то есть аренду серверов в ЦОДе или виртуальных машин) и только потом изучают возможности облака.

У обоих подходов есть плюсы и минусы, и всё же в последнее время всё больше компаний выбирают облачные PaaS-сервисы. Так, по оценке Gartner, к 2022 году более 75% СУБД в мире будут расположены в облаках. Почему? В этой статье попробуем разобраться.

Итак, нам необходимо развернуть систему управления базами данных (СУБД). Казалось бы, начинается все с установки непосредственно дистрибутива СУБД. Однако, если вы решили опираться на собственные силы, то сначала придется подготовить инфраструктуру: арендовать или разместить в ЦОДе оборудование, раскатать операционную систему, скоммутировать сеть. После развёртывания СУБД — настроить политики безопасности, резервное копирование, организовать мониторинг с алертами. С одной стороны, это разовое действие. С другой — если через месяц для нового проекта понадобится новая БД, то все придется делать заново. Немного помогают средства управления конфигурацией типа ansible или puppet, но даже при их использовании приходится делать много «тюнинга» — например, при изменении конфигурации СУБД или обновления её версии и состава компонент.

Управляемая база данных разворачивается быстрее — в этом случае начинаем сразу с настройки непосредственно сервиса, которая делается в веб-интерфейсе: достаточно выбрать тип СУБД, указать количество ресурсов (CPU, RAM, размер дисков), указать количество хостов, настроить расписание резервного копирования. В принципе, вся работа займет не более получаса. Важно, что это время постоянно для развёртывания любого типа СУБД — не придётся разбираться с новой технологией с нуля, когда придёт её время.

Так что, выбирая один из вариантов, необходимо, как минимум, представлять, как будет развиваться бизнес дальше — планируется ли расширение, запуск новых проектов, сколько будет времени на то, чтобы без спешки разобраться с новой технологией и развернуть её самостоятельно. Часто бизнес не может ждать. Поторопившись, можно словить неприятные последствия уже при продуктовой эксплуатации.

Конечно, возможен вариант, когда, например, оборудование уже есть, закупать его не требуется, только настроить. В этом случае в среднесрочной перспективе развернуть БД on-premise будет экономически обоснованно. Однако надо помнить, что эксплуатация оборудования тоже не бесплатна — его надо обслуживать.

После ввода СУБД в эксплуатацию наступает (и не заканчивается) этап поддержки — нужно непрерывно следить как за оборудованием (по мере износа заменять диски, отслеживать потери пакетов и сбои сети, вовремя заказывать и заменять вышедшие из строя компоненты), так и за СУБД (управлять нагрузкой, реагировать на падение производительности). Помнить надо и про безопасность — необходимо регулярно устанавливать обновления ОС и СУБД, чтобы исправлять ошибки и закрывать уязвимости.

У ОС и СУБД регулярно происходят так называемые мажорные обновления.Часто компании откладывают переезд на новую версию на последний момент или продолжают работать с неподдерживаемыми версиями. Потому что самостоятельное обновление и миграция — это долго и сложно: нужно учесть много нюансов, провести тестирование новой версии с приложением и решить возникающие проблемы.

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

В управляемом сервисе поддержкой занимается облачный провайдер, а клиенту нужно только управлять пользователями. То есть оборудование, ОС и СУБД под присмотром: обновления устанавливаются автоматически, системы мониторинга, резервное копирование и сетевые настройки контролируются самим сервисом управляемой СУБД. В управляемой облачной СУБД намного легче мигрировать на новые мажорные версии — достаточно по клику создать копию хоста БД с новой версией, проверить, что все работает как надо, и просто перевести нагрузку на новый хост. Откатиться можно в любой момент.

Также нельзя забывать и про интеграции с СУБД — ни одна система не существует в вакууме. Конкретно СУБД чаще всего интегрируется с BI-системами, с ПО загрузки и трансформации данных (ETL), с шинами данных (Kafka, Rabbit), с кэшами (Redis). В случае размещения своими силами администратору придётся разрабатывать механику интеграций самостоятельно. В случае использования управляемой СУБД большинство интеграций уже имплементированы, их можно использовать без написания кода.

Таким образом, при подсчете совокупной стоимости владения (total cost of ownership, TCO) СУБД следует учитывать не только сами ресурсы, но и сопутствующие факторы.

Факторы, играющие в пользу on-premise размещения:

• Наличие большого пула ресурсов (своих серверов и ВМ) в капитальных расходах, за которые уже уплачены средства
• Наличие опытных узкоспециализированных администраторов по каждой из СУБД в нужном количестве
• Нетребовательность бизнеса к скорости запуска новых проектов (time-to-market) — если бизнес может подождать несколько месяцев, как это было лет десять назад, часто можно обойтись и своими силами

Факторы, играющие в пользу облачных управляемых СУБД:

• Требования бизнеса к скорости развёртывания новых проектов — «надо запуститься сейчас, потом будет уже поздно, так как рынок будет упущен»
• Отсутствие глубокой экспертизы в конкретных технологиях хранения данных
• Необходимость интегрировать СУБД с другими системами компании

Есть два частых вопроса к облачным СУБД, с которыми связаны опасения и заблуждения: безопасность хранения персональных данных в облаке и ширина сетевого канала, соединяющего облачную СУБД с другими системами компании. Так вот:

• Большинство современных облачных провайдеров имеют развитые средства защиты данных и все необходимые сертификаты для хранения любых данных — персональных, финансовых, и т.д
• В большинстве случаев трафик между облачной СУБД и ЦОДом компании идёт не через интернет, а через специальный выделенный канал до ЦОДа — интерконнект. Такой канал имеет пропускную способность около 20 Гбит/с и минимальную latency. Фактически доступ к облачной СУБД не отличается от доступа к СУБД, развёрнутой в своём ЦОДе.

СУБД должна сохранять работоспособность даже в случае отказа одного или нескольких элементов. Поэтому отказоустойчивость — одна из важнейших характеристик, которую нужно обеспечить.

Отказоустойчивость СУБД достигается за счет создания кластера: если из строя выйдет один из хостов, остальные продолжат работу. В идеале хосты лучше расположить в разных ЦОДах, чтобы обезопасить свой проект от сбоев целого дата-центра.

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

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

Управляемые БД — это отказоустойчивость и легкое изменение топологии. Для любой из кластерных баз данных можно создать реплики в трех зонах доступности.

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

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

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

Кроме привычных всем бекапов, в некоторых СУБД есть механизм point-in-time recovery (PITR). Эта полезная функция позволяет восстановить данные на любой момент, а не только на момент создания копии. Например, бекап создается в 00:00. Утром в БД появляются новые данные, а в обед junior-разработчик случайно удаляет одну таблицу. Если восстановить предыдущую копию — то потеряются утренние данные. Механизм PITR позволяет указать точное время, на которое нужно восстановить данные: он сам восстановит последнюю копию и применит все транзакции, которые прошли после ее создания.

PITR работает и при локальной установке БД. Но придется сначала настроить этот механизм, а потом просить системного администратора восстанавливать данные. В управляемой БД PITR уже настроен, а воспользоваться им можно без посторонней помощи.

В управляемой БД вы получаете доступ как пользователь — создаете схемы и таблицы, работаете с данными, анализируете производительность запросов. Но у вас нет root-доступа, то есть вы не можете менять системные настройки и управлять виртуальной машиной, на которой запущена СУБД. Этот вариант подходит тем, кому нужна готовая и стабильная база данных, а не конструктор, который легко сломать. Да, минус гибкость, так как нельзя управлять абсолютно всеми настройками. С другой стороны, даже самая глубокая оптимизация настроек СУБД под конкретный кейс обычно дает лишь несколько процентов производительности относительно управляемой СУБД.

Есть и другой вариант: пользователи получают полный доступ к СУБД и ВМ, на которой она работает. Это нельзя назвать полностью управляемым сервисом, это скорее ВМ с готовым шаблоном для быстрого развертывания. Такой вариант упрощает установку и настройку (то есть вычитаем из затрат первый этап). Но раз вы имеете доступ ко всем внутренним настройкам и функциям — провайдеру сложнее гарантировать стабильную работу. Если из-за вмешательства система сломается, разбираться придется самостоятельно.

Соответственно, в БД on-premise у вас (или администраторов) в руках все карты — все системы управления.

Еще одна особенность управляемых БД — соглашение об уровне сервиса (SLA). Оно гарантирует, что БД будет доступна определенное количество времени. В противном случае провайдер компенсирует стоимость сервиса. Но подобные условия предоставляются только для кластера.

При аренде БД на ВМ провайдер также гарантирует доступность по SLA. Но, как правило, в этом случае она ниже, чем для управляемой БД. Например, в Yandex.Cloud SLA для ВМ — 99,95%. Когда ВМ простаивает, это означает, что БД недоступна на чтение и на запись. А в управляемой БД эти операции разделены, и если она недоступна на запись, то вполне вероятно, что доступна хотя бы на чтение.

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

Компания MongoDB описала все действия, на которые расходуется время в различных моделях развертывания БД — на своем оборудовании, на облачной ВМ и полностью управляемой БД. На схеме видно, что в управляемых БД практически все время уходит на разработку и инновации, то есть на решение конкретных задач бизнеса, а не на настройку и обслуживание БД.

Мы рассчитали стоимость владения и управления тремя видами ресурсов — on-premise, ВМ на базе Yandex Compute Cloud и сервисом по управлению базами данных. Мы выбрали эквивалентное по мощности оборудование и сравнили, сколько это стоит в каждом из вариантов.

Расчеты приведем на горизонте трех лет, то есть амортизацию оборудования в on-premise-решении посчитаем за три года.

Это упрощенный расчет — мы не учли несколько моментов. Например, что в on-premise решении оборудование можно продать после использования, а отсутствие капитальных затрат в управляемой БД можно инвестировать в другие направления бизнеса.

Вот сравнение стоимости управления и владения различными вариантами БД:

Давайте рассмотрим расчеты более подробно.

В случае on-premise придется самостоятельно покупать оборудование и следить за ним, поддерживать бесперебойную работу и периодически менять, когда оно устареет или сломается. Если проект развивается, то со временем мощности станет недостаточно и потребуется новое оборудование. Если же сразу взять мощность с запасом — оборудование будет простаивать.Пример: сервер HP с 12 ядрами стоимостью ≈ 800 000 ₽. С учетом амортизации за три года получается ≈ 22 000 ₽ в месяц.

Согласно исследованию некоммерческой организации NRDC, утилизация on-premise оборудования от трех до четырех раз ниже, чем облачного. С учетом данной поправки стоимость владения оборудованием составит как минимум ≈ 22 000 × 3 ≈ 66 000 ₽ в месяц.

Также необходимо будет искать сотрудников, платить зарплату и социальные взносы. При этом потребуется как минимум два специалиста, чтобы они могли подменять друг друга во время отпуска и болезни. Скорее всего, кроме БД, эти сотрудники будут заниматься и другими задачами, поэтому предположим, что на администрирование БД они тратят только 50% времени.Зарплата специалиста ≈ 100 000 ₽, социальные взносы — 30 000 ₽. Потребуется два специалиста, каждый из которых администрирует БД 50% времени. В итоге получаем ≈ 130 000 ₽ в месяц.Итого ≈ 196 000 ₽ в месяц.

При выборе ВМ на базе Compute Cloud не нужно заниматься оборудованием. Так, например, стоимость развертывания ВМ в Yandex.Cloud ≈ 27 500 ₽ в месяц.

Но все еще нужно искать сотрудников, платить зарплату и социальные взносы. Затраты по этой статье будут такими же, как и при on-premise ≈ 130 000 ₽ в месяц.

Итого ≈ 157 500 ₽ в месяц.

Меньше всего ресурсов потребует управляемая БД, так как уходят затраты на оборудование и администраторов.

Пример: управляемая БД (24 vCPU, 96 RAM, 240 ГБ SSD) стоит ≈ 42 000 ₽ в месяц.

Конечно, помимо выбора между on-premise и облачной управляемой СУБД предстоит определиться и с самой технологией СУБД. Здесь необходимо учитывать сразу несколько параметров, в том числе тип данных, характер нагрузки или необходимость в горизонтальном масштабировании. Недавно мы с командой подготовили специальный тест, который помогает учесть все параметры.

Безусловно, оба варианта размещения СУБД имеют свои плюсы и минусы.

On-premise даёт полный контроль над СУБД, возможность выжать несколько дополнительных процентов производительности за счёт более тонкой настройки «под себя», а также возможность утилизировать уже имеющееся оборудование. Также on-premise размещение часто выбирают высокочастотные финансовые сервисы: например, базы размещают в ЦОДах в центре города, чтобы быть ближе к биржам — источникам котировок, таким образом снизив латентность. Однако надо быть готовым к тому, что такое размещение будет очень дорогим.

Управляемые СУБД выбирают по двум причинам: скорость развёртывания и расширения, и совокупная стоимость, причем, как мне кажется, именно в таком порядке приоритетов. Возможность поддержать бизнес-инициативу, помочь бизнесу стартовать и занять рынок здесь и сейчас, а не через три месяца, быть быстрее конкурентов — вот почему всё больше компаний выбирают управляемые СУБД.

На мой взгляд, именно скорость изменений бизнеса в будущем будет основным преимуществом в высококонкурентных отраслях (онлайн-сервисы, ритейл, финансы, аналитика), и управляемые СУБД ещё сыграют здесь свою немалую роль.

Подписывайтесь на блог Yandex.Cloud, чтобы узнавать еще больше новостей и историй об IT и бизнесе.

Другие истории, которые активно читают наши подписчики:

• Где открыть бизнес: ищем точки на карте с помощью сервиса Yandex DataLens
  
• Как мы сделали мобильное приложение для управления серверами по клику
• Инструкция: делаем простой бот для Slack в облаке