Aristos: Зачем выбирать между «облаком» или выделенным сервером, когда можно взять лучшее от обоих

Каждый кто хоть раз играл в Лего, знает, что даже из малого набора кубиков легко собирается минимум пять вещей. Если приложить усилия, то больше.

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

При необходимости мы пользуемся услугой платного администрирования нашего хостинг-провайдера. Таким образом, у нас сформирована многоступенчатая защита от сбоев.

Кому бы вы посоветовали использовать комбинированную инфраструктуру?
Думаю, что многие компании так или иначе приходят к подобной схеме работы. Мы рекомендуем использовать аналогичную инфраструктуру любым проектам с периодически меняющейся нагрузкой. Разумеется, сам проект должен быть структурно готов к горизонтальному масштабированию.

Март — женщины в хостинге, резервное копирование Acronis и весенний прогноз

Приветы!
Как настроение? Если вы ещё не выбрались из спячки, то сейчас самое время — прогнозируем любопытные перемены. Мы уже успели проникнуться весной и обновляемся вместе с пейзажем за окном.


Весенние обновления в самом разгаре! На проекте FirstVDS появилась подписка на SSL-сертификат, на FirstDEDIC — новая услуга резервного копирования, а на CLO — быстрые диски. А ещё мы приготовили для вас особый весенний прогноз… Но обо всём по порядку.
Статьи и инструкции

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


О гибридной инфраструктуре
Современный рынок предлагает разные технические и программные решения для IT-инфраструктуры. Можно выбирать между ними, а можно объединить, используя преимущества нескольких технологий одновременно. В новом кейсе читайте, как клиенты FirstDEDIC из компании Aristos построили комбинированную инфраструктуру, совместив «облако» и выделенные серверы.
Aristos: Зачем выбирать между «облаком» или выделенным сервером, когда можно взять лучшее от обоих

Как настроить удалённый доступ к MySQL
По умолчанию доступ к серверу баз данных MySQL можно получить только с локального хоста. Чтобы установить удалённое соединение, нужно выполнить ряд настроек. Разрешить удалённый доступ можно как в панели ISPmanager, так и в консоли. Подробнее об этом в нашей статье.
Удаленное подключение к MySQL

Как установить Python 3 на CentOS 7
При установке Python из стандартного репозитория вы получаете 2-ю версию, которая уже отживает своё. Для решения многих задач требуется более свежая версия — Python 3.9. Установить её не сложно, но есть свои нюансы, поэтому составили для вас инструкцию.
Установка Python 3.9.1 на Centos 7
Если не нашли решение проблемы в Базе знаний, напишите нам на sales@firstvds.ru — добавим статью.

Новости
А теперь главные новости марта.



Подписка на SSL-сертификат до 5 лет
Ранее сертификационные центры ограничили срок действия SSL-сертификата одним годом. Чтобы не забыть о продлении, подключите подписку на срок от 2 до 5 лет. Система будет каждый год автоматически отправлять сертификат на перевыпуск, вам останется только переустановить его на сайте. К тому же, подписка это выгодно: чем дольше срок, тем больше скидка.
firstvds.ru/technology/podpiska-na-ssl-sertifikat

С 31 марта закрываем заказ VDS на OpenVZ
Это решение далось нам непросто, но с 31 марта мы перестаём продавать VDS на виртуализации OpenVZ. Вы сможете и дальше пользоваться вашим сервером OVZ, но заказать новый уже не получится. Исключение составят только тарифы для реселлеров.
firstvds.ru/blog/ovz-closed


FirstDEDIC: Acronis для гибкой настройки бэкапов
На проекте FirstDEDIC появилась новая услуга — Acronis Резервное копирование. Вы сможете настроить бэкапы как для виртуальных, так и для физических ресурсов. Выбрать когда и как часто делать копии, как долго и какие данные хранить. Всеми настройками можно централизованно управлять в веб-интерфейсе.
1dedic.ru/additional/acronis


CLO: Быстрые диски для требовательных приложений
Наши разработчики реализовали ещё одну услугу из Плана развития CLO: теперь для заказа доступны локальные NVMe-диски. В отличие от сетевых, они размещаются на том же оборудовании, что и ваш облачный сервер, поэтому скорость чтения/записи выше в два раза. Обратите внимание, что локальные диски могут быть только системными.
clo.ru/changelog

Уязвимости и релизы месяца
Экстренные обновления для Microsoft Exchange

Разработчики Microsoft выпустили внеплановые обновления для устранения уязвимостей «нулевого дня» CVE-2021-26855, CVE-2021-26857, CVE-2021-26858 и CVE-2021-27065. Хакеры уже использовали уязвимости для атаки на тысячи почтовых серверов, поэтому Microsoft рекомендует обновиться как можно скорее. xakep.ru/2021/03/03/hafnium-0days/

Уязвимости в GRUB2, позволяющие обойти UEFI Secure Boot
В загрузчике GRUB2 выявлено 8 уязвимостей, позволяющих злоумышленнику обойти UEFI Secure Boot и запустить вредоносный код на уровне загрузчика или ядра. Чтобы устранить уязвимость, необходимо обновить список отозванных сертификатов (dbx, UEFI Revocation List) — при этом вы больше не сможете использовать старые установочные носители с Linux. www.opennet.ru/opennews/art.shtml?num=54691

Уязвимость в Linux, позволяющая получить права root
В подсистеме iSCSI ядра Linux обнаружена уязвимость CVE-2021-27365, позволяющая непривилегированному локальному пользователю выполнить код на уровне ядра и получить root-привилегии в системе. Для устранения уязвимости необходимо обновить ядро Linux. www.opennet.ru/opennews/art.shtml?num=54754

В SaltStack устранили 10 уязвимостей
В обновлении 3002.5 системы управления конфигурациями SaltStack устранили десять уязвимостей разной степени опасности. Среди них уязвимость CVE-2020-28243, позволяющая непривилегированному локальному пользователю поднять свои права в системе. www.opennet.ru/opennews/art.shtml?num=54685

Уязвимость в Git, вызывающая удалённое выполнение кода
Во всех выпусках Git, начиная с 2.15, была выявлена уязвимость CVE-2021-21300, позволяющая удалённо выполнить код при клонировании репозитория (команда «git clone»). Чтобы исправить проблему, разработчики выпустили корректирующие обновления для выпусков Git 2.17 — 2.30. www.opennet.ru/opennews/art.shtml?num=54730