Разработка высоконагруженного сервиса по парсингу социальных сетей
- Заказчик
- Бизнес заказчика построен на анализе данных в социальных сетях (группы, сообщения, репосты, лайки и прочее).
- Задача
- Модернизация инструмента аналитики данных: обеспечение стабильной работы при больших нагрузках.
Изначально проблема клиента и состояла в том, что система перестала справляться с обработкой данных: сервера отказывали в обслуживании при превышении нагрузки в 50 одновременных пользователей. От нас требовалось повысить мощность системы, визуально улучшить интерфейс и взять на себя технические работы по развитию проекта на основе roadmap заказчика.
В начале мы бы хотели уделить внимание визуальной и функциональной частям сервиса.
1. Сервис. Внешнее
Список мониторингов
- Название
- Дата создания
- Изменение
- Статус и др.
Мониторинг Компании
- Изменение количества подпичиков
- Даты обновления
- Количество вступивших и вышедших
- Список групп и др.
Аудитории - Популярные люди
- Ссылка на сообщество
- Количество подписчиков
- Порог вхождения
- Теги и др.
Сообщества - Мои задачи
- Название
- Статус и др.
Собщества - Группы, где есть ЦА
- Название
- Число подписчиков
- Тип сообщества и др.
2. Сервис. Особенности
- Система работает на 7 собственных серверах
- Самые мощные сервера оснащены процессорами суммарно в 40 потоков и 256 Гб ОЗУ
- Возможность горизонтального масштабирования под нагрузкой
- Логика обхода блокировки серверов
- 900 статистических анализов в день
- В случае выхода из строя одного из серверов второй продолжает обслуживать запросы клиентов
- Постоянный мониторинг каждого сервера с автоматическими уведомлениями о критических событиях
- За сутки обрабатывается в реальном времени порядка 500-800 Гб данных
3. Ход проекта
Описание хода проекта раскроет, что мы сделали для решения основной задачи: обеспечение стабильной работы при повышенных нагрузках. В проекте можно выделить несколько этапов. Все этапы важны и взаимосвязаны между собой. Постараемся раскрыть каждый этап.
1 этап - Документация
Провели реверсивный инжиниринг и создали техническую документацию на проект, которой не было у Заказчика.
2 этап - Разработка архитектуры
Разработали новую архитектуру программы и серверов, которая позволяла неограниченно масштабировать программу.
3 этап - Разработка плана переноса кода
Разработали план переноса кода со старой архитектуры на новую в соответствии с техническим заданием, которое было к тому моменту готово и осуществили переезд.
4 этап - Beta-тестирование
Запустили beta-тестирование системы на 1 сервере на 100 лояльных пользователях заказчика. Система успешно справилась с beta-тестированием.
5 этап - Тестирование
Во время тестирования мы сделали замеры нагрузок во время тестирования. Рассчитали предполагаемую нагрузку при выводе на 10 000 человек и подобрали необходимый парк серверов по техническим характеристикам, который, с одной стороны, решал задачу технической нагрузки, с другой, был выгодным для заказчика.
Развернули парк за 2 недели и запустили на всех пользователях за 2 недели.
6 этап - Дальнейшее развитие
Параллельно настроили систему Grafana для мониторинга состояния каждого сервера. Мониторинг снимал более 100 метрик по каждому серверу в реальном времени.
Настроили Telegram-уведомления о подозрительном поведении сервера. Если какая-то из характеристик приближалась к критическому порогу, мы получали предварительное уведомление в Telegram.
Через месяц по результатам анализа мониторинга мы подкорректировали парк серверов, внеся изменения в аппаратную часть. Изменения были направлены, прежде всего, на снижение стоимости серверов, во вторую очередь – на повышение производительности.
Параллельно с этим мы разрабатывали и внедряли новые функциональные модули согласно планам клиента.
4. Подробное описание архитектуры
Чтобы раскрыть проект, его сложность, но при этом логичность и масштабируемость, предлагаем подробное описание архитектуры.
Клиенты заходят на страницу приложения в браузере. Браузер отправляет запросы на один из двух 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 года.
