Стаття також доступна російською (перейти до перегляду).

Вступ

• Загальні підходи до визначення критеріїв якості роботи брокерів повідомлень
• Швидкість обробки повідомлень
• Балансування навантаження
• Реплікація даних
• Персистентність даних
• Горизонтальне масштабування та відмовостійкість
• Гнучкість при роботі з повідомленнями
• Безпека використання
• Робота з Apache Pulsar у робочому середовищі
• Системні вимоги
• Розгортання програми
• Робота з темами
• Висновки

У статті ми вже розглядали характеристики та питання практичного використання сучасного брокера повідомлень Apache Kafka. Достойною альтернативою йому може стати брокер Apache Pulsar, супроводжуваний Apache Software Foundation. Обидва брокери націлені на використання у розподілених системах публікації повідомлень із підпискою та є лідерами по ряду характеристик у порівнянні із іншими програмними засобами цього сегменту. Однак між ними самими існує чимало відмінностей, котрі роблять Pulsar більш досконалим. Розглянемо порівняльну характеристику брокерів для реалізації в нашій моделі розподіленої системи, а також продемонструємо процес встановлення Apache Pulsar на VPS-сервер Ubuntu.

Загальні підходи до визначення критеріїв якості роботи брокерів повідомлень

Вибір критеріїв напряму залежатиме від цілей використання та конфігурації розподіленої системи. І тому важливо зупинитися на якійсь конкретній моделі для того, щоб визначитися із критеріями або вимогами до роботи брокерів.

Будемо виходити з того, що сервіс повинен працювати у високонавантаженій розподіленій системі із необмеженою кількістю потенційних споживачів повідомлень (Consumer) та видавців (Producer). Її архітектура буде орієнтована на випадки. Це, наприклад, може бути будь-яка конвеєрна або транзакційна система. Визначимо по відношенню до неї основний перелік вимог до роботи брокера повідомлень:

Велика швидкість обробки повідомлень;

• Балансування навантаження;
• Реплікація даних;
• Персистентність даних;
• Горизонтальне масштабування та відмовостійкість;
• Гнучкість при роботі з повідомленнями;
• Безпека використання.

Вказані критерії є вихідними для оцінки якості роботи того чи іншого брокера повідомлень у системі із визначеними характеристиками. Розглянемо кожен з них окремо.

Швидкість обробки повідомлень

Цей параметр є вельми важливою характеристикою для будь-якого сервісу обробки повідомлень, особливо для високонавантажених систем.

За інформацією розробника, котра була неодноразово підтверджена на практиці, сервіс Kafka здатний обробляти більш ніж 1 млн. повідомлень за секунду. Таке значення досягається, перш за все за рахунок архітектури, орієнтованої на потокову обробку даних. Основними ознаками такої архітектури є:

• Кластерна організація;
• Кешування повідомлень перед відправкою;
• Використання партицій;
• Пакетна обробка повідомлень (батчі та інші засоби);
• Окреме зберігання метаданих кластеру за допомогою служби ZooKeeper.

Ці та деякі інші механізми дозволяють сервісу мати вказане значення швидкості.

За цим показником Pulsar наближений до Kafka, тобто здатний обробляти більш ніж 1 млн. повідомлень. Більш того, за результатами декотрих тестів він показує більші значення швидкості, ніж його найближчий конкурент. Впливати на це можуть деякі із удосконалень архітектури, котра за своєю суттю мало відрізняється від аналогу. Окрім наведених вище рішень, Pulsar додатково має наступні кейси:

• Використання брокерів без збереження станів;
• Багатошаровість архітектури;
• Удосконалений механізм партицій;
• Інші рішення, котрі прямо або опосередковано підвищують швидкість роботи сервісу.

Слід зазначити, що сервіс RabbitMQ здатний обробляти лише біля 50 тис. повідомлень за секунду в залежності від конфігурації системи. Вочевидь, таке значення може бути достатнім лише у випадку невеликого потоку даних, а, значить, сервіс не підходить для використання у нашій моделі розподіленої системи. І тому він не буде нами розглядатися у подальшому у якості конкурента іншим сервісам, а буде сконцентрована увага на двох схожих за суттю брокерах – Kafka і Pulsar.

Балансування навантаження

У процесі роботи будь-якого брокеру повідомлень можливе виникнення перевантажень у межах кластеру або екземпляру. Для усунення цього негативного фактору зазвичай виконується балансування навантаження.

У Kafka відсутній влаштований механізм забезпечення автоматичного балансування навантаження. Але його можна «сконфігурувати» за допомогою сторонніх засобів, наприклад, таких, як rebalancer від компанії Confluent та деяких інших.

У Pulsar вказаний механізм є. Це стає можливим за рахунок використання брокерів без збереження стану, котрі можна додавати при виникненні перевантажень у межах кластеру або екземпляру та перенаправляти на них нових клієнтів. Вочевидь, такий підхід набагато кращий, ніж у конкурента.

Реплікація даних

