Yandex for Backend

⚪️ Принципы разработки в Яндекс 360 Всем привет, это Илья Иванов, руководитель группы разработки В2С-сегмента Биллинга. В Яндекс 360 наш сервис отвечает за все домены, которые связаны с монетизацией. Мы управляем тарифами и акциями, рекуррентными подписками и обеспечением выдачи услуг. 💹 В команде бэкенда Яндекс 360 разработчик не только пишет код, но и отвечает за архитектуру целых проектов и фич. А ещё мы думаем о продуктовой ценности для пользователя. Ключевой ресурс в наших командах — это доверие. Его можно заслужить, если делать качественные проекты и повышать их сложность. А чем выше уровень доверия к определённому разработчику или тимлиду, тем больше у него возможностей проявить себя. Об этом недавно читал доклад лид нашего бэкенда Роман Акинфеев. 👩‍⚕️ В карточках я рассказал, как сложился мой путь и почему мне понравилась культура в бэкенде Яндекс 360. 🔶 Подробности можете прочитать в блоге о работе в Яндексе Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🚀 Погружаемся в технологии на deep tech night 5 сентября пройдёт deep tech night — масштабная онлайн-конференция Яндекса о технологических вызовах, с которыми IT-индустрия сталкивается в эпоху AI: от изменений в разработке до новых требований к архитектуре и инфраструктуре. Это событие для опытных бэкенд-разработчиков, техлидов, инженеров и всех, кто работает в IT-индустрии, внедряет AI в процессы, проектирует сложные системы и ищет новые решения. Сфокусируемся на архитектуре в эпоху AI: 🟢 Роль разработчика и как она меняется 🟢 Ревью агентского кода, масштабирование и поддержка качества 🟢 Подходы к работе с большими базами данных 🔶 Зарегистрироваться Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🚘 Семь раз подумай, один раз пошардируй Меня зовут Никита Звонарёв, я разработчик в Яндекс 360. Сегодня расскажу, как мы горизонтально масштабировали метаданные чатов Телемоста, когда нагрузка пробила 650 000 запросов в секунду и PostgreSQL перестал с ней справляться. Бэкенд чатов Телемоста — это единое платформенное решение для всей экосистемы Яндекса. Каждая доставка еды, каждая поездка на такси требует создания нового чата с уникальным составом участников, метаданными и конфигурацией. Дополнительная нагрузка от инфраструктурных сервисов вдобавок к самому контуру Телемоста привела к тому, что мы упёрлись в потолок вертикального масштабирования мастер-ноды по CPU и дисковому I/O. А свободное место на SSD-массивах таяло на глазах. ➖ Нам стало очевидно: нужно кардинально перестроить архитектуру работы с СУБД и распилить монолитную базу на шарды, чтобы бэкенд не сломался под весом экосистемного трафика. ❇️ Что мы сделали 1️⃣ Выбрали ключ шардирования — chat_id Связи между нашими сущностями можно представить в виде трёхмерного куба, где грани — это пользователи, организации и чаты. Шардирование по первым двум не подходило. В одном случае (user_id) создание чата на 10 человек потребовало бы синхронной записи в 10 разных шардов, а в другом (org_id) — мы не покрыли бы наш огромный В2С-контур и сквозные экосистемные интеграции. Так что остановились на чатах (chat_id). Это дало нам локализацию дискового пространства и атомарность транзакций — все данные одного чата теперь лежат на одном физическом шарде. А главное — мы полностью избежали распределённых пишущих транзакций. 2️⃣ Внедрили строковый «Шарпей» для маршрутизации Мы пошли по пути хранения жёсткого маппинга chat_id → shard_id. И для этого задействовали альтернативную конфигурацию сервиса из Почты — строковый «Шарпей». Это дало нам мгновенное горизонтальное масштабирование: когда мы видим, что место на текущих физических шардах заканчивается, мы просто добавляем в кластер новые, а «Шарпей» начинает аллоцировать свежие чаты туда. Старые данные при этом вообще не сдвигаются с места — никакого решардирования. 3️⃣ Перестроили архитектуру и запретили прямой доступ к СУБД для сторонних компонентов Наш CRUD-сервис (Registry) и сервис обработки сообщений (Fanout) теперь не просто ходят в Postgres напрямую. Они перед каждым обращением к БД за шардированными данными выполняют легковесный запрос в строковый «Шарпей», чтобы узнать, какой именно физический шард обслуживает целевой chat_id. Сервисы, которые раньше самостоятельно читали данные из базы, теперь полностью изолированы от сервиса хранения. Для них мы реализовали специализированные эндпойнты внутри Registry. В результате топология упростилась. Прямой доступ к инстансам PostgreSQL сохранили только три компонента: Registry, Files (аналог Registry для работы с файлами в сообщениях) и Fanout. 🔶 Читайте больше подробностей в статье на Хабре. Там я также поделился ключевыми инсайтами, которые помогли нашей команде успешно решить этот крупный сдвиг в архитектуре данных без даунтайма и потери консистентности. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🤖 Когда код не управляет логикой: observability для AI-агентов На связи Даниэль Халиулин, технический менеджер в Yandex Infrastructure. Сейчас AI-агенты развиваются и интегрируются в сервисы с огромной скоростью. Но если не контролировать их работу, последствия могут быть неприятными. Представьте ситуацию: очень важный AI-агент сломался прямо в проде. Инфраструктурные метрики при этом горят зелёным, а в логи заглядывать страшно. Как понять, почему агент стал галлюцинировать? На какие данные смотреть, как и где их хранить? Что делать, когда привычные метрики теряют актуальность? 👩‍⚕️ В карточках я разобрал, что значит observability AI-агентов, почему трейсы сменяют логи и какие инструменты можно использовать для мониторинга. 🔶 А в полном выступлении на infra.conf’26 я рассказал обо всём подробнее. Смотрите доклад на сайте или на ютубе. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🔡 Как мы научили реляционную базу хранить оргструктуру на 500 000 пользователей Представьте: пользователь добавляет одного сотрудника в группу где-то в глубине иерархии и почти минуту смотрит на лоадер. А запрос показать список всех участников и вовсе роняет базу по тайм-ауту. Именно так вела себя наша старая схема хранения оргструктуры. Речь о Директории — компоненте B2B-платформы Яндекс 360, который отвечает за жизненный цикл организаций и служит единым источником истины об их оргструктуре для других сервисов. Меня зовут Малик Минубаев, я занимаюсь развитием B2B-платформы в Яндекс 360. Хочу рассказать, как мы пересобрали архитектуру хранения оргструктуры. ❇️ В поисках идеального паттерна Наша оргструктура состоит из двух сущностей: 1️⃣ Подразделения — это строгое дерево, у каждого только один родитель 2️⃣ Группы — это направленный ациклический граф, который может входить в любое количество других групп и организационных сущностей Специфика системы такова, что читающих операций у нас в сотни, а иногда и в тысячи раз больше, чем пишущих. Оргструктура для нас — это графы и деревья с колоссальным преобладанием операций чтения. Именно скорость обхода графа вглубь — это наш приоритет. Но обычным тюнингом или поднятием лимитов в конфигах обойтись было нельзя, потому что системе требовалось новое хранилище. Мы перебрали классические древовидные паттерны: Adjacency List, Materialized Paths, Nested Sets, но они не умеют работать со структурой групп, где один объект может входить в несколько контейнеров. ➖ У нас осталось два кандидата: Bridge Table и Closure Table. Но листинг состава групп на верхних уровнях вложенности занимает около 20 секунд — это непозволительная роскошь для высоконагруженного B2B-сервиса. Так мы окончательно убедились, что нужно использовать Closure Table. Но его классические варианты и академические оптимизации либо отлично работают на запись, но проваливают удаление рёбер, либо эффективно обрабатывают удаление, но плодят дубликаты, которые намертво вешают чтение через DISTINCT. 💡 И мы поняли: необходимо собственное архитектурное решение. Нам нужно было убрать дубликаты на уровне схемы данных, но при этом сохранить возможность легко перестраивать граф при удалении рёбер. 🔶 Читайте подробности в статье на Хабре. Там я рассказал, какое решение мы придумали, зачем разделили архитектуру хранения на два слоя и как нам удалось выкатить такое масштабное изменение в прод без даунтаймов. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🧬 Инженерная кухня SPQR На связи Денис Волков из команды платформы данных в Yandex Cloud. Мы занимаемся разработкой опенсорс-системы SPQR, которая облегчает переезд на шардированную инсталяцию. Хочу немного рассказать о нашем решении: как мы к нему пришли и что под капотом. 🤔 Нам было нужно построить систему, которая: общается с приложением по протоколу PostgreSQL, позволяет докидывать шарды на лету и держит метаданные о распределении данных в оперативной памяти. А ещё не разваливается, если один ключ приносит непропорционально большую нагрузку, и умеет всё это делать без даунтайма. Из каких блоков собран SPQR: 🟢 Роутер. Принимает клиентские подключения, разбирает запрос, находит нужный диапазон и отправляет запрос на шард. Сам данные он не перевозит 🟢 Координатор. Управляет метаданными и выполняет длинные операции: создаёт задачи перевоза, ведёт их состояние, двигает данные и переключает маршрутизацию 🟢 QDB на базе etcd. Хранит общие метаданные: distributions, key ranges, lock state, а также промежуточное состояние длинных операций 🟢 Балансер. Отдельная утилита, которая смотрит на состояние шардов, ищет перекосы нагрузки и инициирует перевозы там, где они нужны Если коротко: роутер маршрутизирует запросы, координатор перевозит данные, QDB хранит состояние, а балансер решает, что пора двигать. 💹 Как выглядит алгоритм роутинга: 1️⃣ Приходит SQL-запрос 2️⃣ Роутер вытаскивает из него ключ шардирования 3️⃣ Если используется хеш-шардирование, ключ сначала прогоняется через хеш-функцию 4️⃣ Полученное значение ищется в таблице диапазонов 5️⃣ По диапазону находится шард 6️⃣ Запрос уезжает на нужный PostgreSQL-кластер 🔶 В статье на Хабре я рассказал ещё больше подробностей о том, как мы построили эту систему, зачем SPQR оперирует key range, как координатор перевозит данные маленькими кусками и как балансировщик понимает, что именно надо двигать. А также поделился компромиссами и граблями, которые встретились нам по дороге. 👀 Если хотите проверить подход на своих нагрузках без самостоятельной сборки — попробуйте Managed Service for Sharded PostgreSQL. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend

🟢 Поможем подготовиться к собесу и прокачать резюме Мы перезапускаем наш MVP-проект с бесплатными карьерными консультациями для разработчиков от опытных рекрутеров Яндекса. Приходите к нам, а мы поможем с резюме или профилем LinkedIn, расскажем о наших карьерных треках и ответим на все интересующие вопросы о наймовых процессах в IT. Кого зовём: бэкенд-разработчиков уровня мидл+ с опытом от 3 лет. Как всё устроено: 🟢 Отправляете заявку 🟢 Выбираете удобную дату и время 🟢 Узнаёте всё, что хотели, на 45-минутном созвоне 🔶 Узнать подробности и отправить заявку Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend