💬Немного обратной связи💬

Составляю программу практических интенсивов на октябрь.

Будут новые темы и, при необходимости, повторим те, что уже были.

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

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

Описание программ:
🔸Проектирование REST API;
🔸Базы данных;
🔸Функциональные требования (ещё есть места в этом месяце);
🔸Брокеры сообщений.

Опрос ниже 👇

P.S. Новую тему опубликую чуть позже.

Системный анализ | Дмитрий Помаскин

⚙️ Подробный разбор этапов: сервис стримингого обогащения.

Начинаем с него, так как это самый "слабый" участок нашей архитектуры.

Расчеты:
1 млрд сообщений в сутки = ~11500 сообщений в секунду.
1 CPU способен обработать примерно 1000 таких операций в секунду (цифра взята из опыта работы с подобными задачами).
12 CPU = 100% нагрузки, что влечет риски отказов при неравномерной нагрузке.

Внедрим горизонтальную масштабируемость:
1 под сервиса - 4 CPU;
3 пода — 12 CPU = 100% нагрузки;
6 подов — 24 CPU = 50% нагрузки. Это будет количество подов по умолчанию. Есть запас для обработки пиков, при неравномерной нагрузке.

На случай непредвиденного роста сообщений добавим HPA этому сервису со значением 6-12.

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

❓Почему RAM (оперативная память) не будет оказывать сильного влияния на производительность?

Сообщения имеют небольшой размер — в среднем 2кб, поэтому для обработки такого потока сообщений нам будет достаточно 2GB оперативной памяти.

Пример для этого случая:

✅CPU — это скорость движения конвейерной ленты и количество рабочих. Если рабочих мало или лента медленная — бутылочное горлышко.

❌RAM — это размер стола каждого рабочего. Если стол слишком маленький, рабочий не сможет разложить инструменты и детали, работа встанет. Но как только стол достиг достаточного размера, его дальнейшее увеличение не ускорит работу рабочего.

Ссылка на кейс 👈
Ссылка на общее решение 👈

Системный анализ | Дмитрий Помаскин

❗️Последний интенсив сентября❗️

👉 Функциональные требования — сегодня 19:00 МСК 👈

Из непонятных и размытых требований учимся делать четкую структуру:

❌ Как многие пишут ФТ:
Все пользователи должны иметь возможность оформлять заказы.

✅ Как учимся писать:
FRONT — ссылки на разделы, элементы интерфейса и REST API методы, которые необходимо вызывать.

BACK — что делать при получении запроса с фронта; к каким таблицам и атрибутам БД обращаться.

Ролевая модель — как и на каком этапе проверять доступы.

Обработка исключений — какие коды ошибок возвращать с BACK и как на них должен реагировать FRONT.

Запись тут 👇
Функциональные требования

Системный анализ | Дмитрий Помаскин

⚙️ Подробный разбор этапов: Apache Kafka.

Входящие параметры:
11500 (~12000) сообщений в секунду в 1 топик.
2 топика кафки.
Размер сообщения ~2КБ.

Расчеты:
12000*2*3600*24 = ~2ТБ в сутки на 1 топик.
4ТБ в сутки на 2 топика.
Хранить больше суток нет смысла, поэтому retention = 24 часа.

Скорость записи на диск:
12000*2КБ*2топика = 48МБ/сек на 1 ноду кафки.

Нужна отказоустойчивость:
Возьмём стандартный кластер из 3-х нод.
Фактор репликации = 3.
Диски: 4ТБ*3=12ТБ (лучше взять 15ТБ, с запасом)
Репликация данных: 48МБ/сек * 3 = 144МБ/сек — небольшая нагрузка для современных SSD.

Большую часть времени будут занимать I/O операции, поэтому CPU/RAM возьмём по стандарту, так как их хватит с запасом.
На одну ноду: 4CPU, 32GB RAM.

