Разработка, проектирование и производство IT оборудования

Решение Rikor «Сервер очередей на основе Apache Kafka»

Введение

Apache Kafka — распределённый программный брокер сообщений, проект с открытым исходным кодом, разработанный в рамках Apache Software Foundation. Написан на языке программирования Scala.
Отличия от традиционных системы передачи сообщений:
• Cпроектирован изначально как распределённая система, которую легко масштабировать,
• Поддерживает высокую пропускную способность как со стороны источни - ков, так и для систем-подписчиков,
• Поддерживает объединение подписчиков в группы,
• Обеспечивает возможность временного хранения данных для последующей пакетной обработки.

Одной из особенностей реализации инструмента является применение техники, сходной с журналами транзакций, используемыми в системах управления базами данных.

Ключевые особенности системы:

• Скорость: один узел кластера может обрабатывать сотни мегабайт записей в секунду
• Масштабируемость: кластер можно прозрачно расширять без простоя, потоки данных партицированы.
• Надежность: сообщения в кластере отреплицированы, каждый узел может держать терабайты данных без потерь в производительности.

Архитектура

Архитектура Apache Kafka состоит из следующих компонентов:
• Поток сообщений (message) определенного типа в терминах службы называется темой (topic). Сообщение – это полезный для некоего процесса комплект данных, тогда как тема – это категория, в соответствии с которой публикуется то или иное сообщение.
• Производитель (producer) – это любой процесс, публикующий сообщения в соответствующей теме.
• Опубликованные сообщения затем отправляются на хранение на кластер серверов, именуемых брокерами (brokers) или кластеромKafka.
• Потребитель (consumer) может подписаться на одну или несколько тем и использовать сообщения, забирая данные от брокеров.

Kafka 1

Поскольку Kafka по своей природе является распределенной системой, кластер состоит из нескольких брокеров. Для удобства тема разбивается на секции, и каждый брокер отвечает за хранение одной или нескольких секций. Это дает возможность множеству производителей и потребителей публиковать и исполь - зовать сообщения для своих целей одновременно.

Использование Apache Kafka

• Агрегация логов
• Брокер сообщений
• Отслеживание активностей пользователей
• Мониторинг больших данных

Интеграция Apache Kafka c компонентами Hadoop

Kafka 2

Требования к производительности кластера Apache Kafka со стороны Заказчиков:

• Не менее 30 000 сообщений в секунду
• Размер сообщений от 1Кб до 2Мб

Тестирование и оптимизация производительности Apache Kafka на серверах РИКОР Ecoserver R-314

Конфигурация кластера:
• Сервер Rikor EcoServer R314 с тремя 2х процессорными лезвиями Marvel Armada XP 4-core, 8Gb RAM, 320Gb HDD
• В тестах использовался дистрибутив Apache Kafka v. 2.10-0.8.2.0
• На хостах брокеров и зукипера установлена ОС ROSA Enterprise Linux Server 6.5 Helium.
• 1 продюсер на PC Core-2 DUO, 2.6 Ghz, Ethernet 1Gb, RAM или SSD диск.
• От 1 до 6 брокеров на отдельных процессорных узлах 1.6 Ghz, с Ethernet 1Gb, RAM диск, опция аппаратного исполнения Java (CONFIG_ARM_THUMBEE=y), JIT компилятор.
• 1 zookeeper на отдельном процессорном узле 1.6 Ghz, с Ethernet 1Gb, RAM диск, опция аппаратного исполнения Java, JIT компилятор.
• 1-Топик, количество партиций равно количеству брокеров, без репликации (фактор=1)
• Cетевой коммутатор D-Link 1Gb.

Последовательно были проведены 6 серий экспериментов. На рисунке 3 показана последовательность экспериментов снизу вверх, что совпадает с улучшением результатов.
Условия тестирования в каждой серии экспериментов.

