Yandex for Backend

🔨 Как мы чиним невидимое: сеть в 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

💹 YaFF в опенсорсе: как и зачем мы сделали zero‑copy-представление для ProtobufВ высоконагруженных C++-сервисах часто используют Protobuf. Он по-своему удобен, но парсинг миллионов объектов в секунду забирает заметную часть процессорного времени. Переезд на FlatBuffers кажется решением, однако на практике это не «Protobuf без парсинга»: различия в схемах, API и доступе к вложенным данным делают миграцию дорогой и рискованной.🟢 Мы выложили в опенсорс YaFF (Yet Another Flat Format) — альтернативный способ представления Protobuf для высоконагруженных сервисов. Библиотека позволяет встраиваться в существующую Protobuf-инфраструктуру и работать с данными, но не расходовать ресурсы на их десериализацию. Это даёт возможность экономить до 20% вычислительных мощностей.🔶 Читайте в статье на Хабре все подробности об архитектуре YaFF. Внутри: тернистый путь к успеху, низкоуровневые детали и красивые цифры бенчмарков.Подписывайтесь:💬 @Yandex4Backend📹 @YandexforBackend

🧬 Как Яндекс Диск выдерживает сотни гигабит входящего трафикаТипичная схема бэкенд-приложения выглядит стандартно: группа экземпляров сервиса и балансировщик перед ними. Пользователь отправляет на него запрос, а тот проксирует его на конкретный инстанс. Эта схема отлично работает на лёгких API-запросах, но рассыпается, как только трафик становится тяжелее.Меня зовут Илья Абрамов, я разработчик в Диске. И в нашем случае речь идёт о массовой загрузке файлов. Миллионы пользователей с разной скоростью интернета загружают данные самых разных размеров — от крошечных документов до многогигабайтных архивов. Хочу рассказать, как мы решили проблему распределения такой нагрузки.❇️ Что сделалиМы полностью отказались от промежуточных балансировщиков при загрузке файлов. В нашей текущей архитектуре путь данных выглядит иначе: пользователь отправляет тяжёлый трафик напрямую в сервис.Но для этого нам пришлось переосмыслить сам принцип того, как клиент находит нужный сервер, и придумать, как сэкономить сетевые ресурсы. Ведь если хост перегружен, пользователи либо вообще не могут загрузить файл, либо сталкиваются с катастрофическим падением скорости.❇️ Поэтому мы разделили процесс на два типа запросов:🟢 Control (управляющие). Это легковесные HTTP-запросы. Их задача — получить одобрение на загрузку и узнать адрес целевого сервера. Они проходят через стандартный балансировщик, так как почти не создают сетевой нагрузки🟢 Data (данные). Это тяжеловесные потоки байтов, которые идут напрямую от пользователя к выбранному серверу и минуют промежуточные звенья❇️ Теперь архитектуру загрузки в Диске формируют два ключевых компонента:🟢 Балансерун (Balancer). Он выбирает наиболее подходящий экземпляр сервиса для конкретного пользователя. Балансерун в реальном времени держит в памяти актуальный список всех живых серверов (через Service Discovery) и мониторит их состояние. И на выходе отдаёт пользователю уникальную ссылку на загрузку🟢 Кладун (Uploader). Это сервис, который принимает входящий da

📖 Как использовать 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, эта парадигма гораздо гибче простого версионирования и позволяет переключить поведение только у части Wor

💹 Как мы откатываем за секунду и не ломаем продМеня зовут Андрей Мичурин, я работаю в Яндексе больше 13 лет и отвечаю за разработку систем деплоя. Платформа развёртывания входит во внутреннюю инфраструктуру компании, которая решает сложные задачи: от строительства дата-центра до IDE и код-систем.🎙 В новом выпуске подкаста «В офисе» я объяснил, как устроена платформа, которая обслуживает все деплои Яндекса. Вот три кейса из этого разговора:1️⃣ Концепция антихрупкостиКлассический Kubernetes, Docker и OpenSSH не вывозят наши масштаб и требования, поэтому мы написали свой SSH. Это помогает нам находить выход из любой аварии и строить архитектуру таким образом, чтобы поломка одного приложения никак не влияла на весь пайплайн. Зачем? Чтобы любой наш сервис умел деградировать, а не падать. И деградация одного никак не влияла на остальные.2️⃣ Агентская часть деплояСистема стала настолько сложной (стейт-машина, у которой было больше 17 переходов), что погружение нового разработчика в работу у нас занимало примерно год. Поэтому мы переписали логику на поведенческих деревьях — как в движке для ботов Unreal Engine.Их можно переиспользовать и визуализировать, при этом сложность разработки упала в несколько раз, а новый инженер пишет код в продакшен уже буквально через две недели.3️⃣ Роллбэки за секундуЧтобы откатить докер-контейнер, нужно было заново его собрать, проинициализировать скрипты, переменные окружения и секреты. Это занимало много времени. Мы придумали механизм снапшотов. Контейнер, на который нужно откатиться, уже есть в системе: он собран, всё разархивировано, переменные окружения и секреты скачаны. Так что для отката остаётся только «исправить симлинк» и запустить ворклоуд.🔶 В полном выпуске подкаста я также рассказал, как мы обеспечиваем стабильность сервисов, что сложнее всего реализовать в деплой-платформе и как сломать Яндекс Музыку 😄 А ещё объяснил, почему сервисы вообще падают. Полный выпуск подкаста — на ютубе.Подписывайтесь:💬 @Yandex4Backend📹 @Yandexf

