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

Если сервис работает в одном поде, то, в момент перезапуска для установки релиза, сервис перестает исполнять свои функции.

Если же сервис работает в нескольких подах, то обновление и перезапуск происходят поочерёдно. Это позволяет обеспечить непрерывную работу сервиса без потери функциональности.

Пример:
❌ В магазине работает одна касса. Требуется провести инкассацию. Кассу закрывают — все покупатели вынуждены ждать.
✅ В магазине работают три кассы. Инкассацию проводят поочерёдно. Покупатели продолжают оплачивать покупки у открытых касс.

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

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

Слоты начали активно занимать, выкладываю количество мест на данный момент:

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


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

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

❓Горизонтальная масштабируемость — экономия ресурсов.

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

Затем, после снижения нагрузки, вернуть количество подов к первоначальному.

При этом вы не увеличиваете число подов тех сервисов, которые успешно справляются с нагрузкой.

Таким образом, вы добавляете ресурсы только там, где они нужны.

Пример:
✅ В магазине работают три кассы, начинается час-пик. Вы открываете ещё три кассы, чтобы успевать обслуживать покупателей. Час-пик прошёл — вы закрывате лишние кассы.

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

‼️Сегодня 19:00 МСК ‼️
Остались места на интенсив "Брокеры сообщений"

Уровень: Middle.
Требуемые навыки: Понимание принципов работы распределённых систем.
Кол-во участников: до 4.
Длительность: ~4 часа.
Программа:
✅ Типы брокеров (модель обмена, гарантия доставки, умные/глупые брокеры);
✅ RabbitMQ;
✅ ApacheKafka;
✅ Transaсtional outbox;
✅ Обработка ошибок в асинхронных интеграциях.

Практика:
✅ Проектируем внедрение брокеров в распределенную систему;
✅ Поднимаем RabbitMQ и ApacheKafka локально в docker;
✅ Учимся работать с ними через веб-интерфейс;
✅ Описываем формат взаимодействия в asyncapi.

👉 Для записи переходите по ссылке.

P.S. Желательно записываться заранее, чтобы успеть поставить докер перед занятием.

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

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

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

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

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

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

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

✅ 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
Эти ноды также не хранят данные приложения — вся работа происходит в оперативной памяти и передается по сети.


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

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