Поговорили с&nbsp;разработчиками про создание и&nbsp;эксплуатацию систем и&nbsp;приложений, платформенную разработку, базы данных и&nbsp;облачные технологии, тестирование и&nbsp;безопасность, ML-инфраструктуру и&nbsp;опенсорс-решения. 

Практические кейсы от&nbsp;спикеров из&nbsp;крупных компаний: Яндекс, Ozon Tech, Авито, Т1, Альфа-Банк, Selectel, СберМаркет и&nbsp;SberDevices, Тинькофф, Postgres Pro, Лаборатория Касперского и&nbsp;других. 

Над программой конференции работали ключевые разработчики и&nbsp;техлиды команды Yandex Infrastructure, многие из&nbsp;них с&nbsp;опытом в&nbsp;индустрии более&nbsp;15&nbsp;лет.

Олег Бондарь

Анастасия Абрашитова

Николай Пирогов

Ильдар Каримов

Антон Кортунов

Андрей Глазков

Евгений Антонов

Саша Галкина

Сбор гостей (завтрак)

Шина данных уровня Яндекса требует нестандартных решений. Расскажем о&nbsp;том, как появился сервис YDB Topics, рассмотрим его архитектуру, причины отказа от&nbsp;Kafka, применённые оптимизации. И&nbsp;в&nbsp;заключение, как мы&nbsp;сделали Kafka API в&nbsp;режиме serverless.

YDB Topics: история взаимоотношений с&nbsp;Kafka

Перерыв

В Ozon используют S3 для разных задач, начиная от хранения картинок товаров для каталога, заканчивая бекапом баз данных. Мы храним десятки петабайт данных и обрабатываем сотни тысяч rps.

С&nbsp;ростом объёмов и&nbsp;нагрузок нас перестали устраивать opensource решения, такие как Ceph с&nbsp;RGW. В&nbsp;докладе я&nbsp;расскажу с&nbsp;какими проблемами мы&nbsp;столкнулись и&nbsp;как пытались их&nbsp;решать. Как мы&nbsp;спроектировали собственную реализацию&nbsp;S3, выбрали базу для хранения индекса и&nbsp;встроились в&nbsp;существующую архитектуру Ozon для максимально прозрачного переезда.

Расскажу и&nbsp;о&nbsp;проблемах с&nbsp;которыми мы&nbsp;столкнулись на&nbsp;разных этапах: при разработке, миграции и&nbsp;эксплуатации на&nbsp;реальной нагрузке. А&nbsp;еще о&nbsp;том, где мы&nbsp;смогли получить хороший выигрыш по&nbsp;использованию дисков, а&nbsp;где профит оказался меньше, чем мы&nbsp;рассчитывали.

Собственная реализация S3&nbsp;поверх Сeph&nbsp;&mdash; как мы&nbsp;научились предсказуемо работать с&nbsp;индексом и&nbsp;экономить место при тех&nbsp;же гарантиях

В&nbsp;рамках доклада мы&nbsp;разберём дизайн хранилища DNS-данных Яндекса, построенного поверх YTsaurus: посмотрим, какие требования предъявляются к&nbsp;такому хранилищу, какие буквы из&nbsp;CAP нам понадобятся, и&nbsp;как с&nbsp;решением задачи помогает объектная база данных YTORM, построенная поверх YTsaurus.

DNS over YTsaurus: как устроено хранилище DNS-данных всего Яндекса

Не&nbsp;существует масштабной инфраструктуры, которая имеет только линейные зависимости, на&nbsp;деле они часто неочевидные и&nbsp;хитросплетенные. Это затрудняет выполнение и&nbsp;постановку рабочих задач, поэтому необходимо иметь четкое понимание о&nbsp;взаимосвязях внутренних компонентов, что подразумевает их&nbsp;визуализацию и&nbsp;прозрачность. Мы&nbsp;расскажем о&nbsp;реализации предоставления этой неотъемлемой составляющей.

Потребитель и&nbsp;железка. Где связь?

Перерыв (обед)