💻 Декомпозиция, автоматизация и 15 минут нагрузкиМеня зовут Дима Александров, я руководитель технических решений в Яндекс Лавке. За годы работы мне довелось плотно заниматься вопросами надёжности как в Еде, так и в Лавке. А недавно я составил стратегию надёжности, где зафиксировал майндсет и конкретный план действий.Каждый деплой всегда сопряжён с рисками: можно сделать ошибку в коде, подтянуть бажную зависимость или неверно рассчитать нагрузку. Поэтому нужно системно повышать предсказуемость релизов. Что мы для этого делаем:🟢 Проводим автоматическое нагрузочное тестирование в CI. Перед каждой выкладкой мы запускаем его в изолированном load-окружении. Сервис должен поработать под полной нагрузкой хотя бы 10–15 минут. Этого достаточно, чтобы убедиться, что утилизация ресурсов и тайминги ответов не деградировали по сравнению с прошлым релизом🟢 Запускаем end-to-end-тесты в продакшене. Мы регулярно проверяем capacity системы в целом с помощью нагрузочного тестирования в проде. Это помогает своевременно заметить нехватку запаса прочности или выловить кривой релиз🟢 Тотально автоматизируем регресс. Если у вас много ручного тестирования, то ошибок из-за человеческого фактора не избежать. Единственный выход — автоматизировать 75–90% сценариев. Это даёт возможность гонять полный пакет регресс-тестов на каждый релиз🟢 Декомпозируем изменения. Чтобы сократить шанс что-то внезапно сломать, мы разбиваем приложения на модули, уходим от монолитов на бэке и фронте, изолируем блоки🟢 Управляем ресурсами автоматически. Система должна сама докидывать их, если обнаружила нехватку. А когда нагрузка спадает — перекидывать мощности, например, на аналитические вычисления🔶 Читайте больше подробностей в блоге Городских сервисов Яндекса. Там я рассказал, какие два способа помогают снизить ущерб от любого инцидента. И объяснил, что помогает вовремя реагировать на множество алертов в сложной распределённой системе с кучей сервисовПодписывайтесь:💬 @Yandex4Backend📹 @YandexforBackend

🧬 Постмит infra.conf’26: как мы усилили инфраструктуру, чтобы справляться с ещё большими нагрузкамиСпасибо всем, кто присоединился поговорить об инфраструктуре, платформах и observability. Было супер 🈯️Делимся хайлайтами о том, как команда Yandex Infrastructure модернизировала строительство и охлаждение дата-центров, чтобы ускорить внедрение AI:🟢 Концепция «кампус дата-центров». Для поддержания растущих нагрузок Яндекс изменил подход к размещению вычислительных мощностей. Теперь мы будем объединять независимые дата-центры с одной локацией в кампусы с общей внешней инфраструктурой. Это поможет оптимизировать энергопотребление и увеличить мощности в три раза до 180 МВт — рекорд для России.🟢 Жидкостное охлаждение. Для его реализации наши инженеры разработали сайдкары — дополнительные стойки с жидкостно-воздушными радиаторами. До недавних пор мы использовали только фрикулинг — охлаждение воздухом. Сайдкары дополнят этот подход без масштабной реконструкции дата-центров. Сочетание двух технологий сделает терморегуляцию дата-центров эффективнее и ускорит адаптацию инфраструктуры к растущим нагрузкам наших сервисов и продуктов внешних партнёров.🟢 Dev Cluster. Инструмент для динамического распределения GPU-ресурсов поможет разработчикам за несколько кликов настраивать конфигурацию контейнеров для любых задач без сложной настройки.💹 Наши распределённые хранилища уже работают с эксабайтами данных, обеспечивая вам стабильные платформы разработки и деплоя. Теперь мы готовы к нагрузкам, которые ещё вчера казались предельными. Ждём новые фичи в YandexGPT и других сервисах! 🧠⚡️Подписывайтесь:💬 @Yandex4Backend📹 @YandexforBackend

