Перенесли инфраструктуру страхового маркетплейса в новое облако

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

Первоначальный план

У клиента было большое облако и очень много виртуальных машин. Ранее разработчики поднимали окружение на каждый пул-реквест, из-за чего тратилось множество ресурсов, которые не освобождались своевременно. Поэтому в компании решили перейти к статическим окружениям: sandbox (песочница) для разработчиков, стейджинг для проверки релизов и полноценное продакшн-окружение. 

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

На этом этапе мы с нуля создали инфраструктуру в Yandex Cloud. Мы сделали Managed Kubernetes Cluster на несколько окружений, которые используют собственные базы данных и сервисы и полностью изолированы друг от друга. Для процессов мы использовали подход непрерывной интеграции, а для автоматизации выпуска приложений - GitOps. Основным инструментом настройки окружений и автоматической доставки приложений стал Flux CD. 

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

Непредвиденные трудности

Когда мы перешли к переносу основного Rails-сервиса в новую инфраструктуру, оказалось, что он зависит от множества PHP-сервисов, и перенести его отдельно не получится. Масштаб проблемы не был понятен изначально, сервис был наследием другого проекта. 

После тщательного аудита приложения и зависимых сервисов с командой клиента мы выяснили, что переносить придется девять сервисов вместо одного. К каждому прилагаются базы данных MySQL, Mongo DB, Elasticsearch, ClickHouse. Заказчик согласовал новый план и мы принялись за работу. 

Распутываем зависимости

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

Для новой инфраструктуры мы подключили систему отлова ошибок в рантайме Sentry, которая давала и перфоманс-метрики. При первом запуске в продакшн мы столкнулись с тем, что не все партнеры переподключили каналы на наши новые IP-адреса. Из-за этого падала большая часть бизнес-логики: не работали калькуляторы, не приходили ответы от страховых. Когда формальности были улажены, система заработала корректно.

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

Результаты

Несмотря на то, что проект пошел не по плану, нам удалось решить основную задачу по сокращению расходов на облачные ресурсы. Затраты на ежемесячное обслуживание сократились в три раза. Сейчас работают 30 виртуальных машин вместо сотни на старте. Из старых остались прокси для трафика в новое окружение и Nexus как хранилище артефактов. В новый кластер мы перенесли порядка 2,5 Тб данных, настроили мониторинг и аналитику. ETL-процессами мы управляли с помощью Apache Airflow.

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

Напишите нам, если вы ищите опытную DevOps-команду, которая поддержит вас в переносе инфраструктуры в Yandex.Cloud или сделает новую облачную архитектуру для вашего проекта. Мы поможем решить проблемы и проконсультируем по дальнейшей поддержке кластеров.