Mail.ru Cloud Solutions
Назад к кейсам

Goodt: как мы без проблем перенесли 200 серверов в облако MCS и почему нацелены на Kubernetes

Компания
Goodt
Отрасль
HR-tech
Количество клиентов
20 проектов в промышленной эксплуатации
10 активных пилотов
Алексей Колганов
«Goodt», технический директор

Goodt — HR-tech платформа с набором инструментов для компаний с высокой долей массового персонала. Для обслуживания крупных клиентов и поддержки собственных IT-продуктов компании требуются значительные вычислительные ресурсы, а также возможность гибко и быстро управлять ими.

Как Goodt мигрировали в облако MCS, получили в России облачные сервисы мирового уровня и планируют сэкономить до 45% на ресурсах с помощью Kubernetes, расскажет Алексей Колганов, технический директор Goodt.

Goodt — HR-tech-платформа для крупных компаний

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

На платформе Goodt доступны такие HR-инструменты:

  1. Time определяет, сколько и какого персонала надо вывести на точку, и строит сотрудникам персональные смены. Здесь используется Machine Learning и нейронные сети.
  2. Clock — учет присутствия сотрудников на работе. Здесь используем биометрию, распознаем лица сотрудников на видео, отмечаем, кто пришел на работу, а кто нет.
  3. Robusta — геймификация и мотивационные программы, которые стимулируют сотрудников достигать нужных показателей.
  4. Insight — инструмент HR-аналитики, который позволяет контролировать динамику бизнес-показателей и эффективность запущенных решений.

Мы изначально ушли в облака и не планировали строить свою инфраструктуру

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

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

Первый шаг к PaaS: почему для разработки мы выбрали Kubernetes

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

Мы понимаем, что будущее технологий за готовыми облачными платформенными сервисами (PaaS) — они дают множество преимуществ: быстрое внедрение, экономия, увеличение скорости разработки IT-продуктов. Не все наши клиенты готовы к облачным сервисам, часть наших решений находится в on-premise, и это ограничивает нас в возможностях использовать облако, например, в частной инфраструктуре клиенты подключают классические базы данных, а не DBaaS. Мы планируем в будущем обходить эти ограничения, поэтому сразу строили разработку на Kubernetes как сервис, который позволяет нам и обслуживать on-premise решения, и использовать в дальнейшем другие PaaS-сервисы.

В целом, наша разработка построена как классический CI/CD: на нашей стороне облачный Kubernetes, Jenkins для сборки приложений и Artifactory для хранения сборок. Любое обновление собирается, разворачивается на среды разработки, запускаются автотесты. Затем тестирование в клиентском staging-окружении.

Если приложения и обновления требуется передавать в on-premise, передаём их в контейнерах, логика работы Kubernetes позволяет их потом без проблем развернуть в частной инфраструктуре.

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

Первоначально для инфраструктуры мы выбрали облачную платформу Google Cloud Platform, использовали Kubernetes как сервис. Потом возникли ограничения, связанные с выполнением 152-ФЗ, требующим, чтобы данные российских клиентов находились в России. Нам пришлось искать российского провайдера.

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

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

Некоторое время мы были вынуждены использовать площадки разных провайдеров, которые, с одной стороны, были сертифицированы по 152-ФЗ, а с другой стороны — давали возможность предоставлять нашим клиентам нужные услуги. Но здесь была одна большая проблема — такой разрозненной инфраструктурой сложно управлять.

Почему MCS оказалась для нас лучшей российской облачной платформой

Мы стали искать провайдера, к которому смогли бы перенести всю инфраструктуру. Каждый вариант мы оценивали с точки зрения портфолио услуг, планов по развитию — искали полное совпадение с нашими потребностями. Так пришли к Mail.ru Cloud Solutions — эта платформа смогла дать нам привычные возможности и гибкое управление.

Здесь есть сервисы, которые мы используем сейчас, и те, что нам потенциально интересны: базы данных, интеграционные API. Сейчас мы используем облачные вычисления и Kubernetes как сервис от Mail.ru. Смотрим в сторону специальных баз данных, может быть, Tarantool.

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

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

