Статьи
FirstDedic

Этой историей поделился с нами наш клиент Никита Винокуров, технический директор компании SlickJump, которая является разработчиком одноименной платформы контекстной рекламы, работает на рынке с 2014-го года и входит в тройку ведущих компаний по версии крупнейшего отраслевого издания Adindex. Это история о том, какие изменения может претерпевать IT-инфраструктура с ростом бизнеса. Далее передаем слово Никите Винокурову. 

Большинству бизнесов в реалиях настоящего времени не обойтись без собственной IT-инфраструктуры. Многие начинают с shared-хостинга или виртуальных серверов. А затем, с ростом проектов, ищут решения помощнее и понадежнее. Я расскажу об опыте нашей компании. Возможно, кому-то он окажется полезен. 

Идея рекламной платформы и выбор хостинга

Всё началось с идеи создать уникальный рекламный инструмент. Точнее, технологическую платформу для нестандартного размещения рекламы в интернете. С её помощью мы хотели дать доступ рекламодателям к качественным площадкам, которые посещает их целевая аудитория. Изначально предполагалось, что будем ориентироваться на фармацевтические бренды и работать с ресурсами о здоровье. 

Если в двух словах, то работать это должно было так: посетитель переходит на страницу с полезным контентом, а алгоритм подбирает ему рекламный блок, релевантный теме конкретной страницы. При этом одно из основных требований к такому блоку — нативность. Он должен сохранять стиль текста, не выглядеть чужеродным и восприниматься как естественная рекомендация. В этом случае эффект от рекламы усиливается. 

Архитектура проекта созрела достаточно быстро и включала в себя три основных элемента: 

• семантический анализатор веб-страниц, 
• систему управления рекламными объявлениями с базой данных на MongoDB 
• и, собственно, систему подбора объявлений для страницы. 

Всё это должно было располагаться на различных серверах. На одном мы планировали разместить программное обеспечение для текстового анализа содержимого веб-страниц, второй сервер собирались использовать под хранение рекламных блоков для их последующей выдачи. На третьем хотели запустить систему, которая в режиме реального времени реагировала бы на факт посещения веб-страницы, сопоставляла проанализированный текст с базой рекламных блоков и подбирала подходящую по смыслу рекламу.  

Мы знали, что первоначальная нагрузка на серверы будет не очень большой. Самым «тяжёлым» с точки зрения вычислений был семантический анализ страниц — предполагалось, что анализатор будет работать в фоновом режиме, реагируя на появление новых страниц в сети и эпизодически «отъедать» большую часть ресурсов сервера. 

Только представьте, анализатору необходимо сначала определить на странице текстовую часть, затем разбить её на слова, произвести нормализацию слов, отбросив окончания, а только потом построить некую семантическую модель. Или другими словами, такой многомерный вектор, который можно сравнить с аналогичным вектором, построенным из рекламного объявления и содержимого посадочной страницы, на которую это объявление ведёт. 

При этом все простые вычисления происходят уже в режиме реального времени, но на другом сервере — фронтэнд, и сводятся к тому, чтобы найти соответствие между уже найденными векторами страниц и объявлений. 

Мы решили, что в тот момент, когда нагрузка начнёт расти, будем просто докупать серверы и увеличивать размер кластеров нужного типа.

В момент запуска платформы как сайтов с полезным контентом, так и рекламы у нас было немного, поэтому изначальные требования к параметрам серверов были весьма скромными. Для анализатора хватило бы 16 Гб ОЗУ, хорошего процессора и 250 Гб дискового пространства, для остальных узлов требовалось меньше оперативной памяти и диска, но побольше ядер.

И мы поступили так, как делает большинство компаний, только выходящих на рынок с интересной идеей — остановили свой выбор на наиболее популярном тогда сервисе виртуальных серверов Digital Ocean. 

Серверы за границей — хороший сервис, но высокий пинг

Digital Ocean — хороший сервис, удобней в управлении, чем тот же Amazon AWS, с понятным ценообразованием. Но, увы, мощностей сервиса хватило только для запуска платформы, но никак не для её роста и развития. 

