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

Рассказываем, как решали задачу по оптимизации ресурсов на инфраструктуру, переезжали с Microsoft Azure и выбирали провайдера.

Задача

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

Решение

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


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


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


У клиента были тестовые контуры и контур продакшена. Для экономии средств, мы поняли, что тестовый контур вполне может располагаться на казахстанском железе — один сервер как раз уже был развернут. И там же мы развернули Gitlab, Jira и Confluence. Там же мы подняли раннеры, чтобы оптимизировать ресурсы. А в Hetnzer развернули продакшн. На нескольких серверах создали виртуальные машины, настроили их и и приготовились к переносу.


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


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


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

Результат

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


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


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


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

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

  • Kubernetes
  • Gitlab
  • Jira
  • Confluence

Поможем в решении DevOps-задач

Если и у вас есть задача для нас — обращайтесь. Можем начать с аудита инфраструктуры и после этого перейти к полноценному проекту.

Заказать аудит