Итог:
✅ Кластер кафки из 3-х нод;
✅ Фактор репликации: 3;
✅ 4 CPU;
✅ 32GB RAM;
✅ 15ТБ SSD.

Ссылка на кейс 👈
Ссылка на общее решение 👈

Системный анализ | Дмитрий Помаскин

🎉Сегодня ровно полгода с момента появления этого канала и онлайн-школы!

Хочу поблагодарить всех за обратную связь, благодаря ей у меня получается делать контент интереснее и полезнее🤝

За это время мы сильно выросли:
👥Число подписчиков: 949;
🫡Количество постов: 185;
✅Запущено курсов: 3;
👨‍🎓Студентов на курсах: 78;
🏁Закончили обучение и получили сертификаты: 23;
👤Провели персональных консультаций: 34;
⚙️Провели практических интенсивов: 11.

🎁А также, в честь этого события, хочу сделать небольшой подарок в виде промокода HALFYEAR, который дает скидку 20% на все продукты школы.

У промокода 5 активаций😉

UPD: осталось 3 активации.

Системный анализ | Дмитрий Помаскин

⚙️ Подробный разбор этапов: Elasticsearch sink connector.

ℹ️Поток — это наименьшая единица выполнения задач внутри пода, которая может работать параллельно с другими такими же единицами, разделяя общие ресурсы.

Входящие параметры:
11500 (~12000) сообщений в секунду в топик.
Размер сообщения ~2КБ.
Один поток коннектора способен обрабатывать примерно 1000 сообщений в секунду.

Расчеты:
12000 / 1000 = 12 потоков.
Для отказоустойчивости запустим 3 пода коннектора.
12 / 3 = 4 потока на 1 под.
1 поток потребляет ~0.2CPU, с запасом 0.3CPU.
0.3*4=1.2CPU (округлим до 2CPU) на один под коннектора.
4GB RAM с большим запасом на один под коннектора.

Итог:
✅ Количество подов коннектора: 3;
✅ Количество потоков на один под: 4;
✅ 6 CPU;
✅ 12GB RAM.

Ссылка на кейс 👈
Ссылка на общее решение 👈

Системный анализ | Дмитрий Помаскин

⚙️ Подробный разбор этапов: Elasticsearch.

Входящие параметры:
11500 (~12000) сообщений в секунду в топик.
Размер сообщения ~2КБ.

Расчеты:

✅Data-ноды — ноды для хранения данных и чтения из них:
2КБ * 12000 * 3600 * 24 = 2ТБ/сутки.
2ТБ * 30 = 60ТБ за 30 дней.

Нужна репликация для отказоустойчивости и масштабируемости чтения.
Добавим фактор репликации = 2.
60ТБ * 2 = 120ТБ с учетом реплики.

Примерно 15% займут индексы:
120ТБ + 15% = 138ТБ (~140ТБ).

Добавляем шардирование:
Будем хранить по 2ТБ на 1 шарде, 140 / 2 = 70 шардов.

Рассчитаем количество data-нод кластера. На одну ноду поместим 10 шардов:
70 / 10 = 7 нод.

Рассчитаем RAM: на каджые 2ТБ данных добавляем 1ГБ RAM.
140ТБ / 7нод * 2 GB = 40GB RAM на ноду, с запасом сделаем 64GB.

Рассчитаем CPU: на каждый шард по 1.2 CPU.
70 / 7 * 1.2 = 12 CPU на ноду, запас 16 CPU.

✅Master-ноды — ноды для управления данными в кластере:
Стандартный кластер — 3 ноды по 4CPU / 16RAM / 100GB SSD
Эти ноды не хранят данные приложения, а хранят только метаданные кластера и журналы операций.

✅Coordinating-ноды — принимают запросы от клиентов и управляют их выполнением на data-нодах:
Стандартный кластер — 3 ноды по 16CPU / 32RAM / 100GB SSD
Эти ноды также не хранят данные приложения — вся работа происходит в оперативной памяти и передается по сети.