Еще один важный нюанс связан с обновлениями и мониторингом для клиентов, у которых наш продукт находится on-premise. У нас есть комплекс средств для автоматического развертывания обновлений, мы умеем поставлять сборки готовыми контейнерами. Для этого требуется удалённый доступ среды разработки в облаке к on-premise инфраструктуре. Клиенты идут на это, поскольку у них есть доверие к Mail.ru как к значимому игроку на российском рынке.

Как Kubernetes помог мигрировать на облако MCS без проблем и простоев

За два месяца мы перенесли на платформу Mail.ru Cloud Solutions порядка 200 серверов. Это был глобальный переезд, переезжали и те серверы, которые работают в продакшене на российских платформах, и та инфраструктура, что находилась на Google Cloud Platform.

Миграция из Google, где мы также использовали Kubernetes как сервис, проходила бесшовно и без простоев — просто поочередно переносили решения клиентов с помощью скриптов.

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

Мигрировали самостоятельно, в процессе все инсталляции, которые мы сделали, работали стабильно, нареканий никаких нет.

Какие преимущества мы получили и почему ожидаем от облака MCS экономии до 45% на ресурсах и ускорения обновлений в 7 раз

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

При этом мы ничего не потеряли по уровню сервиса — по качеству Mail.ru Cloud Solutions никак не уступает западным компаниям, в отличие от многих других российских платформ. Есть сервисы, которые мы в принципе не могли бы получить в другом месте, например Kubernetes как сервис — у большинства российских провайдеров есть только классические виртуальные машины.

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

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

Мультитенантность позволит ускорить обновления. Сейчас на каждого клиента приходится несколько инсталляций, разные виды контуров: стейдж, девелопмент, продакшен. После выхода каждого релиза нужно обновлять весь парк: мы тестируем обновление на нескольких клиентах, потом выкатываем на всех. Этот процесс растянут до 1-2 недель, даже с готовыми наборами инструментов автоматизации. После перехода к мультитенант-архитектуре мы уменьшим количество инсталляций, а значит — ускорим обновления до 1-2 дней.

Мы продолжаем двигаться в сторону облачных решений

Ранее мы не использовали облачные базы данных, так как их нельзя развернуть у клиента в их имеющихся on-premise контурах. Но в этом году мы добавляем к нашему решению адаптеры. Если клиент захочет развернуть продукт в своей инфраструктуре, мы так же, как сейчас, подключим ему классическую базу данных. Но зато при развертывании в публичном облаке сможем использовать DBaaS, например — на MCS.

Когда нам понадобятся сервисы для работы с большими данными, мы будем использовать Hadoop в виде облачного сервиса, чтобы не заниматься его администрированием. Еще один интересный сервис — Machine Learning, мы уже пробовали такие решения от Google. У нас есть два направления: первое — обучение нейронных сетей и построение с их помощью прогнозных моделей, второе — видеобиометрия, компьютерное зрение, распознавание лиц. Здесь у нас есть собственные наработки, но мы открыты ко всему новому, в том числе к сторонним сервисам.

Основные результаты миграции для бизнеса

  1. Соблюдение норм российского законодательства, в частности 152-ФЗ.
  2. Доступ к облачным сервисам, позволяющим экономить на ресурсах и ускорить разработку, в том числе Kubernetes как сервис.
  3. Возможность построить мультитенант-архитектуру при обеспечении нужного уровня безопасности и сократить расходы на инфраструктуру до 45%.
  4. В перспективе — ускорение обновлений решений компании, предоставляемых клиентам, в 7 раз.

Зарегистрируйтесь и попробуйте сервисы бесплатно

Если бонусов для тестирования не хватит - оставьте заявку, мы начислим еще или предложим полноценный пилот.

21 год
опыта поддержки высоконагруженных сервисов
100+ млн
пользователей по всему миру
7 лет
экспертизы развития облачной инфраструктуры