Зачастую внутренние продукты развиваются без оглядки на&nbsp;данные. Какими функциями продуктов разработчики пользуются, а&nbsp;про какие даже не&nbsp;слышали? Какие задачи занимают слишком много времени? Какие сценарии можно упростить, а&nbsp;к&nbsp;каким все привыкли? Можно вооружиться статистикой, приложить небольшое усилие и&nbsp;получить много счастливых разработчиков. На&nbsp;примере поиска по&nbsp;интранету Яндекса расскажу&nbsp;&mdash; как мы&nbsp;делали метрику счастья пользователя, зачем проводить АБ-эксперименты и&nbsp;к&nbsp;чему это привело.

Зачем нужна продуктовая аналитика внутренних сервисов?

Вас ждёт рассказ о&nbsp;предпосылках выстраивания промышленной инфраструктуры. В&nbsp;докладе:

* погружение в предметную область ML и MLOps, для тех, кто пока не сильно знаком с ними;

* как выглядит целевая архитектура и&nbsp;инфраструктура для неё;

* какие &laquo;узкие горлышки&raquo; есть в&nbsp;архитектуре и&nbsp;как их&nbsp;можно расширить;

* какие могут возникать сложности в&nbsp;реализации. Также спикер поделится практическими бизнес-кейсами.

Промышленная инфраструктура AutoReTrain в&nbsp;реалиях крупного банка

* Что может переиспользовать&nbsp;DS от&nbsp;заводских промышленных линий?

* В&nbsp;чём специфика конвейеров обучения и&nbsp;инференса?

* Где необходимый уровень понимания ML-кода для выбора инфраструктуры?

* Как подбирать конфигурацию вычислительной инфры под профиль ML-нагрузки.

Непреодолимая легкость повышения утилизации GPU: Allocation и&nbsp;Profiling обычного человека

Нагрузочные тесты занимают много времени, а&nbsp;сами запуски часто заканчиваются провалом и&nbsp;результаты выбрасываются в&nbsp;мусорное ведро. В&nbsp;этом докладе расскажу о&nbsp;том, как мы&nbsp;обжигались на&nbsp;особенностях OS&nbsp;Linux, подкручивали power saving процессора, написали свой демон привязки ядер, читали умные книжки по&nbsp;математической статистике и&nbsp;что у&nbsp;нас из&nbsp;этого вышло (или пока выходит).

Улучшаем качество нагрузочного тестирования подкручивая инфраструктуру

При работе с&nbsp;резидентными базами данных применяются различные способы оптимизации производительности. Некоторые из&nbsp;этих способов можно было&nbsp;бы привнести и&nbsp;в&nbsp;Postgres.

В&nbsp;докладе рассматриваются следующие темы:

1. Pointer swizzling. Поиск по&nbsp;первичному ключу проходит длинный путь бинпоиском по&nbsp;страницам B-деревьев, распаковывая IndexTuple, TID, перекладывая страницы в&nbsp;разделяемые буферы, и, наконец, данных HEAP. На&nbsp;этой не&nbsp;самой прямой дороже есть пара мест, где можно срезать.

2. Более подходящие для кэширования структуры страниц. Бинарный поиск может затрагивать меньше строк кэша, а&nbsp;сама страница может иметь колоночную структуру (Partition Attributes Across layout).

3. Более оптимистичный подход к&nbsp;блокировке shared buffers: чтение без блокировки, сброс результата в&nbsp;случае каких-либо изменений.

Трюки in-memory баз данных в&nbsp;традиционных СУБД

Каждый сетевой пакет желает знать две вещи: как попасть в&nbsp;дата-центр и&nbsp;как его покинуть. Путь его лежит через L3&nbsp;балансировщики, файерволы, декапсуляторы. Обслуживание этой базовой части инфраструктуры обладает своей спецификой. В&nbsp;докладе рассмотрим причины появления необходимости в&nbsp;стандартизации, а&nbsp;так&nbsp;же причины, по&nbsp;которым победил облачный подход. В&nbsp;финале сделаем своё облако с&nbsp;dpdk и&nbsp;попыткой преодолеть кучу проблем монолитной инфраструктуры.

Как удобно жить на&nbsp;железе в&nbsp;2К24 базовой инфраструктуре