Ссылка на кейс 👈
Ссылка на общее решение 👈

Системный анализ | Дмитрий Помаскин

🆕 Новая тема интенсива: Event-Driven Architecture 🆕

Уровень: Middle+.
Требуемые навыки: Понимание принципов работы распределённых систем, Apache Kafka.
Кол-во участников: до 4.
Длительность: ~4 часа.
Программа:
✅ Немного общей теории по распределенным системам;
✅ Что такое "событие";
✅ Что такое EDA;
✅ Сильные и слабые стороны EDA;
✅ Модели данных для EDA;
✅ Мониторинг в EDA.

Практика:
✅ Проектируем EDA систему с нуля;
✅ Готовим схему расположения сервисов;
✅ Расширяем функционал системы с использованием имеющихся событий;
✅ Внедряем в систему мониторинг.

P.S. Запись будет открыта сегодня (29.09) в 18:00 по МСК вместе с общим расписанием октября.

Системный анализ | Дмитрий Помаскин

‼️Запись на интенсивы октября открыта‼️

❗️График октября немного нестандартный, ввиду загрузки на проекте, пока не смогу проводить занятия по понедельникам. Поэтому смещаемся на субботу 16:00 🫡

Брокеры сообщений:
🔸Суббота 04.10 16:00
👤Количество мест: 5
ℹ️ Описание интенсива
👉 Запись

Функциональные требования:
🔸Воскресенье 05.10 12:00
👤Количество мест: 5
ℹ️ Описание интенсива
👉 Запись

🆕Event-Driven Architecture:
🔸Суббота 25.10 16:00
🔸Воскресенье 26.10 12:00
👤Количество мест: 4
ℹ️ Описание интенсива
👉 Запись

⚙️ Подробный разбор этапов: Расчет партиций для топиков.

Входящие параметры:
2 топика: raw-events и enriched-events.
2 консьюмера: сервис стримингого обогащения и Elasticserch sink connector.

Расчеты:
Cервис стримингого обогащения имеет 6 подов по умолчанию и HPA 6-12.

ℹ️Вспоминаем правило:
Один под может читать несколько партиций, но несколько подов не могут читать одну партицию.

Для успешного распределения нагрузки при срабатывании HPA, нам необходимо сделать минимум 12 партиций.
Пока подов 6, каждый из них будет читать по 2 партиции, но после срабатывания HPA произойдёт ребалансировка, и каждый под будет читать по 1 партиции.

Elasticserch sink connector всегда работает в 3-х подах. Поэтому для второго топика достаточно 3 партиций для балансировки нагрузки.

Итог:
✅ raw-events — 12 партиций;
✅ enriched-events — 3 партиции.

Ссылка на кейс 👈
Ссылка на общее решение 👈

Системный анализ | Дмитрий Помаскин

❗️Итоговый пост по кейсу с полнотекстовым поиском❗️

Как видите, кейс оказался не таким сложным, как выглядел на первый взгляд:)

⚙️Описание самого кейса
✅Верхнеуровневое решение
Этапы:
1️⃣Сервис стримингого обогащения
2️⃣Мощности для Apache Kafka
3️⃣Elasticsearch sink connector
4️⃣Расчет партиций для топиков
5️⃣Кластер Elasticsearch

Системный анализ | Дмитрий Помаскин

❗️Предложение по занятию в эту субботу:

В группе на 04.10 16:00 "Брокеры сообщений" пока нет записей (хотя за них проголосовали 42 человека 🙃), скорее всего это связано с нестандартным графиком.

Было много запросов по другим темам, поэтому предлагаю сделать замену, если соберутся желающие поучиться :)

Ниже прикреплю опрос, голосуйте за интересующую тему только, если сможете посетить занятие :) 👇

🏁По итогам голосования оставляем на завтра "Брокеры сообщений" :)

Запись снова доступна 👈

