О проекте

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

На тот момент в системе было зарегистрировано 10 000 пользователей.

Задача

Сервис выдерживает только 50 одновременных пользователей. Надо вывести его в рабочий режим и продолжить развивать.

Результат

Производительность выросла в 14 раз: серверы держат до 700 пользователей одновременно.

О проекте

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

На тот момент в системе было зарегистрировано 10 000 пользователей

Задача

Сервис выдерживает только 50 одновременных пользователей. Надо вывести его в рабочий режим и продолжить развивать.

Основной результат

Производительность выросла в 14 раз: серверы держат до 700 пользователей одновременно.

Виды выполненных работ

Реверсивный инжиниринг и создание технической документации

Разработка архитектуры программы и серверов

Перенос программного кода на новую программную архитектуру

Подбор серверов под предполагаемую нагрузку


Реверсивный инжиниринг и создание технической документации

Настройка мониторинга и уведомлений

Внесение изменений в аппаратную часть серверов

Разработка новых функциональных модулей

Ход проекта

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

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

Разработали план переноса кода со старой архитектуры на новую в соответствии с ТЗ, которое было к тому моменту готово. Осуществили переезд.

Запустили бета-тестирование системы на 1 сервере на 100 лояльных пользователях заказчика. Система успешно справилась с бета-тестированием.

Сделали замеры нагрузок во время тестирования. Рассчитали предполагаемую нагрузку при выводе на 10 000 человек и подобрали необходимый парк серверов по техническим характеристикам, который, с одной стороны, решал задачу технической нагрузки, с другой, был достаточно недорогим для заказчика. Развернули парк и запустили на всех пользователях.

Параллельно настроили систему Grafana для мониторинга состояния каждого сервера. Мониторинг снимал более 100 метрик по каждому серверу в реальном времени.

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

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

850+

Статистических анализов обслуживается

11500

Пользователей средняя загрузка серверов

88%

Средняя загрузка серверов

650+

Одновременных пользователей

900000+

Объем потока анализируемых данных из соцсетей (байт в секунду)

55+

Объем хранилища первого уровня доступа (Тб)

850+

Статистических анализов обслуживается

11500

Пользователей средняя загрузка серверов

88%

Средняя загрузка серверов

650+

Одновременных пользователей

900000+

Объем потока анализируемых данных из соцсетей (байт в секунду)

55+

Объем хранилища первого уровня доступа (Тб)

Система сегодня

В процессе эволюции система выросла до следующих модулей:

Клиенты заходят на страницу приложения в браузере. Браузер отправляет запросы на один из двух front-end серверов. Наличие второго front-end сервера повышает комфорт работы за счет лучшего времени отклика системы, увеличивает общую отказоустойчивость: в случае выхода из строя одного из серверов второй продолжает обслуживать запросы клиентов. За распределение запросов между серверами отвечает сервер DNS 1.

Front-end сервера перенаправляют запросы на сервера бизнес-логики БЛ. Их тоже два для повышения отказоустойчивости. Если запрос относится к данным, которые были раньше собраны, то сервер бизнес логики выполняет его, используя данные хранящиеся в Replica Set. Если же запрос касается сбора новых данных, то БЛ сервер отправляет его на аналитику в кластер парсинга. Т.к. кластер парсинга обычно сильно загружен (load average 88%), запросы серверов БЛ ставятся в очередь в блоке Queue Management, который регулирует нагрузку на сервера парсинга.

Сервера парсинга собирают данные из социальных сетей и производят над ними сложные аналитические операции с большими объемами данных (порядка 109 строк), используя базы данных Replica Set. Результат аналитики сохраняется в Replica Set. Один анализ может длиться от нескольких секунд до нескольких недель.

Для того чтобы сократить это время, используется Cache Server, который кэширует запросы к социальным сетям.

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

Все данные Replica Set непрерывно архивируются на Backup Server, который находится в удаленном дата-центре.

Если в дата-центре 1 (ДЦ 1) произойдет что-то страшное, например, пожар, то у системы есть возможность в течение пяти минут переключиться на работу в дата-центр 2 (ДЦ 2), в котором развернута упрощенная копия архитектуры дата-центра 1 (ДЦ 1).

Для того чтобы дата-центр 2 (ДЦ 2) был всегда готов к внезапному приему нагрузки, ключевые данные из дата-центра 1 (ДЦ 1) непрерывно синхронизируются с дата-центром 2 (ДЦ 2) (лаг 2 минуты).

Общий объем хранилища Replica Set 60 TB. На нем хранятся данные только актуальных аналитик (за последние 30 дней). Более старые данные переносятся на back-up-сервер в дата-центр 3 (ДЦ 3), в котором хранятся данные всех анализов с 2015 года.

Те, кто создает софт


Интересные проекты в нашем исполнении

работы

Оставьте заявку или напишите нам на почту

письмо

Мониторинг и техподдержка 24/7

support