Автор кейса
ТектософтЛоготип компании

Разработка высоконагруженного сервиса по парсингу социальных сетей

Заказчик
Бизнес заказчика построен на анализе данных в социальных сетях (группы, сообщения, репосты, лайки и прочее).
Задача
Модернизация инструмента аналитики данных: обеспечение стабильной работы при больших нагрузках.

Изначально проблема клиента и состояла в том, что система перестала справляться с обработкой данных: сервера отказывали в обслуживании при превышении нагрузки в 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 года.


Перейти на сайт

В карточку агентства
Пользуйтесь реальным опытом в IT и следите за успехами потенциальных подрядчиков и конкурентов

Кейсы по этой теме

Не трать деньги на ошибки —
используй чужой опыт

Разработка и продвижение сайтов, SEO, SMM, брендинг и многое другое – вооружайтесь свежими IT — решениями из рассылки кейсов Рейтинга Рунета

Подписаться на кейсы