Обычно виртуальные машины используются в&nbsp;качестве нод кластера Kubernetes, но&nbsp;что если их&nbsp;поменять местами? И&nbsp;начать использовать платформу Kubernetes для запуска виртуальных машин наряду с&nbsp;обычными контейнерами. Машинами с&nbsp;различными операционными системами, еще и&nbsp;на&nbsp;отличающихся архитектурах. В&nbsp;каких случаях это может быть полезно? На&nbsp;каких технологиях это будет работать и&nbsp;как виртуальные машины будут интегрированы в&nbsp;экосистему Kubernetes?

Спикер расскажет возможные решения для запуска тестовых стендов с&nbsp;виртуальными машинами. А&nbsp;также покажет возможную интеграцию с&nbsp;сервисами из&nbsp;мира Kubernetes. И&nbsp;наконец про трансформацию платформы тестирования в&nbsp;Yandex Cloud.

Виртуальные машины в&nbsp;Kubernetes: как и (главное) зачем?

Service Mesh&nbsp;&mdash; это паттерн построения сетевого межсервисного взаимодействия, набравший популярность с&nbsp;распространением микросервисной архитектуры и&nbsp;ростом числа сервисов, которым надо общаться по&nbsp;сети. Типичный Service Mesh состоит из&nbsp;двух частей: Control Plane&nbsp;&mdash; сервис, отвечающий за&nbsp;построение карты сети, и&nbsp;Data plane&nbsp;&mdash; чаще всего, это sidecar proxy, принимающий конфигурацию с&nbsp;Control Plane и&nbsp;непосредственно отвечающий за&nbsp;обработку запросов к&nbsp;сервису и&nbsp;от&nbsp;него.

В&nbsp;Плюс Фантехе мы&nbsp;строим Service Mesh под названием Buckyball. Мы&nbsp;реализовали свой собственный Control Plane на&nbsp;основе k8s для хранения спецификаций узлов сети и&nbsp;построения единой карты. На&nbsp;Data plane мы&nbsp;используем Envoy в&nbsp;качестве sidecar proxy, а&nbsp;также нашего демона buckyball_d, который взаимодействует с&nbsp;Control Plane, реализует внутренний протокол Service Discovery, а&nbsp;также протокол XDS для динамического обновления конфигурации Envoy.

Наша цель&nbsp;&mdash; реализовать на&nbsp;уровне Service Mesh основные требования к&nbsp;сетевому взаимодействию между сервисами: балансировка трафика, межсервисная аутентификация, end to&nbsp;end TLS, observability и&nbsp;reliability, и&nbsp;многое другое. Мы&nbsp;тесно интегрированы с&nbsp;системой Infrastructure as&nbsp;Code, развиваемой в&nbsp;Яндексе, что позволяет нам подключать сервисы всего несколькими строчками YAML&nbsp;конфигурации. При этом все связи между сервисами декларативны, хранятся в&nbsp;репозитории и&nbsp;живут одной жизнью с&nbsp;кодом самих сервисов.

В&nbsp;настоящее время Buckyball активно внедряется в&nbsp;Яндекс Музыке, Кинопоиске и&nbsp;Сказбуке, а&nbsp;так&nbsp;же пилотируется в&nbsp;нескольких других сервисах Плюс Фантеха, и&nbsp;даже за&nbsp;его пределами.

One mesh to&nbsp;rule them all: история внедрения Service Mesh в&nbsp;сервисах Плюс Фантеха

На&nbsp;дворе уже середина 2024 года и&nbsp;мы&nbsp;все чаще слышим об&nbsp;использовании инструмента Cluster API для управления жизненным циклом Kubernetes кластеров. Наша команда тоже не&nbsp;стала исключением и&nbsp;перешла с&nbsp;использования собственной обвязки вокруг RKE и&nbsp;Terraform на&nbsp;него (и&nbsp;даже написала парочку своих infra провайдеров).

В&nbsp;ходе доклада затронем следующие темы:

* Откуда вообще взялся RKE и&nbsp;причем тут terraform?

* В&nbsp;какой момент решение изжило себя, каких проблем хотелось избежать в&nbsp;чудесном новом мире?

* Покомпонентно сравним старый и&nbsp;новый процесс управления кластерами.

* Рассмотрим те&nbsp;новые фичи, которые привнес с&nbsp;собой CAPI.

