Рекомендации по использованию#

В этом разделе приводится рекомендации по работе с сервисами брокера сообщений.

Apache Kafka#

Варианты запуска сервиса#

  • Отказоустойчивый сервис, развёрнутый в кластере из шести экземпляров виртуальных машин в одной или трёх зонах доступности.

Архитектура отказоустойчивого решения#

В кластере Kafka имеется два типа узлов:

  • контроллеры (координаторы);

  • брокеры (серверы с данными).

Контроллеры служат для поддержания кластерного кворума, хранения метаданных Kafka и репликации данных. Даже в инсталляции Kafka с одним узлом контроллер необходим — в этом случае обе роли совмещены на одном узле.

Контроллеры могут быть двух видов:

  • традиционный контроллер Zookeeper;

  • встроенный контроллер Kafka Kraft, пришедший на смену Zookeeper.

В К2 Облаке поддерживается контроллер Kafka Kraft, который лишён ряда недостатков своего предшественника.

Для продуктивных нагрузок совмещать роли контроллера и брокера на одном узле нельзя. Поэтому при развёртывании сервиса создаются три отдельных узла-координатора и три узла-брокера. Контроллеры взаимодействуют между собой по протоколу консенсуса Raft и обеспечивают работу узлов с данными (брокеров). Использование трёх брокеров позволяет разбить топики на разделы и реплицировать разделы на три зоны доступности (при развёртывании кластера в трёх зонах доступности).

Подключение к сервису#

После развёртывания Kafka принимает клиентские подключения на порту tcp/9092 каждой виртуальной машины с ролью брокера. Контроллеры не взаимодействуют с клиентами и не отвечают на клиентские подключения.

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

Мониторинг#

Для мониторинга сервиса мы рекомендуем включить облачный сервис мониторинга Prometheus. Если вы хотите использовать собственный сервер мониторинга, то можете подключить его к экспортёру Prometheus kafka_exporter`, который устанавливается на узлы брокеров вместе с Apache Kafka и работает на порту tcp/9308.

RabbitMQ#

Варианты запуска сервиса#

  • Одиночный экземпляр сервиса, развёрнутый на одном экземпляре виртуальной машины в выбранной зоне доступности.

  • Отказоустойчивый сервис, развёрнутый в кластере минимум из трёх экземпляров виртуальных машин в трёх зонах доступности.

Архитектура отказоустойчивого решения#

Все узлы кластера, где развёрнут отказоустойчивый сервис RabbitMQ, равноценны с точки зрения их функциональности. Узел может представлять собой либо RAM-узел (RAM node), либо дисковый узел (disc node, или disk node). В первом случае его состояние хранится в оперативной памяти (за исключение случаев использования очередей Persistent Queue, либо когда размер очереди слишком велик и не помещается в оперативную память). Во втором случае данные хранятся и на диске, и в оперативной памяти.

Во избежание потери данных кластер должен иметь по крайней мере один дисковый узел. В К2 Облаке из трёх узлов кластера два представляют собой RAM node, а один — disc node. Кроме того, в целях обеспечения максимальной отказоустойчивости политика репликации настроена таким образом, что все очереди реплицируются на все узлы кластера (ha-node = all, ha-sync-mode = automatic). Таким образом, даже потеря двух из трёх узлов кластера не должна приводить к потере данных.

Аутентификация и безопасность#

При развёртывании нового сервиса RabbitMQ необходимо задать пароль пользователя admin, чтобы после его создания вы могли подключиться к веб-интерфейсу RabbitMQ и управлять его настройками. Пользователь admin имеет разрешения на чтение и запись во все очереди любого виртуального хоста (vhost), а также право назначать и изменять разрешения другим пользователям.

Кроме пользователя admin при развёртывании сервиса создаётся встроенный пользователь guest, которые имеет аналогичные права. Однако RabbitMQ позволяет подключаться с этой учётной записью только при использовании localhost, т.е. для неё запрещены удалённые подключения. Вы можете оставить пользователя guest без изменений (не изменять пароль по умолчанию и разрешения), так как никто посторонний не сможет подключиться от его имени.

Мы не рекомендуем использовать учётную запись admin для работы с сервисом RabbitMQ из ваших приложений. Для этих целей лучше создать отдельных пользователей и ограничить им соответствующим образом права. Избегайте утечек пароля пользователя admin, так как данная учётная запись имеет неограниченные привилегии.

Если одной или нескольким виртуальным машинам, на которых работает PaaS RabbitMQ, назначен Elastic IP-адрес, то данный сервис может потенциально оказаться публично доступным. Поэтому обязательно используйте группы безопасности облака, чтобы ограничить доступ к вашим сервисам только адресами и сетями, из которых вы работаете.

Подключение к сервису#

После развёртывания сервис RabbitMQ принимает клиентские подключения по протоколу TCP на порту 5672 на каждом экземпляре виртуальной машины, на котором он запущен.

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

Для простоты и удобства использования отказоустойчивого сервиса RabbitMQ в него встроена инсталляция HAProxy. Это позволяет отслеживать состояние сервиса и автоматически направлять запросы на работающие экземпляры. Сервис HAProxy выполняется на каждом из узлов кластера на порту tcp/5000. Таким образом, вы можете просто обращаться к этому порту на любом из узлов — механизм HAProxy его правильно направит к работающему экземпляру RabbitMQ.

Кроме того, на порту tcp/15672 активируется управляющий интерфейс, к которому можно обращаться с других узлов, используя утилиту rabbitmqctl либо браузер. Чтобы открыть веб-интерфейс для управления настройками RabbitMQ, наберите в браузере адрес http://<vm-address>:15672, где <vm-address> — приватный или публичный IP-адрес виртуальной машины, на которой работает сервис. Публичный адрес может понадобиться, если вы подключаетесь через интернет. Управлять кластером RabbitMQ можно, подключившись к любому экземпляру кластера.

Мониторинг#

Для мониторинга сервиса мы рекомендуем включить облачный сервис мониторинга Prometheus. Если вы хотите использовать собственный сервер мониторинга, то можете подключить его к экспортёру Prometheus rabbitmq_exporter, который устанавливается вместе с RabbitMQ и работает на порту tcp/9090.