🥹 Userspace Networking на Go: когда net уже не справляется

Салют! На связи Александр Демиденко, старший разработчик бэкенда в Yandex Cloud. Сегодня я расскажу, как мы научили Go работать с сетью практически напрямую с железом и уже на старте сэкономили сервису более 1000 ядер CPU.

Почему появилась такая задача? Давайте взглянем на Network Load Balancer. Чтобы сервис знал, куда можно направлять трафик, он должен постоянно проверять доступность пользовательских бэкендов через специальный механизм проверок здоровья. Мы развернули для этого целый кластер, который со временем разросся до нескольких сотен хостов.

Чтобы выполнить проверки здоровья, отдельная подсистема балансера формирует короткоживущие сессии до пользовательских сервисов. Но таких сервисов — сотни тысяч. А когда у нас столько же проверок, то это выливается в аналогичное количество TCP-хендшейков и HTTP-запросов. Время выполнения таких проверок начинает занимать сотни и даже тысячи миллисекунд, при этом просто так всё это не закешировать. А если мы тормозим, то клиентский сервис либо простаивает, либо получает трафик на мёртвый инстанс.

🔍 Как выяснилось, во всём виноват системный вызов socket(). Ядро тратит много времени на выделение структур для нового сокета. При этом Go runtime в ответ плодит тысячи потоков (M), что окончательно добивает планировщик ОС огромными очередями на шедулинг процесса.

Мы встали у развилки: заливать проблему железом и страдать дальше или уходить в хард-корный DPDK и прощаться с Go. В итоге выбрали третий путь — eBPF и AF_XDP.

🦾 Как это работает

🟢 XDP (eXpress Data Path) — программа на eBPF, которая перехватывает пакеты в самой ранней точке, сразу после драйвера сетевой карты

🟢 Наш «вышибала» на C проверяет пакет и, если это наш кандидат, перенаправляет его через XDP_REDIRECT в AF_XDP-сокет, а весь остальной трафик пропускает в стандартный стек ядра

🟢 AF_XDP — это мост в userspace. Пакеты попадают в общую область памяти (UMEM) без лишних копирований через специальные кольцевые буфера

🟢 В Go мы получаем сырой фрейм и далее передаём его для последующей обработки в сетевой стек, реализованный на Go и работающий в userspace

💹 В результате:

🟢 Количество проверок из расчёта на один хост выросло в два раза с примерно 1600 до 3300 в секунду

🟢 На том же железе время выполнения проверки сократилось с секунд до стабильных 20 миллисекунд (и это при двойной нагрузке)

🟢 Тысячи потоков (M) сменились десятками и перестали оказывать давление на шедулер ОС

🟢 Количество системных вызовов сократилось в разы

🟢 Более 1000 ядер CPU освободились для других задач

🔶 А полный доклад смотрите в записи трансляции Я.Субботника на ютубе и в VK Видео. Там я рассказываю, на какие грабли мы наступили в процессе оптимизации, показываю код на C и Go и отвечаю на вопросы из зала.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

🚗 Меняем колёса на ходу: как Авто.ру переезжал с MySQL на Yandex Database

Авто.ру — это сервис, который делает покупку и продажу автомобиля удобной, технологичной и безопасной. Он обрабатывает тысячи запросов в секунду, а внутри у него оркестр из бизнес-логики. Раньше сервис работал поверх шардированного MySQL, но масштабироваться на нём было трудно. Поэтому команда решила переехать на Yandex Database.

А как проходил переезд, с чем столкнулись по пути и как в процессе оптимизировали архитектуру всего сервиса, показывает Андрей Борунов, руководитель группы разработки базовых сервисов в Авто.ру.

В докладе Андрей рассказал:

🟢 Как команда преодолела ограничения по масштабированию для терабайта документов
🟢 Что лежит под катом сердца Авто.ру — системы хранения и процессинга объявлений
🟢 Как ребята разработали движок поверх YDB для распределённой обработки объявлений десятками воркеров с бизнес-логикой

📺 Смотрите полный доклад Андрея с DUMP 2025:

🟢 На ютубе
🟢 В VK Видео

📟 Кому советуем посмотреть: разработчикам и архитекторам высоконагруженных систем, скалистам и всем, кто думает о масштабировании своих сервисов.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend

🧬 Во сколько раз увеличится RPS на ручку поллинга, если уменьшить интервал поллинга с 5 минут до 2?

В 2,5 раза!

👨‍💻 На связи Степан Карпов, бэкенд-разработчик в Яндекс Go. Делюсь кейсом, который научил нас внимательнее подходить к планированию ресурсов под поллинговые ручки.

Мы хотели ускорить сетевую диагностику в приложении, а для этого уменьшили интервал запросов с 5 минут до 30 секунд. Логично предположить: раз клиенты стали ходить в 10 раз чаще, то и нагрузка вырастет в 10 раз. Мы подготовили инфраструктуру под 50 000 RPS, но после релиза увидели лишь 25 000.

Оказалось, что наша модель была слишком простой. На масштабе миллионов пользователей поведение системы описывается не линейной, а более сложной зависимостью. А чтобы понять её, мы построили вероятностную модель, основанную на времени жизни сессии пользователя.

❇️ Что мы вынесли из этой ситуации:

🟢 На больших масштабах простые умножения могут давать ошибку в несколько раз

🟢 Чтобы планировать ресурсы, нужно учитывать паттерны использования приложения

🟢 Даже базовая вероятностная модель помогает избежать серьёзных просчётов

🔶 В статье на Хабре я подробно рассказываю, как мы пришли к формуле прогноза RPS и как проверили её в экспериментах.

Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend