Рефакторинг сервисов при миграции в Yandex Cloud: опыт Renault Россия и OpsGuru

Renault Россия — один из мировых лидеров в области цифровых технологий в автомобильной сфере. Компания имеет опыт внедрения информационных решений в РФ, СНГ, а также на территории стран Латинской Америки, Юго-Восточной Азии и Северной Африки, создает инновационные информационные продукты для других заводов Renault Group и сторонних предприятий автопрома.

Renault Россия работает в формате небольших и средних проектов, поэтому исторически внутри компании есть много команд разработки и стеков технологий. В течение многих лет приложения и сервисы разворачиваются в нескольких разных хостингах.

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

Поэтому перед IT-командой Renault Россия встала задача стандартизировать подходы к разработке и администрированию, а также научиться повторно использовать уже разработанные решения для ускорения бизнес-процессов.

IT-команда Renault Россия решила убедиться, что Yandex Cloud подходит для развертывания IT-приложений компании. Поэтому первым шагом стал перенос текущих приложений и сервисов «как есть» с использованием виртуальных машин в сервисе Yandex Compute Cloud. За два месяца специалисты Renault Россия получили среду для разработки, тестирования и продуктивную среду. В новой инфраструктуре инкапсуляция окружений осуществлялась с использованием нескольких сетей и межсетевых экранов, что позволило IT-команде просто и понятно управлять инфраструктурой в облаке по уже привычным правилам.

В результате был получен ответ на главный вопрос о запуске старого workflow в Yandex Cloud. Самым главным достоинством стала возможность консолидации всех ресурсов в одном месте. Однако скорость и сложность конфигурирования и разработки остались прежними, а для управления средой использовался ручной подход. Любое изменение в количестве виртуальных машин, их конфигурации, переконфигурации правил на межсетевых экранах и другие настройки требовали ручного администрирования через GUI Yandex Cloud и других инструментов. Это влекло за собой трудозатраты, сопоставимые с работой в старой инфраструктуре.

Первый этап открыл много новых возможностей для улучшения инфраструктуры.

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

Используемый стек:

• Linux- и Windows-приложения.
• Обширный список языков разработки.
• Разные фреймворки и библиотеки.
• Несколько типов баз данных.

Также был опыт запуска приложений поверх виртуальных машин с использованием различных средств автоматизации, таких как Ansible, Docker Compose, Docker Swarm и даже кластер Nomad.

При этом были выявлены следующие проблемы:

• Отсутствие стандартов управления жизненным циклом приложений.
• Большие вложения в администрирование баз данных.
• Разные способы журналирования.
• Сложность отслеживания изменений.

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

• Infrastructure as a code — для максимального упрощения администрирования инфраструктуры и хранения истории.
• Immutable-подход — для создания более стабильных приложений, менее зависимых от окружения.
• Kubernetes^® — как единая, стандартизованная среда для управления сервисами, запущенными в Docker.
• Управляемые базы данных — для уменьшения времени на обслуживание баз данных.
• GitLab CI — для стандартизации методов непрерывной поставки, контроля качества и развертывания приложений.

Были добавлены требования:

• Централизованное логирование всех событий, хранение истории логов приложений длительное время.
• Наличие proxy-сервиса: * Для возможности полностью или частично ограничивать сервису доступ в интернет или к другим сервисам.
• Для логирования всех запросов к внешним ресурсам.
• Полное разграничение сред dev, stage и prod.
• Web Application FW для контроля запросов из интернета к нашим сервисам.
• Использование VPN для изоляции приложений на стадии разработки и тестирования.

Третий этап. Выбор партнера

Учитывая количество новых требований, частично противоречащих друг другу, и практик, которые во многом были новыми для компании, было очень сложно просчитать, сколько времени займет реализация новой инфраструктуры, адаптация legacy-приложений и обучение команд. Поэтому успех самостоятельного развертывания был не очевиден, и Yandex Cloud порекомендовала партнера: OpsGuru, глобальную технологическую компанию с фокусом на Cloud Engineering и Data Engineering. У них уже был опыт переезда в облако legacy-решений и эксплуатации необходимых сервисов.

Совместными решениями были обобщены требования к архитектуре и спрогнозированы сроки миграции — от 2 до 4 месяцев:

• Резервирование
• Изоляция и разделение ответственности
• Мониторинг
• Шаблоны Terraform + Terragrunt
• Шаблоны GitLab CI + Helm
• Быстрая сборка и выкатка версий
• Динамическое масштабирование
• Централизованное журналирование
• Гибкая модель инфраструктуры
• Стандартные процессы управления циклом разработки IT + dev + business

После анализа требований стало очевидно, что некоторые из них противоречат друг другу, например:

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

Необходимо было решить, какие сервисы оставить как есть, а какие докеризировать и адаптировать к новым правилам.

Четвертый этап. Решение

Было решено использовать сервисы Yandex Cloud для разделения между собой окружений разных стадий, таких как dev, stage и prod, и разные команды для удовлетворения многочисленным требованиям.

Дизайн инфраструктуры был выстроен с помощью таких ресурсов, как Yandex Resource Manager, Yandex Object Storage, folder и network, что позволило достичь максимальной инкапсуляции и гибкости. Абстракция folder’ов позволила отделять prod от dev разных команд с разными стеками друг от друга, а для гибкой коммуникации между ними использовать VPN.

Все манипуляции по созданию и настройке folder’ов производятся через Terraform в Yandex Cloud, а значит, можно легко повторно использовать ранее написанную конфигурацию и есть вся история инфраструктуры в Git. Использование Terraform снижает риски при изменении инфраструктуры и повышает скорость ее создания. Этот подход позволил, с одной стороны, совместить стандартизацию и повторное использование инфраструктуры, а с другой — добиться гибкости и независимости окружений и команд.

В Yandex Cloud есть библиотека модулей для создания ресурсов, описанных в Terraform-коде и сконфигурированных с помощью YAML-файлов. Это облегчает использование модулей под конкретную задачу, и теперь команды разработки сами могут разворачивать проверенные и новые ресурсы в dev-окружении средствами Terraform.

Созданное окружение в дальнейшем проходит review команды поддержки инфраструктуры и переходит в stage и prod, за счет этого сократилась трудоемкость работы специалистов. С помощью нового workflow удалось ускорить разработку и развертывание, а Terragrunt позволил одной командой применять изменения в масштабе целого окружения.

Пятый этап. Непрерывная поставка — GitLab CI Pipeline

Одним из важных результатов стало внедрение pipeline’ов для поставки продуктов.

• Code review: GitLab
• Code Coverage: SonarQube
• Build & Test: GitLab runner tags
• Yandex Container Registry
• Deploy: Folder + Kubernetes namespaces

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

При успешной сборке и завершении всех проверок в Yandex Container Registry сохраняется готовый образ, и в любой момент его можно опубликовать в любой из сред.

Использование новых подходов и принципов отлично сработало. Сервисы Yandex Cloud позволили совместить несовместимое и при этом дали возможность получить запас изоляции на двух уровнях, где можно реализовать гибкие вещи. Можно делать разные облака и разные VPC в рамках каталогов.

Управляемые сервисы Yandex Cloud позволили значительно ускорить циклы разработки:

• Было: команда делает заявку на создание нужных ресурсов, и срок ожидания составляет от нескольких часов до нескольких дней.
• Стало: команда сама создает нужные ресурсы в dev-окружении по требованию за несколько минут.

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

У Renault Россия получилось выстроить несколько уровней инфраструктуры с использованием как управляемых сервисов Yandex Cloud, так и современных cloud-native продуктов и практик. Это позволило значительно оптимизировать вложения в ее развитие и поддержку.