Проблема, с которой мы столкнулись сразу, — высокий пинг, из-за которого рекламный блок на релевантной странице появлялся с задержкой примерно в 1 секунду. А это значило, что пользователь мог уже «пролистать» и не заметить его.

Пинг 100 мс из Москвы до серверов, находящихся в Европе, уже тогда считался неприемлемым. А ведь мы ориентировались на Россию и страны СНГ, на рост мобильного трафика. Нам было важно, чтобы реклама появлялась на странице мгновенно. Добиться пинга даже в 30 мс казалось нереальной задачей. 

Кроме этого, было чёткое ощущение, что виртуальные серверы выбранного провайдера не подходят для обработки информации в режиме реального времени. Несмотря на то, что серверы Digital Ocean использовали виртуализацию KVM, при пиковых нагрузках, в самых неподходящих моментах, возникала нехватка ресурсов — процессорных и дисковых. Внезапные просадки по скорости обслуживания, похоже, были вызваны тем, что мы с кем-то делили наш дисковый I/O. Резервировать дополнительные виртуалки, которые бы простаивали 80% времени, казалось тогда расточительством.

Несмотря на посредственный сетевой отклик и частое «захлёбывание» в часы пик, SlickJump достаточно быстро стал востребованным среди клиентов. 

К лету 2014-го года SlickJump стратегически сосредоточился на фармацевтических компаниях и производителях авто. Это достаточно требовательные клиенты, которые прежде, чем прийти к нам, попробовали много разных рекламных инструментов и точно знали, что им нужно. Особенно серьёзные запросы предъявлялись к точности таргетирования рекламы.

Теперь перед нами стояла новая задача — наращивать мощности и переводить серверы в Россию. Это было необходимо как с точки зрения скорости передачи данных, так и для соблюдения законодательства. В частности, в законе появилось требование к компаниям, которые занимаются обработкой персональных данных россиян — хранить эти данные на серверах в России. Стало понятно, что дальше требования будут только ужесточаться.

К тому времени накопилось много доводов отказаться от сервиса Digital Ocean — начиная с того, что мы подозревали провайдера в оверселле ресурсов, и заканчивая тем, что серверы DO себя не окупали.

Помимо всего прочего, мы были разочарованы надёжностью кластера системы управления базами данных MongoDB. Он требовал неоправданно большого числа машин — из-за чего только росла вероятность отказа. 

Мы решили найти недорогой российский виртуальный хостинг. Правда, с прицелом на возможность аренды выделенных серверов, чтобы разместить свою инфраструктуру, которая к тому времени включала в себя уже 15 машин.

Digital Ocean

Плюсы 

• Удобный в управлении сервис — проще, чем Amazon AWS.
• Понятное ценообразование

Минусы 

• Высокий пинг по России 
• Большая вероятность оверселла ресурсов 
• Нет возможности работать по ФЗ.152

Хостинг в России: небольшой выбор и виртуальные «грабли» 

В тот момент, когда мы собрались переводить проекты в Россию, выбор провайдеров, которые устроили бы нас по всем параметрам, был небольшой. Ориентируясь на отзывы, мы просмотрели несколько вариантов и остановились на двух — Selectel и FirstVDS. 

Кроме прочих параметров, это был выбор между дата-центрами, расположенными в Химках (Московская область) и Петербурге. Дата-центр в Химках обеспечивал пинг быстрее (< 30 мс) и отличался более доступной ценой. Взвесив все «за» и «против», в октябре 2014-го года мы переехали на FirstVDS. 

Заодно решили дать шанс MongoDB, поместив узлы на дорогих (так нам казалось тогда в сравнении с виртуалками) выделенных серверах на базе процессоров Intel Core i3 у партнёров FirstVDS — провайдера FirstDEDIC.

Во-первых, урезанная функциональность. Шесть лет назад, когда мы только начинали сотрудничать с FirstVDS, провайдер не мог предложить нам ни снапшоты, ни автоматические бэкапы, ни ряд других опций. И тогда нам этого сильно не хватало. Да и к дизайну панели управления после DO пришлось привыкать. 

