Управляемые базы данных в Яндекс.Облаке
В чем разница между базой данных на «железе» и на виртуальных машинах? Чем самостоятельное обслуживание отличается от управляемого сервиса в облаке? Самое главное об управляемых базах данных.
Сегодня мы собрали в одном посте все самое важное о сервисах управляемых баз данных (Managed Databases). Рассказываем о плюсах размещения баз данных на виртуальных машинах. Смотрим, почему самостоятельное обслуживание может выйти дороже, чем кажется на первый взгляд. И небольшой спойлер: в конце поста вас ждёт полезный сюрприз. Тоже про базы данных.
Два главных вопроса для вашего бизнеса про базы данных
Система управления базами данных — набор программ, с помощью которого можно хранить данные, проводить различные операции с ними (добавлять, обновлять, выбирать нужные, удалять ненужные).Это один из основных элементов ИТ-платформы практически любого современного бизнеса. Выбор конкретного вида СУБД зависит от ваших задач.
Какую бы СУБД вы ни выбрали, её нужно где-то разместить. И в этот момент возникают два важных вопроса с точки зрения бизнеса:
- Развернуть СУБД на собственном железе или на виртуальной машине?
- Обслуживать самостоятельно или воспользоваться управляемым сервисомвот?
Мы возьмём в качестве примера условный, вполне типичный бизнес-проект, которому требуется доступность базы на чтение не меньше 99,99%, (простой не более 4 минут в месяц). Доступность на запись — не меньше 99,95% (простой не более 20 минут в месяц). А с нагрузкой на базу данных проекта справляется одна машина вот в такой конфигурации: 8 виртуальных ядер с частотой 2+ ГГц, 32 ГБ RAM и накопитель на 500 ГБ с пропускной способностью 2 000 IOPS.
А теперь посмотрим, какие плюсы и минусы есть у каждого варианта.
Железо или виртуальные машины?
«Железо» или baremetal, пожалуй, до сих пор самый популярный в России вариант размещения. Его преимущества:
производительность и
стоимость. Виртуализация неизбежно отъедает некоторую часть производительности серверов. А стоимость «железного» сервера ниже стоимости аналогичной виртуальной машины. Например, для выбранной нами конфигурации в дата-центрах Hetzner это будет 55 и 108 евро соответственно.
В нашем разговоре про bare metal не имеет значения, собственный это сервер или арендованный. Аналогично и для виртуальных машин: неважно, где они будут размещены — в собственном, приватном или гибридном облаке.
При этом у baremetal есть недостатки:
жёстко фиксированная конфигурация и
сложность масштабирования. «Железные» серверы чётко поделены на уровни «мощности», поэтому чаще всего вы не используете все ресурсы, за которые платите. С другой стороны, при активном росте вы не сможете быстро их нарастить. Покупка, настройка и запуск дополнительных серверов требуют времени.
У развёртывания базы данных на виртуальных машинах есть несколько существенных плюсов по сравнению с «железным» вариантом.
Гибкость. На baremetal сервере не получится увеличить вычислительную мощность или дисковое пространство без простоя. Ресурсы нельзя добавить ровно в нужный момент. То же самое касается временного роста нагрузки. К наплыву посетителей в Чёрную пятницу придётся готовиться заранее. Масштабировать ресурсы виртуальных машин на короткий срок намного проще и менее затратно.
Скорость и удобство. Рабочую виртуальную машину с доступом по SSH можно получить намного быстрее, чем «железный» сервер. Примерно пара минут против 30-40, о которых говорят крупные провайдеры. Операции вне операционной системы на виртуальных машинах тоже выполнять значительно удобнее, чем на baremetal. Например, проводить отладку, когда не грузится операционная система.
Доступность. У крупных облачных провайдеров все диски виртуальных машин сетевые. Если выйдет из строя гипервизор или ToR-коммутатор, виртуальную машину можно будет перезапустить на другом гипервизоре. Простой в данном случае не превысит нескольких минут.
Интеграция с другими облачными сервисами. Крупные платформы предлагают клиентам целый список полезных облачных сервисов. Это может быть балансировщик нагрузки, который повысит надёжность вашего сервиса. Это может быть объектное хранилище, где вы будете хранить резервные копии базы данных. Это могут быть инструменты бизнес-аналитики, которые помогут вам принимать правильные решения.
Самостоятельное обслуживание или управляемая база данных?
У нас в Яндекс.Облаке базу данных можно разместить двумя способами. Первый: поднять виртуальные машины в
Yandex Compute Cloud и развернуть на них СУБД своими силами. Второй: воспользоваться одним из сервисов управляемых баз данных.
В первом случае у вас будет несколько
больше контроля и
несколько меньше затрат. В управляемом сервисе у вас нет прав суперпользователя и доступа по SHH. Нельзя установить расширение, которое не поддерживается сервисом. Не все настройки СУБД можно поменять.
Для сравнения по затратам возьмём
Yandex Managed Service for PostgreSQL. Он уже дешевле других аналогичных сервисов — 17 810 рублей в месяц. Можно добиться еще большей экономии: конфигурация, которую мы выбрали для нашего типичного бизнес-проекта, в Yandex Compute Cloud стоит 12 720, то есть разница составляет 40%.
Но у такого варианта есть серьёзный минус — необходимость
самостоятельно обслуживать СУБД. Вам придётся взять на себя мониторинг, создание резервных копий и реплик базы данных, обеспечение аварийного переключения, а также установку обновлений. Другими словами, вам понадобятся ресурсы на поддержку СУБД.
Управляемый сервис снимает с вас задачи по обслуживанию базы данных, берёт на себя заботы о надёжной работе проекта и упрощает жизнь вашей команды.
Удобство в работе. Чтобы получить рабочую и правильно настроенную базу данных, в управляемом сервисе достаточно нажать одну кнопку и подождать пять минут. В комплекте вы получаете доступ к графическому отображению метрик СУБД и метрик использования системных ресурсов. Так же просто в управляемых сервисах Яндекс.Облака делаются реплики и наращиваются ресурсы БД.
Установка обновлений. При самостоятельном обслуживании минорные обновления для баз данных очень редко устанавливаются в разумные сроки после их выхода. Потому что нет времени, специалисты загружены, всё и так нормально работает.
Проблема в том, что минорные обновления могут включать в себя важные исправления безопасности и решения серьёзных проблем, например, приводящих к
повреждению данных. В управляемых сервисах Яндекс.Облака минорные обновления устанавливаются без вашего участия. Это касается обновлений СУБД, ядра и библиотек.
С мажорными обновлениями — другая история. Их не хотят ставить своими силами, потому что никому не нужны проблемы обратной совместимости. Исторически сложилось, что многие облачные платформы в принципе не предоставляют возможность установки мажорных обновлений и ограничиваются только инструкциями, как это сделать. У Яндекс.Облака такая возможность есть: обновления накатываются по нажатию кнопки пользователем.
Резервное копирование. Чаще всего о резервном копировании вспоминают, когда уже слишком поздно. Но даже регулярное создание резервных копий не защищает вас от ошибок на все 100%. Почему? Да потому что обычно никто не проверяет сами бэкапы. Именно так в своё время была потеряна база данных
Gitlab.
Яндекс.Почта тоже однажды потеряла 3 терабайта данных из-за ошибки. История закончилась хорошо, базу данных удалось вернуть за счёт восстановления на момент времени (point-in-time recovery) непосредственно перед потерей. После этого мы вложили немало сил и ресурсов в развитие инфраструктуры резервного копирования и валидации бэкапов. Сейчас в управляемых сервисах Яндекс.Облака этот процесс налажен очень и очень хорошо.
Отказоустойчивость. Практически любой управляемый сервис позволяет повысить доступность базы данных на чтение за счёт добавления реплик БД. Но мало кто думает о доступности базы данных на запись и обеспечивает автоматическое аварийное переключение на случай отказа мастера. У нас реализованы обе функции.
Конечно, их можно реализовать самостоятельно, но это потребует времени и соответствующей квалификации. А в критической ситуации даже опытные администраторы допускают ошибки при восстановлении из резервной копии или аварийном переключении.
Безопасность. В управляемых сервисах Яндекс.Облака все соединения с СУБД и резервные копии содержимого баз шифруются при помощи протокола TLS и технологии GPG. Кроме того, базы разных клиентов Яндекс.Облака полностью изолированы друг от друга. Благодаря отсутствию общих компонентов никто кроме вас не может получить доступ к вашим данным.
Платформа гарантирует полную безопасность всех настроек управляемых баз данных. И хотя злоумышленники периодически устраивают массовые атаки на различные сервисы, вам не нужно об этом беспокоиться. Под раздачу обычно попадают серверы, где администраторы не запретили внешние подключения. Яркий пример из относительно недавнего прошлого: взломы
десятков тысяч серверов с MongoDB в 2017 году.
Вместо заключения
Выбор СУБД и вариантов её размещения, безусловно, зависит только от ваших задач и потребностей бизнеса. Просто помните, что сервис управляемых баз данных берет на себя всю рутину по обслуживанию инфраструктуры и БД и гарантирует, что всё будет сделано по-настоящему качественно. А вы освобождаете часть своих ресурсов и можете направить их на развитие проекта. Получаете возможность сократить сроки вывода продукта на рынок и сводите к минимуму вероятность возможной потери данных и других эксцессов. Для быстро растущего проекта это хороший вариант старта.
cloud.yandex.ru/promo-mdb/
