Планирование ресурсов и сайзинг

При планировании ресурсов для ваших задач следует учитывать, что масштабированию подлежат компоненты Engine и Actions и Assistants.

Обзор

Единицы измерения производительности компонент – событий в секунду (events per second, EPS).

Engine

Для целей сайзинга принимается, что производительность компоненты Engine равна 200EPS. Один экземпляр Engine запускается в контейнере на 1 ядре с 8 GB RAM.
Производительность может быть ниже, если используются большие сущности контекста событий.

При необходимости многоядерного запуска в несколько контейнеров Engine можно множить для достижения максимальной производительности. Подробнее см. Кластеризация.

Actions

Один экземпляр Actions так же как и Engine запускается в контейнере на 1 ядре с 8 GB RAM.

Производительность компоненты Actions зависит от выполняемых действий: от самых быстрых как проверка аудитории или разделение на A/B группы, до самых медленных как HTTP-запросы. В среднем, на один экземпляр Engine это 100 eps.

При необходимости многоядерного запуска Actions также можно множить для достижения максимальной производительности. Подробнее см. Кластеризация.

Adapters

Производительность компонент adapters зависит от системы-источника событий.

Например HTTP-адаптер может отдавать до 500EPS, тогда как неоптимизированный запрос в SQL-адаптер не превысит 100.

Адаптеры также могут быть запущены в нескольких экземплярах, однако нужно учитывать специфики системы-источника.
Например File-адаптер не рекомендуется запускать в несколько экземплярах на 1 файл, в SQL-адаптер можно разделить запросы на порции, а HTTP-адаптеры могут быть запущены в неограниченном количестве экземпляров.

Планирование

Объем памяти для Redis

Сценарии

Пример: у вас одновременно работает 10 сценариев, в каждом из которых находится одновременно по 1 000 000 клиентов. Каждый клиент имеет 50 полей контекста.
Для такого объема в Redis необходимо 11 983 Mb RAM. При уменьшении/увеличении объема размер уменьшается/увеличивается соответственно.

💡

Для успешной работы и сохранения в Redis всегда должно быть свободно > 50% памяти, если используется RDB-снапшотинг. Следовательно, объем памяти увеличивается до 17966 Mb.

Аудитории

Для кэширования данных аудиторий из БД также требуется объем памяти в Redis. Например, при расчете аудитории у вас получается исходная таблица, в которой 50 колонок и 1 000 000 записей. При кэшировании такой аудитории в Redis будет занято 890 Мб RAM. При уменьшении/увеличении объема размер уменьшается/увеличивается соответственно.

Для комфортной работы с расчетом на рост нагрузки рекомендуется закладывать не менее 16 Gb RAM.

Вычислительные мощности

Расчет зависит от вашего суммарного EPS в секунду. Каждый модуль Engine, Actions или Assistant занимает 1 ядро. Для каждого модуля рекомендуется планировать 2 Gb RAM.

💡

Перед экспериментами с запуском нескольких инстансов сервиса ознакомьтесь с кластеризацией.

Например, если ваш исходный суммарный стабильный EPS равен 1000 из двух разных источников: ActiveMQ, HTTP по 500 EPS на каждый.

Во-первых, запланируйте входную мощность ассистентов. Запустите по 2-3 инстанса ActiveMQ Assistant и HTTP Assistant. Такая расстановка позволит не задерживаться сообщениям в очереди и не вызывать 50x ошибки у системы-источника.

Во-вторых, запустите 5 инстансов Flows Engine. Такая расстановка позволит вам потреблять 1000 EPS без задержек.

В-третьих, запустите 3-4 инстанса Flows Actions для предотвращения задержек внутренних действий и обращений к внешним системам.

В приведенном примере нагрузка рассчитана на стабильную нагрузку в 1000 EPS с пиковыми скачками до 1200 EPS. При росте нагрузки следует запускать дополнительные инстансы. Также вы можете запустить всю систему Accelera Flows на вашей динамической инфраструктуре, если она поддерживает Docker.