В эпоху цифровой трансформации надежная и производительная коммуникационная инфраструктура становится критически важной для государства и бизнеса. Российская информационно‑коммуникационная платформа «Эра», разработанная для обеспечения безопасного и эффективного взаимодействия, подтвердила свой высочайший класс надежности, успешно пройдя масштабное 72-часовое нагрузочное тестирование. Результаты демонстрируют не только соответствие заявленным характеристикам, но и наличие существенного запаса мощности для будущего масштабирования.
О Платформе
Платформа «Эра» — это отечественное программное решение, информационно‑коммуникационная платформа для автоматизации контактных центров, созданная профессионалами с 25-летним опытом в сфере коммуникационного программного обеспечения.
В основе платформы лежит микросервисная архитектура, которая обеспечивает отказоустойчивость и масштабируемость системы. Платформа Эра обеспечивает поэтапную миграцию с оборудования Avaya, Genesys, Cisco и других западных систем на отечественное решение Включена в реестр российского ПО, № 13 770 Соответствует постановлению Правительства РФ от 22.08.2022 N 1478.
В 2021 году программа была впервые опубликована и предложена рынку для использования на объектах критической инфраструктуры для создания коммуникационных и информационных систем.
Подробности тестирования и рекомендации
Платформа была развернута на 4х виртуальных серверах с относительно небольшим сайзингом, расположенных в Яндекс.Облаке. Дополнительно было использовано 2 сервера для эмуляции работы операторов и клиентов. Подробные характеристики стенда описаны в п.7.1.
Было совершено 18 565 353 исходящих вызовов за 72 часа.
Количество обработанных входящих вызовов — 1 555 083 шт.
Качество звука при вызовах нареканий не вызывало.
Утечек памяти на серверах со временем не выявлено.
Роста утилизации ресурсов со временем не выявлено.
Проблем со стабильностью работы системы за истекший период не выявлено.
Ни один микросервис за время теста не перезапускался.
Качество записей разговоров нареканий не вызывало. Входящие вызовы при распределении на операторов записывались. В случайный момент времени можно было обратиться к журналу звонков, обнаружить записанный разговор, прослушать запись. Выборочное прослушивание записей подтвердило высокий уровень качества разговоров и записей.
1% потерянных вызовов связан с нехваткой операторов на второй линии в момент, когда размер очереди первой линии еще не слишком велик, чтобы операторы второй линии быстро освобождались. Это проявлялось в основном в моменты старта кампаний.
Облачная инфраструктура способна заметно ухудшить отклики и качество доставки пакетов, но система справляется успешно за счет распределения и параллелизации критических процессов.
Заметная загруженность жестких дисков СУБД при одновременно низком расходе оперативной памяти:
требует подготовки серверов под СУБД к увеличению нагрузки;
-
может быть преодолена:
распределением данных по разным экземплярам СУБД на разных серверах;
в части архивных данных переходом на колоночную БД для хранения архивных записей;
в части таблиц контрагентов распараллеливанием и мультиплексированием операций при загрузке колл‑листов.
Сайзинг целевой системы
Микросервисная архитектура с горизонтальным масштабированием микросервисов в режиме active‑active и равномерная балансировка нагрузки между однотипными сервисами дает основания утверждать, что разделение ресурсоемких микросервисов позволяет эффективно распределить нагрузку между несколькими серверами. При этом существует несколько механизмов балансировки нагрузки, наиболее часто используемый — hashring.
В ходе текущего тестирования использовалось 6 активных медиашлюзов, которые равномерно обрабатывали по 16.7% звонков. Соответственно, при увеличении нагрузки достаточно лишь увеличить их количество.
Среди других высоконагруженных сервисов — веб‑сервер (ws), юзер‑агент (b2b), движок сценариев (ivr) и модуль обработки данных (dms). Первые три масштабируются в любых количествах по механизму hashring, а четвертый (dms) имеет три уровня масштабирования — сначала по доменам, затем по классам внутри домена, и наконец по идентификаторам экземпляров класса.
При реализации балансировщиков на всех уровнях используются быстрые кеши, поэтому выбор конкретного экземпляра микросервиса занимает от 7 до 12 микросекунд, что ничтожно мало даже при тысячах операций в секунду, особенно с учетом многопоточности.
Текущее нагрузочное тестирование подтвердило, что архитектура и потенциальная производительность системы позволяют масштабировать нагрузку от 100 до 10.000+ операторов. Все перечисленные факторы позволяют ожидать линейного увеличения производительности системы при выделении дополнительных вычислительных мощностей.
На основании внутренних тестов и проведенного нагрузочного тестирования был расчитан целевой сайзинг для 5600 одновременно работающих операторов (6600 одновременно работающих пользователей системы), 4100 портов одновременно работающих автоинформаторов, плюс 15 000 портов с 800 наборами в секунду (CPS) для исходящих активностей:
Примечание:
В расчете не учтена отказоустойчивость в рамках распределения по различным ЦОД. Если необходима географически распределенная система, которая поддерживает работоспособность при полном отказе любого из ЦОД, то количество ресурсов необходимо увеличить кратно количеству ЦОД. При этом архитектура платформы Эра и подход к резервированию не требуют наличия второго плеча в режиме stand‑by, а позволяют при необходимости задействовать часть его ресурсов в режиме active‑active.
Примечание:
Подразумевается использование внешней СУБД и внешнего долговременного хранилища записей разговоров и экранов операторов.
Методика проверки
С систем эмуляторов подается нагрузка с непрерывной плотностью 6 входящих вызовов в секунду, обрабатываемая целевым стендом по алгоритмам обработки входящих вызовов с учетом вероятностных характеристик, приведенных в методике верификации для этого типа вызовов;
На целевой системе запущена исходящая кампания с плотностью 80 вызовов в секунду. Метрики приложения оператора проверяются по результатам работы эмулятора оператора.
Эмулятор PSTN
Обслуживание исходящих вызовов производится в системе‑эмуляторе PSTN с помощью сценариев IVR с заданным в методике верификации распределением. 92% — отбой, 8% — на обслуживание.
Принятые к обслуживанию вызовы распределяются в соответствии с установленными в методике верификации вероятностями.
Всего на эмуляторе PSTN заведено 8 различных сценариев, отрабатывающих сценарии методики верификации:
Эмулятор операторов
Поступающие на операторов вызовы обслуживаются системой‑эмулятором операторов с помощью сценариев IVR по заданным в методике верификации показателям распределения.
Всего в системе‑эмуляторе агентов заведено около 20 сценариев, отражающих различные сценарии из методики верификации:
В каждом из этих сценариев производится замер и сохранение метрики. Например, в приведенном ниже сценарии производится замер времени обработки ответа на входящий вызов.
С учетом большой плотности вызовов сохранение в журнал показателей по метрикам производится выборочно с вероятностью от 1 до 100% в зависимости от частоты той или иной операции.
Данные по метрикам укладываются в БД и доступны на целевой системе в приложении Наблюдатель. В итоговой статистике отображаются общее число операций после вероятностного фильтра, максимальное и среднее значения.
Целевая система
Входящие вызовы распределяются в принимающим сценарием IVR целевой системы по различным очередям в соотношениях, установленных методикой верификации.
Сбор и анализ данных
Мониторинг и сбор данных осуществлялся в течение всего прохождения теста. После проведения теста проведена обработка и анализ результатов — выявление сбоев, блокировок, задержек, загруженность ресурсов.
Требования по утилизации аппаратных ресурсов
Отчетность контакт-центра
Для подтверждения корректности результатов теста используются стандартные отчеты по работе операторов контакт‑центра и обработке звонков, данные которых должны быть сопоставимы со статистикой эмулятора клиента и эмулятора оператора, например, количество звонков, которые сгенерил эмулятор клиента, должно совпадать с количеством принятых входящих звонков в контакт‑центре.
Обзор стенда
Стенд развернут в Яндекс.Облаке на следующих ресурсах:
Целевая система
Единая четырехсерверная целевая система со следующим распределением ключевых ролей между серверами:
EraSrv1:
web‑сервер и бизнес‑логика колл‑центра,
mg/rtx — медиашлюзы;
EraSrv2:
dms — подсистема обработки данных и онлайн‑уведомлений,
mnesia — оперативная СУБД,
mg/rtx — медиашлюзы;
EraSrv3:
b2b — back‑to‑back SIP user agent,
mware — передача событий со слоя телефонии в бизнес‑логику,
callstore — хранилище информации о текущих звонках
mg/rtx — медиашлюзы,
mix — микшер записанных разговоров из RTP в MP3;
EraSrv4:
esg — стыковка по SIP с провайдерами,
sg — стыковка по SIP с агентами,
ivr — исполнение сценариев,
mix — микшер записанных разговоров из RTP в MP3.
Эмуляторы
EraClient1 — эмулятор PSTN для приема трафика исходящей кампании.
EraClient2 — эмулятор PSTN для генерации трафика входящих звонков и операторских телефонов. На этой же машине запускается периодическое выполнение API‑запроса для совершения входящего звонка, а также работают эмуляторы агентских рабочих мест для выставления через API результатов исходящих вызовов.
Функции СУБД распределены по этим же серверам для снижения общей нагрузки. Развернуто несколько экземпляров базы данных.
Приложение мониторинга
Для управления, мониторинга и верификации создано специальное веб‑приложение «Наблюдатель», включающее в себя одновременно и отчетность супервизора, и мониторинг метрик, и мониторинг утилизации аппаратных ресурсов.
Подключение тестовых телефонов
Выделено 10 учетных записей для подключения телефонных устройств по протоколу SIP. Пример настроек, выполненных для приложения(softphone) MicroSIP, для подключения к платформе представителей Заказчика представлен на скриншоте:
— domain: yyy.era‑platform.ru,
— outbound proxy: xxx.era‑platform.ru,
— port: 9160,
— login, username, number, password: 1050001-1050005.
С тестовых телефонов 105ХХХХ можно звонить:
— 901ХХХХХХХ — выход в город с запуском рандомного сценария входящих клиентов,
— 902ХХХХХХХ — выход в город с запуском рандомного сценария исходящих клиентов с контактностью 5-10%,
— 9 029 999 999 — выход в город с запуском рандомного сценария исходящих клиентов с контактностью 100%,
— 903XXXXXXX — выход в город на тестовые линии (при наличии активных регистраций),
— 1ХХХХХХ — прямой вызов любого оператора,
— 700 — главный входящий с донабором,
— 701 — очередь входящие,
— 702 — очередь входящие с блендингом,
— 703 — очередь исходящие,
— 704 — очередь вторая линия,
— 705 — очередь тестовые операторы,
— 799 — вечная музыка (отбой через два часа).
Проведение нагрузочного теста
26.02.2024 в 10:00 в ходе совместной ВКС стенд был проверен, совершен вызов с тестового аппарата. Произведенный вызов был обнаружен во всех мониторинговых отчетах и метриках, по нему была прослушана запись.
26.02.2024 в 10:08 был произведен запуск нагрузочного теста. Для этого был активирован процесс совершения вызовов на системе‑эмуляторе PSTN (входящие вызовы плотностью 6 в секунду), процесс исходящей кампании на целевой системе (исходящие вызовы плотностью 80 в секунду), подключение 620 операторов, некоторые из которых, в соответствии с заданными в методике показателями, осуществляют login и logoff для замера времени обработки.
В ходе проведения теста:
Было совершено 18 565 353 исходящих вызовов за 72 часа. Количество исходящих вызовов по уровню соответствует расчетному. (расчетное — примерно 18 750 000 шт = 72 часа 3600 секунд 80 вызовов в секунду * 30/33 (коэффициент времени остановки кампании каждые 30 минут) и поправка еще на 10 секунд). Несущественное расхождение расчетных и фактических значений вероятно вызвано неточностью работы таймера инициации исходящих наборов в исходящих кампаниях — большинство по 80 в секунду, но иногда 79.
Количество обработанных входящих вызовов — 1 555 083 шт. (расчетное количество входящих вызовов: 1 555 200 = 72 часа 3600 секунд 6 вызовов в секунду)
29.02.2024 в 10:06 тест остановлен
Метрики и анализ технических результатов
Утилизация ресурсов: приведенные ниже скриншоты сняты до остановки тестового стенда в случайный момент времени. На каждом скриншоте приведены соответствующие показатели по четырём серверам целевой системы.
Показатели снимаются отдельным микросервисом с помощью стандартных утилит операционной системы Linux (iostat, iotop, top, и т. д.) и укладываются в СУБД для возможности дальнейшего обращения.
Все показатели на скриншотах приведены за последние 4 часа и за последние сутки.
Утилизация CPU (процессоров): Это общая загрузка процессора всеми активными процессами, исполняемыми на сервере, включая PostgresSQL.
Наблюдаются характерные получасовые периоды интенсивной работы системы, связанные с активностью исходящей кампании плотностью 80 вызовов в секунду. Точечный всплеск на втором сервере связан с обращениями к отчетности в СУБД PostgreSQL.
На протяжении теста никаких отклонений от целевой картины не наблюдалось.
Утилизация оперативной памяти: Это аллокация оперативной памяти всеми процессами операционной системы, исполняемыми на сервере, включая PostgreSQL.
На протяжении всего времени теста не наблюдается никаких заметных отклонений от константы, требуемой для обслуживания предусмотренных методикой количества и плотности вызовов и количества операторов. Утечки памяти отсутствовали.
Утилизация жестких дисков: показатель снимается регулярно утилитой iostat. Это утилизация жестких дисков всеми процессами операционной системы, исполняемыми на сервере, включая PostgreSQL.
Наблюдаются характерные получасовые периоды интенсивной работы системы, связанные с активностью исходящей кампании плотностью 80 вызовов в секунду.
Высокая нагрузка на первых двух серверах связана с размещением на них СУБД PostgreSQL. Два диска на первом сервере и два диска на втором сервере — отданы под 4 экземпляра PostgreSQL, каждый из них обслуживает по одной нагруженной таблице: таблица контрагентов для исходящей кампании, архивы звонков, архивы сеансов, архивы очередей.
Объем обмена данными с жесткими дисками
Показатель снимается регулярно утилитой iostat. Это утилизация жестких дисков всеми процессами операционной системы, исполняемыми на сервере.
Наблюдаются характерные получасовые периоды интенсивной работы системы, связанные с активностью исходящей кампании плотностью 80 вызовов в секунду.
Несмотря на плотную работу PostgreSQL с диском, объем данных, которые он фактически размещает на диск — минимален.
Система ведет запись и последующее микширование — это создает объем обмена данными с диском.
Система ведет логирование.
Система использует распределенную объектную БД, которая также проявляется в графиках (брокеры событий, хранилища текущих вызовов, и т. д.
Количество операций к жестким дискам
Показатель снимается регулярно утилитой iostat.
Наблюдаются характерные получасовые периоды интенсивной работы системы, связанные с активностью исходящей кампании плотностью 80 вызовов в секунду.
Объем занятого места на диске
Заметный плавный рост наблюдается только на 4-м сервере, куда складируются записанные разговоры.
Сетевой трафик
Наблюдаются характерные получасовые периоды интенсивной работы системы, связанные с активностью исходящей кампании плотностью 80 вызовов в секунду.
В большей степени выделяются серверы 1, 2 и 3, где размещены медиашлюзы. Свой вклад в сетевое взаимодействие вносят и SIP‑сигнализация, и взаимодействие микросервисов.
AVG (показатель загруженности операционной системы Linux)
За последние 4 часа:
За последние сутки:
Наблюдаются характерные получасовые периоды интенсивной работы системы, связанные с активностью исходящей кампании плотностью 80 вызовов в секунду.
Утилизация CPU микросервисами коммуникационной платформы
Наблюдаются характерные получасовые периоды интенсивной работы системы, связанные с активностью исходящей кампании плотностью 80 вызовов в секунду.
Наиболее нагруженными микросервисами являются: на 1-м сервере — web‑сервер, на 2-м сервере — менеджер модели данных, на 3-м сервере — back‑to‑back user‑agent. Нагрузка по обслуживанию трафика распределена между 6-ю медиашлюзами на трех машинах. Микросервисы, занимающие менее 10% одного ядра CPU — в списке не отображаются, но могут быть включены в фильтре.
Утилизация оперативной памяти микросервисами коммуникационной платформы
Наблюдаются характерные получасовые периоды интенсивной работы системы, связанные с активностью исходящей кампании плотностью 80 вызовов в секунду.
Кроме того, первый сервер проявляет пилу (зеленый цвет) — это загрузка исходящей кампанией списка контрагентов из БД по мере необходимости. При остановке кампании память высвобождается. Никаких растущих трендов не наблюдается.
На трех серверах архивного графика за последние сутки видны распределенные во времени отсечки вниз — это плановый ежесуточный мягкий (gentle) вывод медиашлюзов из обслуживания.
Записи разговоров
В левом канале записан трафик от эмулятора PSTN — мелодия. В правом канале записан трафик от эмулятора агента — синтезированная речь (стихи).
На скриншоте приведен пример записанного mp3-файла, открытый в редакторе Audacity.
После завершения теста также был проведён выборочный анализ записанных разговоров. Прослушаны звонки с проверкой качества записи.
Остановка теста
Тест остановлен 29.02.2024 в 10:06.
Спустя 3 минуты после остановки 620 операторов освободились от вызовов и от поствызывной обработки.
Система высвободила все ресурсы, требуемые для обслуживания интенсивного потока вызовов, и перешла в idle-состояние.
Утилизация CPU:
Утилизация оперативной памяти:
Утилизация жестких дисков:
Объем данных, обмениваемых с жесткими дисками:
Количество операций с жестким диском:
Свободное место на жестких дисках:
Объем данных, передаваемых по сети:
Утилизация CPU наиболее нагруженными микросервисами коммуникационной платформы:
Утилизация CPU всеми микросервисами коммуникационной платформы:
Утилизация оперативной памяти наиболее емкими микросервисами платформы:
Утилизация оперативной памяти всеми микросервисами платформы:
Счетчики
Метрики
Для расчета метрик использовалась таблица в PostgreSQL, куда данные заносились сценариями, исполняемыми на целевой системе и системе‑эмуляторе агентов. Ввиду высокой нагрузки трафика в целях ослабления давления на БД, для расчета и сохранения принимались не все вызовы, а часть. Выборка производилась случайно исходя из соотношения вероятностей, чтобы общее количество операций за 72 часа тестирования было более 10 тысяч, но не слишком большим.
Процент потерь в голосовом трафике (качество передачи голоса) в среднем составил 0, максимальные потери составили 0.15%. Качество трафика остается высоким, несмотря на сложность сети в Яндекс.Облаке. Разнесение медиашлюзов по разным серверам позволило устранить проблему потерь в трафике, вызванную качеством сети и виртуального окружения.
Из всех показателей только время сбора конференции из трех абонентов вышло за пределы 1 секунды. Тем не менее в 10% случаях оставаясь в пределах установленного методикой верификации показателя в 2 секунды и 3 секунды.
Среди тяжелых операций — логин. В среднем занимает 450 мс, максимально был 1.5 секунды. Всего за пределы 1 секунды вышло 5 операций из 12 тысяч.
Прочие операции: инициация вызова, ответ на вызов, отбой, постановка на удержание, перевод и другие, собранные на основании методики верификации — выполнялись в среднем менее 200 мс.
Ни один микросервис за время теста не перезапускался:
Выводы
Тест пройден успешно. Ограничений для масштабирования не выявлено. У Платформы Эра имеется существенный запас производительности. Система готова к увеличению нагрузки на имеющихся серверах.
Вывод о наличии значительного запаса производительности сделан на основании анализа загруженности системных ресурсов. В частности — ядер центрального процессора (от 15 до 45%, в среднем — 35%) и оперативной памяти (в пределах 25%).
Эти показатели позволяют утверждать, что увеличение нагрузки в два раза с незначительным перераспределением микросервисов между серверами позволят остаться в рамках описанных Методикой показателей (70% CPU и 80%RAM).
Ключевые факторы, влияющие на загрузку системных ресурсов — это количество одновременных разговоров, количество сессий IVR и частота вызовов CPS. Микросервисная архитектура предполагает горизонтальное масштабирование. Препятствий для кратного увеличения нагрузки не выявлено.
Таким образом, можно говорить о потенциальной возможности увеличения CPS входящих вызовов с 6 до 12 вызовов в секунду, исходящих с 80 до 160 вызовов в секунду, операторов с 620 до 1240 без наращивания вычислительных мощностей текущего нагрузочного стенда.
Перспективы и значение для рынка
Результаты тестирования выводят Платформу Эра в лидеры российского рынка коммуникационных решений. На основании этих данных был рассчитан сайзинг для развертывания системы, способной обслуживать до 5600 операторов.
Платформа демонстрирует готовность к внедрению в крупнейших государственных корпорациях, банках и телеком‑операторах, где требования к надежности и производительности максимально высоки.
Это тестирование доказывает, что отечественные разработчики способны создавать сложные, высоконагруженные программные комплексы, которые не только не уступают, но и по многим параметрам превосходят зарубежные аналоги, обеспечивая технологический суверенитет и цифровую независимость России.