При використанні будь-якої моделі розподілених систем зберігання даних постає питання забезпечення надійної синхронізації між копіями даних. І тому усі брокери повідомлень, у тому числі Kafka і Pulsar підтримують відповідні механізми. Однак, між ними є суттєві відмінності.

Kafka використовує механізм синхронізації даних типу follow-the-leader, згідно котрої вихідне повідомлення завжди зберігається на головному вузлі (leader), а всі залежні від нього вузли або клієнти зберігають його копії. Тут використана ієрархічна структура, при котрій кінцеве рішення про оновлення даних приймає виключно головний вузол. І тому затримка може бути значною.

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

Також слід вказати про підтримку Pulsar механізму гео-реплікації, коли дані оновлюються незалежно від місця розташування вузлів, наприклад, це актуально у випадку використання кластерів, вузли котрих розкидані по різним дата-центрам.

Персистентність даних

Забезпечення персистентності даних у роботі розподіленої системи дозволяє мати до них постійний доступ незалежно від часу їх зберігання. Наприклад, забезпечення довготривалого зберігання історії банківських транзакцій є необхідною умовою її функціонування. Звісно, рівень персистентності може бути різним, і чим він вище, тим краще. Однак, за це треба «сплачувати» ресурсами, до котрих, зокрема, можна віднести ємність SSD-дисків або інших пристроїв збереження даних.

Обидва брокери забезпечують певний рівень персистентності, однак у Pulsar він значно вищий, зокрема, за рахунок використання багаторівневого сховища із можливістю підключення зовнішніх сховищ даних. Це дозволяє в автоматичному режимі переміщувати значні об’єми вже «використаних», тобто прочитаних повідомлень до майже безмежних та дешевих хмарних сховищ. Така опція відсутня у Kafka і тому цей сервіс тут програє.

Наявність підтримки високого рівня персистентності дозволяє забезпечити роботу із так званими відкладеними чергами повідомлень, що досить вдало реалізовано у Pulsar. Це значно розширює його можливості у якості брокера повідомлень з довготривалою пам’яттю.

Горизонтальне масштабування та відмовостійкість

Однією з ключових особливостей Pulsar є наявність окремих незалежних шарів у його структурі, тобто багатошаровість. Прикладом тут може бути організація роботи брокерів та сховища, котрі функціонують незалежно одне від одного. Це дозволяє масштабувати брокери окремо і незалежно від станів сховища. Кожен з них може взаємодіяти із різними екземплярами служби BookKeeper, котра регулює роботу сховища.

У той же час ніщо не заважає здійснювати масштабування і по відношенню до сховища і це ніяк не вплине на роботу брокерів. Тобто, масштабування тут можливе водночас у двох площинах.

Як відомо, чим вищий рівень масштабування, тим більш високий рівень відмовостійкості має розподілена система. Це означає, що Pulsar є більш стійким по відношенню до збоїв.

Гнучкість при роботі з повідомленнями

Гнучкість або орієнтованість розподіленої системи на споживача (конс’юмера), зазвичай, вітається. У цьому сенсі Pulsar має ряд вдосконалень, що дає підстави стверджувати про його більш високий рівень гнучкості у порівнянні із конкурентом. Розглянемо це.

Насамперед, це необмежена кількість потенційних конс’юмерів, що дозволяє сприймати сервіс як такий, що не має обмежень.

Розширені можливості для вибору «типу спілкування» конс’юмерів із продюсером за рахунок використання механізму підписок. Це дозволяє обрати механізм обміну даними, котрий більше підходить в залежності від нагальних потреб системи або конс’юмера. Наприклад, для роботи із чергами існує окремий режим роботи. Також можна регулювати кількість конс’юмерів, котрі можуть отримувати ті чи інші повідомлення, тобто здійснювати своєрідну фільтрацію.

У цій же площині у Pulsar підтримується можливість для конс’юмерів підтверджувати повідомлення не тільки групами, а й будь-які окремі з них, котрі можуть бути обрані із загального списку. Тобто, тепер повідомлення можна «аськати» вибірково. І це є дуже суттєвою підтримкою для збільшення рівня гнучкості при використанні сервісу.

Безпека використання

Під безпекою тут розуміється забезпечення недосяжності вмісту повідомлень для сторонніх об’єктів – людей, програм та інш. Найбільш надійний механізм – шифрування повідомлень із використанням ключів, так зване наскрізне шифрування. У такому разі прочитати повідомлення зможуть лише ті клієнти, котрі мають відповідний ключ.

Серед брокерів, що розглядаються, лише Pulsar підтримує наскрізне шифрування. На даний момент часу його застосування можливе за наявності Java-клієнту.

Робота з Apache Pulsar у робочому середовищі

Розглянемо вимоги до програмного середовища, процес встановлення програми та основні кроки для роботи з нею.

Системні вимоги

Інформацію про системні вимоги до версії JVM для встановлення тієї чи іншої версії програми можна подивитися тут. Загальні вимоги нами зведені у Таблицю 1.

Таблиця1. Системні вимоги для встановлення та роботи Apache Pulsar.

