EventStoreDB з AWS: розбираємося, як працює кластер та як налаштувати запуск

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Привіт! Мене звуть Олег, я — Back-end engineer компанії Rolique. Чому я обрав саме таку тему для написання статті? На моєму проєкті була потреба налаштувати EventStoreDB кластер, тож мені було цікаво детальніше розібратись у цій темі.

Документація містить всю потрібну інформацію, однак на початку знайомства цього трохи забагато. В інтернеті майже не було постів з прикладами, тому я вирішив, що це хороша ідея дати трохи контексту щодо того, як EventStoreDB кластер функціонує і також ще й дати робочий зразок для експериментів.

Кому це може бути корисним? Новачкам, які хочуть ознайомитись і спробувати крутий інструмент, не втрачаючи час на суху документацію.

Ключові принципи роботи EventStoreDB у складі групи

EventStoreDB — це база даних, яка зберігає інформацію у вигляді журналу подій. Зараз це один з найпопулярніших інструментів для реалізації шаблону Event Sourcing. Я маю на меті розповісти про ключові принципи роботи EventStoreDB у складі групи. А також хочу показати етапи встановлення та налаштування за допомогою хмарного сервісу EC2 від AWS.

У цій статті я буду використовувати безкоштовний рівень на AWS та відкриту збірку EventStoreDB OSS, щоб усі бажаючі могли поекспериментувати.

У складі групи EventStoreDB функціонує за принципом shared-nothing архітектури. У цьому підході кожна машина або віртуальна машина, на якій працює програмне забезпечення бази даних, називається учасником групи. Кожен учасник використовує свої процесори, оперативну пам’ять і диски незалежно. Будь-яка координація між вузлами здійснюється на програмному рівні за допомогою мережі.

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

Обслуговування є достатньо легким, можна встановлювати оновлення або вносити зміни для кожного з учасників окремо завдяки відмовостійкості. EventStoreDB використовує статичний розмір групи, що має заздалегідь визначену кількість учасників. Якщо вам потрібно змінити кількість учасників групи, то необхідно змінити налаштування розміру групи для всіх учасників, перш ніж новий учасник матиме змогу приєднатися.

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

Узгодженість та доступність даних є загальновідомою проблемою у розподілених системах. Ви могли чути про неї як про теорему CAP. За нормальних умов, коли мережа працює справно, розподілена система може забезпечити узгодженість даних та доступність. А от коли виникає збій мережі, тоді потрібно обирати між узгодженістю даних або їх доступністю.

EventStoreDB досягає узгодженості даних за допомогою кворуму. За цією моделлю розповсюдження даних більшість учасників у групі повинні підтвердити, що вони здійснили запис на диск, перш ніж підтвердити запис клієнту. Це означає, що для того, щоб мати можливість витримати відмову n учасників, група повинна мати розмір (2n + 1). Група з трьох учасників може продовжувати записи, якщо один вузол недоступний. Якщо відмова відбулась на більшій кількості учасників, то група втрачає можливість записувати нову інформацію й дозволяє лише читання.

За нормальних умов група має одного головного учасника — лідера, а інші учасники — це послідовники.

Лідер

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

Послідовник

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

EventStoreDB група використовує алгоритм консенсусу, щоб на основі голосування визначити, хто з учасників має бути лідером, а хто — послідовником. Візуалізація роботи алгоритму.

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

Типові алгоритми консенсусу досягають прогресу, коли будь-яка більшість їх учасників доступна; наприклад, група з 5 учасників може продовжувати працювати, навіть якщо 2 учасники виходять з ладу. Якщо більше учасників виходять з ладу, вони припиняють прогрес (але ніколи не повернуть неправильний результат).

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

Протоколи цього типу виявилися ефективними засобами, за допомогою яких можна виявляти збої у великих розподілених системах асинхронним способом без обмежень, пов’язаних з надійною груповою розсилкою для групового зв’язку.

Тепер коли у вас є уявлення, що таке EventStoreDB група та як вона працює, можна розпочинати встановлення на EC2.

Встановлення EventStoreDB на EC2

Перше, що вам потрібно зробити — це відкрити консоль керування AWS. Потім перейдіть до розділу EC2 та натисніть кнопку «Instances». Після цього перейдіть до красивої помаранчевої кнопки «Launch instances».

Вводимо назву.

Обираємо зразок операційної системи Ubuntu 20.04

У розділі «Instance type» обираємо тип t2.micro, а також у розділі Key pair (login) обираємо «Proceed without a key pair».

В налаштуваннях мережі потрібно натиснути на кнопку «Edit». Всі поля залишаємо без змін і додаємо два правила за допомогою кнопки «Add security group rule».