1. Ethernet адаптер продюсера 100Mb, количество сообщений nMsg=100 000, количество потоков 8-10, при масштабировании количество сообщений и потоков не изменяли. Использовали HDD, не использовали JIT и опцию ядра, все параметры брокера по умолчанию. Проведено 4 эксперимента.
2. Ethernet адаптер продюсера 100Mb, количество сообщений nMsg=1 000 000, количество потоков 8-10, при масштабировании количество сообщений и потоков не изменяли. Использовали HDD, не использовали JIT и опцию ядра, все параметры брокера по умолчанию. Проведено 4 эксперимента.
3. Ethernet адаптер продюсера 1Gb, количество сообщений nMsg=1 000 000, количество потоков 8-10, при масштабировании количество сообщений и потоков не изменяли. Использовали HDD, не использовали JIT и опцию ядра, все параметры брокера по умолчанию. Проведено 5 экспериментов.
4. Ethernet адаптер продюсера 1Gb, количество сообщений nMsg=1 000 000, количество потоков 8-10, при масштабировании количество сообщений и потоков не изменяли. Использовали RAM-диск, не использовали JIT и опцию ядра, все параметры брокера по умолчанию. Проведено 5 экспериментов.
5. Ethernet адаптер продюсера 1Gb, количество сообщений nMsg=1 000 000, количество потоков 8-10, при масштабировании количество сообщений и потоков не изменяли. Использовали RAM-диск, JIT и опцию ядра, все параметры брокера по умолчанию. Проведено 5 экспериментов.
6. Ethernet адаптер продюсера 1Gb, количество сообщений от 1 000 000 до 6 000 000 в зависимости от количества брокеров, количество потоков 8 на каждого брокера (т.е. от 8 до 48), при масштабировании количество сообщений и потоков увеличивалось. Использовали RAM-диск, JIT (см. приложение) и опцию ядра CONFIG_ARM_THUMBEE=y, оптимизированные параметры брокера (см. приложение). Проведено 6 экспериментов.



Kafka 3

Сравнительное тестирование виртуальных машин Oracle-JRE и OpenJDK-JRE с опциями аппаратного ускорения на примере задачи Apache Kafka на кластере ARM серверов РИКОР Ecoserver R314

Конфигурация кластера:
• Oracle-JRE v.7. + Apache Kafka v. 2.10-0.8.2.0
• Серверное шасси Rikor Ecoserver R314 c шестью процессорными узлами ARM x32 4Сore (ARMADA-XP)
• На хостах Брокеров и Зукипера установлена ОС Ubuntu 14.04.0 LTS, в ядре включены опции аппаратного ускорения.
• 1 продюсер на PC Core-2 DUO, 2.6 Ghz, Ethernet 1Gb.
• От 1 до 6 брокеров на отдельных процессорных узлах 1.6 Ghz, с Ethernet 1Gb, HDD диск, опция аппаратного исполнения Java (CONFIG_ARM_THUMBEE=y), JIT компилятор.
• 1 Zookeeper на отдельном процессорном узле 1.6 Ghz, с Ethernet 1Gb, RAM диск, опция аппаратного исполнения Java, JIT компилятор.
• 1-Топик, количество партиций равно количеству брокеров, без репликации (replication-factor=1)
• Cетевой коммутатор D-Link 1Gb

Условия тестирования в каждой серии экспериментов

Работа была выполнена студентами в рамках производственной практики в РИКОР ИМТ, в условиях ограниченного времени. Полученные результаты могут быть улучшены (Рис. 2 и 3, линия чёрного цвета - 6x ARM 4Core : OraceJRE).

1. Ethernet адаптер продюсера 1Gb, количество сообщений от 1 000 000 до 6 000 000 в зависимости от количества брокеров, количество потоков 10 на каждого брокера (т.е. от 10 до 60), при масштабировании количество сообщений и потоков увеличивалось. Использовали HDD-диск, JIT (см. приложение) и опцию ядра CONFIG_ARM_THUMBEE=y, оптимизированные параметры брокера (см. приложение). Проведено 6 экспериментов при размере сообщений 1024 байт (Рис. 2, линия чёрного цвета - 6x ARM 4Core : OraceJRE).
2. Ethernet адаптер продюсера 1Gb, количество сообщений 6 000 000, количество потоков - от 60 до 10, при увеличении размера пакетов количество потоков уменьшалось до достижения состояния, при котором нет сообщений об ошибках. Использовали HDD-диск, JIT (см. приложение) и опцию ядра CONFIG_ARM_THUMBEE=y, оптимизированные параметры брокера (см. приложение). Проведено 6 экспериментов для сообщений размером 1, 2, 3, 5, 10, 20 килобайт (Рис. 3, линия чёрного цвета - 6x ARM 4Core : OraceJRE).



Сравнение производительности Rikor ARM Armada XP vs Intel Xeon E5 2600 v2

При сравнительном тестировании использовался сервер x86: 2x Intel Xeon E5-2695v2 (12c, 2.4 GHz), 256 GB RAM 1600 MHz, 500 GB HDD, ConnectX3 FDR Infiniband, 2x 1 GbE Ethernet.

Kafka 4