Robota.ua — сервис для поиска вакансий и сотрудников в Украине. Включает в себя веб-сайт со средней посещаемостью 7 млн визитов в месяц и приложения для iOS и Android. Мы помогаем robota.ua поддерживать кластеры Kubernetes.
Кейс интересен тем, что за короткое время клиенту удалось бесшовно переехать с Google Kubernetes Engine (GKE) на другой managed-сервис. Расскажем о ключевых этапах проекта, немного об экономике и о том, какие возможности для развития и кастомизации инфраструктуры появились у robota.ua*.
* Примечание
Это не технический, а бизнес-кейс. Упоминаемые технические детали помогают увидеть общую картину с точки зрения бизнеса.
Технологический стек
Robota.ua используют в основном Open Source-решения. Для разработки большей части сервисов — .NET; в качестве хранилищ — реляционные и документные БД (в зависимости от решаемой задачи). Общение между сервисами обеспечивает Kafka, а доступ к ним организован через федеративный GraphQL. Фронтенд написан на Angular и размещается в большом монорепозитории.
Инфраструктура до перезда
До лета 2021 года основная часть инфраструктуры robota.ua размещалась в европейском дата-центре Google. Старые части системы — на собственных серверах в Украине. Большинство сервисов запускалось в GKE.
Почему использовался именно managed-сервис?
У ИТ-команды robota.ua не было опыта работы с Kubernetes, поэтому managed-сервис стал самым рациональным способом куберенетизировать приложения. И такой выбор оправдал себя: по словам CTO Александра Марченко, за все то время, что команда пользовалась GKE, с Kubernetes не было ни одного инцидента: он просто работал. Подход хорош и тем, что разработчики не вникали в сложности устройства Kubernetes, а фокусировались на своей основной деятельности — разработке.
Почему отказались от Google
Основная причина — в росте стоимости managed Kubernetes. В 2018-м, в самом начале кубернетизации, у robota.ua было меньше сервисов, небольшие prod- и тестовое окружения. Некоторое время ценник был приемлемым. Но со временем стоимость тестовых окружений стала обходиться в такую же сумму, что и prod. Количество сервисов, которые развернуты в managed K8s, увеличивалось. В итоге было решено мигрировать в частное облако украинского провайдера и найти альтернативу GKE.
У robota.ua был положительный опыт с managed Kubernetes от Google, и они хотели получать такую же услугу в другом облаке. Такая позиция совпадает с трендом индустрии: недавно мы рассказывали об исследованиях, которые подтверждают, что всё больше компаний выбирают managed Kubernetes у провайдеров или готовые платформы. Причины тренда детально разобрал Дмитрий Столяров в своем докладе «Как правильно сделать Kubernetes».
«Нам нужно было решение, которое бы, с одной стороны, не стоило, как крыло от самолета, а с другой, позволяло бы держать одинаковые кластеры».
Александр Марченко
CTO robota.ua
Тогда robota.ua обратились к нам. С учетом того, что инфраструктура была уже в K8s, они увидели перспективу в managed Kubernetes на базе платформы Deckhouse, которая предлагает готовые к работе кластеры Kubernetes. Большой бонус в том, что такой Kubernetes можно использовать, в частности, поверх любых виртуальных машин (ВМ).
На решение robota.ua повлияло и то, как работает техподдержка «Флант». Мы на связи 24х7 и всегда готовы помочь. Тем более в таком сложном деле, как переезд, который Бенджамин Франклин сравнивал с пожаром.
Переезд
Новую инфраструктуру было решено развернуть в частном облаке украинского провайдера Colocall (Киев). Kubernetes-кластеры запускались на базе платформы Deckhouse, которая работает поверх статических ВМ Colocall.
Нужно было перенести 100+ сервисов (deployment’ов), многие из которых работали под нагрузкой в production. Основную часть команда robota.ua перенесла за две недели; в целом же переезд занял полтора месяца.
Robota.ua используют отдельную continuous delivery-систему Octopus Deploy. Поэтому первым делом было настроено развертывание приложений через систему в новый кластер. При миграции проблем не возникло, так как кластеры Kubernetes под управлением Deckhouse — это, по сути, «ванильный» Kubernetes. Единственное, что нужно было сделать, — поменять kubeconfig в CI-системе.
Все приложения — stateless. Kafka и БД запущены не в Kubernetes и не затрагивались при переезде, настраивать миграцию данных не требовалось. Поэтому далее процесс выглядел достаточно просто и типично:
выкатили приложение в новый кластер;
проверили, что приложение работает;
переключили DNS на новый кластер;
проверили приложение на наличие ошибок и увидели в мониторинге, что запросы проходят корректно.
Перенос консьюмеров Kafka стал еще более простой задачей: достаточно было выкатить консьюмеры в новый кластер, и они сразу же взялись за работу.
Небольшие затруднения возникли с двумя старыми проектами, которые взаимодействовали внутри K8s, не выходя наружу — их нужно было переносить разом. Впрочем, они переносились в последнюю очередь. Поскольку к этому моменту процесс миграции был уже отработан, сервисы переезжали по десятку в день.
Итог
Команда robota.ua самостоятельно и легко справилась с переездом. Мы лишь развернули и поддерживали кластеры, консультировали по вопросам работы с Deckhouse.
«Полет нормальный, Кубер живет своей жизнью. Любопытный факт: многие сервисы стали работать шустрее (теперь всё чуть ли не в соседних стойках живет)... В общем, очень круто. Честно говоря, думал, что переезд будет сильно дольше и больнее. Ведь по сути, мы тут за две-три недели из ничего сделали кластера и бесшовно переехали. Если бы не писал нашим ребятам, никто бы даже не заметил».
Александр Марченко
CTO robota.ua
Как удалось сэкономить
На момент миграции стоимость ресурсов в приватном облаке Colocall была в несколько раза ниже, чем у Google. Хотя сейчас по количеству worker-узлов и совокупной емкости CPU и RAM кластер больше того, что был в GKE, затраты на инфраструктуру и ее обслуживание снизились.
Чтобы измерить экономическую выгоду от переезда, нужно понять, как формируется итоговая стоимость кластера K8s с учетом затрат на ресурсы.
В GKE стоимость за сам Kubernetes символическая; основные затраты приходятся на виртуальные машины для кластера. Вот как распределяется бюджет:
73 USD в месяц — за сам кластер (здесь и далее все цены указаны без НДС);
255 USD — за один worker-узел с параметрами e2-standard-8 с 50 GiB Zonal standard PD в регионе europe-central2.
В расчет стоимости Managed Kubernetes от «Флант» включаем затраты на ВМ от Colocall. В общем получается:
1400 USD в месяц — за базовый кластер (production-кластер от Managed Deckhouse на статических ВМ без доступа к API облака);
153 USD — за три ВМ для управляющего слоя (Control Plane);
61 USD — за один worker-узел идентичной GKE конфигурации.
Теперь используем эти данные, чтобы показать, как меняются совокупные затраты на один Kubernetes-кластер с увеличением количества worker-узлов**:
** Примечание
Это ориентировочный расчет. Его достаточно, чтобы оценить примерную разницу в затратах и динамику расходов при росте кластера. Мы не знаем точные затраты robota.ua на инфраструктуру, поэтому опирались на актуальные расценки Google и Colocall без учета нюансов тарификации и политики скидок провайдеров.
На графике видно, что стоимость кластера в GKE на старте ниже. Но чем больше worker-узлов в кластере, тем дороже становится managed-сервис в целом.
Важная оговорка. Понятно, что GKE — это лишь часть огромной экосистемы Google Cloud. Она дает широкие возможности, решает большой объем задач, у нее высокая отказоустойчивость. Разные проекты используют эти возможности по-разному. В случае robota.ua команде нужен был только «голый» GKE, без дополнительных managed-сервисов — например, БД или мониторинга от Google. Поэтому миграция на другое решение managed Kubernetes оказалась целесообразной и простой. Однако в других случаях при оценке экономической эффективности переезда стоит учитывать все нюансы.
Технические плюсы
1. Более низкая latency. Сервисы robota.ua переехали из Европы в Украину, то есть ближе к основной аудитории. Это снизило задержку (latency) в общей сложности на 100 мс. Особенно явным эффект был у сервисов, время ответа у которых раньше составляло ~ 100 мс. В результате выиграли все — и пользователи, и сами сервисы.
2. Более функциональный K8s. По сравнению с KaaS-сервисами наш Managed Deckhouse подразумевает более широкую функциональность и гибкое управление кластером:
Вместе с «ванильным» Kubernetes пользователь получает преднастроенные модули для мониторинга, автомасштабирования, балансировки трафика и безопасного доступа. В случае KaaS все эти модули нужно устанавливать и настраивать самому.
Пример
Изначально robota.ua хотели настроить сбор логов в Loki с помощью Promtail. Но мы предложили более удобное решение, реализованное в Deckhouse, — модуль log-shipper. Сбор логов в модуле конфигурируется через создание Custom Resource с понятным и простым интерфейсом.
Большинство провайдеров в рамках managed-услуги отвечают только за компоненты управляющего слоя и обновляют только его; обновление остальных компонентов — на пользователе. Deckhouse же полностью управляет кластером и автоматически обновляет все его компоненты. При этом доступны разные каналы обновления.
Можно использовать внешнюю аутентификацию и авторизацию. Поддерживается OIDC.
Подробнее о возможностях платформы.
3. Независимость от поставщика ресурсов. Применительно к robota.ua одно из главных преимуществ, которое дает Deckhouse, — независимость от провайдера. Клиент может развернуть те же самые кластеры в любом облаке или на собственных серверах.
Заключение
Крупные зарубежные провайдеры отдают managed Kubernetes практически даром, основные расходы приходятся на ВМ. Когда кластер растет, можно сэкономить: например, переехать на более дешевые ВМ других провайдеров. Это позволяют платформы вроде Deckhouse. Пользователи такой платформы не занимаются низкоуровневым администрированием Kubernetes, а получают готовый API — по аналогии с тем, как это происходит в GKE, AKS или EKS. Такой вариант снижения затрат подходит, если нет другой привязки к сервисам крупного провайдера или когда понятно, как эту привязку преодолеть (пример — кейс нашего клиента Adapty).
В случае с robota.ua миграция прошла быстро и незаметно и для разработчиков, и для пользователей.
«Всегда, когда есть возможность использовать managed Kubernetes, именно его и нужно использовать».
Александр Марченко
CTO robota.ua
P.S.
Читайте также в нашем блоге:
«Как мы помогли cybersport.ru справиться с The International 10»;
«Переехать в Kubernetes и платить за инфраструктуру вдвое меньше? История Adapty»;
«Опыт миграции инфраструктуры клиента из AWS в Яндекс.Облако».
