Кейс Relog: сократили затраты на хостинг в 3 раза и настроили CI/CD

Задача

Компания Relog размещала свои сервисы у облачного провайдера Microsoft Azure, но коллеги хотели сократить стоимость размещения инфраструктуры.

Решение

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

Каждый облачный провайдер подразумевает, что команде нужно разбираться в конкретном сервисе, настройках и тонкостях. Но как правило команды состоят из разработчиков, а DevOps-инженеров у них нет. Им нужно писать код, а не переживать за то, что что-то может просто отвалиться. И такая картина почти у каждого нашего клиента — кто-то приходит во время пожара, кто-то успевает чуть раньше.

Мы проанализировали рынок и выбрали надёжный провайдер — Hetnzer. Это помогло оптимизировать процесс, сократить ценник и понять, как двигаться дальше. Бизнес в этом плане ничего не теряет, ведь отказоустойчивое решение можно развернуть и на арендованном железе. Взяли сервера и повезли. После чего настроили Kubernetes, выстроили процессы и научили разработчиков действовать по нашему шаблону.

У клиента были тестовые контуры и контур продакшена. Для экономии средств мы развернули тестовый контур на отдельном небольшом сервере. А продакшн инфраструктуру после анализа и калькуляции подняли на нескольких более мощных серверах. Создали виртуальные машины, настроили их и и приготовились к переносу.

Перенесли исходный код всех приложений из Azure в Hetzner, разобрались в его устройстве — то есть, прошли все стадии от сборки и тестирования до деплоя в Kubernetes. После чего выкатили приложения в новый кластер на Hetzner. Так и подготовили приложение к переключению — запланировали ночные работы для всей этой истории и совместно со специалистом компании-клиента переехали на новую инфраструктуру в Hetzner.

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

С тимлидом разработки уточнили время переноса — и уложились с 2 часов ночи до 5 утра. На этом этапе мы всегда учитываем специфику бизнеса и вместе с клиентом выбираем подходящее окно для миграции. Как только нам подтвердили перенос, мы поменяли DNS и поприветствовали новую хостинг-площадку.

Результат

Сократили затраты на хостинг втрое. На общий чек особенно повлияла оптимизация ресурсов и выбор более подходящего хостинг провайдера. Таким образом освободили ресурсы бизнеса на другие задачи.

В результате настройки процесса CI/CD разработчикам стало жить куда комфортнее. Мы поняли, как собирается каждый проект клиента, и автоматизировали весь процесс. Команда просто отправляла commit в систему, после чего автоматом запускался пайплайн, который собирал приложение, тестировал и деплоил его. В итоге вся цепочка CI/CD была настроена максимально эффективно.

После основной задачи мы продолжили совместную работу. Теперь команда разработки может создавать задачи на техподдержку. Если вдруг что-то сломается или начнет работать не так, как нужно, то у нас есть дежурные, которые тут же возьмутся за тикет. Но мы не только тушим пожары, а мониторим всю инфраструктуру, реагируем на инциденты по sla, готовим приложение к планируемой нагрузке, пишем CI / CD для новых сервисов, обновляем все системы для поддержания безопасности в инфраструктуре.

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

Cтек технологий