Внедрение ClusterAPI&nbsp;&mdash; стоит&nbsp;ли овчинка выделки?

Микросервисная архитектура в&nbsp;действии. Гибкая адаптация пот техническую задачу. Заказчик ставит новые требования, архитектура готова к&nbsp;вызовам. Управление on-prem решением через призму DevOps-практик и&nbsp;инструментов. Примеры Update, Backup/Restore, Scale in/out, Scale up/down. Насколько далеко может зайти разработка&nbsp;ПО в&nbsp;парадигме DevOps и&nbsp;Agile. Строили SaaS решение, использовали типичные SDLC процессы и&nbsp;практики. Собрали on-prem коробку, добавили в&nbsp;неё инструменты и&nbsp;процессы. Получилась автономная фабрика ПО + CI/CD, которой может управлять администратор.

CI/CD кунг-фу в&nbsp;онпреме. Поставка ПО&nbsp;в&nbsp;окружение заказчика вместе с&nbsp;CI/CD процессами из&nbsp;коробки (на&nbsp;примере SaluteJazz)

В&nbsp;докладе расскажу о&nbsp;специфике тестов в&nbsp;Kaspersky, и&nbsp;почему пришлось писать свою автотестовую систему. Поделюсь общими терминами и&nbsp;расскажу о&nbsp;том, как наша система исполняет тесты. Поговорим о&nbsp;разных типовых (и&nbsp;не&nbsp;очень) сценариях использования, а&nbsp;также о&nbsp;некоторых технических деталях эксплуатации.

Собственная автотестовая система Hive

Локальное окружение&nbsp;&mdash; это боль. Часто&nbsp;ли вы&nbsp;слышали фразу &laquo;у&nbsp;меня локально все работает&raquo;? DevOps культура научила нас схлопывать окружения для прода, пре-стейбла, тестирования. Или делать их&nbsp;идентичными. А&nbsp;как&nbsp;же Dev окружения? Что если&nbsp;бы мы&nbsp;имели возможность стандартизировать&nbsp;их? Dev окружение должно быть единым&nbsp;и, возможно, близким к&nbsp;проду. Ремоутная разработка имеет ряд проблем в&nbsp;стабильности. При чём&nbsp;же здесь Managed DevEnv или среда разработки как сервис? Расскажем про плюсы и&nbsp;минусы, возможности Codenv. Поделимся историями успеха.

DevEnv как сервис

Из&nbsp;доклада вы&nbsp;узнаете:

* существует ли разница подходов классического DR & Cloud Native DR;
* что скрывается за HA и почему это не DR;
* что такое disaster avoidance;
* основные стратегии восстановления в Cloud;
* Cloud Agnostic как следующий шаг disaster avoidance.

Современный мир Cloud Native и подходы к его аварийному восстановлению

Аварии случаются у&nbsp;всех. Иногда это небольшие инциденты. Иногда большие и&nbsp;страшные.

Каждая такая авария&nbsp;&mdash; это стресс для инженеров и&nbsp;пользователей.

Мы&nbsp;решили сделать &laquo;оружие последнего шанса&raquo;&nbsp;&mdash; fallback систему, позволяющую прикрыть Авито закешированным всем.

В&nbsp;докладе мы&nbsp;рассмотрим:

* дизайн такой системы;

* проблемы, с&nbsp;которыми мы&nbsp;столкнулись в&nbsp;ходе реализации;

* подходы к&nbsp;обеспечению качества такого кеширования;

* подходы к&nbsp;масштабированию;

* метрики успешности.

Static-Fallback

Инженерные истории  
со&nbsp;смыслом. Всё&nbsp;про&nbsp;создание  
инфраструктуры и&nbsp;эксплуатацию  
высоконагруженных систем

infra.conf

Алексей Башкеев

Развитие инфраструктуры&nbsp;&mdash; бесконечный процесс. Мы&nbsp;15&nbsp;лет делаем фундамент из&nbsp;технологий, на&nbsp;которых работает весь Яндекс, используем лучшие инженерные практики, понимаем их&nbsp;плюсы и&nbsp;минусы. Нам есть чем поделиться с&nbsp;сообществом&nbsp;и, конечно, чему научиться у&nbsp;других.  
Поэтому мы&nbsp;решили создать площадку для обмена опытом с&nbsp;экспертами из&nbsp;компаний, которые решают похожие задачи. Именно так появилась конференция infra.conf.

