Yubo: инфраструктура на 80 млн силами 5 инженеров

Бэкенд-инфраструктура Yubo состоит примерно из 300 рабочих нагрузок и 50 баз данных, распределённых по нескольким дата-центрам. Каждый дата-центр выполняет свою специализированную роль:

И, разумеется, эта конфигурация воспроизводится в наших средах разработки (staging и integration).

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

Пока большинство команд говорит об автоматизации, мы идём на шаг дальше — к шаблонизации автоматизации. При более чем 300 рабочих нагрузках и 50 базах данных на 8 различных СУБД-технологиях шаблонизация необходима для поддержания эффективности. Мы используем инструменты, которые дают разработчикам возможность самостоятельно управлять такими ресурсами, как базы данных и сервисы, устраняя узкие места и ускоряя выкатку новых функций.

В нашей инфраструктуре ключевые компоненты, такие как дата-центры, описываются с помощью Custom Resource Definitions (CRD), которые фиксируют важнейшие сведения — CIDR подсети, CIDR диапазона подов и CIDR сервисов. Более того, даже коллекции и индексы баз данных моделируются как CRD, что отражает наш упор на согласованность и автоматизацию.

Несколько месяцев назад произошёл серьёзный сдвиг: мы начали переиспользовать компоненты Yubo для создания новых приложений, и это совпало с приобретением Terraform компанией IBM. Для нашей команды инфраструктуры это стало отличной возможностью уйти от Terraform и перейти на Google Config Connector, что позволило нам управлять инфраструктурой в виде YAML-шаблонов.

Сегодня все наши ресурсы в GCP управляются через YAML-шаблоны, что даёт нам больше контроля над облачной инфраструктурой. Кроме того, наши мониторы Datadog тоже описаны шаблонами в YAML — благодаря Datadog Operator, — что упрощает процессы мониторинга.

Системы шаблонизации, такие как Argo Workflow, ytt и Helm, играют ключевую роль в нашей работе. Эти инструменты позволяют проектировать каждую часть системы с прицелом на кастомизацию и гибкость, благодаря чему наша инфраструктура развивается вместе с нашими уникальными задачами.

Например, ArgoCD использует Helm для управления рабочими нагрузками Kubernetes, тогда как Argo Workflow шаблонизирует наши CI/CD-пайплайны, cron-задачи и задачи автоматизации, а шаблонизацию YAML обеспечивает ytt. Google Config Connector, в свою очередь, отвечает за провижининг облачных ресурсов.

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

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

Argo Workflow позволяет нам оркестрировать сложные процессы внутри Kubernetes, а также все наши пайплайны непрерывной интеграции. Будь то зависимые задачи или сложные пакетные процессы, Argo берёт на себя самую тяжёлую работу при минимальной сложности.

По сути, все наши CI и workflow — это экземпляры Argo Workflow Templates, что позволяет переиспользовать их бесконечно и заметно ускоряет настройку CI для новых приложений.

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

И, чтобы замкнуть круг, даже сам наш стек Argo Workflow — это приложение ArgoCD.

Наша инфраструктура спроектирована для динамического масштабирования и легко справляется с колебаниями трафика благодаря Kubernetes HPA и кастомным метрикам. Но иногда этого недостаточно.

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

Несмотря на небольшую команду, мы используем разнообразный технологический стек. По сути, мы считаем, что ОДНА технология — это ОДИН ответ на ОДНУ задачу. Поэтому мы не ограничиваем разработчиков в выборе языка и не ограничиваем выбор баз данных под конкретные функции. Мы верим в использование правильного инструмента для задачи, а не в ограничение себя несколькими технологиями. Эта философия распространяется и на базы данных: мы выбираем наиболее подходящую, исходя из модели данных каждой функции и требований к масштабированию.

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

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

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

Мы также применяем стратегию двойной отправки (dual shipping) для логов и метрик, чтобы обеспечить резервирование на случай сбоя.

Сбои неизбежны при эксплуатации столь сложной системы. В Yubo мы относимся к сбоям как к возможности чему-то научиться. Проводя тщательные post-mortem-разборы, мы постоянно совершенствуем свои процессы и развиваемся с каждым новым вызовом.

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

Обслуживать 80 миллионов пользователей и при этом сохранять экономическую эффективность — задача не из лёгких. Мы внедрили несколько стратегий, чтобы держать расходы под контролем:

Постоянное внимание к оптимизации ресурсов позволяет удерживать расходы на низком уровне, сохраняя высокую производительность.

Управление инфраструктурой на 80 миллионов пользователей силами всего пяти человек — это балансирование между автоматизацией, обменом знаниями и непрерывным улучшением. Экспертиза нашей высококвалифицированной команды — ключ к успеху, но по мере роста мы намерены привлекать новые таланты и уравновешивать команду джуниорами, сохраняя соотношение senior к junior на уровне 4:1.

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