Серверы работают под управлением операционной системы Linux. Поддерживаются российские операционные системы, которые есть в реестре российского ПО. Развертывается через докер-контейнер. Широкий спектр поддерживаемых СУБД, между которыми распределяются данные в зависимости от специфики работы. Все real-time данные, которые обеспечивают работу системы, хранятся в очень производительной СУБД Mnesia, которая распределяется между серверами кластера, если их несколько, и обеспечивает очень большое количество операций в секунду. Все настройки, архивы и прочие жизненно важные данные, как правило, хранятся в Postgres. При этом архивы хранятся в таблицах с партициями. При удалении старых разговоров или какой-то еще устаревшей информации, достаточно удалить partition. Это происходит мгновенно. Файлы сразу с диска удаляются и не приводят к фрагментации и последующему торможению базы данных.

В случае, если Postgres не хватает, либо требуется интеграция с внешними BI-системами, мы поддерживается работа с KAFKA и Clickhouse. Это позволяет обеспечить и дополнительный уровень отказоустойчивости, и очень высокую производительность при построении отчетов.

Снаружи абсолютно вся функциональность, которую мы видим из приложений, и даже чуть больше, доступна через REST API, как по HTTPS, так и через WebSocket, в том числе, через их безопасные версии HTTPS и VSS.

Архитектура микросервисная и с точки зрения сервисов можно разделить систему на два слоя. Первый слой, нижний, это слой платформы, где обеспечена вся работа с данными, коммуникациями, телефонией. Там порядка 50 микросервисов. разработанных на языке Erlang и работающих под управлением OTP. И сверху есть продуктовые сервисы. К ним относятся все, что связано с call-центром, все пользовательские приложения и все, что мы можем разработать на Билдере. Там используется язык TypeScript, и эти микросервисы работают под управлением платформы Node.js. Как план минимум, все эти микросервисы, порядка сотни штук, могут находиться на одном сервере.
При этом этот сервер будет подключаться и к провайдерам, к нему будут подключаться абоненты, он будет интегрироваться с внешними системами и с ним же будут работать пользователи. Понятно, что здесь будет минимум по отказу устойчивости, но этот сервер в состоянии обслужить достаточно высокую нагрузку. В случае, если нам одного сервера не хватает, а это может произойти по двум причинам, либо не хватает вычислительных ресурсов, либо нам нужна дополнительная отказоустойчивость. то мы можем развернуть кластер из двух серверов. В этом случае внешние системы и пользователи могут работать как с одним, так и с другим в зависимости от конфигурации. И при попадании одного из серверов происходит автоматическое переключение на другой. Если нужно гарантированно сохранять текущие разговоры, то нужно четыре и более сервера, потому что необходимо разделить медиа и сигнализацию телефонии.

С точки зрения потребления ресурсов процессора, основных показателей мы выделяем три основных показателя. Это количество звонков в секунду ЦПС, количество сессий IVR, которые разговаривают с нашими абонентами в автоматическом режиме и количество живых разговоров, где мы выполняем коммутацию и, как правило, ведем запись. С точки зрения оперативной памяти, больше всего ее потребляют большие кол-листы. Если у нас в кол-листах миллионы контрагентов, то, как правило, мы их либо сразу загружаем при старте компании, либо плавно и постепенно. С точки зрения места на диске, понятно, что здесь основное место занимают записанные разговоры, ну и плюс растущие со временем базы данных.

В рамках одного из проектов было успешно проведено нагрузочное тестирование. Онлайн были подключены 600 операторов, непрерывно работала исходящая компания с ЦПС 80 звонков в секунду и шли входящие по 6 штук в секунду. Таким образом, одновременно было активных более 2000 разговоров. За 72 часа теста мы совершили более 20 миллионов звонков. Всю эту нагрузку обслуживали 4 из 16 ядерных сервера, на которых ядра были загружены примерно на треть.