infra.conf&nbsp;&mdash; всё про создание инфраструктуры и&nbsp;эксплуатацию высоконагруженных систем

Yandex Infrastructure

Новости команды, статьи, анонсы мероприятий и&nbsp;многое другое

Telegram-канал

Собираем IT-специалистов, обмениваемся опытом и&nbsp;лучшими практиками

Чат в&nbsp;Telegram

Приглашаем разработчиков, сетевых инженеров, DevOps и&nbsp;SRE специалистов, а&nbsp;также всех, кому интересны open source продукты&nbsp;&mdash; на&nbsp;митап команды Yandex Infrastructure в&nbsp;Новосибирске.

Расскажем о&nbsp;том, как мы&nbsp;создаём и&nbsp;развиваем платформу для эффективной работы разработчиков Яндекса.

Поговорим про систему контроля версий Arc, сервисы платформы для работы с&nbsp;данными (YDB)&nbsp;&mdash; таблицы и&nbsp;топики. А&nbsp;также про особенности сборки и&nbsp;тестирования в&nbsp;монорепозитории большой компании.

Помимо докладов запланирована нетворкинг-сессия с&nbsp;едой и&nbsp;напитками&nbsp;&mdash; для знакомства, ответов на&nbsp;вопросы и&nbsp;неформального общения.

Участие бесплатное, но&nbsp;необходима регистрация.

Митап Yandex Infrastructure

Приглашаем backend разработчиков, DevOps и&nbsp;SRE инженеров на&nbsp;Yandex Infrastructure Meetup в&nbsp;Екатеринбурге.

Расскажем о&nbsp;том, как мы&nbsp;создаём и&nbsp;развиваем платформу для эффективной работы разработчиков Яндекса. Поговорим про приватное контейнерное облако, использование простаивающих ресурсов во&nbsp;внутреннем облаке Яндекса и&nbsp;про YTsaurus&nbsp;&mdash; платформу для обработки и&nbsp;хранения больших данных.

Помимо докладов запланирована нетворкинг-сессия&nbsp;&mdash; для знакомства, ответов на&nbsp;вопросы и&nbsp;неформального общения.

Участие бесплатное, но&nbsp;необходима регистрация.

Приглашаем backend разработчиков, сетевых инженеров, DevOps и&nbsp;SRE инженеров, а&nbsp;также всех, кому интересны open source продукты Яндекса&nbsp;&mdash; на&nbsp;митап команды Yandex Infrastructure.

Расскажем о&nbsp;том, как мы&nbsp;создаём и&nbsp;развиваем платформу для эффективной работы разработчиков Яндекса.

Поговорим про устройство сети Yandex Cloud, Nirvana&nbsp;&mdash; вычислительную платформу Яндекса, а&nbsp;также про использование технологии SRv6.

Помимо докладов запланирована нетворкинг-сессия с&nbsp;едой и&nbsp;напитками&nbsp;&mdash; для знакомства, ответов на&nbsp;вопросы и&nbsp;неформального общения.

Участие бесплатное, но&nbsp;необходима регистрация.

Приглашаем разработчиков бэкенда, инженеров DevOps и&nbsp;SRE на&nbsp;митап Yandex Infrastructure в&nbsp;Минске.

На&nbsp;встрече расскажем, как мы&nbsp;создаём и&nbsp;развиваем платформу для разработчиков Яндекса.

Поговорим про систему контроля версий Arc, сетевую инфраструктуру Yandex Cloud и&nbsp;сервисы платформы для работы с&nbsp;данными (YDB)&nbsp;&mdash; таблицы и&nbsp;топики.

Помимо докладов запланирована нетворкинг-сессия с&nbsp;едой и&nbsp;напитками&nbsp;&mdash; для знакомства, ответов на&nbsp;вопросы и&nbsp;неформального общения.

Приглашаем разработчиков, DevOps и&nbsp;SRE специалистов, а&nbsp;также всех, кому интересны open source продукты&nbsp;&mdash; на&nbsp;митап команды Yandex Infrastructure в&nbsp;Нижнем Новгороде.