🚗 Как мы связали бэкенд UMO 5 с телематикой автомобиляНа связи Миша Чарзавакян, руководитель разработки Яндекс Электро, и Лёша Косенко из Яндекс Авто. Хотим рассказать, как мы строили Connected Car для нового электромобиля UMO 5 с технологиями Яндекса.Речь об удалённом управлении машиной: согреть салон зимой в минус 15, проверить состояние, отправить команды. Кажется, звучит довольно просто, но давайте заглянем под капот.❇️ Как устроена телематика в UMO 5У каждого современного автомобиля есть блок телематики, который отвечает за взаимодействие с внешним миром. Мы пошли не по пути прямой интеграции бэкенда с этим блоком, а сделали cloud-to-cloud. Наш бэкенд общается с сервером партнёра, а тот — уже с телематикой.В обычной схеме это HTTP-трафик для получения состояния и отправки команд + Kafka для результатов команд, алертов и сообщений. И мы думали, что интеграция будет максимально тривиальная. Но нет.❇️ Главная боль — KafkaУ партнёра развёрнут кластер Kafka из трёх инстансов. Когда наш бэкенд к нему подключался, Kafka возвращала список своих внутренних IP-адресов. А драйвер нашего бэкенда пытался подключиться к этим IP, но не мог, потому что это внутренняя сеть партнёра.Мы не понимали, что с этим делать. В нашей команде вообще не было экспертизы в Kafka: в Городских сервисах она не используется.❇️ Как решили проблемуНам помог самый простой AI-промпт. В Kafka есть выделенный параметр advertised.listeners, который позволяет переопределять IP-адреса кластера Kafka. Мы попросили партнёра прописать на их стороне наши IP. И — о чудо! — всё заработало.🔶 В полном выступлении мы также рассказали, что ещё есть под капотом электромобиля. Спойлер: там не только батарея 64 кВт/ч и мотор на 200 лошадиных сил 🙃 А ещё мы объяснили, как работает Алиса в UMO и почему она может это делать даже без интернета. Смотрите видео на сайте Городских сервисов, ютубе и в VK Видео.Подписывайтесь:💬 @Yandex4Backend📹 @YandexforBackend

🏗️ infra.conf’26 уже сегодня: подключайтесь обсудить инфраструктуру, платформы и observability Совсем скоро встретимся, чтобы поговорить о высоких нагрузках, инструментах, базах данных, надёжности, доступности, управлении инцидентами и особенностях эксплуатации инфраструктуры в эпоху ML.Доклады начнутся в 11:00 мск. В программе:🟢 Как управлять доступами к 1500 системам (и без бутылочных горлышек)🟢 Зачем нужен механизм выгрузки метаданных объектов в S3 Inventory🟢 Как освободить разработчиков от рутины с помощью агентов и Kubernetes-операторов🟢 Что помогает перемещать десятки петабайт данных внутри S3🔶 Полное расписаниеПодключайтесь к трансляции на сайте конференции. Для тех, кто будет очно, дополнительно подготовили экспозону и несколько мастер-классов.🈯️ До встречи на infra.conf’26!Подписывайтесь:💬 @Yandex4Backend📹 @YandexforBackend

🛎 Приглашаем на Vertis Java MeetupЭто встреча разработчиков и инженеров от Яндекс Вертикалей. Мы обсудим практический опыт, новые подходы, реальные задачи и пообщаемся с коллегами и единомышленниками в неформальной атмосфере.Когда и где:📆 18 июня, 18:00📍 Екатеринбург, «Ельцин-центр»В программе:🟢 Как мы используем Temporal в Недвижимости. Герман Михайлов, бэкенд-разработчик в Яндекс Недвижимости, расскажет, как и зачем мы перешли с сервисов-scheduler’ов на Temporal. А также поделится, можно ли (не) построить космолёт на десятки тысяч workflow в секунду и во сколько обойдутся первоклассные наблюдаемость и отказоустойчивость🟢 CGLIB, Spring AOP и нарушение гарантий JVM. Михаил Черноскутов, бэкенд-разработчик в Яндекс Путешествиях, разберёт реальный случай, где NullPointerException возник на final-поле с инициализацией new ConcurrentHashMap<>(). И расскажет, как Spring через CGLIB создаёт прокси, почему final-методы могут обойти AOP-перехват и что происходит с инициализацией полей при low-level-инстанциации📟 А после докладов вас ждёт «Громкий вопрос» Это интеллектуально-юмористическая игра из одноимённого интернет-шоу. Каждый участник должен правильно ответить на поставленный вопрос. Но есть нюанс: игроки друг друга совсем не слышат! 🤯🔶 Зарегистрироваться на Vertis Java MeetupПодписывайтесь:💬 @Yandex4Backend📹 @YandexforBackend

🤩 Хотите узнать, о чём мечтали в детстве разработчики Яндекса? Мы тоже хотели, поэтому ко Дню защиты детей наши бэкенд-разработчики заполнили виртуальные анкеты. Мы задали вопросы, чтобы узнать об их детстве, первой написанной программе и школьной оценке по информатике. Спойлер: пятёрок по информатике было много, а преподавателем так никто и не стал 😄 👩‍⚕️ Давайте вместе посмотрим страницы из анкет в карточках выше! Подписывайтесь:💬 @Yandex4Backend📹 @YandexforBackend