О проекте
Заказчик обратился к нам после того, как задачу пытались решить 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 года.
Те, кто создает софт
