Технические особенности платформы

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

База данных и организация хранения

Платформа по своей сути является stateless приложением, все данные хранятся в БД репозитория платформы. Для этого используется СУБД PostgreSQL. Платформа к БД репозитория подключается с помощью технической учетной записи, указанной в конфигурации серверной части приложения.

Прямое соединение с базой данных репозитория должно быть доступно со стороны серверной части приложения (сервера). В репозитории располагаются все данные обо всех объектах системы, их структура и т.д. Размер этой БД напрямую зависит от объема данных, которые рассчитываются на графах.

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

Соединение с внешними источниками данных

Чтобы соединиться с внешними источниками данных, используя коннекторы, они должны быть доступны с сервера платформы. Клиентское приложение к источникам данных доступа не имеет.

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

Использование Redis

Во время работы платформы Redis решает две основные задачи: кэширование и разделяемая память.

Кэширование

Для обеспечения кэширования результатов расчета, прав доступа и других внутренних структур платформы во время работы в Redis создается отдельная БД (коллекция). При этом Redis не хранит свои состояния на диске, то есть работает только в режиме нахождения в оперативной памяти.

Если север Redis будет выключен, то все данные из него будут удалены. При этом система будет недоступна для работы. По умолчанию сервер Redis запускается рядом с системой в виде отдельного контейнера docker.

При обработке большого количества данных, особенно для картографических визуализаторов, необходимо подбирать объемы памяти в соответствии с объемами

Разделяемая память

На серверной части платформы используется Python. Его особенность состоит в том, что он является однопоточным. Серверы приложения wsgi и Gunicorn, которые используются для обслуживания большого количества запросов, используют воркеры (workers). Они запускаются в виде отдельных процессов на сервере. Каждый воркер внутри Gunicorn представляет собой отдельную копию приложения, запущенную в виде отдельного процесса. При этом процессы не имеют общей памяти, каждый из них изолирован от другого и не знает о том, что рядом запущены еще воркеры.

Gunicorn-сервер принимает запросы от клиентов и распределяет их по воркерам по принципу roundrobin, то есть заранее нельзя сказать, какой воркер будет обрабатывать следующий запрос. При этом внутри приложения все равно необходима организация хранилища для взаимодействия между воркерами. Для этих целей используется Redis - воркеры обмениваются информацией друг с другом с помощью хранения состояний в Redis.

Ограничения по потребляемой памяти

Для работы самой платформы (не Redis) также требуется достаточно большое количество оперативной памяти. Существует прямая зависимость между объемами оперативной памяти и объемами обрабатываемых данных. Все расчеты происходят в памяти сервера, поэтому в случае, если требуется обработка больших объемов данных единовременно, и нет возможности разбить их на части, необходимо подбирать объем оперативной памяти сервера в соответствии с планируемыми объемами данных.

Количество нод расчетчиков (workers) и workers сервера Gunicorn

У платформы есть режим работы с собственными вокерами (workers), которые могут осуществлять расчеты, находясь на удаленных серверах, а не на основном. При этом воркер - это полноценный сервер платформы, запущенный в другом режиме. Для его работы так же нужно соединение с БД репозитория.

Воркеры платформы используют очередь сообщения RabbitMQ для общения с координатором (основным приложением).

Количество воркеров платформы

Количество воркеров для расчетов можно рассчитать исходя из предполагаемой нагрузки именно по расчетам. Один воркер может обслуживать расчеты от 10 до 50 пользователей. Количество напрямую зависит от того, насколько трудоемкие расчеты предполагаются к выполнению.

Gunicorn workers

Внутри воркеров платформы и координатора запущен Gunicorn-сервер со своими воркерами, которые обслуживают запросы пользователей.

Для режима только координатора используется 6 воркеров Gunicorn.

Для режима координатора с воркерами, в координаторе используется 3 воркера Gunicorn. Внутри каждого воркера платформы используется по 1 воркеру Gunicorn.

Особенности расчетов с высокой нагрузкой на CPU

Если расчет графа представляет собой ресурсоемкое математическое вычисление, особенно с использованием внешних библиотек типа statmodels - это может привести к тому, что воркер Gunicorn, на котором происходит выполнение, перестает отвечать и обрабатывать запросы (так как python является однопоточным по своей природе). Это приводит к тому, что если таких расчетов запустить несколько, бэкенд сервера перестанет отвечать. В этом случае может потребоваться перезагрузка или ожидание окончания расчета. При возникновении подобных ситуаций желательно рассмотреть вариант работы с воркерами платформы.