Выражаем благодарность за подготовку статьи Артему Жуковец — CTO NovaPress Publisher. Проект-победитель конкурса “Герои российских стартапов”
Всем привет! Сегодня мы расскажем об архитектуре сервиса NovaPress Publisher и опыте его переноса в облако Microsoft Azure.
NovaPress Publisher – веб-сервис, который облегчает компаниям работу с социальными сетями. Он позволяет планировать контент в социальных сетях на дни и месяцы вперед. А также автоматически брать контент по мере появления на сайте компании и размещать во всех социальных сетях.
В настоящий момент данный сервис уже используют в работе более, чем 9500 компаний, включая известные бренды — журналы, газеты, телеканалы, коммерческие и государственные организации.
Как все начиналось
Наш сервис появился в 2010 году, но к работе с Azure мы пришли не сразу. В первые годы жизни сервиса мы использовали для работы виртуальные машины на различных хостингах.
Перед нами стояла задача – без задержек обрабатывать и размещать в социальных сетях по несколько тысяч записей в минуту в режиме 24/7.
И при этом настоящей проблемой были периодические перебои в работе виртуальных машин. Они приводили к тому, что в очереди скапливалось огромное количество неопубликованных записей, либо созданный пользователями контент становился временно недоступен.
Кроме того, в часы пик нагрузка на сервис была слишком большой, и возникали задержки при отправке записей.
На тот момент сервис должен был отправлять до 6000 записей в минуту в социальные сети и синхронизировать до 1500 RSS каналов в минуту. Сейчас эти значения существенно больше.
Выше всего нагрузка была в утренние и вечерние часы, особенно в 00 минут и 30 минут (например, 17:00, 17:30, 18:00, и так далее).
Наше решение на тот момент было таким:
Роботы, выполняющие запланированные задачи (публикующие контент в социальные сети), дублировались на несколько серверов, также, как и создаваемый пользователями контент. С ростом числа пользователей мы подключали дополнительные сервера.
Однако со временем масштабирование давалось все сложнее, открывались новые узкие места. Кроме того, периодические сбои у хостинг-провайдеров создавали нам существенные проблемы. И вместо того, чтобы внедрять новые функции в наш сервис, мы тратили много времени на то, чтобы справиться с возросшей нагрузкой и обеспечить несмотря ни на что высокую доступность сервиса и публикацию записей без задержек.
Поэтому мы стали искать новое решение, которое могло бы защитить нас от сбоев и обеспечить гибкое масштабирование в зависимости от нагрузки.
И в итоге, в 2013 году мы остановили выбор на облаке Azure, в котором опции масштабирования, репликации и балансировки нагрузки были доступны сразу же, из коробки.
Переход на Azure
Такой стала схема работы нашего сервиса после перехода в облако Azure:
Пользователи работают с сервисом через веб-сайт (Azure Website, ASP.NET MVC), данные хранятся в базе данных SQL Azure и хранилище Azure Storage. Для быстрого доступа к данным используется кэш Redis в облаке.
Всю автоматику (размещение записей в социальные сети, копирование записей с сайтов или других социальных сетей) выполняют Windows-сервисы, размещенные на большом количестве виртуальных машин Azure VM. Эти сервисы работают в несколько потоков, выполняя задачи по мере их поступления в очередь ServiceBus. Если задач становится больше, и нагрузка повышается, мы увеличиваем количество виртуальных машин.
Кроме того, в пиковые минуты (18:00, 18:30, и т.д.) сервис переконфигурируется (автоматически уменьшает число роботов, выполняющих второстепенные задачи и увеличивает число роботов, публикующих в социальные сети), чтобы как можно быстрее и без задержек опубликовать контент в социальные сети.
Процесс перехода
Переход на Azure мы проводили в несколько этапов, начиная с самых важных:
- Перенос базы данных. До перехода в облако мы использовали базу SQL Server. Миграция базы SQL Server в облачную SQL Azure прошла довольно просто, с помощью специального приложения. После перехода мы получили стабильную работу базы данных без сбоев. (уровень доступности 99.99%).
- Перенос пользовательского контента. До перехода в облако мы сами дублировали пользовательский контент (фото, текст) на несколько серверов, чтобы обеспечить доступность в случае сбоя. Но это требовало много ресурсов и дискового пространства. При переходе в облако мы перенесли весь контент в Azure Storage с автоматической георепликацией (весь контент автоматически дублируется в 3х датацентрах Azure). Уровень доступности: 99.99%
- Перенос очереди задач в ServiceBus. Раньше очередь задач (например, записей, которые нужно опубликовать) была завязана на базе данных. После перехода на Azure сервис отправляет все задачи, которые необходимо выполнить, в очередь ServiceBus. Это сняло часть нагрузки с базы данных и существенно увеличило потенциал дальнейшего масштабирования сервиса.
- Перенос веб-сайта в облако. Сайт перенесли на Azure Website и включили автоматическое масштабирование, чтобы сайт был всегда доступен и лучше держал нагрузку.
- Кэш Redis в облаке. Мы используем Redis, чтобы обеспечить максимально быстрое размещение записей в социальных сетях. Подготовленный к публикации контент и настройки его публикации хранятся в кэше, чтобы в нужную минуту, как можно быстрее уйти в социальные сети. Redis в облаке уже из коробки имеет автоматическую репликацию и гарантирует доступность как минимум 99.99% времени.
Дальнейшие шаги
В декабре 2015 года мы выпустили новую бета-версию, в которой улучшили начинку сервиса:
- Сайт сервиса теперь представляет собой SPA-приложение AngularJS. Все html-формы, скрипты и стили минифицированы и подгружаются при старте, чтобы дальнейшее переключение форм было моментальным.
- Работа с данными идет через отдельное веб-приложение ASP.NET Web API. Вы вызовы Web API сделаны так, чтобы как можно быстрее получать результат операции. Активно используется кеширование с помощью Redis.
В дальнейших планах у нас следующие улучшения:
- Работа с сервисом в реальном времени благодаря WebSocket (SignalR). Так как с сервисом часто одновременно работают несколько сотрудников компании, то хотелось бы, чтобы внесенные каждым пользователем изменения мгновенно отображались у других сотрудников. Также пользователь сразу же увидит, как только сервис выполнит ту или иную задачу (например, опубликует записи в социальных сетях, или загрузит новые записи с сайта).
- Мониторинг и аналитика в социальных сетях. Покажет, насколько эффективно компания работала с социальными медиа и подскажет, как улучшить эти показатели. В этом плане мы смотрим в сторону Stream Analytics и Machine Learning.
Полученные результаты
В результате перехода на Azure мы:
- обеспечили высокую доступность нашего сервиса для клиентов. Все работает как часы и это не может не нравиться клиентам.
- получили запас производительности для дальнейшего роста сервиса. Сейчас сервис размещает в социальных сетях по 23000 записей в минуту, но это далеко не предел.
- освободили наше время для других важных задач, переложив обеспечение высокой доступности и масштабирования на Azure. Так что мы смогли полностью cконцентрироваться на улучшении сервиса и добавлении новых функций.
Об авторе
Артем Жуковец — Технический директор компании NovaPress Publisher