es
Feedback
Yandex for Backend

Yandex for Backend

Ir al canal en Telegram

Канал для бэкендеров от Яндекса. Рассказываем про события по Python, Go, Java и C++ и не только, делимся экспертизой, обсуждаем технологии и поддерживаем бэкенд-комьюнити. Другие каналы Яндекса по стекам разработки: https://t.me/addlist/Hrq31w2p1vUyOGZi

Mostrar más
9 857
Suscriptores
+124 horas
+127 días
+12230 días
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 S
🔍 Архитектура 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
⚪️ Принципы разработки в Яндекс 360 Всем привет, это Илья Иванов, руководитель группы разработки В2С-сегмента Биллинга. В Янд+8
⚪️ Принципы разработки в Яндекс 360 Всем привет, это Илья Иванов, руководитель группы разработки В2С-сегмента Биллинга. В Яндекс 360 наш сервис отвечает за все домены, которые связаны с монетизацией. Мы управляем тарифами и акциями, рекуррентными подписками и обеспечением выдачи услуг. 💹 В команде бэкенда Яндекс 360 разработчик не только пишет код, но и отвечает за архитектуру целых проектов и фич. А ещё мы думаем о продуктовой ценности для пользователя. Ключевой ресурс в наших командах — это доверие. Его можно заслужить, если делать качественные проекты и повышать их сложность. А чем выше уровень доверия к определённому разработчику или тимлиду, тем больше у него возможностей проявить себя. Об этом недавно читал доклад лид нашего бэкенда Роман Акинфеев. 👩‍⚕️ В карточках я рассказал, как сложился мой путь и почему мне понравилась культура в бэкенде Яндекс 360. 🔶 Подробности можете прочитать в блоге о работе в Яндексе Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend
1 987
4
🚀 Погружаемся в технологии на deep tech night 5 сентября пройдёт deep tech night — масштабная онлайн-конференция Яндекса о т
🚀 Погружаемся в технологии на deep tech night 5 сентября пройдёт deep tech night — масштабная онлайн-конференция Яндекса о технологических вызовах, с которыми IT-индустрия сталкивается в эпоху AI: от изменений в разработке до новых требований к архитектуре и инфраструктуре. Это событие для опытных бэкенд-разработчиков, техлидов, инженеров и всех, кто работает в IT-индустрии, внедряет AI в процессы, проектирует сложные системы и ищет новые решения. Сфокусируемся на архитектуре в эпоху AI: 🟢 Роль разработчика и как она меняется 🟢 Ревью агентского кода, масштабирование и поддержка качества 🟢 Подходы к работе с большими базами данных 🔶 Зарегистрироваться Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend
2 071
5
🚘 Семь раз подумай, один раз пошардируй Меня зовут Никита Звонарёв, я разработчик в Яндекс 360. Сегодня расскажу, как мы гор
🚘 Семь раз подумай, один раз пошардируй Меня зовут Никита Звонарёв, я разработчик в Яндекс 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
🤖 Когда код не управляет логикой: observability для AI-агентов На связи Даниэль Халиулин, технический менеджер в Yandex Infr+8
🤖 Когда код не управляет логикой: observability для AI-агентов На связи Даниэль Халиулин, технический менеджер в Yandex Infrastructure. Сейчас AI-агенты развиваются и интегрируются в сервисы с огромной скоростью. Но если не контролировать их работу, последствия могут быть неприятными. Представьте ситуацию: очень важный AI-агент сломался прямо в проде. Инфраструктурные метрики при этом горят зелёным, а в логи заглядывать страшно. Как понять, почему агент стал галлюцинировать? На какие данные смотреть, как и где их хранить? Что делать, когда привычные метрики теряют актуальность? 👩‍⚕️ В карточках я разобрал, что значит observability AI-агентов, почему трейсы сменяют логи и какие инструменты можно использовать для мониторинга. 🔶 А в полном выступлении на infra.conf’26 я рассказал обо всём подробнее. Смотрите доклад на сайте или на ютубе. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend
2 771
7
🔡 Как мы научили реляционную базу хранить оргструктуру на 500 000 пользователей Представьте: пользователь добавляет одного с
🔡 Как мы научили реляционную базу хранить оргструктуру на 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 На связи Денис Волков из команды платформы данных в 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-проект с бесплатными карьерными консультациями
🟢 Поможем подготовиться к собесу и прокачать резюме Мы перезапускаем наш MVP-проект с бесплатными карьерными консультациями для разработчиков от опытных рекрутеров Яндекса. Приходите к нам, а мы поможем с резюме или профилем LinkedIn, расскажем о наших карьерных треках и ответим на все интересующие вопросы о наймовых процессах в IT. Кого зовём: бэкенд-разработчиков уровня мидл+ с опытом от 3 лет. Как всё устроено: 🟢 Отправляете заявку 🟢 Выбираете удобную дату и время 🟢 Узнаёте всё, что хотели, на 45-минутном созвоне 🔶 Узнать подробности и отправить заявку Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend
3 003
10
🏠 Как мы вынесли рекламу в офлайн Меня зовут Юра Журихин, я руководитель разработки наружной рекламы в Поисковых сервисах и+8
🏠 Как мы вынесли рекламу в офлайн Меня зовут Юра Журихин, я руководитель разработки наружной рекламы в Поисковых сервисах и ИИ. В нашей бизнес-группе большое количество разных бэкенд-сервисов. И наружная реклама — один из таких нетривиальных примеров. Мы долго занимались онлайн-рекламой и уже успели стать в ней экспертами. Но сейчас я хочу рассказать, с какими вызовами мы столкнулись, когда выносили её в мир офлайна. 👩‍⚕️ Читайте об этом в карточках выше 🔶 На конференции «Я про бэкенд» я более подробно рассказал о методах определения аудитории вблизи физических рекламных экранов и поделился алгоритмами отслеживания видимости рекламы на движущихся носителях. А также объяснил, какие способы помогли нам переосмыслить традиционные методы оценки эффективности наружной рекламы. 📺 Смотрите доклад на ютубе. 📎 Кстати, конференция «Я про бэкенд» пройдёт уже этой осенью — будем много говорить про бэкенд и то, как он меняется в эпоху ML. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend
3 374
11
🈯️ Приглашаем на Back to Back! Это конференция для бэкенд-инженеров, архитекторов, SRE и техлидов. Поговорим о том, что боли
🈯️ Приглашаем на Back to Back! Это конференция для бэкенд-инженеров, архитекторов, SRE и техлидов. Поговорим о том, что болит в больших системах: latency, bottlenecks, отказоустойчивость, масштабирование и инфраструктура. А также обсудим архитектурные решения, которые нельзя проверить на слайдах — только в продакшене. Когда и где: 📆 1 августа 📍 Одновременно в Москве, Белграде и Ереване В каждом городе — свой фокус программы: 🟢 В Москве и Ереване собираем инженеров на Architecture & Performance — трек про производительность и реальные продакшен-задачи 🟢 В Москве и Белграде ждём всех, кто дружит с C++, — трек C++ Zero Cost про производительность, системную разработку и инженерные задачи 💹 Но это не всё! На площадках будут активности от команд и сервисов Яндекса. А если не сможете приехать лично — подключайтесь онлайн к любому из городов. 🔶 Полную программу мы соберём к началу июля, но регистрация уже открыта! Так что переходите на страницу своей площадки, чтобы узнать подробности и оставить заявку: 📟 Москва 📟 Белград 📟 Ереван Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend
2 978
12
🔨 Как мы чиним невидимое: сеть в Yandex Cloud 🎙️ Меня зовут Костя Крамлих, я руководитель службы сетевой виртуализации в Ya
🔨 Как мы чиним невидимое: сеть в 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++-сервисах часто испол
💹 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, которые мы вывели из нашего опыта. ❇️ Не поддавайтесь иллюзии чистой архитектуры Бизнес-логика в 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 За последние пару лет искусственный интеллект проник во все сферы. Сложно построить новый проект без умных рекомендательных и генеративных технологий. Появились сотни новых AI-first-продуктов и тысячи AI-фич в обычных сервисах. 🈯️ Приглашаем на «Я про бэкенд 2026». На этой конференции мы поговорим о высоконагруженных рекомендательных, генеративных и других системах под капотом продуктов с AI/ML, а также о вызовах, с которыми сталкиваются их разработчики. В прошлом году было 13 докладов от специалистов из Яндекса, Авито, Т-Банка, Сбера и VK. Например, спикеры рассказали, как выжимать максимум из decoder attention на GPU и как сэкономить 200 тысяч CPU в рекомендательном движке Рекламы. Посмотреть все выступления можно в плейлистах на ютубе или в VK Видео. В этот раз мы ждём ваши доклады на такие темы: 🟢 Архитектура систем с AI/ML 🟢 Работа на стыке бэкенда с железом, в том числе глубокая оптимизация по использованию GPU, CPU, памяти, сети 🟢 Облачные и коммунальные решения, инфраструктура 🟢 Алгоритмы и подходы к решению практических задач 🟢 Хранение и стриминг данных 🟢 MLOps: деплой, эксплуатация, наблюдаемость и так далее 🟢 Любые другие темы, связанные с интересными челленджами на бэкенде 🔶 Отправить заявку на участие можно тут Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend
305
18
💹 Как мы откатываем за секунду и не ломаем прод Меня зовут Андрей Мичурин, я работаю в Яндексе больше 13 лет и отвечаю за ра
💹 Как мы откатываем за секунду и не ломаем прод Меня зовут Андрей Мичурин, я работаю в Яндексе больше 13 лет и отвечаю за разработку систем деплоя. Платформа развёртывания входит во внутреннюю инфраструктуру компании, которая решает сложные задачи: от строительства дата-центра до IDE и код-систем. 🎙 В новом выпуске подкаста «В офисе» я объяснил, как устроена платформа, которая обслуживает все деплои Яндекса. Вот три кейса из этого разговора: 1️⃣ Концепция антихрупкости Классический Kubernetes, Docker и OpenSSH не вывозят наши масштаб и требования, поэтому мы написали свой SSH. Это помогает нам находить выход из любой аварии и строить архитектуру таким образом, чтобы поломка одного приложения никак не влияла на весь пайплайн. Зачем? Чтобы любой наш сервис умел деградировать, а не падать. И деградация одного никак не влияла на остальные. 2️⃣ Агентская часть деплоя Система стала настолько сложной (стейт-машина, у которой было больше 17 переходов), что погружение нового разработчика в работу у нас занимало примерно год. Поэтому мы переписали логику на поведенческих деревьях — как в движке для ботов Unreal Engine. Их можно переиспользовать и визуализировать, при этом сложность разработки упала в несколько раз, а новый инженер пишет код в продакшен уже буквально через две недели. 3️⃣ Роллбэки за секунду Чтобы откатить докер-контейнер, нужно было заново его собрать, проинициализировать скрипты, переменные окружения и секреты. Это занимало много времени. Мы придумали механизм снапшотов. Контейнер, на который нужно откатиться, уже есть в системе: он собран, всё разархивировано, переменные окружения и секреты скачаны. Так что для отката остаётся только «исправить симлинк» и запустить ворклоуд. 🔶 В полном выпуске подкаста я также рассказал, как мы обеспечиваем стабильность сервисов, что сложнее всего реализовать в деплой-платформе и как сломать Яндекс Музыку 😄 А ещё объяснил, почему сервисы вообще падают. Полный выпуск подкаста — на ютубе. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend
2 832
19
💻 Декомпозиция, автоматизация и 15 минут нагрузки Меня зовут Дима Александров, я руководитель технических решений в Яндекс Л
💻 Декомпозиция, автоматизация и 15 минут нагрузки Меня зовут Дима Александров, я руководитель технических решений в Яндекс Лавке. За годы работы мне довелось плотно заниматься вопросами надёжности как в Еде, так и в Лавке. А недавно я составил стратегию надёжности, где зафиксировал майндсет и конкретный план действий. Каждый деплой всегда сопряжён с рисками: можно сделать ошибку в коде, подтянуть бажную зависимость или неверно рассчитать нагрузку. Поэтому нужно системно повышать предсказуемость релизов. Что мы для этого делаем: 🟢 Проводим автоматическое нагрузочное тестирование в CI. Перед каждой выкладкой мы запускаем его в изолированном load-окружении. Сервис должен поработать под полной нагрузкой хотя бы 10–15 минут. Этого достаточно, чтобы убедиться, что утилизация ресурсов и тайминги ответов не деградировали по сравнению с прошлым релизом 🟢 Запускаем end-to-end-тесты в продакшене. Мы регулярно проверяем capacity системы в целом с помощью нагрузочного тестирования в проде. Это помогает своевременно заметить нехватку запаса прочности или выловить кривой релиз 🟢 Тотально автоматизируем регресс. Если у вас много ручного тестирования, то ошибок из-за человеческого фактора не избежать. Единственный выход — автоматизировать 75–90% сценариев. Это даёт возможность гонять полный пакет регресс-тестов на каждый релиз 🟢 Декомпозируем изменения. Чтобы сократить шанс что-то внезапно сломать, мы разбиваем приложения на модули, уходим от монолитов на бэке и фронте, изолируем блоки 🟢 Управляем ресурсами автоматически. Система должна сама докидывать их, если обнаружила нехватку. А когда нагрузка спадает — перекидывать мощности, например, на аналитические вычисления 🔶 Читайте больше подробностей в блоге Городских сервисов Яндекса. Там я рассказал, какие два способа помогают снизить ущерб от любого инцидента. И объяснил, что помогает вовремя реагировать на множество алертов в сложной распределённой системе с кучей сервисов Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend
2 546
20
🧬 Постмит infra.conf’26: как мы усилили инфраструктуру, чтобы справляться с ещё большими нагрузками Спасибо всем, кто присое+8
🧬 Постмит infra.conf’26: как мы усилили инфраструктуру, чтобы справляться с ещё большими нагрузками Спасибо всем, кто присоединился поговорить об инфраструктуре, платформах и observability. Было супер 🈯️ Делимся хайлайтами о том, как команда Yandex Infrastructure модернизировала строительство и охлаждение дата-центров, чтобы ускорить внедрение AI: 🟢 Концепция «кампус дата-центров». Для поддержания растущих нагрузок Яндекс изменил подход к размещению вычислительных мощностей. Теперь мы будем объединять независимые дата-центры с одной локацией в кампусы с общей внешней инфраструктурой. Это поможет оптимизировать энергопотребление и увеличить мощности в три раза до 180 МВт — рекорд для России. 🟢 Жидкостное охлаждение. Для его реализации наши инженеры разработали сайдкары — дополнительные стойки с жидкостно-воздушными радиаторами. До недавних пор мы использовали только фрикулинг — охлаждение воздухом. Сайдкары дополнят этот подход без масштабной реконструкции дата-центров. Сочетание двух технологий сделает терморегуляцию дата-центров эффективнее и ускорит адаптацию инфраструктуры к растущим нагрузкам наших сервисов и продуктов внешних партнёров. 🟢 Dev Cluster. Инструмент для динамического распределения GPU-ресурсов поможет разработчикам за несколько кликов настраивать конфигурацию контейнеров для любых задач без сложной настройки. 💹 Наши распределённые хранилища уже работают с эксабайтами данных, обеспечивая вам стабильные платформы разработки и деплоя. Теперь мы готовы к нагрузкам, которые ещё вчера казались предельными. Ждём новые фичи в YandexGPT и других сервисах! 🧠⚡️ Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend
3 440