Внедрение RabbitMQ в облачную платформу: проблемы и решения

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

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

Что такое брокер RabbitMQ

RabbitMQ — один из самых популярных брокеров сообщений наряду с Kafka. Kafka построена по принципу “глупый брокер, умный потребитель”, RabbitMQ — “умный брокер, глупый потребитель”. В RabbitMQ можно строить логику обработки и направления сообщений, в то время как Kafka — это просто лог данных, а вся логика хранится в консьюмерах. Kafka обычно используется с большим потоком сообщений или данных, например, десятки или сотни тысяч сообщений в секунду. Если в приложении не планируется обрабатывать такие объемы, то стоит рассмотреть RabbitMQ: он более легковесный в потреблении ресурсов и проще в настройке. У каждого брокера есть плюсы и минусы, оба используют в крупных компаниях.

В dBrain мы используем оба брокера, чтобы закрывать потребности компаний любого размера и запросов к функционалу MQ (Message queue).

Как реализовали в dBrain

В платформе dBrain предусмотрен инструмент для создания и развертывания приложений, управления базами данных и мониторинга — консоль. Это веб-интерфейс, который упрощает взаимодействие с инфраструктурой, базами данных, Kubernetes. Из консоли dBrain в пару кликов можно развернуть любой сервис (как это происходит, можно прочитать тут). Брокер RabbitMQ также можно развернуть с помощью интерфейса dBrain.

В dBrain мы реализовали управление RabbitMQ на основе двух популярных операторов:

• RabbitMQ Cluster Kubernetes Operator

• RabbitMQ Messaging Topology Kubernetes Operator

Первый управляет непосредственно кластерами RabbitMQ, второй — всеми остальными элементами в кластере, такими как User, Vhost, Queue, Exchange, Binding и тд.

Проблемы внедрения

При внедрении брокера в платформу контейнеризации dBrain возникли некоторые нюансы. Например, проблема с дефолтными настройками RabbitMQ Cluster: сервис не утилизировал (не использовал по максимуму) всю выделенную RAM (random-access memory).

Для этого мы обратились к настройке vm_memory_high_watermark, она по дефолту равна 40%. На первом шаге попробовали заменить настройку на vm_memory_high_watermark.relative = 0.7 (согласно рекомендациям). Это улучшило утилизацию, но привело к периодическому рестарту подов. После более детального изучения документации мы изменили настройку как рекомендовано тут и тут, немного скорректировав логику расчета: vm_memory_high_watermark.absolute = {{ (memory * 0.7) | int }}Mi.Операция приведения к int обязательна, т.к. RabbitMQ не запустится, если указать не целое число.

Для продакшен-окружения рекомендуем установить настройку disk_free_limit.relative = 1.0 чтобы RabbitMQ мог сбросить все содержимое из памяти на диск. Также стоит выбрать настройку cluster_partition_handling. Если у вас нечетное количество инстансов, рекомендуем выставить в pause_minority.

Настройка RabbitMQ включает несколько уровней:

• rabbitmq.conf — основной файл настроек, самый удобный и простой:

• advanced.config — конфиг в формате Erlang-а: ограниченный набор настроек, используется, когда не подошел пункт 1

• rabbitmq-env.conf — файл для настроек переменных окружения

Дополнительный функционал в RabbitMQ подключается через набор плагинов. Список предустановленных плагинов можно проверить, выполнив в поде команду rabbitmq-plugins list. Там же можно увидеть список включенных плагинов. Мы дополнительно включили плагин rabbitmq_top, который предоставляет простой, но информативный UI. Он нужен, когда необходимо посмотреть детальную информацию.

Самый простой способ включения настроек для мониторинга в RabbitMQ реализован аналогично — через плагин rabbitmq_prometheus. Он открывает порт и предоставляет метрики в формате prometheus. Далее по набору лейблов на поде RabbitMQ через указанный для мониторинга порт VictoriaMetrics забирает метрики согласно описанию ниже.

apiVersion: operator.victoriametrics.com/v1beta1 kind: VMPodScrape metadata:   name: rabbitmq-metrics   namespace: mon   labels:     component: rabbitmq spec:   podTargetLabels:     - "cluster-name"   namespaceSelector:     any: true   selector:     matchLabels:       component: rabbitmq       app.kubernetes.io/part-of: rabbitmq       database-metrics-enabled: true   podMetricsEndpoints:     - port: prometheus       path: /metrics

