❓Когда горизонтальная масштабируемость не поможет?

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

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

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

❗️Обновленная информация по интенсивам❗️

Выкладываю количество мест на данный момент:

✅ REST API 15.09 — осталось 4 места.
☑️ Брокеры сообщений 21.09 — мест нет;
✅ Функциональные требования 22.09 — осталось 3 места.

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

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

❓Возможная проблема при использовании горизонтальной масштабируемости

✅ Один под:
Сервис работает в одном экземпляре — задачи исполняются ровно в той последовательности, в которой поступают. Все строго и предсказуемо.

❌ Несколько подов:
Сервис масштабирован — порядок исполнения задач между разными подами не гарантируется.

Почему это проблема?

Представьте:
🔸Запрос А: «Списать 100 рублей»
🔸Запрос Б: «Заблокировать карту»

Если Б выполнится раньше А из-за параллельной обработки в разных подах — получим ошибку при исполнении запроса А.

P.S. Игнорирование этого вопроса — прямой путь к рассинхрону данных и багам, которые очень сложно отловить.

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

❗️Итог по горизонтальной масштабируемости

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

🔸Что такое горизонтальная масштабируемость;
🔸Влияние на отказоустойчивость;
🔸Влияние на установку релизов;
🔸Экономия ресурсов;
🔸Горизонтальная vs Вертикальная масштабируемость;
🔸Неконсистентность данных.

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

💬 Интерактивный кейс: полнотекстовый поиск на больших объемах

Кейс:
Имеем базу данных, в которую записывается ~1 млрд сообщений в сутки. Средний размер одного сообщения 2кб. Срок хранения 30 дней.

Задача:
Внедрить полнотекстовый поиск по сообщениям.

Важно:
Время работы поиска не должно превышать 1 секунду.

💬 В комментариях предлагайте свои варианты решения проблемы.

❗️В следующих видео расскажу вариант решения и отдельно разберу все его этапы.

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

❗️3 последних места на интенсивах сентября❗️

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

Учимся писать ФТ без воды, структурировано и понятно, чтобы у разработчиков не осталось вопросов :)

Подробнее:
Тема: Функциональные требования.
Уровень: junior.
Требуемые навыки: Работа с ER-диаграммой, понимание принципов работы REST API.
Время проведения: ~4 часа.
Кол-во участников: до 4.
Программа:
✅ Виды требований;
✅ Какие бывают ограничения и как они влияют на ФТ;
✅ Что включать в ФТ;
✅ Правильная структура ФТ;
✅ Где описывать ФТ.

Практика:
Подготовка ФТ под различные кейсы:
✅ FRONT;
✅ BACK;
✅ Интеграции(синхронные и асинхронные);
✅ Базы данных.

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

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

💬 Решение: полнотекстовый поиск на больших объемах.

1️⃣ Выбрать технологию подходящую под задачу и её масштабы. Тут подойдёт Elasticsearch.
2️⃣ Разделить чтение и запись. Записывать данные будем в основную БД, а поиск осуществлять из Elasticsearch.
3️⃣ Настроить репликацию данных от основного сервиса в Elasticsearch.
4️⃣ Внедрить сервис для потокового обогащения событий, чтобы приводить их в удобный для поиска формат.
5️⃣ Для наполнения хранилища Elasticsearch использовать коробочное решение Kafka Connect Elasticsearch Sink, которое будет читать топик с обогащенными сообщениями и через Bulk API отправлять данные в Elasticsearch.

ℹ️ Bulk API — это высокопроизводительный интерфейс для массовой асинхронной обработки больших объёмов данных.

👇 Ниже приложу схему для наглядности👇

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

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

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

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

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

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

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

Описание программ:
🔸Проектирование 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

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