Yandex for Backend
Ir al canal en Telegram
Канал для бэкендеров от Яндекса. Рассказываем про события по Python, Go, Java и C++ и не только, делимся экспертизой, обсуждаем технологии и поддерживаем бэкенд-комьюнити. Другие каналы Яндекса по стекам разработки: https://t.me/addlist/Hrq31w2p1vUyOGZi
Mostrar más9 857
Suscriptores
+124 horas
+127 días
+12230 días
Carga de datos en curso...
Canales Similares
Nube de Etiquetas
Menciones Entrantes y Salientes
---
---
---
---
---
---
Atraer Suscriptores
julio '26
julio '26
+145
en 3 canales
junio '26
+190
en 2 canales
Get PRO
mayo '26
+249
en 3 canales
Get PRO
abril '26
+333
en 0 canales
Get PRO
marzo '26
+282
en 3 canales
Get PRO
febrero '26
+311
en 2 canales
Get PRO
enero '26
+240
en 0 canales
Get PRO
diciembre '25
+359
en 5 canales
Get PRO
noviembre '25
+586
en 7 canales
Get PRO
octubre '25
+474
en 2 canales
Get PRO
septiembre '25
+203
en 3 canales
Get PRO
agosto '25
+144
en 2 canales
Get PRO
julio '25
+131
en 0 canales
Get PRO
junio '25
+236
en 0 canales
Get PRO
mayo '25
+181
en 0 canales
Get PRO
abril '25
+231
en 1 canales
Get PRO
marzo '25
+94
en 0 canales
Get PRO
febrero '25
+121
en 0 canales
Get PRO
enero '25
+179
en 0 canales
Get PRO
diciembre '24
+312
en 4 canales
Get PRO
noviembre '24
+399
en 3 canales
Get PRO
octubre '24
+165
en 0 canales
Get PRO
septiembre '24
+242
en 0 canales
Get PRO
agosto '24
+327
en 8 canales
Get PRO
julio '24
+173
en 3 canales
Get PRO
junio '24
+1 438
en 6 canales
Get PRO
mayo '24
+112
en 0 canales
Get PRO
abril '24
+393
en 1 canales
Get PRO
marzo '24
+755
en 6 canales
Get PRO
febrero '24
+231
en 2 canales
Get PRO
enero '24
+89
en 0 canales
Get PRO
diciembre '23
+271
en 0 canales
Get PRO
noviembre '23
+3 198
en 3 canales
| Fecha | Crecimiento de Suscriptores | Menciones | Canales | |
| 23 julio | +5 | |||
| 22 julio | +6 | |||
| 21 julio | +5 | |||
| 20 julio | +5 | |||
| 19 julio | +6 | |||
| 18 julio | +5 | |||
| 17 julio | +6 | |||
| 16 julio | +5 | |||
| 15 julio | +8 | |||
| 14 julio | +13 | |||
| 13 julio | +7 | |||
| 12 julio | +1 | |||
| 11 julio | +4 | |||
| 10 julio | +7 | |||
| 09 julio | +4 | |||
| 08 julio | +11 | |||
| 07 julio | +6 | |||
| 06 julio | +12 | |||
| 05 julio | +2 | |||
| 04 julio | +9 | |||
| 03 julio | +3 | |||
| 02 julio | +7 | |||
| 01 julio | +8 |
Publicaciones del Canal
🛎 Успейте зарегистрироваться на Back to Back
До Back to Back осталось меньше двух недель! Напоминаем: это новая бэкенд-конференция Яндекса, которая пройдёт сразу в трёх городах — Москве, Белграде и Ереване. Присоединиться можно как офлайн, так и онлайн.
💹 Немного о программе:
📍 Москва
Савва Лебедев из Positive Technologies расскажет, как команда добавляла поддержку LuaJIT в eBPF-профилировщик Perforator. Даниил Подольский из YADRO разберёт аутентификации в гетерогенных системах, а Антон Пионтковский из Yandex Cloud объяснит, что делать, когда данные отсортированы не так, как ожидает запрос.
📍 Белград
Душан Йованович из Inceptive разберёт возможности статической рефлексии в C++26, а Александр Зайцев, зависимый от PGO эксперт, поделится опытом использования Profile-Guided Optimization и расскажет, как получить от неё реальный прирост производительности.
📍 Ереван
Брюс Момджиан, один из самых известных евангелистов PostgreSQL в мире, выступит с докладом про WAL. А Монс Андерсон из Exness расскажет о современных подходах к генерации распределённых идентификаторов для масштабных систем.
🔶 Выбирайте площадку и регистрируйтесь. Вас ждут доклады про бэкенд, производительность, распределённые системы и современный C++.
🈯️ До встречи на Back to Back!
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend
| 2 |  🔍 Архитектура S3 в Яндексе: шардирование, листинги и сбор метаданных
Меня зовут Артём Мурашко, я разработчик Cloud Storage Services в Yandex Infrastructure. Уже более трёх лет я строю S3 в Яндексе. Хочу рассказать, как можно быстро собрать метаданные сотен миллиардов объектов в S3-хранилище.
❇️ Как всё устроено
Наши внутренние и облачные инсталляции — это миллионы бакетов (именованных контейнеров) и миллиарды объектов (файлов). А сама архитектура S3-хранилища построена на разделении метаданных и данных:
🟢 Data — низкоуровневое хранилище, где на запись данных мы получаем уникальный ключ, по которому можем прочитать или удалить информацию
🟢 Metadata — PostgreSQL
Путь клиентского GET-запроса выглядит так: он попадает на бэкенд, который обслуживает S3-протокол, далее мы идём в PG за метаданными, получаем ключ от низкоуровневого хранилища, по нему читаем данные и возвращаем их обратно пользователю.
❇️ Как мы шардируем метаданные
🟢 Пространство хешей ключей бакета нарезаем на непересекающиеся диапазоны — чанки
🟢 Каждый объект имеет ключ → hash(key) попадает в один диапазон → это его чанк
🟢 У одного бакета может быть более одного чанка (они живут на разных шардах)
❇️ Есть два типа баз данных:
1️⃣ s3meta. Хранит бакеты и их настройки, адресацию чанков, пользователей, статистику
2️⃣ s3db. Хранит метаданные объектов и дублирует информацию о чанках на шарде
Путь запроса: бэкенд приходит в s3meta, по хешу ключа определяет, какой s3db-шард нужен, и идёт на него, читает метаданные объекта, а затем — данные из низкоуровневого хранилища.
❇️ Проблема листингов
Пользователям нужно получить полный список объектов бакета с метаданными:
🟢 Для аудита настроек на объектах
🟢 Для выявления объектов, которые давно не использовались
🟢 Для расчёта суммы размера объектов с определённым префиксом
В спецификации S3 есть метод ListObjects, который возвращает до 1000 ключей в лексикографическом порядке и принимает continuation-токен для пагинации.
Последовательный обход бакета на стороне клиента выглядит как цикл с запросами ListObjects, пока сервер не скажет, что объектов больше нет.
Со стороны S3 листинг тысячи ключей работает так: спецификация ListObjects гласит, что нужно возвращать объекты в лексикографическом порядке. Шардируемся мы по хешу ключа, поэтому приходится идти на каждый шард, полистить тысячу ключей, смержить и отсортировать в рантайме, вернуть первую тысячу. И так далее, пока не обойдём весь бакет.
❇️ Негативные факторы:
➖ Для пользователя
Надо писать логику сбора данных, поднимать инфраструктуру и где-то это всё промежуточно хранить. А для больших бакетов — это особенно долго. Также ListObjects возвращает не весь возможный набор метаданных. Чтобы получить их полностью, придётся делать дополнительные запросы на каждый из объектов.
➖ Для сервиса
Мы не контролируем нагрузку: чем больше шардов у бакета, тем больше походов в s3db-шарды нам нужно сделать на каждый ListObjects. А ещё есть проблема «шумных соседей» — можно попасть на деградированный шард, что ухудшит общее время ответа.
🔶 В своём докладе на infra.conf’26 я рассказал, как мы решили эту проблему. А также объяснил, как мы реализовали S3 Inventory в Яндексе и почему отказались от пошардового обхода. Смотрите подробности на ютубе.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 1 432 |
| 3 |  +8⚪️ Принципы разработки в Яндекс 360
Всем привет, это Илья Иванов, руководитель группы разработки В2С-сегмента Биллинга. В Яндекс 360 наш сервис отвечает за все домены, которые связаны с монетизацией. Мы управляем тарифами и акциями, рекуррентными подписками и обеспечением выдачи услуг.
💹 В команде бэкенда Яндекс 360 разработчик не только пишет код, но и отвечает за архитектуру целых проектов и фич. А ещё мы думаем о продуктовой ценности для пользователя.
Ключевой ресурс в наших командах — это доверие. Его можно заслужить, если делать качественные проекты и повышать их сложность. А чем выше уровень доверия к определённому разработчику или тимлиду, тем больше у него возможностей проявить себя. Об этом недавно читал доклад лид нашего бэкенда Роман Акинфеев.
👩⚕️ В карточках я рассказал, как сложился мой путь и почему мне понравилась культура в бэкенде Яндекс 360.
🔶 Подробности можете прочитать в блоге о работе в Яндексе
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 1 987 |
| 4 |  🚀 Погружаемся в технологии на deep tech night
5 сентября пройдёт deep tech night — масштабная онлайн-конференция Яндекса о технологических вызовах, с которыми IT-индустрия сталкивается в эпоху AI: от изменений в разработке до новых требований к архитектуре и инфраструктуре.
Это событие для опытных бэкенд-разработчиков, техлидов, инженеров и всех, кто работает в IT-индустрии, внедряет AI в процессы, проектирует сложные системы и ищет новые решения.
Сфокусируемся на архитектуре в эпоху AI:
🟢 Роль разработчика и как она меняется
🟢 Ревью агентского кода, масштабирование и поддержка качества
🟢 Подходы к работе с большими базами данных
🔶 Зарегистрироваться
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 071 |
| 5 |  🚘 Семь раз подумай, один раз пошардируй
Меня зовут Никита Звонарёв, я разработчик в Яндекс 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 | 2 191 |
| 6 |  +8🤖 Когда код не управляет логикой: observability для AI-агентов
На связи Даниэль Халиулин, технический менеджер в Yandex Infrastructure. Сейчас AI-агенты развиваются и интегрируются в сервисы с огромной скоростью. Но если не контролировать их работу, последствия могут быть неприятными.
Представьте ситуацию: очень важный AI-агент сломался прямо в проде. Инфраструктурные метрики при этом горят зелёным, а в логи заглядывать страшно. Как понять, почему агент стал галлюцинировать? На какие данные смотреть, как и где их хранить? Что делать, когда привычные метрики теряют актуальность?
👩⚕️ В карточках я разобрал, что значит observability AI-агентов, почему трейсы сменяют логи и какие инструменты можно использовать для мониторинга.
🔶 А в полном выступлении на infra.conf’26 я рассказал обо всём подробнее. Смотрите доклад на сайте или на ютубе.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 771 |
| 7 |  🔡 Как мы научили реляционную базу хранить оргструктуру на 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 | 2 475 |
| 8 |  🧬 Инженерная кухня 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 | 2 597 |
| 9 |  🟢 Поможем подготовиться к собесу и прокачать резюме
Мы перезапускаем наш MVP-проект с бесплатными карьерными консультациями для разработчиков от опытных рекрутеров Яндекса. Приходите к нам, а мы поможем с резюме или профилем LinkedIn, расскажем о наших карьерных треках и ответим на все интересующие вопросы о наймовых процессах в IT.
Кого зовём: бэкенд-разработчиков уровня мидл+ с опытом от 3 лет.
Как всё устроено:
🟢 Отправляете заявку
🟢 Выбираете удобную дату и время
🟢 Узнаёте всё, что хотели, на 45-минутном созвоне
🔶 Узнать подробности и отправить заявку
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 3 003 |
| 10 |  +8🏠 Как мы вынесли рекламу в офлайн
Меня зовут Юра Журихин, я руководитель разработки наружной рекламы в Поисковых сервисах и ИИ. В нашей бизнес-группе большое количество разных бэкенд-сервисов. И наружная реклама — один из таких нетривиальных примеров.
Мы долго занимались онлайн-рекламой и уже успели стать в ней экспертами. Но сейчас я хочу рассказать, с какими вызовами мы столкнулись, когда выносили её в мир офлайна.
👩⚕️ Читайте об этом в карточках выше
🔶 На конференции «Я про бэкенд» я более подробно рассказал о методах определения аудитории вблизи физических рекламных экранов и поделился алгоритмами отслеживания видимости рекламы на движущихся носителях. А также объяснил, какие способы помогли нам переосмыслить традиционные методы оценки эффективности наружной рекламы.
📺 Смотрите доклад на ютубе.
📎 Кстати, конференция «Я про бэкенд» пройдёт уже этой осенью — будем много говорить про бэкенд и то, как он меняется в эпоху ML.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 3 374 |
| 11 |  🈯️ Приглашаем на Back to Back!
Это конференция для бэкенд-инженеров, архитекторов, SRE и техлидов. Поговорим о том, что болит в больших системах: latency, bottlenecks, отказоустойчивость, масштабирование и инфраструктура. А также обсудим архитектурные решения, которые нельзя проверить на слайдах — только в продакшене.
Когда и где:
📆 1 августа
📍 Одновременно в Москве, Белграде и Ереване
В каждом городе — свой фокус программы:
🟢 В Москве и Ереване собираем инженеров на Architecture & Performance — трек про производительность и реальные продакшен-задачи
🟢 В Москве и Белграде ждём всех, кто дружит с C++, — трек C++ Zero Cost про производительность, системную разработку и инженерные задачи
💹 Но это не всё! На площадках будут активности от команд и сервисов Яндекса. А если не сможете приехать лично — подключайтесь онлайн к любому из городов.
🔶 Полную программу мы соберём к началу июля, но регистрация уже открыта! Так что переходите на страницу своей площадки, чтобы узнать подробности и оставить заявку:
📟 Москва
📟 Белград
📟 Ереван
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 978 |
| 12 |  🔨 Как мы чиним невидимое: сеть в Yandex Cloud
🎙️ Меня зовут Костя Крамлих, я руководитель службы сетевой виртуализации в Yandex Cloud. Недавно я заглянул в гости к ребятам из подкаста «Разбор полётов» — поговорили про сеть, надёжность и немного про стажёров.
Что мы обсудили:
🟢 Принцип нашей работы
Все Data Plane должны работать полностью при отказе Control Plane — это самое главное и фундаментальное свойство надёжности.
Почему? Control Plane — это сложные сервисы с бизнес-логикой, вероятность отказа там гораздо выше. А Data Plane — это то, что реально процессит трафик клиента.
Если упал Control Plane — неприятно, но клиент может подождать. Но если перестал работать Data Plane — трафик не идёт. А для пользователя это в 10 раз хуже.
🟢 Мы стремимся обновляться незаметно для клиентов
Раньше перезапуск Data Plane ронял трафик. Поэтому мы используем Blue Green Deploy прямо на хосте: привозим на живой сервер две инсталляции Data Plane и плавно переключаем интерфейсы виртуальных машин с одного на другой.
Результат — сотни миллисекунд, которые укладываются в TCP-ретрай. И подавляющее число наших клиентов этого вообще никак не замечает.
🟢 Собственная модель учений
В большом Яндексе их проводят почти 20 лет: просто отключают один дата-центр фаерволом и смотрят, все ли сервисы выжили. Но в облаке так нельзя: мы не можем диктовать клиентам, как строить резервирование.
Поэтому у нас гибридная модель. Раз в две недели на препроде полностью отключаем одну зону. А некоторые сервисы (региональные, консоль) тестируем прямо на проде: они по своему построению должны выдерживать отказ любой зоны.
🔶 Слушайте больше подробностей о том, как мы строим сетевые продукты в Yandex Cloud, в полном выпуске подкаста «Разбор полётов» на сайте, ютубе и в Яндекс Музыке.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 607 |
| 13 |  💹 YaFF в опенсорсе: как и зачем мы сделали zero‑copy-представление для Protobuf
В высоконагруженных C++-сервисах часто используют Protobuf. Он по-своему удобен, но парсинг миллионов объектов в секунду забирает заметную часть процессорного времени. Переезд на FlatBuffers кажется решением, однако на практике это не «Protobuf без парсинга»: различия в схемах, API и доступе к вложенным данным делают миграцию дорогой и рискованной.
🟢 Мы выложили в опенсорс YaFF (Yet Another Flat Format) — альтернативный способ представления Protobuf для высоконагруженных сервисов. Библиотека позволяет встраиваться в существующую Protobuf-инфраструктуру и работать с данными, но не расходовать ресурсы на их десериализацию. Это даёт возможность экономить до 20% вычислительных мощностей.
🔶 Читайте в статье на Хабре все подробности об архитектуре YaFF. Внутри: тернистый путь к успеху, низкоуровневые детали и красивые цифры бенчмарков.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 847 |
| 14 |  🧬 Как Яндекс Диск выдерживает сотни гигабит входящего трафика
Типичная схема бэкенд-приложения выглядит стандартно: группа экземпляров сервиса и балансировщик перед ними. Пользователь отправляет на него запрос, а тот проксирует его на конкретный инстанс. Эта схема отлично работает на лёгких API-запросах, но рассыпается, как только трафик становится тяжелее.
Меня зовут Илья Абрамов, я разработчик в Диске. И в нашем случае речь идёт о массовой загрузке файлов. Миллионы пользователей с разной скоростью интернета загружают данные самых разных размеров — от крошечных документов до многогигабайтных архивов. Хочу рассказать, как мы решили проблему распределения такой нагрузки.
❇️ Что сделали
Мы полностью отказались от промежуточных балансировщиков при загрузке файлов. В нашей текущей архитектуре путь данных выглядит иначе: пользователь отправляет тяжёлый трафик напрямую в сервис.
Но для этого нам пришлось переосмыслить сам принцип того, как клиент находит нужный сервер, и придумать, как сэкономить сетевые ресурсы. Ведь если хост перегружен, пользователи либо вообще не могут загрузить файл, либо сталкиваются с катастрофическим падением скорости.
❇️ Поэтому мы разделили процесс на два типа запросов:
🟢 Control (управляющие). Это легковесные HTTP-запросы. Их задача — получить одобрение на загрузку и узнать адрес целевого сервера. Они проходят через стандартный балансировщик, так как почти не создают сетевой нагрузки
🟢 Data (данные). Это тяжеловесные потоки байтов, которые идут напрямую от пользователя к выбранному серверу и минуют промежуточные звенья
❇️ Теперь архитектуру загрузки в Диске формируют два ключевых компонента:
🟢 Балансерун (Balancer). Он выбирает наиболее подходящий экземпляр сервиса для конкретного пользователя. Балансерун в реальном времени держит в памяти актуальный список всех живых серверов (через Service Discovery) и мониторит их состояние. И на выходе отдаёт пользователю уникальную ссылку на загрузку
🟢 Кладун (Uploader). Это сервис, который принимает входящий data-запрос по прямой ссылке и сохраняет файл в целевое хранилище
💹 Схема взаимодействия выглядит так: пользователь спрашивает у Балансеруна, куда положить файл → Балансерун анализирует загрузку системы и отвечает: «Вот ссылка на сервер №3» → пользователь открывает прямое соединение с этим сервером и отправляет данные в Кладун.
🔶 В статье на Хабре я рассказал, как мы искали идеальный алгоритм для достижения равномерной утилизации сети на всех аплоадерах (и почему это было не так-то просто), а также как нам пришлось глобально переработать логику и в итоге создать алгоритм HOBA 🤸🏻
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 437 |
| 15 |  📖 Как использовать Temporal
Меня зовут Миша Иглицкий, я бэкенд‑разработчик в платформе Яндекс Еды. Наш процессинг заказов уже почти год работает целиком на Temporal. Я уже рассказывал, как эта функция безболезненно решает привычную проблему распределённой бизнес-логики. А сегодня хочу поделиться советами миграции на Temporal, которые мы вывели из нашего опыта.
❇️ Не поддавайтесь иллюзии чистой архитектуры
Бизнес-логика в Temporal Workflow выглядит очень соблазнительно. Но её изоляция от ввода-вывода (I/O) сама по себе не гарантирует хорошую архитектуру. В идеале ваша доменная область вообще ничего не должна знать о Temporal — только предоставлять нужные вам интерфейсы.
Наши грабли: первая версия Workflow была просто «простынёй» вызовов Activity в правильном порядке. Одну часть бойлерплейта для юнит-тестов мы копипастили, а вторую — адаптировали. В итоге сложность нашей системы разрослась до неподдерживаемой и пришлось менять подход.
❇️ Как надо делать:
🟢 Тестируйте бизнес-логику небольшими блоками, изолированно от Temporal SDK
🟢 Используйте интерцепторы для метрик, retry policy и кастомного логирования
🟢 На Go обязательно пользуйтесь кодогенератором для вызовов Activity
💹 Сохраняйте всё, что способно повлиять на работу бизнес-логики
Она должна всегда приводить к одному и тому же результату на одинаковой истории событий — это суть детерминистического подхода в Temporal, который обеспечивает такую надёжность.
Какие инструменты могут помочь:
🟢 SideEffect. Фиксирует в истории результат недетерминированного вычисления и не оформляет его как отдельную Activity. При повторных проигрываниях Temporal просто достаёт сохранённое значение
🟢 Версионирование. Позволяет старым Workflow работать по-старому, новым — по-новому. Полезно именно там, где бизнес-логика обновляется без возможности отката
🟢 Feature Flags. Хотя технически они реализуются через LocalActivity или SideEffect, эта парадигма гораздо гибче простого версионирования и позволяет переключить поведение только у части Workflow. Это особенно полезно для постепенного внедрения изменений с возможностью откатиться
➖ Неочевидный совет: лучший способ не выстрелить себе в ногу с версионированием — это копипаст. Весь старый код оборачивается в if version == oldVersion, а новый просто пишется рядом уже с улучшениями. Когда старых Workflow не остаётся, ветвление удаляется. Да, это временное нарушение DRY, но код всё равно скоро исчезнет. Главное — действительно потом его удалить 🤫
🔶 Читайте все подробности в статье на Хабре. Там я рассказал, что именно нам помогло обеспечить плавность перехода на Temporal и какие тесты мы используем для защиты от случайного недетерминизма. А также объяснил, что делать, если в Workflow слишком много действий, и поделился другими разными полезностями для работы с Temporal.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 3 648 |
| 16 | все | 1 |
| 17 |  🎙 Мы знаем, что бэкендерам есть что рассказать про серверную сторону AI
За последние пару лет искусственный интеллект проник во все сферы. Сложно построить новый проект без умных рекомендательных и генеративных технологий. Появились сотни новых AI-first-продуктов и тысячи AI-фич в обычных сервисах.
🈯️ Приглашаем на «Я про бэкенд 2026». На этой конференции мы поговорим о высоконагруженных рекомендательных, генеративных и других системах под капотом продуктов с AI/ML, а также о вызовах, с которыми сталкиваются их разработчики.
В прошлом году было 13 докладов от специалистов из Яндекса, Авито, Т-Банка, Сбера и VK. Например, спикеры рассказали, как выжимать максимум из decoder attention на GPU и как сэкономить 200 тысяч CPU в рекомендательном движке Рекламы. Посмотреть все выступления можно в плейлистах на ютубе или в VK Видео.
В этот раз мы ждём ваши доклады на такие темы:
🟢 Архитектура систем с AI/ML
🟢 Работа на стыке бэкенда с железом, в том числе глубокая оптимизация по использованию GPU, CPU, памяти, сети
🟢 Облачные и коммунальные решения, инфраструктура
🟢 Алгоритмы и подходы к решению практических задач
🟢 Хранение и стриминг данных
🟢 MLOps: деплой, эксплуатация, наблюдаемость и так далее
🟢 Любые другие темы, связанные с интересными челленджами на бэкенде
🔶 Отправить заявку на участие можно тут
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 305 |
| 18 |  💹 Как мы откатываем за секунду и не ломаем прод
Меня зовут Андрей Мичурин, я работаю в Яндексе больше 13 лет и отвечаю за разработку систем деплоя. Платформа развёртывания входит во внутреннюю инфраструктуру компании, которая решает сложные задачи: от строительства дата-центра до IDE и код-систем.
🎙 В новом выпуске подкаста «В офисе» я объяснил, как устроена платформа, которая обслуживает все деплои Яндекса. Вот три кейса из этого разговора:
1️⃣ Концепция антихрупкости
Классический Kubernetes, Docker и OpenSSH не вывозят наши масштаб и требования, поэтому мы написали свой SSH. Это помогает нам находить выход из любой аварии и строить архитектуру таким образом, чтобы поломка одного приложения никак не влияла на весь пайплайн. Зачем? Чтобы любой наш сервис умел деградировать, а не падать.
И деградация одного никак не влияла на остальные.
2️⃣ Агентская часть деплоя
Система стала настолько сложной (стейт-машина, у которой было больше 17 переходов), что погружение нового разработчика в работу у нас занимало примерно год. Поэтому мы переписали логику на поведенческих деревьях — как в движке для ботов Unreal Engine.
Их можно переиспользовать и визуализировать, при этом сложность разработки упала в несколько раз, а новый инженер пишет код в продакшен уже буквально через две недели.
3️⃣ Роллбэки за секунду
Чтобы откатить докер-контейнер, нужно было заново его собрать, проинициализировать скрипты, переменные окружения и секреты. Это занимало много времени. Мы придумали механизм снапшотов. Контейнер, на который нужно откатиться, уже есть в системе: он собран, всё разархивировано, переменные окружения и секреты скачаны. Так что для отката остаётся только «исправить симлинк» и запустить ворклоуд.
🔶 В полном выпуске подкаста я также рассказал, как мы обеспечиваем стабильность сервисов, что сложнее всего реализовать в деплой-платформе и как сломать Яндекс Музыку 😄 А ещё объяснил, почему сервисы вообще падают. Полный выпуск подкаста — на ютубе.
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 832 |
| 19 |  💻 Декомпозиция, автоматизация и 15 минут нагрузки
Меня зовут Дима Александров, я руководитель технических решений в Яндекс Лавке. За годы работы мне довелось плотно заниматься вопросами надёжности как в Еде, так и в Лавке. А недавно я составил стратегию надёжности, где зафиксировал майндсет и конкретный план действий.
Каждый деплой всегда сопряжён с рисками: можно сделать ошибку в коде, подтянуть бажную зависимость или неверно рассчитать нагрузку. Поэтому нужно системно повышать предсказуемость релизов.
Что мы для этого делаем:
🟢 Проводим автоматическое нагрузочное тестирование в CI. Перед каждой выкладкой мы запускаем его в изолированном load-окружении. Сервис должен поработать под полной нагрузкой хотя бы 10–15 минут. Этого достаточно, чтобы убедиться, что утилизация ресурсов и тайминги ответов не деградировали по сравнению с прошлым релизом
🟢 Запускаем end-to-end-тесты в продакшене. Мы регулярно проверяем capacity системы в целом с помощью нагрузочного тестирования в проде. Это помогает своевременно заметить нехватку запаса прочности или выловить кривой релиз
🟢 Тотально автоматизируем регресс. Если у вас много ручного тестирования, то ошибок из-за человеческого фактора не избежать. Единственный выход — автоматизировать 75–90% сценариев. Это даёт возможность гонять полный пакет регресс-тестов на каждый релиз
🟢 Декомпозируем изменения. Чтобы сократить шанс что-то внезапно сломать, мы разбиваем приложения на модули, уходим от монолитов на бэке и фронте, изолируем блоки
🟢 Управляем ресурсами автоматически. Система должна сама докидывать их, если обнаружила нехватку. А когда нагрузка спадает — перекидывать мощности, например, на аналитические вычисления
🔶 Читайте больше подробностей в блоге Городских сервисов Яндекса. Там я рассказал, какие два способа помогают снизить ущерб от любого инцидента. И объяснил, что помогает вовремя реагировать на множество алертов в сложной распределённой системе с кучей сервисов
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 2 546 |
| 20 |  +8🧬 Постмит infra.conf’26: как мы усилили инфраструктуру, чтобы справляться с ещё большими нагрузками
Спасибо всем, кто присоединился поговорить об инфраструктуре, платформах и observability. Было супер 🈯️
Делимся хайлайтами о том, как команда Yandex Infrastructure модернизировала строительство и охлаждение дата-центров, чтобы ускорить внедрение AI:
🟢 Концепция «кампус дата-центров». Для поддержания растущих нагрузок Яндекс изменил подход к размещению вычислительных мощностей. Теперь мы будем объединять независимые дата-центры с одной локацией в кампусы с общей внешней инфраструктурой. Это поможет оптимизировать энергопотребление и увеличить мощности в три раза до 180 МВт — рекорд для России.
🟢 Жидкостное охлаждение. Для его реализации наши инженеры разработали сайдкары — дополнительные стойки с жидкостно-воздушными радиаторами. До недавних пор мы использовали только фрикулинг — охлаждение воздухом. Сайдкары дополнят этот подход без масштабной реконструкции дата-центров. Сочетание двух технологий сделает терморегуляцию дата-центров эффективнее и ускорит адаптацию инфраструктуры к растущим нагрузкам наших сервисов и продуктов внешних партнёров.
🟢 Dev Cluster. Инструмент для динамического распределения GPU-ресурсов поможет разработчикам за несколько кликов настраивать конфигурацию контейнеров для любых задач без сложной настройки.
💹 Наши распределённые хранилища уже работают с эксабайтами данных, обеспечивая вам стабильные платформы разработки и деплоя. Теперь мы готовы к нагрузкам, которые ещё вчера казались предельными. Ждём новые фичи в YandexGPT и других сервисах! 🧠⚡️
Подписывайтесь:
💬 @Yandex4Backend
📹 @YandexforBackend | 3 440 |