Це дозволить нам отримати доступ до екземплярів через порт 22 за допомогою SSH, щоб ми мали змогу налаштувати їх. Також нам потрібен порт 2113 для доступу до вебчастини EventStoreDB і порт 1112, який учасники групи використовують для спілкування між собою.

Екземпляри залишаються відкритими для всіх IP-адрес лише для спрощення прикладу. AWS і я особисто рекомендуємо вам налаштувати правила групи безпеки, щоб дозволити доступ лише з відомих IP-адрес.

Розділ «Configure storage» залишаємо без змін.

У розділі «Advanced details» в поле User data додаємо декілька команд, які встановлять EventStoreDB на кожен екземпляр.

#!/bin/bash

curl -s https://packagecloud.io/install/repositories/EventStore/EventStore-OSS/script.deb.sh | sudo bash

sudo apt-get install eventstore-oss=22.10.0

У розділі «Summary» змінюємо кількість екземплярів до 3.

Натискаємо на «Launch instance». Як тільки екземпляри стануть активними, ми можемо продовжити налаштування групи EventStoreDB.

Потрібно підготувати список приватних адрес наших екземплярів. Ми будемо посилатися на них у наших конфігураційних файлах як private-ip-node-1, private-ip-node-2, private-ip-node-3.

Натисніть на екземпляр і відкрийте вкладку «Деталі», щоб переглянути приватну IP-адресу екземпляра.

А тепер нам слід підготувати конфігураційний файл для кожного екземпляра. Щоб полегшити вам життя, я додаю шаблон для конфігураційного файлу (зверніть увагу на три риски на початку файлу та пробіли при копіюванні, оскільки він використовує формат yaml).

Цей шаблон слід використовувати для 1-го файлу, тому майте на увазі, що він повинен бути пов’язаний з 2-м і 3-м вузлами через GossipSeed. Така ж логіка застосовна до решти вузлів.

Це зразок зі спрощеною конфігурацією безпеки. Для використання у роботі важливо налаштувати функції безпеки EventStoreDB, щоб запобігти неавторизованому доступу до ваших даних. Для отримання детальнішої інформації про налаштування безпеки, зверніться до документації EventStoreDB.

---

# Paths
Db: /var/lib/eventstore
Index: /var/lib/eventstore/index
Log: /var/log/eventstore
# Insecure mode
# When running with protocol security
# disabled, everything is sent unencrypted
# over the wire
Insecure: true

# Network configuration
IntIp: private-ip-node-1
ExtIp: private-ip-node-1
HttpPort: 2113
IntTcpPort: 1112
EnableExternalTcp: false
EnableAtomPubOverHTTP: true

# Cluster gossip
ClusterSize: 3
DiscoverViaDns: false
GossipSeed: private-ip-node-2:2113,private-ip-node-3:2113

# Projections configuration
RunProjections: All

# Timeouts and intervals
GossipIntervalMs: 2000
GossipTimeoutMs: 3000
IntTcpHeartbeatInterval: 5000
IntTcpHeartbeatTimeout: 1000

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

Наступне, що нам потрібно зробити — це просто підключитися до екземпляра та виконати такі команди (*повторіть дію для кожного учасника групи).

Виберіть екземпляр та нажміть кнопку «Connect».

Після підключення до екземпляра виконайте наступні команди:

• створіть конфігураційний файл:
  $ sudo touch /etc/eventstore/eventstore.conf
• відкрийте файл будь-яким зручним для вас чином та вставте конфігурацію, яка відповідає даному учаснику:
  $ sudo nano /etc/eventstore/eventstore.conf
• запустіть EventStoreDB. Коли ви встановлюєте EventStoreDB, служба не запускається автоматично. Це робиться для того, щоб ви могли змінити конфігурацію, розташовану в /etc/eventstore/eventstore.conf, і щоб запобігти створенню файлів бази даних і індексів у типовому розташуванні.
  $ sudo systemctl start eventstore

Ви можете перевірити, чи готовий ваш кластер до використання http://public-ip-node-1:2113/web/index.html#/clusterstatus. (Загальнодоступна IP-адреса вказана безпосередньо біля приватної IP-адреси. Обов’язково http, а не https).

На цей момент у вас повинні бути всі учасники в статусі Alive. А також у групі повинен бути один Leader і два Follower.

І ось так ви запустили EventStoreDB групу за допомогою AWS. Однак майте на увазі, що це — не готовий до використання в реальному житті приклад, а лише зразок для ознайомлення.

Також, якщо ви не хочете використовувати AWS, то документація EventStoreDB має чудові приклади з використанням Docker.

Висновки

Сподіваюсь, моя стаття допомогла зробити перший крок у знайомстві з розподіленими системами та EventStoreDB зокрема легким і цікавим. А також зробить подальшу роботу з офіційною документацією набагато комфортнішою.