Highload на Битрикс24: 10 особенностей, которые нужно знать

Highload на Битрикс24: 10 особенностей, которые нужно знать

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

1. Выбор платформы

Заказчик уже владел рабочим порталом на платформе Liferay, но остро встал вопрос об импортозамещении.

Новая платформа должна была обеспечить:

• Доступность для пользователей всех основных бизнес-кейсов старого портала.
• Значительное развитие и обогащение функционала портала.
• Стабильность работы при большом количестве активных пользователей.
• Высокую степень защищенности системы.
• Широкие возможности для кастомизации и доработке под задачи организации.
• Возможность получения полноценной технической поддержки и регулярных обновлений продукта.

Выбор остановился на платформе Битрикс24 (коробочная версия), которая имеет сертификат ФСТЭК, зарегистрирована в Реестре Российского ПО, имеет ряд кейсов с удержанием высокой нагрузки, богатый функционал и отвечает всем вышеуказанным требованиям.

2. Региональное деление внутри портала

Внедряя портал на десятки тысяч пользователей, мы неминуемо сталкиваемся с задачей разделения контента или функционала по филиалам (подразделениям) компании. При этом, следует учитывать, что известный механизм мультидепартаментности в Битрикс скорее всего не подойдёт в чистом виде и нужно будет писать своё решение с учётом требований заказчика и ограничений по высокой нагрузке.
При реализации проекта мы пошли по принципу мультирегиональности: портал имеет общую оргструктуру из всех пользователей с использованием подразделений. Функционал и наполнение портала для конкретного пользователя формируется путем использования фильтров и разграничения прав, в соответствии с подразделением. Это позволяет отойти от необходимости “клонировать” любые доработки на версии порталов разных регионов, что, в свою очередь, упрощает процесс развития портала.

• Для каждого сотрудника в зависимости от его структурного подразделения определяется его регион.
• Информация на портале отображается в зависимости от региона сотрудника.
• В регионально-зависимых разделах, по умолчанию устанавливается фильтр «Мой регион», но, при необходимости, сотрудник может посмотреть информацию другого региона.

3. Загрузка новых пользователей

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

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

4. Проверка исходных данных до загрузки

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

Постарались нивелировать ситуацию с помощью:

• Логирования ошибок для их отслеживания, анализа и исправления.
• Обработки некритичных ошибок, позволяющих завершить процесс импорта массива данных.
• Реализации мониторинга и информирования о критичных ошибках, блокирующих процесс импорта.

5. Взаимодействие с закрытой системой

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

Для организации удалённого доступа к закрытой сети в соответствии со стандартами безопасности заказчика пришлось использовать выделенный криптошлюз, имеющий сертификацию ФСТЭК.

6. Кластеризация серверов

Для успешной реализации необходимо мы развернули и настроили кластер серверов, позволяющий распределить нагрузку.

Но даже это решение не позволило избежать периодического “зависания” системы. При довольно типичных операциях, периодически загрузка серверов доходила до 100%.



В результате анализа логов проблема была достаточно быстро обнаружена: при единовременной обработке данных для огромного числа пользователей наблюдалось значительное отставание слейвов. А, при отставании более чем на 3 минуты, начинался бесконечный цикл запросов. Именно он приводил к 100% загрузке серверов приложений.




7. Массовые события

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

Оптимизация работы и отключение некоторых указанных функций позволило значительно снизить нагрузку и стабилизировать работу системы на любых процессах:



8. Нагрузочное тестирование

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

9. Административные и юридические тонкости

Работая с проектом такого масштаба имеешь дело с большим количеством контактных лиц, а согласование документов и этапов работы может проходить продолжительное время.

Очень важно обращать пристальное внимание на любую документацию и обязательно фиксировать в ней:

• Все требования и пожелания к разрабатываемой системе, собранные и согласованные со всеми ключевыми участниками проекта.
• Сроки реализации проекта и отдельных этапов (с учетом рисков на необходимое согласование и приёмку результатов).
• Алгоритм работы при отклонении от согласованного плана.
• Четкие критерии завершенности проекта и механизм сдачи проекта и его этапов.

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

10. Helpdesk

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

Вывод

Разработка Highload-проекта накладывает повышенные требования к проектированию и реализации.
Фундаментом успешной разработки является выбор платформы, соответствующей заявленным техническим требованиям и зарекомендовавшей себя в аналогичных проектах.
Также, особое значение имеет подбор компетентной команды разработчиков. Нам было не легко, но мы справились. Теперь в PWD есть опыт внедрения корпоративного портала на десятки тысяч пользователей.

Есть похожий проект? Приходите, сделаем!