Версія програми	Версія та тип JRE/JDK	ОС серверу	ОП серверу, Gb	Автоматизація збірки проектів
<= 2.10	11	64-bit macOS, Linux, Windows (при наявності Docker)	4	3.6.Maven 1+
> 2.10	17

Наш сервер має значення ОП не менші, ніж зазначені у Таблиці 1, 64-бітну версію ОС Ubuntu і відповідну версію Maven.

Розгортання програми

Для того, щоб вирішити яку версію програми ми можемо встановити на сервер, з'ясуємо яка версія бібліотек JRE/JDK є наявною на даний момент на нашому сервері. Для цього введемо в терміналі:

$ java -version

Результат:

OpenJDK Runtime Environment (build 11.0.22+7-post-Ubuntu-0ubuntu222.04.1)
OpenJDK 64-Bit Server VM (build 11.0.22+7-post-Ubuntu-0ubuntu222.04.1, mixed mode, sharing)

Це означає, що наразі ми можемо встановити версію Apache Pulsar 2.10.3 або старшу.

Перед тим оновимо індекс пакетів за допомогою наступної команди:

$ sudo apt update

Завантажимо офіційний дистрибутив програми. Для цього введемо в терміналі

$ wget https://archive.apache.org/dist/pulsar/pulsar-2.10.3/apache-pulsar-2.10.3-bin.tar.gz

Результат:

apache-pulsar-2.10.3-bin.tar.gz 100%[=======================================================>] 334.68M  7.90MB/s   in 32s

Отже, файл успішно завантажений. Розпакуємо його:

$ tar xvfz apache-pulsar-2.10.3-bin.tar.gz

В результаті виконання команди був створений кореневий каталог програми. Перейдемо до нього:

$ cd apache-pulsar-2.10.3

Переглянемо вміст каталогу apache-pulsar-2.10.3, щоб з’ясувати які системні директорії та файли були створені:

$ ls -1F

Вихід команди:

bin/
conf/
examples/
instances/
lib/
LICENSE
licenses/
NOTICE
README

На наступному етапі розгортання сервісу запустимо автономний кластер Pulsar. Це можна зробити за допомогою наступної команди:

$ bin/pulsar standalone

При запуску кластеру програма створює додатково ще дві директорії: Data та Logs. У першій з них будуть зберігатися всі дані, створені BookKeeper та RocksDB. У другій будуть зберігатися всі журнали на стороні серверу.

Окрім того, автоматично створюється загальний простір імен public/default, призначений для розробників.

Також ми могли б скористатися можливістю запустити сервіс у фоновому режимі. Це можна зробити за допомогою наступної команди:

$ bin/pulsar-daemon start standalone

Робота з темами

Після виконання попередніх дій стає можливим створення тем (топіків), до котрих будуть прив'язуватися повідомлення, котрі до них відносяться. Розробники сервісу рекомендують одразу ж у явному вигляді створювати потрібні теми, не чекаючи поки програма їх створить в автоматичному режимі.

Для створення теми, зазвичай, використовується наступна команда:

$ bin/pulsar-admin topics create persistent://public/default/my-topic

Де my-topic – ім’я потрібної теми.

Для створення повідомлення у обраній темі слід скористатися наступною конструкцією:

$ bin/pulsar-client produce my-topic --messages 'What's new?'

При цьому Pulsar переходить у режим прослуховування, що видно із вигляду запрошення командної строчки (див. скрин вище). Для виходу із вказаного режиму необхідно водночас натиснути комбінацію клавіш ctrl+C.

Після того, як у темі накопичиться певна кількість повідомлень, їх завжди можна прочитати за допомогою наступної управляючої конструкції:

$ bin/pulsar-client consume my-topic -s 'my-subscription' -p Earliest -n 0

Формат виводу змісту повідомлень буде наступним:

----- got message -----
 key:[null], properties:[], content: What's new?

У випадку, якщо потрібно відправити одразу групу повідомлень можна скористатися наступною командою:

$ bin/pulsar-client produce my-topic --messages "$(seq -s, -f 'Mess New.%g' 1 10)"

Висновки

За результатами розгляду двох схожих по багатьом параметрам брокерів повідомлень ми з'ясували, що за своєю структурою Kafka і Pulsar мають багато спільних рис, зокрема, це потоковість та швидкість обробки даних, логіка роботи та інші характеристики. Однак, Pulsar, по суті, є вдосконаленим варіантом Kafka, котрий має набір важливих рішень, наприклад, таких як багатошаровість архітектури, підтримка роботи із відкладеними чергами та багатьох інших. Тобто він в більшій мірі відповідає вимогам, сформованим нами на початку статті.

Підписуйтесь на наш телеграм-канал https://t.me/freehostua, щоб бути в курсі нових корисних матеріалів.

Дивіться наш канал Youtube на https://www.youtube.com/freehostua.

Ми у чомусь помилилися, чи щось пропустили?

Напишіть про це у коментарях, ми з задоволенням відповімо та обговорюємо Ваші зауваження та пропозиції.

Дата: 17.04.2024 Автор: Олександр Ровник #cqrs#devops#programming#ubuntu

Голосування 1 2 3 4 5