Подобный пример из оператора тут (как и пример алертов для RabbitMQ).

Помимо самого кластера RabbitMQ в dBrain можно управлять внутренними элементами кластера, такими как Vhost, User, Queue, Binding, Exchange.

Для примера создадим в кластере эти сущности (все настройки можно найти тут):

apiVersion: rabbitmq.com/v1beta1 kind: Vhost metadata:   name: rabbitmq-cluster1-vhost-host1   namespace: backend   labels:     app: rabbitmq-cluster1     component: rabbitmq     cluster-name: cluster1 spec:   name: host1   tracing: false   defaultQueueType: classic   rabbitmqClusterReference:     name: rabbitmq-cluster1     namespace: backend

apiVersion: rabbitmq.com/v1beta1 kind: Queue metadata:   name: rabbitmq-cluster1-queue-queue1   namespace: backend   labels:     app: rabbitmq-cluster1     component: rabbitmq     cluster-name: cluster1 spec:   name: queue1   vhost: host1   type: classic   autoDelete: false   durable: true   rabbitmqClusterReference:     name: rabbitmq-cluster1     namespace: backend

apiVersion: rabbitmq.com/v1beta1 kind: Exchange metadata:   name: rabbitmq-cluster1-exchange-exchange1   namespace: backend   labels:     app: rabbitmq-cluster1     component: rabbitmq     cluster-name: cluster1 spec:   name: exchange1   vhost: host1   type: direct   autoDelete: false   durable: true   rabbitmqClusterReference:     name: rabbitmq-cluster1     namespace: backend

apiVersion: rabbitmq.com/v1beta1 kind: Binding metadata:   name: rabbitmq-cluster1-binding-queue1-to-exchange1-xyz   namespace: backend   labels:     app: rabbitmq-cluster1     component: rabbitmq     cluster-name: cluster1 spec:   vhost: host1   source: queue1   destination: exchange1   destinationType: exchange   routingKey: "product.*"   rabbitmqClusterReference:     name: rabbitmq-cluster1     namespace: backend

Создадим юзера, креды и права в кластере:

apiVersion: v1 kind: Secret metadata:   name: rabbitmq-cluster1-user1   namespace: backend   labels:     app: rabbitmq-cluster1     component: rabbitmq     cluster-name: cluster1 type: Opaque stringData:   username: user1   password: secret_password

apiVersion: rabbitmq.com/v1beta1 kind: User metadata:   name: rabbitmq-cluster1-user1   namespace: backend   labels:     app: rabbitmq-cluster1     component: rabbitmq     cluster-name: cluster1 spec:   rabbitmqClusterReference:     name: rabbitmq-cluster1     namespace: backend   importCredentialsSecret:     name: rabbitmq-cluster1-user1

apiVersion: rabbitmq.com/v1beta1 kind: Permission metadata:   name: rabbitmq-cluster1-user1-permission-yxz   namespace: backend   labels:     app: rabbitmq-cluster1     component: rabbitmq     cluster-name: cluster1 spec:   vhost: host1   user: user1   permissions:     write: "*"     configure: "*"     read: "*"   rabbitmqClusterReference:     name: rabbitmq-cluster1     namespace: backend

Если в будущем потребуется изменить пароль пользователя, то просто поменять значения в Secret для этого юзера будет недостаточно. Существует важный нюанс: оператор не отслеживает изменения в Secret’ах. Чтобы оператор смог увидеть новое значение и обновить пароль в RabbitMQ, необходимо модифицировать содержимое лейблов или аннотаций в User.

Вывод

Внедрение RabbitMQ в dBrain — это развитие функционала платформы в соответствии запросами клиентов, которые хотят видеть альтернативу Kafka. Основные функции управления RabbitMQ доступны через пользовательский интерфейс dBrain. В редких случаях, когда требуются специфические изменения, можно воспользоваться YAML-конфигурациями. Добавление сервиса в dBrain упрощает запуск и управление RabbitMQ для приложений и сокращает время от начала разработки до выхода продукта на рынок.

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

Читайте также:

• Куда плывут облака? Тренды развития Kubernetes в 2025 году

• Выбор операционной системы для серверных решений: ключевые аспекты

• DevOps спит, консоль работает. Как сократить путь от разработки до внедрения приложения