Привет! Я Дмитрий Головнич, руководитель команды разработки в Klaud Atlas. Моя команда делает инструмент для создания ИТ-инфраструктуры - контейниризированную платформу dBrain.cloud. Вы слышали о Red Hat OpenShift и VMWare Tanzu? Мы сделали российскую альтернативу этих продуктов. Сегодня я хочу поделиться, как мы с командой собираем комплект баз данных, которые можно использовать для запуска микросервисных приложений. Мы понимаем, что не каждый разработчик ПО знает все базы данных, а поддержание ИТ-инфраструктуры компании для многих инженеров превратилось в рутину. Я расскажу, как автоматизировать эти процессы с помощью консоли dBrain и что мы предлагаем для быстрого старта в работе с незнакомыми для вас базами данных.
Когда микросервисы доставляют хлопоты
Все мы знаем, что сейчас разработчики активно переходят на микросервисную архитектуру. Помимо написания приложений, разработчики должны решать вопросы, где и как разворачивать свои продукты, какие технологии для этого использовать, как организовать сети и хранение данных, управлять сервисами, как мониторить и логировать работу системы. Это превращает работу DevOps в рутину, где нужно бесконечно дирижировать микросервисами, чтобы приложение работало. А как же время на саму разработку?
Нам близок подход: там, где можно упростить, надо упрощать, если процесс можно автоматизировать - это нужно сделать. Поэтому мы создали инструмент для запуска и управления микросервисами, используем его в своих многочисленных проектах и вам советуем.
Все дело в базе…
Правила написания микросервисных приложений (Twelve-Factor Application best practices) основаны на использовании оптимально подходящего вида базы данных: SQL либо NoSQL. Поэтому в платформе dBrain мы обеспечили варианты баз данных каждого вида и шину данных. Шина увеличивает отказоустойчивость микросервисных архитектур, позволяет их гибко масштабировать как горизонтально, так и вертикально, используя hpa и vpa автоскейлеры.
Мы проанализировали сферу разработки и пришли к выводу, что самые востребованные инструменты для запуска и управления микросервисными приложениям - Cassandra, Clickhouse, Kafka, MongoDB, PostgreSQL, Redis. Их и внедрили в консоль dBrain - это пользовательский интерфейс, в котором разработчик может быстро развернуть и администрировать микросервисы, подключиться к любой базе данных в любом кластере, управлять правами доступа пользователей к кластерам и базам данных, анализировать логи аудита на уровне кластера Kubernetes и баз данных. Консоль позволяет осуществлять maintenance сервисов централизовано в несколько кликов.
В dBrain одна реляционная SQL база данных - Postgres, три NoSQL - MongoDB, Cassandra, Clickhouse, а также шина баз данных Kafka и система Redis, используемая как кэш либо key-value. Как показывает наш опыт, такой набор баз данных закрывает большинство кейсов разработки. Конечно, мы испробовали все базы на себе: четыре проекта нашей компании работают на них.
Наша команда деплоит не просто ванильные базы данных, а подготовленные и оптимизированные для работы в периметре Kubernetes. У нас используется только Production Ready решения.
Как облегчить жизнь DevOps?
Мы учли запросы разработчиков и внедрили в платформу механизм бэкапирования баз данных, записи WAL логов в S3. Каждый разработчик не раз почувствовал боль от падения системы. Поэтому для платформы выработан механизм защиты от сбоев и отключения бэкапов. Например, если инстанс мастера PostgresSQL “упадет”, он переключит реплику на роль мастера и после вычитки всех незавершенных транзакций из WAL логов возобновит работу. Если лага репликации нет, то и задержка на переключение может пройти незаметно для конечного пользователя. WAL логи, в свою очередь, сохранятся на диске или в S3-бакете.
Чтобы облегчить жизнь DevOps, в платформе есть механизм pgAdmin: внутри консоли можно провалиться в мощный инструмент для администрирования баз данных. На панель консоли вынесли часто используемые функции: создание таблиц, юзеров, расширение диска. Это обеспечивает быстрый доступ к инструментам, инженерам не нужно заходить в сам контейнер, выполнять SQL-команды. Все манипуляции разработчик выполнит, не погружаясь в более низкоуровневые структуры.
PostgreSQL. Это один из самых больших и долгоживущих open source проектов с доступным функционалом по open source лицензии. Многие компании имеют экспертизу работы с PostgreSQL. Эта база данных поддерживает конфигурацию мастер-реплика. В PostgreSQL нет проблем с репликацией и бэкапированием. Существует большое количество модулей расширений, которые поддерживают разного рода проекты и постоянно развиваются.
Наш подход заключается в следующем: мы предоставляем общий набор инструментов для работы c базой с уже адаптированной имплементацией внутри Kubernetes в виде StatefulSet. В качестве лог балансера внутреннего и управляющего компонента мы используем Patroni. Приложение следит за состоянием инстансов самого кластера PostgreSQL и в случае необходимости может переключать коннекшены с мастера на реплику. Если база данных для проектов заведена в одном инстансе, то и мастер у нас один. Такая конфигурация часто используется в различных develop-средах и имеет право на жизнь.
MongoDB. В этой базе данных такой же механизм как в Postgres: бэкапирование осуществляется с помощью WAL логов в S3.
Cassandra. Автоматического бэкапирования из консоли в ней пока нет, т.к. это распределенная база данных. Подход Cassandra заключается в том, что все реплики отвечают на запрос. Например, если в структуре базы пять инстансов, то запрос распределяется на все пять инстансов. В то время как подход Postgres - это мастер реплик, который принимает все изменения и только делает синк с репликой данных. Мы создаем не меньше трех реплик Cassandra, поэтому выход из строя одной ноды не приведет к потере данных.
Clickhouse. Для менеджмента Clickhouse в нашей платформе используется оператор. В Clickhouse реализован функционал HA и бэкапирование в S3.
Redis. В основном используется клиентами как кэш.
Kafka. Шина данных в связи со своими техническими особенностями не бэкапируется. Она настраивается при помощи зеркалирования под нужды клиента и используется совместно с Zookeeper.
Как Lego, только dBrain
В dBrain разработчик просто кликает на кнопку в консоли и создает базы данных. Это касается Postgres, Cassandra и других. В нашей платформе закрыты вопросы, как деплоить базы данных и разворачивать их в Kubernetes. Разработчик нажимает кнопку консоли в UI, а через kube API вызываются функции, которые создают необходимые элементы в самом Kubernetes. Это позволяет закрывать весь уровень абстракции между разработчиком и инфраструктурой. Чтобы создать базу данных в dBrain, нужно ввести креды для подключения к ней в свое приложение - и оно тотчас заработает в одном кластере с ней. Созданной базой данных можно управлять через консоль.
Пользователь dBrain может задействовать в своем проекте все сервисы платформы или их часть. Это зависит от приложения. Если проекту не нужны все базы данных платформы, то их можно не разворачивать. При этом в основе консоли заложен функционал для их развертывания в дальнейшем.
Если какого-то сервиса заказчику не хватает, мы его внедряем в рамках услуг DevOps as a Service. Наша компетенция позволяет проработать нужное решение и добавить его в консоль. Приведем пример. Для одного из проектов - онлайн-лотереи - нужно было проработать специализированное решение для хранения большого объема time-series данных аналитики. Подходящим вариантом была база данных Clickhouse. Сначала мы вдоль и поперек исследовали базу: разобрались, как ее деплоить, бэкапировать, настраивать, можно ли тюнинговать. Проработали решение на бэке, во фронте, отрисовали скрины, только потом внедрили в консоль. Задача с Clickhouse прорабатывалась под конкретный проект, а теперь входит в стандартный набор баз данных dBrain.
Внедряя новый элемент в платформу, мы досконально прорабатываем именно практическую часть: как сервис развернуть, какие изменения внести в конфиги, чтобы он лучше работал с нашими кластерами Kubernetes. Также дорабатываем мониторинг этих баз данных. У нас есть уже готовые дашборды на каждую базу, а также контейнер Sidecar, который собирает необходимые метрики для отображения на дашбордах. Как правило, используются специфические метрики мониторинга баз данных, которых нет в стандартном наборе Kubernetes. Например, лаги репликации между мастером и репликой.
Мы ориентируемся на хорошо себя зарекомендовавшие open source решения, которые покрывают практически все use-кейсы. Все примитивы мы создаем внутри кластера Kubernetes. Они видны в нашем стандартном дашборде с надстройкой, которая позволяет управлять сервисами на уровне кластеров самих баз данных.
dBrain в деле
Станут ли с платформой процессы разработки быстрее? Расскажем о собственном опыте работы с dBrain на наших проектах. Мы совсем перестали тратить время на создание конфигов под конкретный кластер, а также на актуализацию Helm Chart.
Платформа легко разворачивается для любого приложения, будь это мессенджер, межсетевой экран или гемблинговая платформа. Процесс не зависит от внешних репозиториев и сервисов. С помощью встроенного в консоль механизма темплейтинга это можно реализовать полностью в замкнутом контуре. Наши разработчики разворачивают у себя в namespace точную копию используемой в проде базы данных, чтобы проводить тесты.
Так как в dBrain Kubernetes поставляется вместе с одним из вариантов объектного и блочного Storage, то он позволяет разворачивать все сервисы сразу в Kubernetes.
Для своих проектов мы используем специализированные базы данных: для метрик - VictoriaMetrics, для логов - кластер Grafana Loki. Их мы также включили в платформу. VictoriaMetrics и Grafana Loki собирают метрики и логи со всех микросервисов. Это служебные сервисы, которые обеспечивают Production Ready функционал основных. Данные о состоянии развернутых из консоли сервисов автоматически поступают в системы мониторинга и логирования. Но не будем забегать вперед: подробнее о системах мониторинга и логирования мы расскажем позже.
На одних наших проектах основная нагрузка приходится на высоконагруженную базу данных PostgreSQL объемом более 20 ТБ, на других - на шину данных Kafka и Cassandra. Это позволяет выжать максимум из open source и ежедневно улучшать нашу экспертизу. Кроме того, на наших проектах используются кластера Ceph объемом более 20 ПБ, отведенным под объектное хранилище S3.
Это наш взгляд на работу с базами данных и микросервисными приложениями. В нашей публикации мы постарались осветить актуальные проблемы разработчиков и поделиться своим видением их решения. Это первая публикация о характеристиках консоли платформы dBrain и возможностях, которые она дарит разработчику микросервисов. Направление в своей разработке мы выбираем, опираясь на пользовательские запросы. Поэтому задавайте свои вопросы в комментариях, для нас это ценный ориентир. Мы обязательно ответим вам.
В следующих публикациях мы подробнее расскажем о структуре dBrain и работе ее компонентов.