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.
Читайте также в нашем блоге:
Комментарии (19)
arround
29.12.2021 13:57Очень странное решение. Компания четко просчитала риски связанные с переездом в облако мелкого провайдера? Маски-шоу вроде как запрещены, но никто не застрахован, что могут отрубить часть инфры или вывезти пачку серверов. Также как быть со скейлингом - если резко возрастет нагрузка, а у провайдера не будет ресурсов.
konstantin_axenov Автор
29.12.2021 17:01+3Все эти риски естественно присутствуют. Также если говорить, например, про РФ, есть риски, что будут блокировки иностранных облаков со стороны Роскомнадзор. Или есть разные федеральные законы, которые могут создать проблемы с использованием облачных услуг у иностранных поставщиков.
В статье мы постарались дать понимание, что "стоимость вм" - это один из факторов, который стоит учитывать. Скейлинг и отказоустойчивость - это сильные преимущества Google Cloud.Важная оговорка. Понятно, что GKE — это лишь часть огромной экосистемы Google Cloud. Она дает широкие возможности, решает большой объем задач, у нее высокая отказоустойчивость. Разные проекты используют эти возможности по-разному. В случае robota.ua команде нужен был только «голый» GKE, без дополнительных managed-сервисов — например, БД или мониторинга от Google. Поэтому миграция на другое решение managed Kubernetes оказалась целесообразной и простой. Однако в других случаях при оценке экономической эффективности переезда стоит учитывать все нюансы.
Одним из преимуществ Deckhouse и услуги, которую мы предоставляем на базе этой платформы, является одинаковый для пользователя Kubernetes. Таким образом, если возникнут проблемы с текущим провайдером, то мы достаточно легко перевезём кластера клиента к другому. Это частично защищает от указанных рисков.
gecube
30.12.2021 01:31+3вы абсолютно правы, только вот интересно (техническая деталь) - в GKE кластера размазаны были по разным AZ и были толерантны к отказу одного провайдера/ЦОДа гугла и пр.? В случае же некоего украинского провайдера есть высокая степень вероятности, что уровень отказоустойчивости будет просто на порядки ниже. Простой пример - заказали Вы ВМки, накатили на них кластер, ВМки попали неудачным образом на один гипервизор. Он шлепнулся. Кубернетес нам не помог. Потому что сам валяется. А про топологию под капотом они ничего не знает. Или. ВМки попали на разные гиперы, но в рамках одной стойки или одного СХД. Стойка обесточилась или на нее сверху протек кондиционер, или СХД отказало. Опять же - вроде кубер есть, только толку? Как решали в этом случае эту проблематику?
konstantin_axenov Автор
30.12.2021 13:19Я полностью согласен, что в облаке небольшого провайдера отказоустойчивость на порядок ниже, чем у Google или AWS. К сожалению, в данном публичном облаке Colocall у нас нет возможности управления распределением вм по гипервизорам. Таким образом, мы даже не можем гарантировать, что ноды control-plane находятся на разных гипервизорах или тем более на гипервизорах в разных стойках. Этот тот риск, который надо обязательно брать в расчёт.
Если говорить в целом про небольших провайдеров, то у многих помимо публичного облака есть услуга приватного облака. Тут ситуация лучше, так как они обычно выделяют гипервизоры в разных стойках. Таким образом, мы закрываем часть проблем. Но если уж отказало СХД, то, скорее всего, это будет фатально. Опять же такие приватные облака обходятся дороже, чем публичные. Решение и принятие рисков здесь полностью на стороне бизнеса.
ReDev1L
29.12.2021 15:40А спот инстансы рассматривали?
konstantin_axenov Автор
29.12.2021 16:48+1Спот инстансы подходят не всем клиентским приложениям, но это действительно один из лучших способов сэкономить. Также можно рассмотреть "1 year commitment" или "3 year commitment" планы. Перед компанией Флант не ставилась задача уменьшения стоимости эксплуатации GKE, поэтому тут, к сожалению, не можем привести точного расчёта экономической составляющей, которая привела к переезду.
andreyverbin
29.12.2021 20:227 миллионов визитов в месяц, положим каждый по 10 минут. Примерно 27 активных визитов в секунду. Кажется тут надо не с GKE уезжать, а что-то оптимизировать.
Cloud66
29.12.2021 20:34В 1400usd входит обслуживание кластера deckhouse и цена обслуживания не зависит от кол-ва нод?
EvgenySamoylov
29.12.2021 21:40На самом деле зависит. По ссылке есть калькулятор, который показывает, что 10 VM входят в стоимость обслуживания сразу, а каждая последующая добавляет $20 к стоимости. Если посмотреть на красную линию на графике (а лучше не просто посмотреть, а приложить лист бумаги например;), то можно заметить, что линия переламывается и после десятой ноды цена начинает расти быстрее.
gecube
30.12.2021 01:28+1очень жаль, что не расписали как мигрировали оставшиеся сервисы - кафка и все то, что не в кубернетесе. Потому что гонять трафик через полинтернета такое себе решение.
allexx
30.12.2021 08:32+1Понятно что статейка рекламная, чтобы показать "flant deckhouse" (свой как бы дистрибьютив), но судя по всему даже нет возможности сконфигурироваться с eBPF и/ calico-cni.
gecube
30.12.2021 11:43+2свой как бы дистрибьютив
Почему "как бы"? Вполне себе дистрибутив. Ранчеру можно, а Фланту нельзя? Да ещё и CNCF сертификацию прошли...
Другой вопрос, что дистрибутив дистрибутиву рознь, а я просто не успел все ещё пощупать, что там ребята накодили. Но по спецификации выглядит... интересно
судя по всему даже нет возможности сконфигурироваться с eBPF и/ calico-cni.
ну, это просто говорит, что продукт пока в активной стадии разработки (Окей, можно сказать, что "сыроват", но у кого нет проблем и недоработок)
ybonar
В это истории не совсем понятно:
Почему изначально при выборе решение был выбран GKE понимая что основной продукт компании в основном для рынка Украины и если задержки критичны то размещаться изначально нужно было в Украине. Интересно чем тогда руководствовались.
Я более чем уверен что и раньше стоимость GKE была выше чем собственный сервер в ДЦ в Украине. Получается что тогда кто-то решил за деньги компании получить для себя и команды опыт работы с GKE?=)
Насколько текущее решение с прицелом на будущее а не решение текущей проблемы? Основная мотивация всей затеи снижение затрат на k8s? ЗП одного инженера с лихвой может перекрывать траты на инфру)
shurup
На первый вопрос логичным ответом звучит то, что еще тогда сразу требовалось managed-решение:
А из чего было выбирать в самой Украине?..
По третьему вопросу: график хорошо показывает, что с ростом кластера затраты на текущий вариант Kubernetes'а становятся только выгоднее (по сравнению с managed-решением от крупного провайдера). Если говорить про сравнение с зарплатой, то ведь логично (раз сейчас всё устраивает), что и инженер из-за растущей инфраструктуры: а) понадобится позже, б) будет решать более высокоуровневые задачи по инфре, оставив низкий уровень платформе Deckhouse (об этом был такой наш доклад).
ybonar
Да немного пока писал комент потерял инфу. Спасибо что указали.
В Украине и сейчас получается не из чего выбирать) Я как бы локальный рынок Украины знаю еще с 2000 годов когда занимался телекомом и на моих глазах росли сети и так называемые "серверные". Игроки одни и те же остались по сути) Тот же collocal как был тогда так и сейчас есть.
У меня все так же остаются вопросы и их много. А так спасибо за работу и за продвижение технологий)
konstantin_axenov Автор
Я бы добавил, что GKE - это самый логичный и быстрый способ попробовать Kubernetes. Многие компании, особенно стартапы, делают такой первый шаг, чтобы понять, на сколько Kubernetes подходит им и решает их проблемы. А дальше уже начинают возникать вопросы с урезанием стоимости инфраструктуры.