Во-вторых, нехватка ресурсов. Даже на KVM виртуалки в FirstVDS не справлялись с нашим нагруженным проектом, несмотря на то, что мы увеличивали количество ресурсов под каждый элемент нашей платформы. 

В процессе эксплуатации было также замечено, что, в отличие от виртуалок, выделенные серверы не перегружались и сохраняли связность. Поэтому постепенно мы начали перемещать критические части в FirstDEDIC, оставляя на виртуалках экспериментальные разработки и некритичные сервисы.

FirstVDS

Плюсы

• Низкий пинг по России
• Доступная цена

Минусы 

• Нехватка ряда опций
• Неудобный дизайн панели управления

Выделенные серверы — инфраструктура, растущая вместе с проектом

С переездом SlickJump на выделенные (физические) серверы мы почувствовали себя более уверенно — работа всех систем стала предсказуемой. А значит, пришло время совершенствовать инфраструктуру под растущие требования проекта. Их было довольно много. 

Так, убедившись в надёжности выделенных серверов, мы предприняли попытку уйти от MongoDB. В 2015 году началась миграция на PostgreSQL. 

Прежде у нас было много сложностей, связанных с горизонтальным масштабированием каждого сервиса, теперь мы наконец-то перешли на размножение крупных вертикалей с warm-standby на уровне данных. 

Фронтэнд-серверы, от которых требовалась непрерывная работа с минимальным временем отклика, были отвязаны от бэкэнда по зависимостям и настроены на максимальную автономность. Они получали трафик от обратного прокси на Nginx, который оставался единственной точкой отказа. 

Каждый узел нашей инфраструктуры требовал полной отдачи сервера, чтобы максимально быстро показать релевантный баннер конечному пользователю. Если это был фронтенд-узел — ему была нужна вся сеть и весь процессор; если сервер процессинга логов — весь диск и вся сеть; eсли база данных — весь диск и весь процессор и так далее. В итоге компромиссу использования виртуальных машин в нашей инфраструктуре не осталось места. И FirstDEDIC раскрылся для нас полностью.

В Москве пинг составлял 6 мс, мы практически забыли про отказы, равно как про ночи, которые на старте проекта уходили на восстановление работоспособности систем MongoDB. Рост трафика, рост объёма хранимой информации требовал от нас новых вложений в инфраструктуру. Но мы решили удерживать бюджет в рамках линейного роста. В среднем, чек за услуги рос на 2.5 тыс. рублей в месяц. 

При этом качество обслуживания не падало, а росло — оборудование регулярно менялось инженерами FirstDEDIC по нашему требованию на более современное и более производительное практически с той же ценой или чуть дороже. 

Дополнительные серверы SlickJump мы старались вводить как можно реже, при условии, что в этом была инфраструктурная необходимость. Процессоры Core i3 постепенно были вытеснены Xeon E3. Сначала PostgreSQL жил на серверах с HDD-дисками и кэшем на SSD, затем постепенно перебрался на NVMe. Если у нас возникали какие-либо нарекания к производительности дисковой подсистемы, к которой наша разросшаяся база данных стала весьма требовательной, то они оперативно решались заменой дисков.

Сейчас у FirstDEDIC появилась недорогая мощная линейка серверов на AMD Ryzen, которую мы уже тестируем на надёжность и производительность под разными нагрузками. Возможно, в будущем она вытеснит в нашей инфраструктуре серверы Intel. 

FirstDEDIC

Плюсы 

• Возможности вертикального масштабирования
• Низкий пинг 
• Своевременное обновление и апгрейд оборудования

Минусы

• Пока не выявлено

Резюме

В целом, мы считаем, что наше решение перенести всю инфраструктуру с виртуальных серверов на выделенные было верным. Стало проще следить за нагрузкой и масштабировать инфраструктуру под проект, который развивается — с 2014 года SlickJump вырос в популярный международный сервис и сейчас высоко ценится профессионалами и бизнесом в разных странах. И надо признать, что частью своего успеха мы обязаны профессионализму инженерной команды FirstDEDIC.