❓ Немного о CQRS простыми словами

CQRS (Command Query Responsibility Segregation) — это архитектурный паттерн, который предполагает разделение ответственности для операций чтения и записи данных.

Command (Команда) — изменить данные (создание, обновление, удаление);
Query (Запрос) — получить данные (чтение);

🔽Command-сторона — это ваш основной сервис, который обрабатывает действия, меняющие состояние.

🔼Query-сторона — это специально построенная система отчетов или кэш, которая моментально отдает данные, но сама их не меняет. Модель данных для чтения оптимизирована для быстрых и сложных запросов — она может быть денормализованной, чтобы минимизировать количество JOIN.

P.S. Примером применения подхода является наш кейс про полнотекстовый поиск.

Системный анализ | Дмитрий Помаскин

❗️Остаток мест на интенсивах❗️

Первая половина занятий октября прошла 👍

Осталось 2 занятия по новой теме Event-Driven Architecture:

🟡 Суббота 25.10 16:00 — осталось 1 место;
🟢 Воскресенье 26.10 12:00 — осталось 4 места.

ℹ️ Описание программы
👉 Запись

Системный анализ | Дмитрий Помаскин

❓ Разделение чтения и записи: Event Sourcing

Наиболее мощный и сложный способ разделения чтения и записи.

Основная идея:
Состояние системы не хранится, а восстанавливается из последовательности событий (Event Sourcing). Команды генерируют события, которые затем обрабатываются "проекциями" для обновления хранилищ чтения.

Как работает:
1️⃣ Command Side: При получении команды создается событие и сохраняется в журнале событий (Event Store).

2️⃣ Event Store (Журнал событий): Это единственный источник истины. Хранит неизменяемую последовательность событий.

3️⃣ Projections (Проекции): Это фоновые процессы, которые слушают события из Event Store. Их задача — обновлять хранилища для чтения на основе этих событий.

4️⃣ Query Side: Запросы выполняются из оптимизированных хранилищ, которые были заполнены проекциями.

P.S. Кто пропустил пост про CQRS, он тут.

Системный анализ | Дмитрий Помаскин

❓ Разделение чтения и записи: на уровне одной базы данных

Это самый простой и распространенный способ начать использовать CQRS. Он не требует сложной инфраструктуры.

Основная идея:
Используется одна и та же база данных, но для операций Чтения (Query) и Записи (Command) создаются отдельные модели.

Как работает:
1️⃣ Команды (Commands): используют одну схему объектов (ORM-модели, сущности) для изменения данных.

2️⃣ Запросы (Queries): используют другие, упрощенные модели (например, View Models), которые могут быть оптимизированы для конкретных запросов. Запросы могут обращаться к тем же таблицам, но избегают сложных связей, используя, например, SELECT только нужных полей.

➕Согласованность: Данные для чтения всегда актуальны.
➖Производительность: Нагрузка на чтение и запись ложится на один сервер БД.

P.S. Кто пропустил пост про CQRS, он тут.

Системный анализ | Дмитрий Помаскин

❓ Разделение чтения и записи: использование репликации.

Это модифицированный вариант предыдущего способа — переходим на кластер.

Основная идея:
Настраивается репликация с основной базы данных (мастера) на одну или несколько подчиненных реплик. Команды пишутся в мастер, а запросы читаются из реплик.

Как работает:
1️⃣ Поднимается кластер БД с иерархией master-slave.

2️⃣ Операции на запись приходят в master.

3️⃣ Данные реплицируются в slave.

4️⃣ Операции на чтение приходят в реплику(slave).

➕Масштабируемость чтения: Нагрузка на чтение распределяется по репликам.
➕Производительность: Уменьшается нагрузка на основную базу данных.
➖Возможная несогласованность: Данные на репликах могут немного отставать от мастера (задержка репликации).

P.S. Кто пропустил пост про CQRS, он тут.

Системный анализ | Дмитрий Помаскин