Каждый кто хоть раз играл в Лего, знает, что даже из малого набора кубиков легко собирается минимум пять вещей. Если приложить усилия, то больше.
Сейчас, когда рынок насыщен техническими и программными решениями, строительство IT-инфраструктуры начинает превращаться в творческий процесс. И только от «строителя», его опыта и знаний зависит, какие «кубики» он предпочтёт использовать, а от каких откажется совсем.
Если раньше компании были более категоричны в выборе — или то, или другое, то сегодня многие склоняются к тому, чтобы объединить преимущества нескольких решений с целью добиться синергетического эффекта. Как это сделали наши клиенты из компании Aristos, которые построили комбинированную инфраструктуру, найдя в ней место и для выделенных серверов, и для облачных технологий.
О подходе к созданию такой IT-платформы, её преимуществах и особенностях рассказывает Андрей Мистулов, технический директор.
Андрей, расскажите, чем занимается компания?
Мы работаем в области ритейла. Предлагаем услуги аутсорсинга электронной коммерции крупным международным брендам. Например, сотрудничаем с Philips, Castrol, Nestle, DeWalt и другими. Создаем и разрабатываем сайты, решаем задачи логистики. Бухгалтерия, закупки, склады — это все завязано на нас.
Наша IT-платформа для интернет-коммерции состоит из множества модулей собственной разработки, приложений и сервисов: CRM, ERP, телефония, логистика, мобильные приложения и так далее. За время работы мы сформировали эксклюзивный набор инструментов и технологий, которые помогают нам непрерывно повышать качество сервиса. Естественно, что такой серьезный инструментарий требует соответствующего фундамента — надёжной и отказоустойчивой архитектуры.
С чего началось строительство IT-платформы?
Первый сервер мы арендовали в 2011 году в Нидерландах — под официальный интернет-магазин Philips. Тогда еще не было 152-ФЗ, который обязывал бы нас хранить персональные данные в России, да и головной офис Philips настаивал, чтобы серверы находились в Европе. На этом сервере хранились и база данных, и веб-сервер, и программный код.
В первые годы работы нам удалось запустить на этой же платформе проекты и для других крупных брендов — Tefal, Olympus, Oursson, Oppo. По мере роста проектов росла и нагрузка. Чтобы её оптимизировать, мы решили перенести базу данных на отдельный сервер.
Так мы работали до 2014 года — в кризис курс доллара резко вырос, а с ним и стоимость серверов в Европе. Арендовать там стало невыгодно, и мы задумались о необходимости переноса инфраструктуры в Россию. Дополнительным аргументом в пользу такого решения стал тот факт, что мы периодически сталкивались с проблемами доступности серверов — для клиентов из России пинг до Европы выше, чем внутри страны. Соответственно, скорость обслуживания медленнее.
Кроме того, нужно было закупать новые серверы. Во-первых, мы расширили команду, специалисты которой нуждались в рабочих инструментах. Во-вторых, под растущие проекты требовалось все больше вычислительных мощностей. Возникла необходимость в сопутствующих серверах и сервисах — препродакшн, тестовые стенды, автоматические тесты и так далее.
К переезду готовились основательно. У нас имелся ряд определенных требований к хостинг-провайдеру, например, собственный дата-центр не ниже уровня Tier II, адекватные тарифы, возможность гибко конфигурировать серверы. Мы несколько недель анализировали рынок хостинговых услуг на соответствие стандартам качества и безопасности, прежде чем выбрали подходящего провайдера.
Мы арендовали три сервера под разные задачи, и на тот момент наша инфраструктура была такой:
- Технический сервер, так называемый dev-сервер, с рядом вспомогательных сервисов (тестовый сервер, git-сервер, мониторинг доступности, сервис управления проектами, телефония и др.).
- Отдельный сервер под базу данных и сервисы, обслуживающие непосредственно интернет-магазины.
- Производительный сервер для обслуживания HTTP-запросов (веб-сервер и обработка запросов со стороны бэкэнд-логики).
С ростом нагрузки возникла необходимость масштабирования вычислительных мощностей. Постепенно мы переработали программную часть инфраструктуры таким образом, что стало возможным запускать ее на неограниченном количестве серверов. Подключили сервис-балансировщик. Его задача — самостоятельно оценивать производительность и нагрузку на каждом из доступных серверов, а затем распределять нагрузку между наименее загруженными серверами.
За счёт этих решений мы смогли реализовать быстрое горизонтальное масштабирование — меньше времени тратить на то, чтобы добавлять новые серверы в общую архитектуру. А кроме того, повысили доступность наших проектов.
Также в первые две недели после переезда мы объединили все серверы в локальную сеть с помощью услуги VLAN. До этого момента серверы общались друг с другом через интернет. И чтобы обратиться к базе данных, требовалось отправить запрос на внешний IP. Такое решение было ненадёжным сразу по двум причинам. Во-первых, сервисы смотрели «наружу», что само по себе не безопасно. А во-вторых, терялась скорость при передаче данных из-за избыточности маршрута. Часть вспомогательных сервисов распределяется между серверами, поэтому нам требовалась оперативная связь между ними. В тот момент этого нам не хватало. Организация локальной сети решила эти проблемы.
Изначально вы строили инфраструктуру только на базе выделенных серверов. По каким причинам решили использовать и облачные технологии?
Дело в том, что спрос на товары брендов, с которыми мы сотрудничаем, неравномерен в течение года. Так высокий сезон у большинства из них начинается в конце года — ближе к праздникам. Кроме того, в течение года бренды запускают акции, рекламные кампании, распродажи, привлекая новых посетителей. В такие моменты нагрузка на серверы возрастает в разы.
Раньше для нас это было серьезной проблемой. Например, традиционно та же «Черная пятница» длилась всего 1-2 дня, а не растягивалась на неделю-другую, как практикуется в последнее время. Чтобы выдержать приток посетителей на клиентские сайты, мы были вынуждены арендовать дополнительные выделенные серверы. И хотя пик посещаемости часто приходился на пару-тройку дней, платили за полный месяц аренды.
Плюс «облаков» в том, что с ними вы получаете почти неиссякаемый резерв вычислительных мощностей. И можете, во-первых, использовать столько ресурсов, сколько нужно, во-вторых, оперативно их подключать, а в-третьих, платить только за те, которые используете.
Поэтому сейчас, когда нагрузка возрастает, справиться с ней нам помогают облачные серверы. Несмотря на то, что облачные решения более дорогие по сравнению с арендой выделенных серверов, такой подход к их использованию позволяет нам экономить.
Вы интегрировали облачные решения в действующую инфраструктуру. Что для этого потребовалось сделать?
Как я уже говорил, сперва мы внедрили ряд решений для быстрого горизонтального масштабирования. Каждый ключевой компонент платформы трансформировался в отдельную операционную единицу с распределенным запуском на разных серверах.
Базы данных (SQL и NoSQL), поисковый сервис, функциональные приложения для работы проекта, API — теперь каждый компонент масштабируется независимо от остальных.
Затем мы подготовили архитектуру платформы для быстрого разворачивания облачных серверов — загрузочные образы включаются в наш стек за считанные минуты. Также автоматически запускается процесс настройки сервера, во время которого активируются сервисы, необходимые для работы.
Облачные серверы связываются с выделенными через IPv6 туннель и WireGuard VPN. А за распределение нагрузки отвечает сервер с системой программной балансировки. Систему разрабатывали самостоятельно, так как хотели иметь полный контроль над поведением балансировщика.
Сейчас это работает так. Система опрашивает серверы, анализирует текущую нагрузку на каждом по нескольким метрикам, исходя из параметров его мощности и количества обрабатываемых задач. В результате анализа присваивает серверу некий «вес» среди всех серверов, обслуживающих конкретный проект. На основе полученного «рейтинга» балансировщик распределяет входящие запросы по наиболее свободным серверам в группе проекта. Так как «опрос» серверов запускается ежеминутно, система реагирует на изменения нагрузки практически в реальном времени.
Вообще мы рассчитываем на то, что этот механизм при необходимости поможет нам в дальнейшем разворачивать дополнительные облачные серверы в автоматическом режиме. Сейчас это делается вручную — пока мы не вводим столько новых серверов, чтобы это стало для нас проблемой.
В результате мы получаем гибкую инфраструктуру, у которой нет ограничений на добавление ресурсов. И при этом все ресурсы используются рационально.
Почему вы не переехали в «облако» полностью?
Облачные серверы стоят дороже. И нет никакого смысла переплачивать за «облако» в спокойный период, когда нагрузка остается в допустимых пределах. В это время мы работаем на мощностях, которые арендуем на постоянной основе. Например, в первой половине года. А облачные ресурсы задействуем на короткие периоды и только тогда, когда это необходимо.
Правда, это не касается облачных дисков. За них мы платим постоянно. Но этот холостой ход не требует больших затрат и позволяет быстро разворачивать данные. Так наша архитектура помогает оптимизировать расходы на серверные мощности.
Расскажите подробнее, какие задачи вам помогает решать комбинированная инфраструктура?
Во-первых, как я уже упоминал, это задача по оптимизации затрат на поддержку и развитие инфраструктуры. Раньше под высокий сезон мы арендовали выделенные серверы стоимостью 15 тысяч рублей в месяц. Теперь на те дни, когда ожидается рост нагрузки, арендуем аналогичные облачные мощности, что обходится нам примерно в 5 тысяч рублей за сервер. В отличие от выделенного сервера «облако», хотя оно и дороже, позволяет не платить за неиспользуемые ресурсы.
А во-вторых, это рост качества наших услуг. Используя гибридное решение, мы повышаем уровень доступности клиентских проектов. К примеру, мы уже знаем, что в зависимости от сезона нагрузка может увеличиваться на 30%, и превентивно в пики посещаемости подключаем дополнительные серверы, чтоб исключить любой риск нехватки ресурсов. При этом в остальное время года используем обычные выделенные серверы — облачные переводятся в режим ожидания, но всегда готовы к моментальному развертыванию.
Такой подход помогает повышать надёжность и при возникновении проблем в работе наших сервисов — в этом случае вышедший из строя сервер немедленно заменяется аналогичным из пула доступных серверов. И процесс не останавливается.
Если нагрузка связана с DDoS-атакой, мы также реагируем на нее введением дополнительных серверов и инструментами фильтрации трафика. К счастью, подобные ситуации возникают редко.
В целом, комбинированная инфраструктура тем и хороша, что учитывает плюсы и недостатки как выделенных серверов, так и облачных. К слову, в выполнении серверных задач отличий нет, потому что принцип один и тот же — использование мощностей. Но нарастить эти мощности проще в «облаке». Чтобы добавить пару ядер, не нужно физически менять процессор.
Подготовка облачного сервера также занимает гораздо меньше времени — за счет готовых образов для развертывания новый сервер вводится в строй в течение 10-15 минут. На подготовку выделенного сервера обычно уходят сутки, так как требуется время на конфигурирование и перенос сервисов. Но при этом стоимость его ниже, а значит в долгосрочной перспективе использовать его выгоднее.
Что необходимо, чтобы поддерживать стабильную работу такой инфраструктуры?
В первую очередь, необходимо, чтобы все элементы инфраструктуры работали согласованно. Поэтому мы в обязательном порядке следим за идентичностью программного окружения, а также проверяем корректность синхронизации локальных файлов.
Но, пожалуй, самое главное — это контролировать работу всех её элементов. В этом нам помогают различные системы мониторинга. Причём, основную работу выполняет Zabbix. Он отслеживает состояние всех серверов по ряду параметров — нагрузка процессора, объём дисков, объём оперативной памяти. А также контролирует работу конкретных сервисов.
Кроме этого, мы используем внешние сервисы мониторинга — для контроля за доступностью сайтов и сервисов. При возникновении проблем, например, если пропал доступ к сервисам, специальные службы на серверах пробуют перезапускать их автоматически. Оповещения о проблемных событиях тут же доставляются в специальный Telegram-канал, где дежурят наши администраторы, готовые оперативно прийти на помощь, если автоматика даст сбой.
При необходимости мы пользуемся услугой платного администрирования нашего хостинг-провайдера. Таким образом, у нас сформирована многоступенчатая защита от сбоев.
Кому бы вы посоветовали использовать комбинированную инфраструктуру?
Думаю, что многие компании так или иначе приходят к подобной схеме работы. Мы рекомендуем использовать аналогичную инфраструктуру любым проектам с периодически меняющейся нагрузкой. Разумеется, сам проект должен быть структурно готов к горизонтальному масштабированию.