Расскажем, как мы&nbsp;создаём и&nbsp;развиваем внутреннюю инфраструктуру&nbsp;&mdash; фундамент из&nbsp;продуктов и&nbsp;технологий, которые помогают разрабатывать, деплоить и&nbsp;эксплуатировать все основные сервисы Яндекса.

Помимо докладов запланирована нетворкинг-сессия с&nbsp;едой и&nbsp;напитками&nbsp;&mdash; для знакомства, ответов на&nbsp;вопросы и&nbsp;неформального общения.

Участие бесплатное, но&nbsp;необходима регистрация.

DevPlatform Party

Nexthop

Приглашаем разработчиков, SRE и DevOps инженеров на митап команды Yandex Infrastructure в Санкт-Петербурге.

Расскажем, как мы создаём и развиваем внутреннюю инфраструктуру - фундамент из продуктов и технологий, которые помогают разрабатывать, деплоить и эксплуатировать все основные сервисы Яндекса.

Помимо докладов запланирована нетворкинг-сессия с едой и напитками – для знакомства, ответов на вопросы и неформального общения.

Участие бесплатное, но необходима регистрация.

Митап Yandex Infrastructure в Санкт-Петербурге

Я.Субботник — технологическое мероприятие, основная аудитория которого — разработчики и технические специалисты. 
 
17 февраля команда Yandex Infrastructure провела очередную встречу, посвящённую инфраструктуре.  

Рассказали, как в Яндексе создают и развивают внутреннюю инфраструктуру, которая помогает разрабатывать, деплоить и эксплуатировать сервисы компании. Поговорили про подходы и сложности построения инфраструктуры, про устройство сети Yandex Cloud, монорепозиторий, опенсорс-продукты YDB и YTsaurus, стораджи и многое другое. 


Я.Субботник по&nbsp;инфраструктуре

Core Infrastructure Bootcamp

В начале июня 2024 года проведём большую конференцию Яндекса по инфраструктуре. Мероприятие пройдёт в гибридном формате — присутствовать можно будет как офлайн в Москве, так и онлайн.

Приём заявок на выступление уже открыт — будем рады видеть вас в качестве спикеров!

Ключевые темы:
- Platform engineering — создание и поддержка инфраструктуры и платформ для эффективной разработки и разработчиков. Собственные vs вендорские решения
- DevOps-практики и культура, включая DevNetOps и DevSecOps
- Эксплуатация систем: управление конфигурациями, SRE, доступность, отказоустойчивость, мониторинг, логирование, наблюдаемость систем, тестирование, безопасность
- Аппаратное обеспечение, умные устройства 
- Базы данных и хранилища
- Инструменты коллаборации, разработка и эксплуатация
- Инфраструктура и аналитика ML

Принимаем заявки до 1 апреля. С ответом вернёмся не позднее 10 апреля.

По любым вопросам, пожалуйста, пишите Саше Галкиной: galkinaal@yandex-team.ru / tg @nu_saash.


Конференция Яндекса по инфраструктуре — Приём докладов закрыт

Yandex Platform Engineering Bootcamp

В&nbsp;этом году вас ждут два трека докладов, Q&amp;A сессии со&nbsp;спикерами и&nbsp;много нетворкинга

В&nbsp;этом году будет два трека докладов: Enterprise Networks и&nbsp;Common Network Topics

Конференция  
по_сетевым_технологиям

Москва  
и_онлайн

Enterprise networks

Network security

Enterprise Wireless

Common Network Topics

nexthop

Сайт Yandex Infrastructure

Хабр

YouTube

и&nbsp;чат

2018

2019

2020

2021

2022

2023

Как это было

Ошибка

Команда Yandex Infrastructure создаёт и&nbsp;предоставляет внутреннюю инфраструктуру Яндекса&nbsp;&mdash; фундамент из&nbsp;продуктов и&nbsp;технологий, на&nbsp;базе которого тысячи инженеров разрабатывают, деплоят и&nbsp;эксплуатируют основные сервисы Яндекса: Поиск, Такси, Маркет, Алису, Кинопоиск и&nbsp;многие другие.

404

Другие мероприятия

Core Infrastructure Bootcamp

Yandex Platform Engineering Bootcamp

nexthop