Миграция без права на ошибку: как перенести 70 кластеров MongoDB в 7 и не сломать продакшен

В сфере искусственного интеллекта произошло заметное событие. onurimanov 9 минут назад Миграция без права на ошибку: как перенести 70 кластеров MongoDB в 7 и не сломать продакшен 12 мин 174 Блог компании Яндекс MongoDB * Высоконагруженные системы * Серверная оптимизация * Базы данных * Разворачивать новый кластер базы данных каждую неделю — так себе удовольствие, особенно когда обслуживание десятков кластеров съедает время дежурных. Когда кластеров стало много, локальные аномалии стало сложнее замечать на общих дашбордах. С этой проблемой мы столкнулись в Яндекс Трекере: за год количество активных организаций и кластеров выросло вдвое, а нагрузка на сервис поднялась всего на 13%.

Получилось парадоксально: потребление ресурсов и сложность эксплуатации росли вместе с числом организаций, хотя реальная нагрузка увеличивалась значительно медленнее. Меня зовут Олег Нуриманов, я старший разработчик в Яндекс 360. В статье расскажу о том, как мы ушли от модели «одна организация — одна база», сократили число бэкенд‑кластеров с 70 до 7 и снизили потребление ресурсов в 2 раза.

Технические детали

Бывшая архитектура Яндекс ТрекераДля хранения данных в Яндекс Трекере мы используем Yandex StoreDoc — наш внутренний аналог MongoDB® Atlas (дальше я буду писать просто MongoDB). Исторически модель хранения строилась по схеме «одна организация — одна база данных». Почему эта модель была удобна: Естественная изоляция: данные организаций разделены по разным базам.

Крупной организации можно легко выделить персональный кластер. Разработчик работает с базой организации, как будто она одна, и ему не нужно учитывать мультитенантность. Простое управление данными организации: легко делать полный бэкап данных организации и изолированно восстанавливать отдельные организации.

Предыдущая модель разделяла данные организаций по разным базам; при необходимости организации можно было дать собственный кластер. В модель входили следующие ключевые компоненты:Фронтенд и Public API принимали внешние запросы пользователей и интеграций. Балансер запрашивал у Координатора маппинг организации на нужный бэкенд и маршрутизировал туда входящие запросы от Frontend и Public API.

Отраслевые последствия

Координатор выбирал наиболее свободный кластер, чтобы разместить новые организации, и управлял жизненным циклом организации на кластере. Кластеры бэкенда обрабатывали бизнес‑логику; при этом под каждый отдельный кластер MongoDB заводился свой кластер бэкенда. Хранилище (MongoDB / Yandex StoreDoc) — каждая организация жила в отдельной базе данных, примерно по 110 коллекций на организацию, а один кластер Mongo содержал несколько сотен таких баз.

Схема бывшей архитектуры ТрекераНо у этой схемы была неприятная обратная сторона — ограничение MongoDB на количество коллекций.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.