Когда сервис начинает быстро расти, инфраструктура почти всегда отстает. Сначала это выглядит как редкие ошибки, потом — как нестабильная работа в часы пик, когда пользователи просто не могут пользоваться сервисом. А дальше становится понятно: если хочешь сохранить клиентов и масштабироваться, то дальше так работать нельзя.
Примерно в такой точке к нам и пришел Senler — сервис автоматических рассылок во «ВКонтакте», который хорошо знаком SMM-специалистам (менеджеры соцсетей). На тот момент продукт уже был известен на рынке, активно рос и обрабатывал большой поток запросов через API VK ( прикладной программный интерфейс ВКонтакте). А значит — жил в условиях лимитов, пиковых нагрузок и постоянно растущего объема данных.
Этот проект был реализован несколько лет назад. Но запросы, с которыми тогда пришел сервис Senler, — не история из прошлого. К нам регулярно обращаются компании, которые чувствуют, что техническая часть проекта начинает тормозить развитие. Поэтому мы решили рассказать этот кейс — он остается актуальным для любого быстрорастущего сервиса.
Проблема: рост количества клиентов начинает ломать сервис
Команда основателей столкнулась с ситуацией, когда продукт развивался, клиенты приходили, но инфраструктура, рассчитанная на меньшие объемы, начинала упираться в пределы. Сервис начинал подвисать в часы пиковой нагрузки. А любая ошибка в сервисе — это недовольные пользователи и потеря прибыли. Своей команды, отвечающей за ИТ, у клиента еще не было, а количество пользователей росло быстро и нужно было оперативно решать вопрос.
Задача звучала просто: подготовить сервис к дальнейшему росту, сделать его стабильным и предсказуемым, при этом не переписывая продукт с нуля. Нужно было решить проблему именно на уровне инфраструктуры.
Что мы сделали и почему это сработало
Мы подключились как команда, отвечающая за серверную часть и надежность сервиса. Работа инфраструктурой, в которой было больше 10 серверов, шла в нескольких направлениях.
Настроили мониторинг для предотвращения возможных проблем. Мы внедрили систему Zabbix, которая позволяет видеть, что происходит с сервисом в реальном времени: как растет нагрузка, где заканчиваются ресурсы, какие сервисы начинают вести себя нестабильно. Это сильно меняет подход к поддержке продукта — проблемы перестают быть неожиданными и их можно избежать.
Подготовили базу данных к масштабированию. При росте количества пользователей и сценариев использования одна база начинает работать все медленнее, и никакие «костыли» это не спасают. Мы сделали шардирование, то есть разделили хранилище на несколько независимых частей, шардов (от англ. shard — осколок), чтобы распределить данные и сохранить скорость работы сервиса даже при кратном увеличении объемов.
Настроили логирование (т.е. запись событий в журналы). В больших сервисах ошибки редко выглядят как «все упало». Чаще это проблемы, которые затрагивают небольшую часть пользователей и никогда не доходят до поддержки. Без автоматической записи событий в журналы о них просто никто не узнает. После нашей настройки все нештатные ситуации начали фиксироваться и становиться видимыми для команды.
Параллельно мы оптимизировали веб-серверы, подготовили инфраструктуру к пиковым нагрузкам и настроили репликацию данных (создание и автоматическое обновление копий базы данных на нескольких серверах). Все это в комплексе сделало сервис устойчивым к ситуациям, когда нагрузка растет резко и непредсказуемо — например, после маркетинговых активностей.
Результат: стабильность, скорость и запас по росту
В результате сервис Senler получил инфраструктуру, которая перестала быть узким местом для бизнеса. Сервис стал работать быстрее, стабильнее и спокойнее переносить рост нагрузки. Команда получила контроль над происходящим, а продукт — технический запас для дальнейшего развития.
Наша задача была именно в том, чтобы помочь в моменте и заложить фундамент под дальнейший рост — и она была решена. После этого в Senler появился ИТ-отдел, и сервис продолжил развиваться уже с собственной командой, что логично для компании такого масштаба.
Кому нужны такие решения
Подобные задачи не возникают у «просто сайтов». С ними сталкиваются сервисы, которые активно растут, работают с API ( прикладными программными интерфейсами), сложной логикой и большим количеством пользователей. Если у вас появляются зависания и ошибки, падения сайта, а вы ожидаете резкий наплыв клиентов — значит, инфраструктура уже стала бизнес-риском.
Мы можем помочь именно в этот момент: когда рост есть, а уверенности в том, что сервис его выдержит, — нет. Помогаем масштабироваться, наводим порядок в инфраструктуре и делаем так, чтобы продукт мог расти дальше.
ВКОНТАКТЕ
TELEGRAM