Доклады

Как повысить безопасность своего кода при помощи чистых функций? Подойдет ли Go для любителей «функциональщины»?

Многие элементы функционального программирования давно применяются в Go и других языках. Но часто эти подходы не упоминаются. Я покажу, что несмотря на свою «математичность», оно проще, чем кажется на первый взгляд.

В докладе обсудим разные типы функций, «чистоту», посмотрим на ФП-код с точки зрения производительности, тестируемости и поддержки.

Поговорим о том, как внедрить подход к проектированию, при котором приложение разбивается на независимые сервисы, каждый из которых выполняет свою конкретную задачу. Проработаем все ошибки, которые делают разработчики при подготовке к внедрению данного подхода.

Пройдем весь путь — от формулирования цели, зачем нужны микросервисы, и что мы об этом знаем, до внедрения и работы с возможным сопротивлением.

Разработчикам довольно часто хочется переписать легаси-проект по красоте. Неизменно возникает вопрос: а «по красоте» — это как? Для ответа на этот вопрос прибегают к помощи широко известных подходов «Чистая Архитектура», «Гексагональная Архитектура» и «Предметно Ориентированное Проектирование (DDD)».

Но так ли просто переписать проект, следуя этим подходам на Go? Как язык может в этом помочь и как он может мешать? А, возможно, Go не так уж хорош для реализации сервисов с чистой архитектурой и DDD, а Rust, несмотря на свою «низкоуровневую природу», наоборот, подходит лучше?

С этими вопросами мы постараемся разобраться на докладе с высоты нашего практического опыта рефакторинга сервиса на Go.

Профессия разработчика быстро эволюционирует, а скрипт собеседований, кажется, не успевает за этой эволюцией. Зачем мы пишем на собеседованиях одинаковые задачи с литкода, рассказываем теорию про отличие тредов и горутин, и как работает garbage collector (будто бы собеседующий сам знает ответ)? Почему на каждом втором собеседовании просят спроектировать сокращатель ссылок? Почему вроде стараешься, вкладываешься, а зарплату повышают коллеге, который больше нравится продакту?

Попробую разобрать эту тему как менеджер: что на самом деле важно в разработчике, как это измерить в работе и как проверить на собеседовании. Поговорим про ожидания от разработчика на разных грейдах. Будет масса примеров кода — как надо и как не надо. Из этого нарисуем матрицу компетенций и посмотрим, как эти вещи проверяют на технических интервью.

Бонус: задачи для собеседований, которые не решает ChatGPT, и матрица компетенций для оценки своего уровня.

WebAssembly (WASM) представляет собой виртуальную машину, предназначенную для выполнения высокопроизводительного кода, написанного на различных языках программирования, не только в браузере, но и в других средах. Хотя WASM изначально разрабатывался для веб-приложений, его потенциал выходит далеко за пределы браузеров, открывая новые возможности для создания кросс-платформенных приложений и сервисов.

Golang стал одним из первых языков, поддерживающих WASM, и в настоящее время занимает одно из ведущих мест среди языков с хорошей поддержкой этой технологии. В данном докладе мы сосредоточимся на внебраузерных применениях WASM, обсудим, как правильно подготавливать Go-приложения для запуска в WASM-рантайме, а также рассмотрим сложности, с которыми сталкиваются разработчики. Мы уделим внимание подводным камням, связанным с интеграцией Go с WASI (WebAssembly System Interface), и обсудим текущие вызовы, мешающие разработчикам компилятора Go поддерживать актуальные стандарты и расширять функциональность вне браузера.

Мы в Т-Банке активно используем Go в качестве языка для разработки ML-приложений. В этом докладе мы поговорим про backend-часть, ведь ML не заканчивается на обучении. Мы не будем говорить о том, как устроены модели, чаще всего для backend-разработчика они являются «чёрными ящиками», строительными блоками, такими же как очередь или база данных. Но реальное ML-приложение, такое, например, как система распознавания речи, синтеза речи или голосовой биометрии — это несколько моделей + бизнес-логика. Также для разных запросов может потребоваться разный набор моделей, поэтому ML-приложение имеет нестандартную архитектуру.

В докладе мы:
* вспомним, что такое пайплайны;
* почему ML-приложение можно представить как пайплайн из моделей;
* напишем небольшое приложение на примитивах языка без использования дополнительных библиотек;
* напишем небольшое приложение на нашей собственной библиотеке;
* обсудим, какую пользу мы получили в команде от использования собственной библиотеки пайплайнов.

Когда нам приходится работать в многоядерных системах, где доступно значительно больше ядер, чем привычные 4 или 8, то стандартные подходы и даже стандартная библиотека могут не обеспечивать достаточной производительности. Поговорим о том, как в таких условиях выжимать максимум из доступного CPU.

Из доклада вы узнаете:
* почему и когда стоит шардировать работу с atomic-значениями и с map;
* зачем нужны такие алгоритмы, как biased locking for reader writer locks;
* что такое оптимистичное чтение и когда его можно использовать.

Мы также рассмотрим протокол MESI, работу кэша CPU и способы его эффективного использования.

Расскажу, как можно ускорять код, используя абстрактный ассемблер Go. Разберу часто используемые SIMD-инструкции, покажу, как можно пользоваться инструкциями, которые не поддержаны из коробки, затрону gccgo и Cgo. Приведу и разберу примеры программ.


Подготовительные материалы:
https://www.youtube.com/watch?v=KINIAgRpkDA
https://habr.com/ru/companies/badoo/articles/317864/ (дублирующая статья)
https://habr.com/ru/companies/vk/articles/358088/
https://go.dev/doc/asm

Когда мы начали заниматься фаззингом в Go, готовых решений не существовало — нам пришлось стать первопроходцами и разрабатывать всё с нуля. Сегодня наш опыт служит основой для других команд в YADRO.

В своём докладе я поделюсь лучшими практиками по выбору и настройке инструментов фаззинга для Go. Рассмотрю неочевидные проблемы и дам полезные советы, которые не найти в открытых источниках. После выступления вы сможете легко писать и запускать фаззинг-тесты для ваших продуктов, а не только для учебных задач. Приходите узнать, как сделать фаззинг неотъемлемым элементом вашей разработки на Go!

Часто ли вы сталкивались с необходимостью при чтении чужого пулл-реквеста переходить в полноценную IDE, потому что в веб-платформе не хватает нормальной навигации по коду? А задумывались, откуда эта проблема и как её решить? Расскажем о том, как подошли к решению этой задачи в новой платформе для разработчиков SourceCraft от Яндекса.

Мы сделали систему инкрементальных индексов на каждый коммит для поиска декларации/использований кода в репозитории. Открываешь коммит — и поиск работает моментально, ничего на стороне клиента/сервера не надо перестраивать.

Работая с любой платформой для разработчиков, мы постоянно пополняем кодовую базу своего проекта. Каждый коммит порождает новую версию модели кода и ее индексов. Все подобные инструменты сталкиваются с этой проблемой, и чаще всего никто не берётся за её решение. Мы в Яндексе при разработке собственной платформы для разработчиков SourceCraft решили эту задачу. Для этого разработали свою систему индексов, основанную на иммутабельных инкрементальных структурах данных. В докладе поделимся архитектурными приёмами, какие структуры данных нужны для различных сценариев и как мы их храним.

Далее рассмотрим конкретные примеры индексов, необходимых для решения задач навигации по коду. Обсудим отличия от IDE и к каким техническим решениям это приводит. Детально разберем алгоритмы под капотом нашей системы.

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

Как мы можем помочь компилятору делать свою работу лучше? Какие трюки из старой школы еще актуальны для Golang? Какие нюансы рантайма стоит учитывать в процессе разработки? Давайте вместе попробуем разобраться во всех этих вопросах и узнать, насколько глубока нора преждевременных оптимизаций.

Расскажем о задаче (CDN на Go).
* Почему на Go.
* Кратко: как оно работает?
** упирались в Х — решили так.
** упирались в Х2 — решили так

Уперлись в TLS — стали терминировать hitch, но и в него уперлись.

Тут поговорим кратко о том, как, чем и зачем его можно терминировать. Почему стандартный Go не справился, и почему решили «править» его, а не уйти с Go вообще (но думали).

Собственно, тут и будем говорить по гошный TLS и TLS вообще, как он работает, какие способы есть его «прокачать».

Как итог, с «и 40 Gbps — уже боль», мы отдаем 100 с достаточно старого железа.

Go отлично подходит для оркестрации сложных взаимодействий. Однако в языке не всегда достаточно возможностей с точки зрения оптимизации ресурсов, например, памяти и процессорного времени. Мы пишем свою систему мониторинга и стремимся минимизировать нагрузку от неё на наблюдаемую систему. Значительную часть логики по компрессии и обработке данных мы написали на C++, но взаимодействие получившегося ядра с основным кодом на Go могло свести на нет все оптимизации.

В докладе мы подробно разбираем работу шедулинга горутин и устройство моста между Go и С/С++. Слушатели узнают, как мы отслеживаем аллокации памяти и сопрягаем данные между языками.

Задумывались ли вы когда-нибудь о том, что такое мьютексы и атомики на самом деле? И как они устроены под капотом? И зачем вообще нужны, если формально при записи переменной эта запись условно атомарна? Или не совсем?

Заходите на доклад, и я немного напомню вам, что творится в процессоре, когда мы запускаем конкурентный код, и нырнем в глубины Gо поближе к процессору.

CGо — это мощный и удобный инструмент, позволяющий вызывать любые функции на C/C++, не опасаясь блокировки своей Go-программы. Однако за это удобство приходится расплачиваться в случае неблокирующих вызовов, таких как асинхронные операции в ядре ОС или числодробительные задачи (сжатие/распаковка, криптография, математические расчеты и т. д.).

Помимо накладных расходов на каждый вызов C, нас также может ожидать неожиданная просадка производительности при обработке больших объемов данных. Кроме того, использование CGо может привести к потере гарантий на время исполнения горутин.

В докладе мы разберем случаи, когда CGо может негативно сказаться на производительности проекта. Обсудим, как Go внутри своего рантайма «экономит» на неблокирующих вызовах, как мы можем использовать эти механизмы, а также рассмотрим другие обходные пути.

Доклад посвящен основам механической симпатии: как работа процессора с памятью и кэшем отражается на производительности Go-приложений. Обсудим важность принципов локальности и методы оптимизации представления данных. Рассмотрим метод оптимального обмена информацией между горутинами с учётом конкурентности в многоядерных системах и согласованности кэша. Разберемся, как проектирование кода с учетом архитектуры процессора может дать ускорение до 30% без значительных изменений кода.

В докладе будут рассмотрены ключевые аспекты авторизации и причины платформизации этого решения. Мы обсудим, зачем нужна авторизация и какие преимущества даёт платформенный подход к управлению доступом. Уделим внимание сравнению двух моделей авторизации — RBAC (ролевая) и ABAC (атрибутивная), а также их применению в разных сценариях.

Далее мы разберём различные подходы к реализации авторизации, начиная от хардкода и заканчивая использованием декларативных языков, таких как CEL и Rego. В заключение будет рассмотрен процесс организации платформы контроля доступов: как осуществляется генерация политик, интеграция клиентов и проверка доступов к ресурсам.

В своем докладе я сравню разные инструменты для генерации моков интерфейсов в Go. Возьмем наиболее популярные генераторы моков: Mockery, Gomock, Minimock — и посмотрим на практических кейсах плюсы и минусы каждого из них по сравнению с аналогами, удобность и сложность использования, а также бестпрактис по написанию юнит-тестов с моками. И попробуем ответить на вопрос, какой же мокер самый лучший?

Конкурентность в Go открывает широкие возможности, но также и представляет риск «выстрелить себе в ногу» — от обращения горутин к одним и тем же данным до проблем с work-stealing. В этом докладе мы рассмотрим, как дополнить и расширить идеи из выступления Роба Пайка по конкурентности в Go.

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

Что вы получите на выходе?
* Четкий алгоритм построения конкурентных приложений в Go.
* Понимание, как выбирать правильные паттерны конкурентности в зависимости от задачи.
* Практические советы по избеганию распространенных ошибок при разработке конкурентных систем.

В мире микросервисов часто возникает необходимость сделать согласованные изменения в разных сервисах. На докладе будет рассмотрен один из подходов — сага.

Объясню, из чего состоит сага, какие есть нюансы в работе с ней и, самое главное, — покажу, как это можно выразить в коде на Go. Вы увидите реальное использование саги, а не умозрительные примеры из статей. Объясню, почему мы сделали именно так, и от каких вариантов отказались.

Temporal набирает популярность, и большие компании чаще начинают его использовать для решения своих задач. Довольно частый кейс использования — это процессинг заказов и платежей, чуть реже — сборка и деплой сложных релизов, еще реже — специфичный бэкенд для чат-бота. Но сегодня я хочу посмотреть чуть шире на Temporal и предложить его для реализации MVP, когда вместо сервисов мы используем только Temporal Workflow.

В этом мастер-классе я вместе с вами напишу бэкенд для фудтех-приложения, где большая часть бизнес-логики будет реализована на Temporal. Мы рассмотрим процесс написания и проектирования Workflow, реализуем пачку активити, сделаем синхронные и асинхронные обновления, покроем это метриками и подумаем, можно ли это масштабировать.

* Обсудим, зачем в Go добавили новый и весьма нетривиальный функционал — итераторы, также называемый range over funcs.
* Посмотрим на бенчмарки: быстрые ли итераторы? Быстрее каналов или медленнее?
* Как их использовать, где могут быть полезны, в чем была мотивация их добавлять в язык.

В этом докладе я расскажу, какие проблемы возникли у нас при эволюционном развитии нашего сервиса и почему это стало тормозом в развитии. О том, как мы изменили архитектуру так, чтобы клиентские сервисы всегда содержали свежую версию данных. Какие решения потребовалось принять для этого. И как Go помог нам быстро реализовать центральный компонент новой системы поставки данных.

У нас стояла задача по локализации китайского гитхаба в РФ. Представьте, что вам надо каждый день реплицировать сотни, а то и тысячу репозиториев и сопутствующих материалов, а потом еще и переводить их, да еще и сленг учитывать. Вот, пришлось писать целую систему.

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

Мы рассмотрим в докладе три основные стратегии работы с gRPC в WEB-разработке: gRPC-Web, Buf Connect и gRPC-Gateway. Обсудим их ключевые преимущества и недостатки, а также проведем детальное сравнение производительности с помощью бенчмарков на базе k6. В завершение мы поделимся экспериментальными подходами для улучшения производительности gRPC-Gateway, включая использование кастомных маршаллеров и оптимизаций на уровне генератора.

Хоть я и не написала ни одной строчки на Go, тысячи Go-разработчиков по всему миру используют мой продукт.

Дизайнеры — люди, от которых меньше всего ждут вклада в Open Source, и зря!

Моя любовь к доступным продуктам и продуктовый подход позволили создать уникальную и успешную историю. У маскота языка Go изначально отсутствовала мимика, был скудный набор изолированных иллюстраций и неудобная лицензия. Сейчас Free Gophers Pack хорошо знаком многим гоферам и широко используется в комьюнити.

Расскажу, как появился и развивался проект, чем мне помог продуктовый подход и почему к Open Source имеет смысл привлекать не только тех, кто умеет кодить. А также почему я сменила лицензию и как это все помогает котикам.

У нас было три монолита на PHP, по 180 минут на выкатку каждого, 30 минут на обновление наличия товара на сайте, полсервиса на Go и PHP, множество джоб всех сортов и расцветок, а также Docker, Cobra, целая куча репозиториев в GitLab, пинта чистого Kubernetes и Terraform. Не то чтобы это был необходимый арсенал для разработки, но если начинаешь собирать удобный деплой, становится трудно остановиться. Единственное, что вызывало опасение, — это сервисная архитектура. Нет никого более беспомощного, безответственного и испорченного, чем разработчики и архитекторы, пытающиеся определить границы предметных областей и не создать новый монолит при распиле старого. Но мы знали, что рано или поздно окунемся и в это.

Чаще всего мы, как Gо-разработчики, пишем всевозможные микросервисы. И уже давно все привыкли, что управляет ими некий монстр под названием Kubernetes. Он автоматически переподнимет наш упавший под, поможет скалировать сервис и многое другое. А что кубер не делает автоматически, то по старинке делается ручками.

Однако существуют операторы, которые позволяют автоматизировать буквально что угодно.

А что сегодня используется для написания операторов? В подавляющем большинстве случаев это будет kubebuilder или operator-sdk, и оба используют библиотеку kubernetes-sigs/controller-runtime как основу.

Доклад посвящен обзору внутреннего устройства библиотеки controller-runtime, пониманию тонкостей функционирования отдельных её частей и их влиянию на разработку Kubernetes-операторов. Знание внутренних механизмов позволит иначе взглянуть на вопросы оптимизации производительности и повышения надежности операторов, построенных на базе CR.

В рамках доклада расскажу про:
* компоненты controller-runtime — Manager, Controller, Reconciler, Client и другие, их связь и внутреннее устройство;
* жизненный цикл контроллера, механизм доставки уведомлений и др.;
* подводные камни и грабли, которые могут встретиться при разработке операторов, варианты их обхода и способы оптимизации.

При разработке масштабных проектов задачи по генерации кода возникают неизбежно. Каждый раз, переходя от одного проекта к другому, сталкиваешься с теми же вопросами и проблемами. За двадцать лет своей карьеры я многократно создавал генераторы кода без «без фатального недостатка».

В своём докладе я поделюсь историями и открытиями из своего опыта, начиная со студенческих лет и заканчивая настоящим временем. Расскажу о том, что мне зашло, и о моментах, в которых стоит «подстелить соломку».

Ежедневно платформа умного дома Sber обслуживает сотни тысяч открытых долгоживущих соединений с устройствами пользователей, чтобы обеспечивать опыт управления устройствами в реальном времени 24/7. Характер такой нагрузки существенно отличается от привычного в вебе паттерна «запрос – ответ», что формирует определенную специфику проектирования и сопровождения такого бэкенда. Примерно год назад мы прошли долгий путь, состоящий из инцидентов и улучшений, об этом и будет доклад.

В этом докладе расскажу:
* как понять, что текущая система перестает устраивать;
* как выбрать подходящие инструменты и научиться сравнивать их;
* как готовить приложения на Go и работать с профилировщиками нагрузки;
* как выглядит инфраструктура api-gateway за пределами приложения;
* с какими проблемами можно столкнуться и как их обнаружить.

Мир машинного обучения быстро развивается, предлагая множество новых инструментов и возможностей. Однако большинство из них ориентированы на другие языки программирования. А что же современные библиотеки предлагают для Go-разработчиков?

Давайте узнаем!

Хорошему разработчику может быть сложно стать тимлидом. Потому что для руководителя это риск: можно потерять хорошего разработчика и получить плохого лида.

Повышение до лида — это более серьезное изменение, чем просто повышение грейда. Чтобы это случилось, нужно проявлять другие качества. Хороших технических скилов недостаточно.

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

Сделаем «живое» демо нагрузочного тестирования Valkey, Redis, Memcached, PostgreSQL, MySQL и, может быть, ещё чего-нибудь, если успеем.

В Авито у нас несколько тысяч микросервисов, десятки команд разработки и единая платформа, на основе которой делаются все наши микросервисы. Из доклада вы узнаете, как наша команда ArchGovernance помогает разобраться во всём этом архитектурном хаосе и позволяет найти ошибки в архитектуре при помощи инструмента arch-rater.

Я расскажу:
* как мы обрабатываем 5 миллионов трейсов;
* как строим карту взаимодействия между нашими микросервисами и какие инструменты для этого используем;
* какие способы анализа этой карты мы используем, чтобы находить проблемы в архитектуре и повышать надёжность.

Картинки — это часть поиска Яндекса, работающая с визуальным контентом и обрабатывающая более 10 000 тяжёлых запросов в секунду с помощью десятков тысяч CPU в рантайме. Мы расскажем, как, столкнувшись с необходимостью масштабирования сервиса, с помощью ML в сочетании с архитектурными изменениями смогли не только увеличить пропускную способность в ~2 раза на том же железе, но и дать инструмент для более гибких продуктовых внедрений.

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

API Gateway — широко распространённая технология, которую применяют многие компании. Каждый делает это по своему и закладывает разный функционал в него.

В этом докладе я расскажу, какой API Gateway создали мы в Авито, что в него заложили, какие подходы применили.

Гибридный поиск — это сочетание классического полнотекстового поиска и векторного поиска. Я расскажу, как мы в Т-Банке внедряли гибридный поиск, какие проблемы пришлось решать и какой результат мы получили.

Наш поиск реализован на базе OpenSearch. Для улучшения полноты поиска мы реализовали отдельный сервис векторного поиска на базе векторной БД Qdrant. В докладе я затрону следующие темы: что такое векторный поиск, что такое векторные БД, какую проблемы мы хотим решить с помощью векторного поиска, как векторный поиск устроен у нас, как смешивать результаты полнотекстового и векторного поиска.

В большой компании число микросервисов, участвующих в обработке пользовательского запроса может составлять несколько сотен, а иногда даже и тысяч. В такой ситуации встает вопрос, как организовать их взаимодействие и не потеряться в логике обработки запроса.

В Яндексе для этого разработали собственное решение - AppHost.

Мы расскажем:
* как работает Аппхост и какие проблемы он решает;
* каким образом мы всегда можем посмотреть, из чего состоит запрос в наши сервисы;
* как наш подход помогает в траблшутинге;
* обсудим плюсы и минусы нашего подхода.

Расскажу, как контент в KION попадает в рекомендации, на персональные витрины, как мы разрабатывали ТВ-витрину. А еще про самые интересные бизнес-правила и как редакция помогает растить смотрение.

В KION есть элемент «блендер». Он формирует витрину, используя разные источники, применяет свыше 50 бизнес-правил, и все это — быстрее, чем за 300 мс для каждого запроса. При этом рекомендации и витрины формируются максимально релевантные пользователю. Например, просмотренный фильм больше не покажется на витрине. Или если пользователь несколько раз не реагирует на постер фильма, витрина предлагает ему другой, чтобы пользователь с большей вероятностью обратил внимание на тайтл. Все это строго персонально и очень быстро.

Devhands.io — R&D-центр, который активно занимается корпоративным обучением. Как бэкендеру расти в «хайлоад»? Можно ли, вообще, изучать темы «large-scale and performance» и как? Поделимся нашим взглядом, опытом и кейсами.

В связи с ростом количества клиентов и объема трафика VK Рекламы увеличивается объем данных в системе и потребление аппаратных ресурсов, поэтому повышается вероятность возникновения проблем. Чтобы снизить риски потерь в этих условиях, необходимо заниматься оптимизацией архитектуры сервиса и заранее позаботиться о том, как резко не деградировать при возникновении нештатных ситуаций с использованием принципа graceful degradation.

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

С помощью предложенных методов можно повысить надежность высоконагруженного сервиса в процессе его постоянного развития, а также своевременно выявлять и диагностировать проблемы.

Distributed-101: что же такое распределённые системы без «зауми». Eventual consistency, CAP-теорема и PACELC-классификация простыми словами, их влияние на развитие разработки больших нагруженных проектов.

Технология WebAssembly (Wasm), вопреки распространенному мнению, с момента создания подразумевала возможность использования на бэкенде. Помимо браузеров, Wasm активно используется для плагинов/расширений в качестве полезной нагрузки в облаках/контейнерах, для переносимых компонентов ПО, и даже для смарт-контрактов в блокчейне.

Расскажу историю развития и важные для бэкенд-разработки особенности и преимущества технологии. Разберемся, почему Wasm сможет то, чего не смогла Java, как он ведет себя под нагрузкой, и почему релиз Компонентной модели открывает двери новому архитектурному паттерну, у которого есть шанс заменить микросервисы.

Feature Platform — новый взгляд на решение типовых задач из мира ML-разработки. Я расскажу, из каких компонентов состоит платформа и что стоит учитывать при ее проектировании, проанализирую рынок, сформулирую свои требования к системе на основе на прикладной задачи и соберу MVP на основе конкретных возможностей.

Цифровой банк — это десятки продуктов, сотни сервисов, тысячи команд и десятки тысяч людей, которые 24/7 что-то проектируют, разрабатывают, тестируют, катят в прод или, наоборот, откатывают с прода, включают и выключают фичи, делают бэкапы и миграции, и это не считая интеграций, за фасадом которых происходят вещи и похуже. Как обеспечить надежность услуг для пользователя в таком муравейнике? Грамотно проектировать? Да. Применять GitOps, канарейки, нагрузочные тесты? Тоже да. Круглосуточные дежурства SRE-инженеров и даже разработчиков? Без этого никуда! Но всё это лишь части общей картины, которая много-много больше.

В докладе верхнеуровнево рассмотрим, из каких сервисов и процессов построена работа с надежностью в Т-Банке, как эти части работают в динамике во время инцидента и какие меры принимаются, чтобы до инцидентов не доводить.

В Яндексе много различных сервисов, и каждый из них представляет большой интерес не только для людей, но и для роботов. Роботный трафик, в первую очередь, создаёт излишнюю нагрузку на сервис, что может привести к нарушению его работоспособности или вовсе к отказу. Не всегда задачей робота является скачать информацию с ресурса. Робот (или даже целый ботнет) может совершать злонамеренную атаку с целью положить сервис — DDoS.

Много лет в Яндексе существует система «Антиробот», призванная защищать сервисы от DDoS-атак и парсинга. Это один из самых высоконагруженных сервисов в Рунете по количеству обрабатываемых запросов в секунду.

В этом докладе я постараюсь приоткрыть занавес и рассказать, как построить такой масштабируемый, отказоустойчивый и надёжный сервис с низким latency. Расскажу, что мы делаем, чтобы защититься от DDoS, покажу, как устроена архитектура антиробота и какие приёмы мы используем для быстрого расчёта факторов для моделей машинного обучения. Также расскажу, как устроена капча и как ещё можно издеваться над роботами.

Мобильные платежи давно стали неотъемлемым атрибутом нашей жизни. На докладе расскажем о том, как устроена платформа мобильных платежей - сердце мобильных платежей «Мир». С какими трудностями и проблемами приходится сталкиваться и как их решаем.

На примере работы приложения Mir Pay разберем, что делают в Мир Plat.Form, чтобы справиться с регулярно возрастающей нагрузкой, какие используют технологии и архитектурные решения для обеспечения эффективной адаптации к изменениям.

В последнюю чёрную пятницу у нас в Wildberries было около миллиона RPS в поиске и рекомендациях товаров. И эти запросы обслуживает меньше тысячи серверов.

Расскажу, как у нас это получается, что мы делаем, чтобы не только выдерживать нагрузку на поиск и рекомендации без деградации их качества, но и глубоко персонализировать выдачи, применять мультимодальные эмбеддинги для понимания свойств товаров и поведения пользователей, а также быстро проводить множество экспериментов для улучшения систем.

TrafficSoft — российский разработчик высокопроизводительных сетевых решений для дата-центров и телеком-операторов. Сегодня наши продукты обслуживают миллионы абонентов и обрабатывают десятки терабит трафика в России и за рубежом.

Наша история началась в 2014 году с R&D-проекта: мы поставили перед собой цель создать софт, способный заменить проприетарные сетевые решения для обработки трафика в сетях операторов связи. Взяли за основу Open Source-приложение L3fwd из DPDK, сделали первые нагрузочные тесты и разработали прототип нашего первого продукта — CGNAT. Это положило начала созданию нашей платформы, способной в будущем претендовать на звание «Сетевой операционной системы».

В докладе я расскажу о том, как эволюционировала архитектура нашего софта: от L3fwd, то есть полного ее отсутствия, до полноценной программной платформы, построенной на событийно управляемой архитектуре с собственными Scheduler, TCP-стеком и гибкими возможностями в сфере debug, на базе которой сейчас работают все наши продукты.

Расскажу о том, как в погоне за производительностью, гибкостью и масштабируемостью в условиях жесткой конкуренции и постоянного отсутствия времени, мы достигли сотен миллионов PPS и миллионов CPS и RPS в наших продуктах. И о том, как, казалось бы, самые хорошие идеи разбивались о стену неидеальной реальности мира hardware.

* Программа лояльности в НСПК - что это.
* Как было сначала (MVP).
* Как рассчитать кешбэк:
** за 30 секунд,
** иногда за год,
** для всех.
* Как выплатить кешбэк (ну или забрать его назад).
* Что будет дальше.

Юридические, фактические, почтовые — адреса везде. Без адреса курьер не доставит заказ еды. Разбираемся, как правильно готовить адрес в системе любого масштаба. Почему Озон привозит заказ к калитке моего дома, а Я.Маркет так не умеет.

В логистическом агрегаторе ДоставИМ моя команда проделала большой путь решения проблем с адресами, разработав до этого крупнейшую в РФ адресную базу — на нём мы впервые поняли, что из 1000+ активных клиентов почти столько же кастомных адресных баз, а у самих доставщиков ситуация не лучше.

Расскажу о том, как мы учились мэтчить адреса, подключались к платным публичным сервисам и разочаровывались в них, выходили за рамки РФ, учили страшные слова типа ЦХДПА, КЛАДР и ФИАС, как нерешаемую за год задачу решили за один спринт и что из этого я определённо готов затащить в архитектуру новой системы и рекомендовать тебе.

Бонусом в конце поделюсь крутым решением, которое уже несколько лет не может доехать до РФ, но точно когда-нибудь будет в ДоставИМ 2.0.

Что обсудим? Сначала посмотрим на карту развития бэкенд-программиста от мидла до эксперта. Её можно использовать как для составления плана на обучение, так и для быстрой проверки «зон роста» (в том числе тех зон, которые нужно подтянуть как для перехода на новый «уровень», так и для прохождения интервью — а часто это разные зоны).

Затем обратимся к тем, кто собирается менять работу или находится уже в процессе поиска.

Поговорим о следующем:
* Как, вообще, понять, менять работу или нет?
* Обсудим типовые ошибки, которые совершают программисты на разных этапах:
- составление резюме: формат, фокус и почему (и когда) это до сих пор важно, нужны ли референсы и сопроводительные письма;
- от общения с рекрутером до общения с будущим руководителем;
- прохождение coding sessions;
- прохождение architecture (system design) sessions.
* Как можно было бы классифицировать компании, чтобы понять — компания «нормальная» или нет.
* Какие вопросы задать себе, чтобы понять, чего вы хотите сами, и в зависимости от этого сформировать список вопросов для компании, чтобы понять, ваша это компания или нет.
* Ну и, если успеем, поучаствуем в спецолимпиаде: какой трек выбрать, IC или EM?

Очевидно, что в современном мире разработки ПО без метрик будет непросто. Метрики помогают нам понять, как живут наши сервисы. А для того, чтобы собирать, хранить и анализировать метрики, нужен инструмент. В Т-Банке такой инструмент — это observability-платформа Sage, в которую собирается телеметрия всех сервисов банка.

Подсистема метрик Sage за 4 года прошла несколько витков эволюции.

В своем докладе я расскажу:
* как мы прошли путь от Prometheus до кластерной Victoria Metrics cо сроком хранения метрик до 1 года;
* как несколько сбоев вскрыли наши проблемы и стали триггером к следующем витку эволюции наших подходов;
* как мы адаптировали пайплайн записи и поиска метрик при постоянном росте количества записываемых временных рядов;
* какие знания мы получили о кластерной Victoria Metrics и на какие ее метрики мы обращаем внимание в первую очередь.

Доклад будет интересен как экспертам, так и людям, которые только погружаются в тему метрик.

1. Зачем нам проезжать 1 млн километров каждую ночь в симуляторе?
2. В чем отличие Open Loop- и Closed Loop-симуляций и зачем они?
3. Как мы сделали одновременно детерменированное и многопоточное исполнение пайплайна на базе ROS.
4. Как мы запускаем распределенную симуляцию в YTsaurus.

Аббревиатура WASM всё чаще встречается в описании совершенно различных продуктов — от браузеров до ядра Linux.

Разберёмся, как появилась эта технология, какие задачи она пыталась решить изначально, и какие задачи перед ней стоят сейчас. Посмотрим на внутреннее устройство и актуальные реализации. Затем попытаемся встроить WASM в angie и обсудим, какие проблемы при этом возникают, и попытаемся понять, как надо проектировать такие интерфейсы.

В заключение посмотрим в будущее и обсудим компонентную модель WASM-приложений.

Виртуальную сеть в облаке часто сравнивают с кровеносной системой человека, которая доставляет до сервисов сетевые пакетики, словно кислород до клеток. В 2015 году основа этой «кровеносной системы», которую мы использовали — Software-Defined Network (NSX) перестала развиваться и затем поддерживаться VMware. Кроме этого, к прежнему решению были вопросы по части производительности и надёжности.

Мы решили перейти на Оpen Source-решение OVN, и в докладе я расскажу обо всех этапах этого перехода: от предпосылок, выбора и тестирования нового решения до исправления багов в его коде.

В результате мы смогли смигрировать все инфраструктуры клиентов облака в 3 Availability Zone’ах в новый SDN «на лету», решить проблемы производительности и открыть дорогу новым фичам в сети.

Если вы думаете, что финтех — это исключительно о банках, подумайте еще раз. Этот «монстр» проник во все сферы: e-commerce, e-grocery, betting и многое другое. И даже если вы меняете компании, вы все равно оказываетесь в том же самом бесконечном круге финтеха. Почему? Давайте разберемся вместе!

За годы работы в этом домене я столкнулась с одной и той же архитектурной реальностью, которая не просто надоедает, а вызывает ненависть. Финансовые институты существуют с древних времен и, как любой древний механизм, они опираются на веками выработанные подходы и правила. Эти правила — основа стабильности и понятности, независимо от границ, языков и законов. Но как в любом древнем механизме, хотелось бы в финтехе перестать встречать один и те же «немного поломанные» решения.

В этом докладе я не просто выскажу свои недовольства. Я на примерах покажу, где именно финтех «ломает» и почему. Но главное — мы не остановимся на жалобах. Мы рассмотрим решения, которые помогут превратить «финтеховою» ненависть в НЕискреннюю любовь.

Приготовьтесь к веселому и динамичному путешествию по миру финансовых технологий! Без уныния, но с песнями (но точно без танцев)!

Какие артефакты архитектуры необходимы нам в компании? А какие они вообще бывают и сколько их? А как с ними потом работать и не страдать? Знакомые вопросы?

Мы хотели бы поделиться нашим опытом организации архитектурных артефактов в масштабах экосистемы. Рассказать о том, как мы использовали на практике «Enterprise Architecture on a page», что применили из описанных артефактов, как их связали и что автоматизировали с помощью систем.

В этом докладе я расскажу о том, как мы перепроектировали систему управления товарными данными и почему результаты эволюционного развития наших сервисов перестали нас устраивать. В условиях, когда у нас более миллиарда товаров, рост объемов данных превратил горизонтальное масштабирование в настоящую проблему. Я расскажу, какие архитектурные решения могут устранить эти трудности и чем сможет помочь централизованное хранилище, в частности, какие задачи оно должно решать, а каких точно избегать. Также расскажу о взаимодействии сервисов в новой архитектуре, выборе СУБД и сложностях, с которыми мы столкнулись при реализации. Отдельное внимание уделю процессу миграции: как перейти на новую схему без сбоев в работе. Наконец, расскажу, что у нас получилось в итоге.

Каждый год на платформе VK Видео появляются сотни миллионов единиц уникального контента: видео от известных блогеров, музыкальные клипы, фильмы и сериалы. Мы хотим защищать такой контент и его авторов от копирования. В докладе расскажем, как мы это сделали в условиях такой нагрузки и крайне высокой цены ошибки.

Мы вместе пройдем путь эволюции системы, позволяющей находить копии видеоконтента: от прототипа до production-ready-решения, использующего Java/C++, низкоуровневую работу с ffmpeg, нейросети (libtorch), FAISS с IVF-индексами на GPU. Рассмотрим ключевые проблемы, с которыми мы столкнулись: многопоточное декодирование видео и снятие отпечатков, размеры и масштабирование индексов, квантизация, повышение точности работы алгоритма матчинга.

Летом этого года мы выпустили обновленную программу лояльности СберСпасибо для 80 млн клиентов. Чтобы сделать программу прозрачнее, мы перевели взаимодействие с пользователями в режим реального времени, что увеличило нагрузку на системы в десятки раз.

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

И всё это для того, чтобы и вы могли уверенно делать запуски любых масштабов!

Часто ли вы задаетесь вопросом, как работают лифт, стиральная машина или… светофор? Кажется, что это достаточно простые системы, однако зачастую это далеко не так.

Данный доклад посвящен закулисьям разработки с нуля сложной системы управления светофорными объектами Москвы. Я расскажу, как мы прошли путь длиной в три года, применяя Go, Postgres, NATS, K8S, ML, чтобы получить готовую АСУДД.

Перколятор (percolate queries) — функциональность, позволяющая реализовать обратный поиск. Перколятор давно существует в ElasticSearch и OpenSearch, а недавно был добавлен в Sphinx, используемый в Авито.

В своем докладе я расскажу о том, как работает перколятор в Sphinx, чем он отличается от решения в ElasticSearch, за счет чего получился довольно быстрый и, самое главное, разберем как «обычный» практический кейс для сохраненных поисков на большом масштабе, так и несколько «необычный» кейс для поиска соответствия в потоке разнородных JSON-данных.

Расскажу, что такое YTsaurus и как он работает на примере задачи симуляции езды автономного транспорта:
* как устроена map-reduce-операция в YTsaurus;
* какие есть подводные камни, влияющие на скорость симуляции;
* как быстрее читать входные данные;
* как оптимальнее доставлять код приложения.

А также покажу, какие еще есть способы уменьшить общее время симуляции.

Этот доклад — первое публичное представление современной архитектуры национального видеохостинга RUTUBE. Покажу техническую начинку и характеристики видеоплатформы и поделюсь предпосылками архитектурных решений:
* устройство видеохранилища (и это не S3 — расскажу почему);
* видеобалансер для петабайтов контента;
* CDN на сотни узлов.

Познакомлю с продуктовым ландшафтом: кто нас смотрит, откуда (по данным Mediascope), и как работает воспроизведение видео. А главное — что у нас изменилось после замедления YouTube, и будем ли мы пересматривать архитектурные и инфраструктурные подходы.

«Яндекс Лавка» сейчас состоит примерно из 100 микросервисов, которые поддерживают различный функционал: цикл заказа, каталог, поиск, промокоды, пуши, скидки, инструменты поддержки, платежи. На базе этих технологий мы решили построить модульный SaaS-продукт, способный динамически настраивать необходимый функционал для каждого партнера без кратного роста команды разработки.

В этом докладе расскажем, как:
1. выбирали синглтенант или мультитенант;
2. выбирали признак, по которому изолировать наши микросервисы, и учились с ним жить;
3. разделяли конфигурации и эксперименты между B2C- и B2B-направлениями;
4. научились разворачивать наши инсталляции в различных контурах;
5. сократили время развертывания нового клиента от нескольких месяцев до недели и теперь стремимся к 1 дню;
6. какие боли перенесли и какой опыт вынесли.

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

Я расскажу, как мы это сделали и как решили следующие проблемы:
* скорость ответа: как начать отвечать пользователю не за десять секунд, а быстрее;
* цена запроса: как не тратить тысячи GPU;
* стабильность: как не сломать то, что хорошо работает сейчас.

Посмотрим, что получилось в итоге, что можно улучшить и почему мы все еще это не сделали.

Кто не встречался с самыми крупными распродажами года — на Черную пятницу, Новый год или гендерные праздники? В это время продавцы стараются сделать свои товары максимально привлекательными, а покупатели — урвать по выгодной цене. На самом деле, это происходит не только в периоды крупных ретейл-поводов. Акции на маркетплейсах — важный инструмент работы с ценами в любое время года.

Яндекс Маркет — сервис для выбора и покупки сотен миллионов товаров от сотен тысяч продавцов. В высокий сезон здесь совершается более 800 заказов в минуту, а больше 80% из них — по акциям.

В докладе я покажу, как устроен мир работы акций изнутри: с чего мы начинали свой путь и как решение выглядит сейчас. По шагам разберу общую архитектуру системы, расскажу об используемых технологиях и подходах с пояснениями, почему были выбраны именно они. Поделюсь историями, как мы шли к текущей схеме, какие ошибки и ценные уроки собрали по пути. А ещё расскажу, какую нагрузку держит такая система и как происходит подготовка к высокому сезону.

Одним из наиболее распространенных способов запуска веб-приложений на языках PHP, Python и Ruby является связка nginx и сервера приложений, которыми чаще всего выступают php-fpm, gunicorn, unicorn, uwsgi, puma и подобные или даже Apache в этой роли.

У такого способа есть ряд существенных недостатков:
* необходимость правильно настраивать и поддерживать работоспособность ещё одного компонента в инфраструктуре, а то и нескольких;
* ошибки сопряжения и отсутствие мониторинга со стороны nginx рабочих процессов приложения напрямую, что приводит в итоге к 502-504-ошибкам при возрастании нагрузки, которые частенько видят посетители;
* дополнительные накладные расходы на обмен данными между nginx и приложениями снижают производительность и масштабируемость.

Мы занимаемся внедрением возможности запуска процессов приложений непосредственно в nginx в рамках Angie — его главного обратно совместимого форка, разрабатываемого бывшей командой разработчиков nginx. При этом это будет простая и полноценная замена упомянутых выше связок с простой конфигурацией и без необходимости вносить какие-либо изменения в код приложений.

Поговорим про преимущества такого подхода и посмотрим на результаты бенчмарков, которые обещают быть интригующими.

Перед некоторыми сервисами спустя время встаёт задача быстро релизить свои ресурсы, например, новые версии ML-модели или шарды поисковой базы. Задача сложна тем, что пользовательский процесс может долго перезапускаться из-за десятка гигабайтов нетривиального состояния в памяти, и релиз даже мегабайтного ресурса окном на сотни подов может затянуться на часы. Всё усложняется тем, что система должна быть надёжной — нужно предусмотреть как минимум отказ источника ресурсов, проблему некорректной версии ресурса и откат на стабильную версию.

Мы написали REX — multitenant-сервис доставки динамических ресурсов, который умеет обновлять ресурс, не требуя пересборки контейнера / перезагрузки процесса. Мы уже отмасштабировали его на большинство сервисов Яндекса.

В этом докладе мы расскажем:
* как организовать обновление версии ресурса без перезагрузки процесса в контейнере;
* предоставить удобную, надёжную и масштабируемую архитектуру для решения задачи обновления динресурсов за единицы минут.

Рекламная система Яндекса обрабатывает сотни тысяч запросов в секунду. Для этого ей требуются терабайты данных: информация о партнерских площадках, рекламных кампаниях и стратегиях, баннерах и многое другое. Все эти данные поступают из разных систем в разных форматах и имеют различные требования к скорости доставки обновлений.

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

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

В ходе доклада расскажу о том, как изменить формат данных так, чтобы не страдать от постоянных перекладываний полей, покажу наш новый индекс, который предоставляет возможность быстро доставлять обновления до движков. Также расскажу, как мы добавили гибкости системе: со стороны поставщиков данных необходимо одновременно поддерживать обработку потока обновлений и одномоментную загрузку полного набора данных, а со стороны рантайма нужно совмещать разнородные паттерны доступа к данным, объем которых варьируется от сотен мегабайт до десятков терабайт.

В современном мире все привыкли к созданию сложных и громоздких систем DWH и OLAP, стоимость которых порой может вызвать холодный пот. В своем докладе Александр продемонстрирует, как встроенные базы данных могут стать ключом к решению многих проблем, а также сэкономить значительное количество ресурсов и финансов. Он поделится своими инсайтами о том, как применение встроенных баз данных в рамках классических подходов открывает новые горизонты масштабируемости и эффективности. Не упустите шанс узнать, как инновационные решения могут трансформировать ваш подход к обработке данных.

У нас была железка с ксеоном и 48 ядрами, PostgreSQL с одиссеем, MySQL, Memcached и Redis со множеством клонов, а также redis-benchmark, xwrk и k6. Не то чтобы это был необходимый запас для исследования. Но если начинать бенчмаркить — трудно остановиться. Единственное, что вызывало у меня опасение, — это k6. Нет ничего более беспомощного, безответственного и испорченного, чем писать сценарии на javascript. Я знал, что рано или поздно мы перейдем и на эту дрянь.

Мы взяли Xeon Gold 24/48C 128GB RAM и при помощи напильника исследовали «деградацию» перформанса самых последних версий «классических» компонентов СУБД (PostgreSQL, MySQL) и кэшей (Redis, Valkey, DragonFly, Memcached) на read-only-нагрузке. Будет много latency-throughput-диаграмм, на основе которых мы выясним, кто сможет «вытянуть» миллион RPS, с каким latency, для какого числа одновременных соединений.

Обсудим архитектуру современных сервисов и порассуждаем о том, есть ли у нас шанс начать обходиться без кэш-слоя в хайлоад-проектах.

Про выделение микросервисов из монолита рассказывали много, но у каждого свой путь, в докладе расскажем про наш.

От простейшего выделения сервиса в модуль в начале до решения проблем разрыва транзакций, SQL Join-запросов, задержек асинхронного API и непосредственно выделения нового сервиса. Использование event-driven-архитектуры, редизайна модели данных и интеграционного слоя как основных подходов в процессе выделения.

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

В докладе Алексея вы узнаете:
* какая бывает архитектура нагрузочного софта и почему одни утилиты медленные, а другие очень быстрые;
* какие параметры можно и нужно менять при проведении нагрузочного тестирования;
* что такое coordinated omission и как с ним бороться;
* почему именно latency/throughput-диаграмма, а не число RPS является основной характеристикой и «паспортом» сервиса;
* какую опасность таят в себе «перцентили» и как их нужно использовать;
* особенности и демо wrk2/wrkx (выжмем 100K+ из какого-нибудь сервиса).

Через A/B-эксперименты принимается огромное количество внедрений в Яндексе, поэтому процесс анализа метрик стоит на критическом пути.

На больших объемах данных классические подходы расчета метрик A/B через MapReduce дают большие задержки — часы и дни.

В докладе я расскажу, как мы построили систему подсчета метрик в режиме реального времени под большой нагрузкой и на большом объеме данных. Поговорим о том, зачем это нужно, как это устроено под капотом и какие трудности мы решали.

Вы хотите использовать Apache Kafka в своих системах? А может быть, уже это делаете? Мы — да и много, но местами мы ее используем не только как систему обмена сообщениями, но и как хранилище данных. Это хорошо или плохо? Удобно или только боль? На эти вопросы я отвечу в своем докладе, расскажу, в каких вариантах мы используем Kafka, поведаю историю, как мы столкнулись с проблемами бэкапа данных из Kafka и как решали их на 400 сообщений в треде в мессенджере.

Чтобы вы не допускали ошибок в использовании Apache Kafka, мы сделали это за вас, и я расскажу об этих ошибках.

Все клиенты Т-Банка могут выйти с сотрудником на связь по видеозвонку — это важная часть нашего процесса обслуживания. С помощью видеосвязи мы надёжно аутентифицируем клиентов на чувствительных операциях и доверительно общаемся с SME и private-клиентами.

При разработке сервиса видеозвонков основными требованиями были надёжность и способность горизонтально масштабироваться. В итоге у нас получилось приложение, которое состоит из двух инфраструктурно независимых зон доступности, и при этом, с точки зрения пользователя, работает как единое целое.

В докладе я расскажу, как у нас всё устроено, проведу обзор проблем и трейдоффов, которые возникают при проектировании таких приложений в масштабах Т-Банка, а также поделюсь опытом использования видеосвязи в задачах антифрода.

* Изучим вертикальное и горизонтальное расширения кластера Пикодата;
* научимся делать бэкап и восстановление кластера;
* разберем наиболее часто встречающиеся проблемы эксплуатации и методы их решения.

WebAssembly — это виртуальная машина, разработанная для выполнения веб-приложений в браузере. WASM предоставляет эффективный способ запуска высокопроизводительного кода, написанного на различных языках программирования. На самом деле, эта технология не только про веб-разработку и применима в очень большом количестве разных сфер, за счет чего и набирает большую популярность.

В этом докладе мы посмотрим на возможности, которые дают WebAssembly-рантаймы вне браузера. Я расскажу про опыт внедрения WASM-рантайма в Tarantool, про встреченные на этом пути сложности и про то, как WASM позволил научить сервер приложений в Tarantool говорить на вашем любимом языке, каким бы он ни был.

У нас большая дата-платформа с несколькими системами хранения и обработки данных. Но не во всех системах есть хороший data governance и правильные процессы. Иногда это приводит к тому, что данные можно легко удалить по ошибке, что и произошло.

Но в этот раз рассказ будет не только про ошибку, но и про то, как нам удалось (почти полностью) ее исправить и что мы делаем, чтобы ее не повторить.

В программе:
* полная остановка боевого кластера Hadoop;
* поднятие еще двух кластеров для пользователей;
* восстановление данных с дисков после удаления (и очистки корзины);
* игрища с побайтовыми чтениями и поиском parquet magic numbers в петабайтном стогу сена.

Обзорный доклад о NewSQL СУБД Picodata. Основные концепции, архитектура, «фишки», сценарии использования и отличия от других СУБД.

Любая СУБД должна не только предоставлять качественный сервис, но и эффективно работать на каждом этапе жизненного цикла данных, и резервное копирование — один из ключевых этапов этого жизненного цикла. При этом возможны различные подходы к резервному копированию, но, независимо от подхода, необходимо обеспечить ключевые требования по производительности: минимизировать время снятия копии и ее объем, контролировать нагрузку на базу в процессе резервного копирования, уложиться в допустимые RPO и RTO.

В докладе расскажем о нашем инструменте Ptrack и применяемом в нем механизме хранения изменений на основе bloom filter и сравним его с выходящим в PostgreSQL 17 Walsummarizer и его механизмом хранения — roaring bitmap.

Взаимодействие с дисками — один из самых важных компонентов в работе пользователя с облаком. Оно должно быть стабильным, быстродействующим, а также иметь возможность скейлиться и адаптироваться к нагрузке клиента. Расскажем, как мы этого добились с помощью самописного сервера-библиотеки (которая теперь в открытом доступе!) и что у нас получилось.

Picodata — это распределенная СУБД. Мы сделали ее на основе Tarantool, который выступает локальным хранилищем и реализует репликацию. На фасаде мы реализовали новый движок распределенного SQL, а управлять всем этим поставили кластер-менеджер на основе алгоритма Raft.

Чтобы разобраться, как это работает, придется научиться думать в терминах распределенной стейт-машины, но я все объясню:
* почему такая сложная архитектура — это на самом деле просто;
* какие у отказоустойчивости критерии, и где границы сохранности данных;
* как работает расширение функциональности при помощи плагинов на Rust.

* Dev Room Picodata День 2, 15-40.

Изучим на практике:
* требования к ресурсам для развертывания кластера Picodata;
* инструменты для развертывания кластера;
* постановка кластера на мониторинг;
* создание, модификация и управление данными.

Хранение бэкапов — это всегда очень большие объемы данных и долгий срок хранения. Разрабатывая нашу систему хранения данных (СХД) для резервных копий TATLIN.BACKUP, мы столкнулись с недопустимо быстрым ростом метаданных для восстановления данных, причём метаданные часто дублировались. При среднем сжатии данных в 6 раз и доступной ёмкости для данных в 690 ТБ, объём метаданных достигал 13 ТБ, что занимало всю выделенную ёмкость под них.

Я расскажу:
* как мы решали эту проблему с использованием структуры Дерева Меркла и сократили объём метаданных на 83% при средней дедупликации в 6x раз;
* как это позволило нам ускорить поиск дубликатов в 10 раз;
* о применении content-defined chunking-алгоритма для построения дерева для того, чтобы эти решения работали;
* о подобных (но не наших) решениях для систем контейнеризации и распределённых key-value-хранилищ.

Наш подход сильно экономит дисковое пространство, а значит, и финальную стоимость хранения. И его также могут использовать системы хранения и БД для ускорения операций поиска, pull/push-операций данных или быстрой синхронизации реплик в распределённых БД.

Во ВКонтакте мы храним несколько триллионов фото, аудио и прочих файлов на тысячах серверов. Из-за такого объёма невозможно пользоваться нашими обычными подходами к разработке движков. Я расскажу, как менялась архитектура хранилища за 18 лет, что используется сейчас, как мы обеспечиваем отказоустойчивость.

Как мы управляем кластером PostgreSQL на 650+ двухтерабайтных шардов с помощью собственного сервиса шардирования.

Яндекс Почта — высоконагруженный сервис, который держит 300 000+ RPS и хранит информацию о миллиарде пользователей. Для хранения всей метаинформации мы используем PostgreSQL на 650 шардов. Чтобы справляться с такими нагрузками, мы реализовали собственный сервис шардирования — шарпей.

В докладе подробно расскажу:
1. как мы пришли к реализации сервиса шардирования;
2. как устроено основное хранилище информации о распределении пользователей по шардам и в самих шардах;
3. какие технические подходы мы используем, чтобы максимально уменьшить время получения информации из основного хранилища;
4. разберем историческое развитие сервиса, и какие оптимизации нам понадобились после переезда в Облака;
5. разберем преимущества такого решения, и как эти преимущества помогают многим сервисам Яндекс 360.

Осенью 2024 года вышел Valkey — клон Redis, поддержанный Linux Foundation и cloud-провайдерами, в первую очередь AWS.

Рассмотрим особенности Valkey, сделаем живое демо и в дискуссионной манере обсудим его перспективы.

Время выполнения SQL-запросов зависит от наличия индексов, актуальной статистики и т.п. Большинство проблем с производительностью СУБД решаются оптимизацией самых медленных запросов. Но, увы, бывают ситуации, когда классическая оптимизация запросов не приносит желаемого успеха, система продолжает себя вести неадекватно.

На HighLoad++ 2022 мы уже показали, какие бывают аномальные случаи, но прошло время, и кое-что исправлено, а что-то новое нашлось.

Приходите на доклад, чтобы узнать:
* что изменилось в PostgreSQL за последние два года;
* когда индексы могут тормозить или совсем не работать;
* какие сюрпризы заложены в fetch size'е
и другие увлекательные истории. Давайте вместе обсудим, каким иногда бывает PostgreSQL.

* Устройство плагина.
* Создание плагина, его установка и обновление.
* SDK Picodata.

* Чем заменить MySQL или как превратить хеш-мапу в полноценную базу данных, привет YTsaurus.
* Всегда ли нужна нормализация данных?
* Потоковая обработка данных: per aspera ad astra.
* Версионирование данных — must have!
* Проблема размножения обновлений по иерархии объектов.

Недавно мы добавили стоимостный оптимизатор в YDB, зачем мы это сделали и какие задачи он поможет решать?

YDB создавалась как OLTP-система для поддержки высоконагруженных проектов с большим объемом транзакций. Обычно в таких системах запросы довольно простые, хотя все равно попадаются и аналитические запросы со значимым количеством соединений таблиц. Такие запросы довольно сложно оптимизировать вручную, и на помощь приходит стоимостный оптимизатор. Многие наши конкуренты, такие как CockroachDB, TiDB, Yugabyte добавили стоимостные оптимизаторы к своим продуктам.

Но несколько лет назад мы также решили добавить колоночное хранение и сложную аналитику в YDB. В этом сценарии качественный стоимостный оптимизатор становится просто необходим, и требования к нему намного более серьёзные, чем в сценарии OLTP. Причем, поддерживая сразу строчное и колоночное хранение в одной СУБД, можно перейти в режим HTAP, где пользователь даже не знает, где будет исполняться его запрос — сверху строчного или колоночного хранилища — это решает как раз оптимизатор запросов.

В этом докладе мы расскажем о том, как мы написали свой стоимостный оптимизатор для этих сценариев, какая у него текущая функциональность на данный момент, сравнимся с конкурентами в области OLTP- (CockroachDB, Yugabyte), OLAP- (GreenplumDB, Teradata, Oracle Exadata, Trino) и HTAP- (TiDB) решений и расскажем о планах развития.

Rust последние несколько лет стабильно остаётся самым любимым языком программирования по данным StackOverflow Developer Survey. Также в последние годы его всё больше используют и в индустрии. За 3 года разработки Picodata мы успели познакомиться со многими нюансами языка и готовы поделиться своим опытом. Затронем такие темы, как тулинг, кривая обучения, надёжность, скорость разработки и выполнения, особенности архитектуры.

YDB — это распределенная платформа для работы с данными с поддержкой OLTP-, OLAP- нагрузок и потоковыми очередями сообщений (топиками, аналогичными топикам в Apache Kafka). Apache Kafka — признанный лидер в сфере потоковых брокеров сообщений.

Транзакции в любой системе — это, с одной стороны, мощный инструмент упрощения кода пользователя и работы с системой в целом, а также достижения гарантий, которые до этого невозможно/сложно было получить. Например, Apache Kafka за счет транзакций позволяет достичь exactly once-гарантий. А с другой стороны, это зачастую достаточно сложная и интересная архитектура внутри системы. Транзакции позволяют сложность перенести из пользовательского кода в серверный.
Основной упор в докладе делается на рассмотрение архитектуры транзакций в YDB и Apache Kafka со сравнением плюсов и минусов этих подходов.

В докладе будут рассмотрены следующие аспекты:
* что такое топик, транзакционная запись в топик, транзакционное чтение из топика;
* модельная задача решардирования с гарантиями порядка и exactly once-обработки. Почему ее нельзя решить без транзакций в Apache Kafka. Как она решается без транзакций в YDB. Как она решается в обеих системах с использованием транзакций;
* архитектура транзакций в Apache Kafka;
* архитектура транзакций в топиках YDB;
* сравнение производительности транзакций в Apache Kafka и YDB.

Динтаблицы YTsaurus используются внутри Яндекса с 2017 года для построения больших сервисов, требующих строгих гарантий консистентности и доступности. В 2023 году исходный код YTsaurus был выложен в open source и, в теории, нашими наработками мог бы воспользоваться любой желающий. Однако несмотря на наличие нескольких докладов на конференциях про отдельные фичи динтаблиц YTsaurus, мы никогда не рассказывали на широкую аудиторию, что же это за система, какой функционал она предлагает и, что, возможно, наиболее интересно потенциальному пользователю, в каких сценариях успешно используется.

В этом докладе я хочу рассказать про самые интересные фичи динтаблиц YTsaurus и сценарии использования в Яндексе.

Apache Iceberg — популярный табличный формат для построения современных lakehouse-платформ. В докладе мы детально рассмотрим архитектуру и реализацию Apache Iceberg.

Представьте, что вам необходимо выполнить анализ данных, распределённых по нескольким системам хранения: например, таблицы, размещённые в реляционных СУБД, надо объединить с CSV-файлами из S3. Что вы предпримете? Если данных немного, можно написать простой скрипт на любом ЯП, который последовательно вычитает данные из каждого источника в оперативную память и объединит их в одну таблицу, после чего её можно будет проанализировать. При этом вам придётся написать свою реализацию JOIN либо использовать для этого стороннюю библиотеку неизвестной эффективности.

Но что делать, если данных очень много, они имеют сложную структуру, а для описания аналитических операций над ними гораздо лучше подойдёт привычный и выразительный SQL? Здесь на помощь приходят СУБД и движки обработки запросов с федеративными возможностями. В этом докладе мы поговорим о принципах работы таких систем и о ключевых оптимизациях, позволяющих им быстро и эффективно извлекать и обрабатывать большие объёмы данных из внешних источников.

1. Проблематика миграции на PostgreSQL.
* Отсутствие готовых нагрузочных тестов: вызовы и риски.
* Методы оценки производительности PostgreSQL без проведения полноценного нагрузочного тестирования.

2. Проблемы традиционного нагрузочного тестирования.
* Потенциал ошибок и неточностей в симуляции реальной нагрузки.

3. Методы оценки производительности PostgreSQL без стандартных нагрузочных тестов.
* Верификация производительности БД до ввода в эксплуатацию.
* Выявление возможных узких мест и проблем в конфигурации.
* Примеры использования статистических данных для идентификации узких мест.

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

В первой части доклада рассмотрим с какими особенностями поведения операционной системы приходится сталкиваться для обеспечения надежного хранения данных. Разберем, почему нельзя ретраить fsync, как к этому пришли разработчики PostgreSQL (спойлер: было потеряно какое-то количество данных, и сломано очень много копий в спорах с разработчиками ядра Linux).

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

Развитие баз данных привело к появлению технологий категории Distributed SQL: решений для исполнения запросов на больших объёмах данных. Движок распределённых запросов — это важный компонент подобных распределённых СУБД, позволяющий работать с ними через привычный SQL-интерфейс.

В докладе расскажу о внутреннем устройстве движка, который мы разработали в Пикодате. Покажу, как устроены фазы планирования и исполнения запросов и какую роль в этих процессах играют ключи распределения и библиотека горизонтального масштабирования Vshard. Поделюсь тем, как в процессе исполнения DDL-запросов используются алгоритмы Raft и CaS.

В конце доклада приведу сравнение с другими СУБД, предоставляющими функциональность распределённого SQL.

* Существующие подходы к шардированию данных.
* Особенности подхода, выбранного в Picodata.
* Алгоритм сборки кластера. Discovery-узлов.
* Целостность метаданных в кластере.

Valkey, в отличие от Redis, изначально построен по полностью Open Source-модели, у него нет Entrerprise-версии, которая бы каким-то образом ограничивала его развитие.

С момента начала работы над ним весной 2024 года команда разработки успела принять и стабилизировать некоторое количество патчей, заметно улучшающих производительность в сравнении с версией 7.2.

В этом докладе мы посмотрим на некоторые из этих патчей, оценим (с бенчмарками) их позитивные (а местами и негативные) эффекты на производительность.

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

Настоящее живое демо Redis/Valkey-кластера: принципы организации данных в кластере, масштабируемость, отказоусточивость, производительность. Попробуем выжать 1.000.000 (один миллион) RPS.

Любая SDS воспринимается как монолитная и монструозная коробка, в которой боязно что-то менять и сложно что-то проверить с коротким циклом обратной связи. В своем докладе расскажу, как тестировать изменения в Ceph без опасений и влияния на продакшн и какие инструменты помогают команде «Рунити» воспринимать каждый отдельный Ceph как облако.

Тезисы доклада:
* Ceph как легко развертываемый кластер;
* функциональное тестирование на виртуальных машинах;
* путь изменений от виртуальных машин при разработке решений до продакшна;
* воспроизведение функциональных пользовательских кейсов в изолированных окружениях.

В нашей компании принята стратегия технологического суверенитета. В рамках этой стратегии мы разрабатываем свою облачную платформу.

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

Kubernetes уже добрался и до enterprise-систем, в которых много легаси, коробочных решений и жестких требований по безопасности. Что самое неприятное — в таких системах предстоит долго (если не всегда) жить в условиях двоевластия по управлению сетями и мониторингом безопасности, когда разработке и эксплуатации хочется современных инструментов и подходов, а безопасникам — старых проверенных iptables.

В своем докладе я покажу на реальных кейсах, как при помощи ebpf подружить эти два мира, чтобы разработчики и инженеры получили удобный инструмент, а безопасники не беспокоились.

Современные платформы на базе Kubernetes предоставляют очень широкие возможности для управления безопасностью сетевого взаимодействия приложений. Настолько широкие, что можно все настроить «как надо», а получить совсем не то, что ожидалось. В докладе на одном из таких примеров разберем механизмы безопасности сети в Kubernetes, а также погрузимся в детали реализации и лучшие практики на примере популярных Open Source-проектов.

Как сделать платформу, которая будет ускорять разработку и делать эксплуатацию надежнее?

Я построил платформу в компании Купер (ex. СберМаркет) с нуля. В докладе я подведу итог четырех лет разработки и перечислю основные стратегические и тактические ошибки, которые никогда не совершил бы сейчас. Каждый случай разберем отдельно и выведем набор принципов, которые помогут вам избежать моих ошибок и построить лучшую платформу.

Наша команда давно и успешно развивает сервис централизованного логирования в МТС. За это время мы успели вырасти в сотни раз по объемам, пользователям и нагрузке, перейти от одного единственного кластера Elasticsearch к геораспределенной системе из множества кластеров OpenSearch. Не все наши изначальные архитектурные решения выдержали проверку временем, и с их последствиями мы боремся до сих пор. А часть компонентов пришлось дорабатывать или заменять собственными решениями.

В докладе расскажем, как нам удалось сделать геораспределенную систему логирования на базе OpenSearch на 300+ TB и 3 000 пользователей. Как менялись наша архитектура и стек с ростом нагрузки. И самое главное — что бы мы сделали по-другому, если бы начали с нуля.

Рассмотрим ключевые паттерны использования PowerShell DevOps'ами в распределенных системах с акцентом на практические примеры и бизнес-кейсы. Обсудим, где и почему PowerShell может быть предпочтительнее Ansible. Очертим возможности PowerShell 7 в 2024 году. Включены примеры с кодом, методы логирования и тестирования, а также рекомендации по структуре скриптов для сложных решений.

Доклад ориентирован на тех, кто хочет эффективно использовать PowerShell для автоматизации в DevOps.

Контейнеризация позволяет сделать более надёжными и масштабируемыми даже «немодные» монолитные приложения. Я докажу это на практическом примере перевода сетки высоконагруженных новостных сайтов на базе Drupal 8 в Kubernetes. Обсудим типовые паттерны архитектуры приложений в контейнерной среде, лучшие практики миграции, а также типичные сложности и распространённые ошибки.

Доклад поможет решить проблему автомасштабирования и управления такими PHP-приложениями, как Drupal в облачных средах. Вы узнаете, какие шаги предпринять для успешной миграции монолита в K8s и как в рамках одного кластера развязать окружения друг от друга. А также как экономить на инфраструктуре благодаря HPA и значительно уменьшить Time-to-Market за счёт автоматизации CI/CD-процессов.

Что делать, если деплой в облачный кубер падает из-за нехватки ресурсов, но мониторинг говорит, что реальная утилизация ниже 20%, при этом стоимость инсталляции в месяц составляет 8-значную сумму?

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

Наша трансформация DevOps началась в 2019 году с внедрения IT-стандартов, которые включали практики Continuous Integration, Code Review и Trunk Based Development. Мы активно развивали инженерную культуру, улучшали процессы и автоматизировали оценку практик. В 2020 году добавились Continuous Delivery, Logging и Monitoring, а переход на GitLab открыл новые возможности для оптимизации CI/CD-процессов. В 2022 году «IT-Стандарты» были преобразованы в «Лучшие практики», позволив командам самостоятельно достигать технического совершенства и следовать инженерным целям.

Сегодня, в 2024 году, мы делаем следующий шаг — запускаем платформу «Технические возможности», которая автоматизирует оценку практик и сбор метрик. Эта платформа позволит оценивать зрелость команд с помощью интеграций и опросов, объединяя в себе методы из DORA Core Model и внутренние метрики в компании. Платформа реализует единую экосистему для управления инженерной культурой и техническими процессами, помогая командам не только улучшать свои результаты, но и двигаться в сторону долгосрочной устойчивости и эффективности.

Приходите послушать про наш опыт, если перед вами стоят похожие задачи по развитию и оценке инженерной культуры и процессов в большой компании.

В этом докладе мы расскажем вам о практике наших учений по отключению ДЦ. Поделимся одним конкретным случаем, когда у нас произошел факап, который привел к тому, что в патрони-кластере (и не одном) в строй вернулись мастера на старых таймлайнах.

В заключение расскажем о нашей культуре постмортемов, которые помогают нам каждый следующий раз становиться чуточку лучше предыдущего.

Привилегированный доступ к *nix-системам обычно строится через SSH. Аутентификация в SSH развивалась эволюционно, методы аутентификации покрывали различные кейсы и строились исходя из ограничений окружающей инфраструктуры.

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

Разберем, как организовать процесс разработки мобильных приложений со встроенными в них СКЗИ, чтобы соблюсти все требования безопасности информации, не нарушить порядок согласования с заказчиком и обеспечить высокую частоту выпуска обновлений.

В докладе расскажу:
* как разработать безопасную архитектуру мобильного приложения с использованием СКЗИ;
* как обеспечить быстрый процесс выполнения требований ФСБ России по оценке влияния мобильных приложений на встроенные СКЗИ;
* какие инструменты и методы использовать для контроля целостности и безопасности кода на этапе разработки;
* как автоматизировать процесс контроля релизных сборок и обеспечить соответствие стандартам безопасности.

В последние годы популярность и потребность в удаленной работе кратно выросла, что привело к росту использования VPN в организациях: значительно большее число сотрудников получили возможность попасть в сеть компании из любой точки мира.

Даже при наличии правильно сегментированной сети с гранулярной выдачей минимально необходимых доступов — VPN все еще дает доступ в сеть компании.

В своем докладе я расскажу, как минимизировать риск при выдаче доступа к VPN для наименее доверенных групп сотрудников. Про то, как можно заменить доступ к сети компании через VPN максимально точечным и гранулярным доступом до веб-приложений с помощью достаточно простого и лаконичного решения — Identity Aware Proxy, сделав тем самым весомый шаг в сторону Zero Trust.

Приложения, перед которыми стоит задача высокой производительности, зачастую пишутся на небезопасных с точки зрения использования памяти языках программирования, таких как С и С++. В Яндексе разрабатывается и используется множество сервисов, написанных на С++, как доступных исключительно для внутренних пользователей, так и опубликованных в Open Source: YDB, YT, userver, etc.

В этом докладе я расскажу о том, как в Яндексе мы автоматизируем поиск уязвимостей порчи памяти при помощи фаззинга в наших сервисах, о том, как мы используем ресурсы Яндекса для ускорения этого процесса, а также внутреннем устройстве нашей платформы для координации фаззинга, какие неожиданные сложности решали в процессе ее создания.

В Российской Федерации на законодательном уровне начали формировать первичные требования к умным многоквартирным домам и их безопасности. Рассмотрим разницу между умным домом и умным многоквартирным домом. Ознакомимся с международным анализом уязвимостей и угроз кибер-физических систем современных домов и использования IoT и IIoT на службе цифровизации домов. Сформулируем гипотезы перспектив повышения уровня безопасности умного многоквартирного дома.

История ошибок переполнения буферов насчитывает более 35 лет. За это время появилось множество технологий, которые должны были избавить нас от этого класса уязвимостей раз и навсегда. Мы постоянно слышим, что переполнения в 20хх году уже "мертвы". Однако на деле количество найденных ошибок и, что еще важнее, их эксплуатация в реальных атаках только растет.

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

В Сбере больше 1500 команд, разрабатывающих и поддерживающих около 2000 автоматизированных систем (АС). Эти АС используют компоненты стандартного технологического стека от операционной системы, систем управления виртуализацией и контейнерами до Middleware и баз данных. АС регулярно масштабируются, команды создают новые и выводят старые микросервисы, технологический стек меняется под влиянием внешних и внутренних факторов. Один из актуальных факторов – импортозамещение. Управление доступом к компонентам технологического стека и между ними сложный технический вопрос не только для Сбера и его большой инфраструктуры, но и для других компаний в России и мире. Перед нами стояла задача решить эту задачу для более 500 000 экземпляров компонентов техстека и не только автоматизировать предоставление доступа и создания технических и привилегированных учетных записей, но и управление их жизненным циклом, ролями, полномочиями и секретами.

В рамках доклада мы разберем:
* организацию учета, продуктов, компонентов и др., а также как вести привязку команд сопровождения и развития;
* организацию ролей и учетных записей в IGA;
* что такое PAM и Vault, передачу секрета УЗ под управление в эти системы;
* управление доступом к Vault и PAM из IGA, разделение ролей;
* управление доступом на примере Linux. Централизованная аутентификация vs ssh-ключи. Управления sudo. Разграничение доступа;
* как использовать Vault для работы с сертификатами, магия istio + vault agent;
* преимущества и недостатки внедрения такой автоматизации.

В современном мире атаки на базы данных и утечки становятся все более актуальной проблемой для организаций. Несмотря на то, что многие СУБД предоставляют различные способы контроля доступа к базам данных, пароли все еще часто используются, а другие способы защиты не применяются.

Для организации безопасного доступа разработчиков к базам данных мы в Яндексе реализовали сервис Database Bastion, который позволяет ограничить сетевой доступ сотрудников, обеспечивает дополнительные шаги при аутентификации с использованием аппаратных токенов, а также анализирует запросы пользователей и ответы сервера, собирая статистику и отправляя события для дальнейшего аудита.

Атакуя приложение, хакер держит в голове некоторую его модель, меняющуюся по ходу проверки гипотез и включающую в себя критичные точки выполнения, способы воздействия на них и ожидаемую реакцию приложения. Дерево атак, реализуемых хакером, является набором достижимых путей в такой модели. Функциональность вторична для хакера, он мыслит «вне коробки» приложения и свою модель строит, исходя из необходимой ему «функциональности», которая позволит провести эффективную атаку.

Разрабатывая приложение, программист тоже держит в голове его модель, но несколько иную, обусловленную реализуемой архитектурой и направленную на реализацию необходимых фич. Каждая фича, реализуемая программистом, является набором юзкейсов, представляющих собой достижимые пути в его модели, которую он строит, исходя из функциональных требований, ограничивающих его определёнными рамками.

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

Доклад посвящён тому, как взять лучшее из обоих подходов для разработки «hackerproof»-приложений.

Быстрый рост IТ-компаний, как правило, влечет за собой необходимость в увеличении мощностей IТ-инфраструктуры. Как следствие, это несет за собой сложности в части поставки нового оборудования и масштабирования информационных систем. Облачные провайдеры могут значительно облегчить решение этих проблем за счет быстрого предоставления необходимых вычислительных ресурсов и управляемых сервисов. Однако при размещении своих сервисов в облаке, важно сохранить должный уровень защищенности.

Относительно недавно мы в своей компании тоже столкнулись с подобной задачей, поэтому готовы рассказать о «подводных камнях» заезда нагрузок экосистемы Т-Банка в публичное облако на примере Yandex Cloud, а именно: особенности обеспечения доступа пользователей в YC, настройка сетевой сегментации в большом количестве облаков, защита пайплайна и обеспечение контроля публикации приложений из YC.

Решили выстроить процесс автоматизированного анализа кодовой базы на уязвимости, но DefectDojo не выдержал нагрузки? С такой же проблемой столкнулись и мы два года назад. За это время мы разработали собственную платформу оркестрации SAST- и SCA-инструментов и ежедневно проводим полторы тысячи сканирований, подключив к системе шесть тысяч проектов, а наша БД, хранящая «сырые» сработки, перевалила за 300 гигабайт.

Расскажем, как мы справляемся с такими объёмами, чего нам стоило разработать собственную систему vulnerability management силами 3 разработчиков, как мы справляемся с анализом проектов в миллионы строк кода и как проводим многоступенчатую дедупликацию данных, благодаря которой 150 миллионов «сырых» срабатываний SAST-анализаторов превращаются в несколько тысяч агрегированных срабатываний в Web-UI, с которымИ работают разработчики.

Кратко:
Попробуем разобраться, как инструментально отлавливать уязвимости бизнес-логики максимально «слева», а самое главное — как обернуть это в понятный и ненасильственный для команд процесс.

Подробно в тезисах:
* уязвимости бизнес-логики — самая неприятная история, которую не найти сканерами;
* отловить такие проблемы может и сама команда на ранних этапах планирования, необязательно привлекать Security;
* моделирование угроз можно и нужно обернуть в процесс, а командам — дать инструменты, которыми они смогут пользоваться в своих Agile-процессах;
* варианты процессов и инструментария: плюсы, минусы, опыт и обратная связь;
* как дальше этот процесс можно увязать: с чемпионами, с моделью зрелости команд, с оценкой рисков и адаптивностью проверок безопасности на гейтах.

ЭЦП сейчас используется повсеместно и за последние несколько десятков лет эволюционировала во множество алгоритмов, начиная с симметричного MAC и заканчивая пороговыми, групповыми подписями, квантово-устойчивыми подписями и даже zero-knowledge-доказательствами валидности проверки подписи.

Доклад рассказывает о различных типах подписей, их эволюции, лежащих под ними математических концепциях, их слабых и сильных сторонах, о том где они применяются и какие правильные вопросы задать криптографам, предлагающим внедрить тот или иной криптоалгоритм.

В докладе разберём на примерах различные векторы атак на CI/CD. Подробно рассмотрим, к чему приводит их реализация и какого импакта можно добиться. Обсудим, как защититься от таких атак, и рассмотрим практические примеры использования различных способов смягчения рисков.

VK развивает более 200 проектов — суммарно это более 40 тысяч репозиториев с кодом, который команды разработки хранят в разных системах контроля версий. Чтобы строить процессы безопасной разработки, инженерам ИБ нужно иметь под рукой актуальную информацию обо всех из них.

Для этого мы (департамент защиты приложений VK) своими силами разработали на Python инструмент, ежедневно осуществляющий обход всех систем контроля версий, укладываясь в rate-limit, и сохраняющий в БД информацию о репозиториях (и образах), хранящихся в них, чтобы мы могли быстро и эффективно искать уязвимый код, библиотеки и чувствительную информацию.

Расскажу, как выглядит процесс инвентаризации, что мы сохраняем в БД, как применять полученные данные для решения задач DevSecOps, даже если у вас далеко не 40 тысяч репозиториев, а также поделюсь исходным кодом наших наработок.

При внедрении DevSecOps-практик многие сталкиваются с такими проблемами:
* выявленных уязвимостей больше, чем команда может исправить;
* высокий false positive rate статического анализатора;
* у команды продукта не хватает знаний и компетенций для исправления уязвимости, она не понимает, что требуется сделать;
* нехватка инженеров ИБ на рынке, которые могли бы сопровождать команды и улучшать качество работы анализаторов;
* текучка кадров и динамичность технологического стека — мы не успеваем учить всех принципам безопасной разработки.

В докладе расскажем о том, как создавали и внедряли решение для помощи разработчикам в устранении уязвимостей и недостатков в коде с использованием технологий ИИ. Поделимся результатами сравнения коммерческих и Open Source-моделей, различными трюками для улучшения качества, тестирования, обогащения данных. Покажем примеры работы и общую архитектуру решения.

Наш ассистент умеет:
* объяснять суть уязвимости, предлагать векторы атаки (важность конкретного кейса);
* предлагать варианты исправления в коде через GitLab и/или IDE;
* выявлять False Positive-результаты работы SAST;
* собирать обратную связь для улучшения качества работы;
* использовать внутреннюю базу знаний для принятия решений.

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

В докладе пойдет речь о том, как Timeweb Cloud применяет свой подход и масштабирует сетевые сервисы под бизнес-задачи клиентов.

Из доклада вы узнаете:
* о проблемах органического роста сетей в облаке. Откуда берутся L2-домены на десятки тысяч машин, как при этом ведет себя сеть (физическая и виртуальная);
* особенности поведения сетевого оборудования, с которыми вы можете столкнуться;
* с какими запросами приходят клиенты и как это влияет на развитие сетевых сервисов;
* об опыте внедрения и масштабирования подхода Timeweb Cloud — physical vtep vs linux kernel, L3 directconnect vs L2.

Ситуация в IT в России изменилась после 2022 года за счет западных санкций и наших законов. Целые сегменты рынка опустели, ушло большинство западных вендоров, и встал вопрос, что теперь делать с IT-системами. Организации либо начали проектировать свои решения, либо искать отечественных вендоров, которые могут заместить западные продукты и решения. Но практически все такие решения зависят от Open Source-продуктов, на которых они обычно основаны.

Доклад посвящен тому, какие есть подводные камни, при работе с Open Source-продуктами, рассмотрены различные мифы про их использование. К чему надо готовиться при внедрении таких продуктов и чего лучше не делать. Также будет рассказано про методологию построения своего продукта на базе OpenStack.

Service Mesh – технология, которая призвана обеспечить гибкое, стабильное и надежное общение сервисов. Технология, призванная упростить эксплуатацию сетевого взаимодействия. Но сделает ли она систему проще?

За последние шесть лет в Авито мы внедрили два собственных Service Mesh-решения и перешли на Istio. Поговорим о причинах данных переходов, о сложностях, с которыми мы сталкивались, и об их решениях.

Затронем следующие темы:
* причины выбора собственной реализации и почему в итоге ушли на Istio?
* почему Istio не сделает проще?
* польза и трудности от внедрения mTLS;
* как мы ускоряем разработку Service Mesh и отлаживаем его работу.

Поговорим и про организацию процессов, и про техническое устройство Service Mesh на масштабе более трех тысяч сервисов и миллионов запросов в секунду.

Многие знают, что K8s рожден быть многотенантным, но не многие сразу понимают, что не только его нужно делать таковым.

В этом докладе хочу поделиться опытом эксплуатации десятков многотенантных кластеров K8s с тысячами RPS входящих запросов. CPU, MEM, HDD и Network — далеко не единственные коммунальные ресурсы, за которые ваши поды будут сражаться. Помимо них, у нас есть ingress, а еще egress. В каждом случае надо разбираться отдельно: где-то Open Source-сообщество уже сильно вам помогло, а где-то вам надо помогать сообществу.

ЦОДы уровня TIER 3 не падают. А даже если падают, то есть DRP-планы, и на бумаге мы должны прекрасно пережить отказ дата-центра. Поэтому часто бывает соблазн отложить задачи техдолга чуть в сторону. Но иногда достаточно проблем с электропитанием, программного сбоя или просто человеческого фактора, и все риски могут стрельнуть разом.

Расскажем о том, как пережить падение ЦОДа на опыте VK Cloud. Как мы восстанавливались, корректируя архитектуру решения без простоя для клиентов и сервисов, и какие уроки приготовили для вас.

В наш век повсеместного распространения контейнеров все считают их привычной магией и забывают о том, что они построены на базе самых стандартных технологий, которым не один десяток лет. Особенно это касается организации сетевого взаимодействия. Пора снять завесу тайны с этих технологий и потрогать их руками!

Всегда хотели вжух-вжух и дебажить сети в этих ваших куберах и докерах, но не знали с чего начать? Приходите — покажем, расскажем и научим основополагающим вещам в этом нелегком деле!

На нашем workshop мы разберем те кирпичики, из которых построены все сети как под K8s, так и под стандартными облаками. Проведем лабораторные работы и выдадим домашнее задание по следующим темам:
* набор утилит iproute2 как основной способ взаимодействия с сетевым стеком linux;
* устройство сетевых namespace в ядре linux;
* виртуальные сетевые интерфейсы: виды, особенности, применение;
* OpenVSwitch: лучший сетевой швейцарский нож.

Для участия в workshop вам потребуется ноутбук с доступом в Internet и ssh-клиент.

Большинство из вас в курсе, что мы в CDEK в конце мая заводили наш энтерпрайз с полного нуля. Пока воспоминания свежи, поделимся лайфхаками. Что уже должно быть у вас в коде (и в голове) до того, как все полетит в тартарары? Какие ваши апи самые важные? Какие, казалось бы, одноразовые скрипты не стоит выкидывать? Какие схемы стоит нарисовать заранее? Какие дополнительные навыки стоит изучить, чтобы быть полезным во время армагеддона?

Это будет история о том, как наш проект внезапно столкнулся с нагрузкой в 20 000 RPS в самый ответственный момент, какие управленческие и технические решения мы принимали в условиях кризиса, чтобы минимизировать ущерб и восстановить работу системы.

Поделюсь нашим опытом разграничения нагрузки, оптимизации запросов в базе данных и API, а также тем, как мы избавлялись от старых «костылей». Вы узнаете, как нам удалось увеличить устойчивость системы до 10 000 RPS всего за двое суток, и какие у нас планы по достижению стабильной работы при нагрузке свыше 20 000 RPS.

Это будет не просто технический доклад, а познавательная история одного проекта со всеми его взлетами и падениями как для новичков, так и для опытных специалистов, которые сталкиваются с проблемами высокой нагрузки и дефицитом времени на оптимизацию. Приготовьтесь к увлекательному путешествию по реалиям быстрого реагирования на кризисные ситуации!

Расскажу, как мы держим «Пульс» не ниже 99,99 — обрабатываем ежедневную нагрузку автоматизированных HR-процессов более 3000rps, переживаем пики нагрузки при повседневной работе, по рассылкам об обучении или важной информации от руководства, либо High Season пользовательской активности в конце кварталов или года.

В докладе разберем подход к конфигурированию базового образа для запуска Java-приложений в контейнеризированной среде без изменений кодовой базы. На основе практических исследований выясним, как повысить утилизацию CPU, какой тип аллокатора выбрать, на что влияет выбор GC (пропускная способность, максимальная задержка, потребляемые ресурсы), как эффективно использовать всю доступную память, какие области необходимо ограничить, как защитить себя от прихода сверхпиковой нагрузки.

Вопрос управления расходами на инфраструктуру был и остаётся актуальным. А в нынешние турбулентные времена — актуальным вдвойне. Для облаков придумали FinOPS — с инструментами, графиками, детализацией вплоть до вызова конкретной serverless-функции. А что в on-prem? По-прежнему непонятные таблички и ещё более непонятные счета?

Давайте разбираться.

* Чем отличается облако и он-прем с точки зрения затрат?
* Из чего состоит «Железный» FinOPS?
* При чём тут управление рисками?

В компании Скала^р используется собственное решение для управления сложными IT-инфраструктурами, основанное на графовом Control Plane, разработанном на базе опыта в суперкомпьютерной индустрии. Это решение, распространяемое по открытой лицензии Apache 2.0, объединяет программные и аппаратные компоненты в единую модель IT-инфраструктуры, при этом эффективно обрабатывая большой поток сигналов и поддерживая кластеризацию с резервированием данных.

Главная задача применения этой технологии в Скала^р — интеграция всех этапов жизненного цикла ПАК от проектирования до эксплуатации. Графовая модель позволяет системам взаимодействовать в единой интеграционной среде, что значительно сокращает время на настройку и синхронизацию, минимизируя ручные процессы и обеспечивая высокую консистентность данных.

Эта технология эффективно решает проблемы традиционных методов интеграции, таких как обмен API или сообщениями, благодаря своей динамичной модели и асинхронной архитектуре. Она легко адаптируется к изменениям и поддерживает стабильность при потерях связи.

Встроенные инструменты визуализации и отслеживания изменений упрощают управление инфраструктурой, повышая прозрачность процессов. Такой подход в Скала^р закладывает основу для создания самоорганизующихся и самоопределяемых систем, что открывает новые возможности для автоматизации и оптимизации работы с IT-инфраструктурой.

Говорят, все, что утекло в Интернет, останется там навсегда. Это не так — хранение данных стоит денег и требует ресурсов. SSD дороги и недолговечны. Но как же быть, если вам нужно сохранить Интернет в архив для будущих исследователей? Для этого существуют технологии хранения «холодных» данных. Они дешевле и надежнее SSD и даже HDD.

В докладе я расскажу, какие существуют технологии хранения данных, чем они отличаются друг от друга. Почему магнитные ленты из 80-х все еще актуальны. Где еще живут забытые оптические диски. Что разрабатывают им на замену. И, оказывается, есть новые российские конкурентные технологии.

Для качественного тестирования разрабатываемых сервисов программно-аппаратного контроллера беспроводного доступа, способного эффективно управлять тысячами устройств, необходимо было создать условия, максимально приближенные к реальной эксплуатации Wi-Fi-сетей.

Мы поместили сервисы реальной точки доступа в контейнер, создав эффективный и масштабируемый инструмент для решения задач имитации функционирования Wi-Fi-сетей в различных сценариях.

Таким образом, мы не только проверяем решения задач управления беспроводными сетями, но и тестируем исправления и улучшения сервисов, обеспечивая, в том числе стабильную работу реальных точек доступа.

Представьте ситуацию: единое тестовое окружение, в котором работает более 300 микросервисов, нагрузка свыше 300 RPS на сервис, и этим окружением пользуются все — от разработчиков до аналитиков.

Задача: нам нужны моки для негативных сценариев, ускорения текущих автотестов и стабилизации сервисов, но нельзя просто взять и замокать сервисы, ведь остальным нужно ходить в реальные сервисы.

Мы выбрали Wiremock, который может быть не только мок-сервером, но и прокси. Однако оказалось все не так просто — Wiremock начал падать даже при нагрузке в 100 RPS, Kubernetes перезапускал поды, а один из багов Kubernetes и вовсе сломал мастер-ноду.

Всё это мало напоминало успех, но в результате — после множества экспериментов и расследований — мне удалось разобраться в причинах. После исправлений всех проблем и аппрува от создателя Wiremock — производительность Wiremock выросла в десятки раз, он стал выдерживать нагрузку более 1000 RPS. Чтобы узнать, как мы с этим справились, с какими проблемами столкнулись и как мы их решали, приходите на мой доклад. Будет интересно и поучительно!

Производительность etcd-кластера с множеством объектов — головная боль команд, которые любят и ценят кубернетес. И вот почему: чаще всего для роста производительности кластера используют горизонтальное скалирование, а это приводит к нагрузке на кластер из-за увеличения времени согласования записи данных. В результате вместо шустрого кластера получается неповоротливый тяжеловес. Мы в VK Cloud разогнали наш Managed Kubernetes под очень высокие нагрузки (500 000 объектов в кластере) и сохранили его производительность. В докладе расскажу, как мы провели тюнинг ectd-кластера, какие настройки нужны, чтобы повысить производительность Kubernetes-кластера. Рецепты пригодятся для команд, которые работают с Kubernetes в облаке и готовят его на своем железе.

* Почему горизонтальное масштабирование etcd-кластера — это плохо;
* почему etcd — это не про большие объемы, и какой опыт у Google, AWS;
* надо понимать, что хотите хранить в etcd;
* как перекосы в типах хранимых данных влияют на производительность и как это исправить;
* что нужно не хранить в etcd и выносить за пределы кластера;
* как одна ошибка в манифесте может заставить достичь лимитов Kubernetes и сломать его.

Технологии не стоят на месте. Особенно, если речь заходит о Java-технологиях и JVM.

Когда говорят о производительности Java и микросервисов на Spring Boot, есть несколько болевых точек, в которые постоянно бьют: время запуска и динамическая компиляция байт-кода JIT-компилятором JVM.

В этом докладе мы поговорим о новшествах, которые появились в Java и JVM: CRaC и GraalVM. Они призваны решать упомянутые проблемы. Но разработчики и рынок еще к ним не готовы, потому что не знают, как именно это работает и что, вообще, с этим делать.

Добро пожаловать в мир Java и компиляторов! :)

Детектирование и устранение инцидентов, управление бизнес-объектами мониторинга, политики эскалаций, постанализ — эти процессы помогают эффективно выявлять и устранять возникающие инциденты. Для выстраивания таких процессов нужен удобный инструментарий.

На докладе будут освещены следующие аспекты:
* как внедрение платформы помогает снижать MTTR и повторяемость критичных инцидентов?
* какие технические сложности проектирования и разработки нам пришлось преодолеть, чтобы сделать отказоустойчивый продукт?
* инцидент-менеджмент — это только про IТ или не только?

Наивный способ отправлять файлы по сети — это читать данные в буфер из файла (системный вызов read) и записывать этот буфер в сокет (системный вызов send). Такой подход не самый эффективный, потому что переключения контекста и лишние копирования из кэша ядра в пространство пользователя и, наоборот, из пространства пользователя в буфер сетевой карты очевидно излишни. Для оптимизации такой задачи еще в начале 2000-х в ядре linux появился системный вызов sendfile, в него можно было передать файловый дескриптор, сокет, количество байт и отступ, и в итоге за один системный вызов ядро делало необходимую работу без лишнего копирования и только с одним переключением контекста. Проблема только в том, что данная схема не работает если мы используем TLS, потому что данные перед отправкой в сокет надо зашифровать блочным шифром. С версии ядра 4.13 уже появилась частичная поддержка (TLS 1.2), а с версии ядра 5.1 полноценная поддержка (TLS 1.3) шифрования трафика на стороне ядра — kernel TLS (сокращенно kTLS).

В докладе подробно будет рассказано, каким образом можно реализовать поддержку kTLS с упором на java. Реализация этого функционала позволила значительно улучшить скорость отдачи данных консьюмерам в кластере Apache Kafka.

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

Мы — компания, работающая с большим парком разнообразных IoT-устройств в микромобильной области. В разные этапы жизни компании мы сталкивались с различными проблемами высокой нагрузки, масштабирования и отказоустойчивости. Разные виды протокола, особенности аппаратной части, приводило к необходимости унификации нашей IТ-платформы, а также решать вопросы со statefull-соединениями IoT-устройства и бэкенда.

Доклад о том, как мы изменили архитектуру для увеличения стабильности связи с IoT-устройствами, как не получать downtime в высокочастотном сервисе, а также как решали вопросы с балансировкой соединений и сообщений от IoT-устройств и как жить в K8s с «несовременными» протоколами обмена сообщений.

В линейке складских роботов Яндекса есть несколько роботов. Один из них — робот Spectro — выполняет задачу инвентаризации и актуализации состояния товара на складе.

Робот представляет собой платформу размерами 2 на 1 метр, которая автономно передвигается по складу и сканирует аллею с помощью массива камер высокого разрешения, установленных на мачте высотой 12 м. Вся обработка этого огромного потока данных выполняется непосредственно на самом роботе в процессе его движения и тесно интегрирована с системами на роботе.

Доклад посвящен системе сканирования на роботе Spectro и задачам, которые ей необходимо решать. Поговорим об организации пайплайна обработки данных, как эффективно получать синхронные кадры с камер и как нам в этом помог YDB. Расскажем о средствах профилирования, которые помогли улучшить наш код, а также почему мы отказались от ROS2 при реализации системы сканирования.

Генеративные нейросети научились рисовать картины, писать осмысленные тексты и подняли ряд непростых вопросов. Можно ли использовать в серьезных проектах код, написанный нейросетью? Что такое, вообще, «хороший код»? Действительно ли «Исходники — лучшая документация»? Я пишу код 25 лет, а пять лет изучаю нейрофизиологию, чтобы писать код чуть лучше.

В докладе я расскажу о том, что современная наука знает (или не знает) о коде: как мы его осознаем, сколько строк «влезает в голову», что делает код «читаемым». И вместе с вами прикину, какое будущее нас может ожидать и к чему можно готовиться прямо сейчас. Станет ли код на любом языке программирования новым «ассемблером», который будут писать и читать нейросети по текстовому описанию. И нужно ли заботиться о том, чтобы код был читаем для человека?

* Объяснение OpenRAN в целом и их роль как спецификаций, достаточных для проектирования и производства отдельных узлов RAN небольшими командами при некосмических бюджетах.
* Преимущества OpenRAN по аналогии с текущим состоянием рынка оборудования стека Ethernet-IP-TCP-App.
* Юридические и регуляторные основания и предпосылки к внедрению OpenRAN.
* Политические предпосылки к внедрению OpenRAN, в частности, потенциал к импортозамещению.

Препятствия к разворачиванию OpenRAN:
- в аппаратном обеспечении;
- в программном обеспечении;
- в организационных аспектах существующих поставщиков;
- кейсы из наработанного опыта.

Random Coffee на HighLoad++ 2024 — это интерактивное событие, направленное на развитие профессиональных связей между участниками конференции. С помощью специального Telegram-бота участники могут зарегистрироваться и получить случайно подобранного собеседника для непринужденной беседы. Активность позволяет каждому найти интересные знакомства и обсудить актуальные темы в сфере высоких нагрузок и смежных областях. Присоединяйтесь к Random Coffee и откройте для себя новые возможности нетворкинга!

Открытость данных против интеллектуальной собственности. Боты против систем защиты — эта игра в кошки-мышки идёт уже много лет. В докладе я расскажу о текущей ситуации в этом сражении.

Я участвую в развитии сервиса, который скачивает 200М страниц в день с сайтов, защищённых антибот-системами. Расскажу, как мы пытались заставить браузер в контейнере под Linux выглядеть как браузер под Windows.

О вызовах, с которыми мы столкнулись при масштабировании системы обхода таких антибот-систем, как
* Cloudflare,
* Datadome,
* Incapsula.

В частности, как антибот-системы принимают решения, базируясь на:
* Canvas,
* шрифтах,
* общей целостности отпечатка и почему сложно учесть все аспекты при его подделывании.

App.Farm — это PaaS-платформа, предназначенная для управления интеграционными потоками и средой исполнения приложений в РСХБ.

В докладе речь пойдёт о ключевых аспектах архитектуры и особенностях интеграции платформы App.Farm. Также мы расскажем об уникальных решениях и подходах, которые разработала наша команда для эффективного выполнения поставленных задач.
Этот доклад будет полезен специалистам, которые занимаются интеграцией высоконагруженных систем и стремятся обеспечить их безопасную и стабильную работу.

Во время доклада вспомним, как работают асинхронные движки, а также разберём, почему стандартный GDB не справляется с отладкой асинхронных приложений на С/С++.

На примере наших приключений по исправлению ошибок в Odyssey (пулер соединений для PostgreSQL) разберём, как всё-таки можно научиться искать ошибки в асинхронных приложениях с помощью GDB.

Задача идентификации клиентского трафика остро стоит для большинства компаний, которые используют эти знания для рекламных кампаний, борьбы с фродом, ботами при условии невозможности проставить third-party cookie. Одним из возможных решений является использование технологии server-side fingerprinting, при котором сервер анализирует данные клиентского соединения.

В докладе подробно рассмотрим существующие алгоритмы вычисления fingerprint, обсудим их достоинства, недостатки и ограничения. Поговорим, как можно было бы обмануть существующие алгоритмы, поможет ли режим инкогнито, другие технологии. Я расскажу, какого качества идентификации мы добились в нашей команде на основе исследований и работы с tls-fingerprint для трафика экосистемы МТС, а также в каком направлении идет развитие этих алгоритмов. В докладе будет много технических подробностей, связанных с работой сетевых протоколов и вычислением fingerprint.

Может ли клиентская статистика быть «ленивой» или стоит предъявить жесткие требования ко времени ее отправки? Что лучше — «тонкие» события, содержащие минимум информации, или «толстые», в которых находится большой объем избыточных данных? Стоит ли отправлять статистику с регулярным временным интервалом или более правильно делать это сразу после возникновения события?

В докладе сравним разные подходы к сбору технической статистики, идущей с клиентских приложений на бэкенд. Кроме того, на примере видеоплатформы VK рассмотрим, как поменять один подход на другой на высоконагруженном, работающем 24/7 сервисе с более чем 500К событий статистики в секунду.

В докладе я подробно расскажу, как про старую модель статистики, так и про новую, про их преимущества и недостатки, поделюсь результатами внедрения новой статистики.

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

Мы рассмотрим решение данной проблемы на примере внедрения ML в алгоритмы прогнозирования времени экспресс-доставки, спроектируем целевую архитектуру, а также поймем, на какие вещи важно посмотреть:
1. как ее поэтапно внедрить, минимизировав риски;
2. как вовремя замечать узкие места и ускорить time to market;
3. когда начинать оптимизировать и как потом остановиться.

Когда переход на VXLAN в облачных сетях грозил нарушить работу системы анализа трафика, нам нужно было найти быстрое и эффективное решение. В этом докладе поделюсь опытом использования технологии eBPF для решения этой задачи. Как eBPF помогла нам решить ее без значительных изменений в архитектуре системы в целом.

Вы узнаете, как происходит обработка сетевых пакетов ядром Linux и из каких этапов она состоит. А еще — как можно использовать eBPF, чтобы внедрить дополнительную логику в сетевой стек Linux.

Расскажу, какие требования привели нас к eBPF, и как мы внедрили эту технологию для анализа и декапсуляции пакетов VXLAN на серверах, обрабатывающих до 6 миллионов пакетов в секунду.

В докладе будут раскрыто:
* какие инструменты мы используем для анализа трафика клиентов и переход на VXLAN;
* рассмотренные решения для декапсуляции VXLAN и выбор в пользу eBPF;
* инструменты, использованные для реализации решения;
* результаты и выводы, полученные в ходе внедрения eBPF.

Picodata - это распределённая СУБД, где мы реализовали поддержку плагинов на языке Rust, что оказалось нетривиальной задачей.

Поговорим о том, что такое плагины вообще и кому они могут быть нужны, разберём технические детали реализации, а также пройдёмся по интересным особенностям, вызванным специфическими условиями, в которых нашим плагинам приходится функционировать.

В докладе будут затронуты следующие темы:
* сравнение различных способов расширения функциональности;
* Foreign function interface (FFI) и как с этим работать в Rust;
* дизайн системы плагинов в условиях распределённой системы.

Каждый день в публичном облаке Yandex Cloud запускается огромное количество виртуальных машин (ВМ). В большинстве случаев на одном хосте одновременно существуют несколько ВМ, принадлежащих разным клиентам. В такой ситуации одной из задач провайдера облачных услуг является разделение ресурсов хоста между ВМ. Но позволяют ли современные процессоры на x86-64-архитектуре разделить и изолировать абсолютно всё?

Процессоры имеют внутренние ресурсы, которыми программист не имеет возможности управлять явно. Например, кэш и шина памяти. От их доступности может зависеть производительность приложений в ВМ. Но как понять, что производительность приложения снизилась именно из-за конкуренции ВМ за внутренние ресурсы процессора?

Этот доклад про увлекательное исследование в Yandex Cloud длиной в год, из которого вы узнаете о способах обнаружения проблем с производительностью приложений из-за конкуренции за кэш L3 и шину памяти.

В докладе покажу пример поэтапного улучшения решения, на первый взгляд, несложной задачи, с сопутствующими «граблями», в ходе которого осваиваем понимание плана запроса, преодолеваем страх писать на Scala, даже если проект на PySpark, убеждаемся в такой себе производительности Python UDF.

Доклад рассматривает роль Greenplum (GP) в текущей аналитической платформе и ожиданиях по фичам, которые должны были появиться с выходом GP 7. Но после закрытия проекта как Open Source-решения, сроки доступной production-ready сборки GP 7 сдвинулись на неопределенный срок.

Обсуждаются ключевые критерии выбора новых решений, таких как масштабируемость и совместимость. Посмотрим на альтернативы с акцентом на концепцию Data Lake House (DLH). Разберем преимущества технологий для реализации DLH: Iceberg, Trino и S3 и что делает их привлекательными для современных проектов.

В заключение перейдем к практике. Разберем успешный кейс внедрения production DLH для обработки данных clickstream, с которыми на Greenplum работать ресурсоемко.

В современном мире больших данных и больших вычислительных нагрузок оптимизация Spark-приложений играет решающую роль в обеспечении эффективной работы систем. В данном докладе мы рассмотрим ключевые аспекты, позволяющие улучшить производительность Spark-приложений — от базовых методов до более сложных техник, которые вы сможете воспроизвести самостоятельно.

В докладе будут рассмотрено:
* эффективное использование специального скрипта, ручного и автоматического репартицирования для улучшения обработки данных;
* настройка оконных функций и их влияние на производительность;
* различные подходы к объединению данных и случаи, когда лучше обойтись без него.

В заключение доклада будет показано, как запуск множества небольших Spark-приложений в одном может повысить эффективность обработки данных и значительно снизить необходимые ресурсы — как ОЗУ, так и ЦПУ. Мы также обсудим, зачем это нужно и как все шаги, описанные в докладе, способствовали нашей цели.

В докладе я поделюсь опытом разработки и внедрения инференс-платформы на базе Triton Inference Server и Kubernetes. С какими проблемами мы столкнулись в Seldon и почему отказались от него. Как мы обеспечили канареечный деплой инференсов с помощью Istio. Каким образом реализовали инференс-граф на отдельных нодах с GPU с помощью Ray.

Вы узнаете, как наше решение позволило увеличить пропускную способность инференса в 10 раз. За счет чего это произошло?
Мы используем автоматический подбор конфигураций Triton для сетапа динамического батчинга запросов и конвертацию разных форматов моделей в tensorrt.

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

Какие профиты мы еще получили? Теперь дата-сайентисты могут сами деплоить модели с минимальным участием опсов.

Доклад об опыте создания MLOps-платформы на 20+ команд. Расскажем, как выбирали стек, исходя из бизнес-задач и потребностей ML-разработчиков. Поделимся видением, почему для компании нашей структуры подошел в качестве основы платформы именно KubeFlow. Расскажем об этапах раскатки KubeFlow в Яндекс.Облаке и нюансах на каждом этапе. Честно поделимся опытом разработки шаблонов и обучений, деления GPU на команды, интеграции с Vault для хранения секретов и подготовки CI/CD на базе Jenkins и Artifactory.

Закончим на приятной ноте: что мы получили с точки зрения пользовательского опыта и бизнеса — сократили time-to-market выкатки моделей в прод в 1.5 раза при потреблении в 1.9 раза меньше ресурсов.

В мире, где большие языковые модели (LLM) становятся основой для автоматизации бизнес-процессов, важно понимать, как правильно интегрировать их в корпоративную инфраструктуру. В своем докладе я поделюсь опытом внедрения LLM в компании X5 Tech, начиная с простых вопросов: что такое LLM и как они могут изменить подход к решению задач.

Далее мы обсудим три ключевых бэкенда для инференса, которые обеспечивают различные уровни производительности и удобства, и покажем, как правильно выбрать подходящий инструмент в зависимости от имеющихся ресурсов и бизнес-целей. Я расскажу о том, как оптимизация инференса влияет на качество ответов и скорость реакции приложений, таких как чат-боты, и почему это критически важно для успешной работы.

На примере нашей инфраструктуры в X5 Tech я покажу, как мы организовали работу с LLM, включая использование специализированных решений для управления запросами и анализа производительности. Наконец, я поделюсь практическими рекомендациями по выбору и тестированию моделей, основанными на нашем опыте, чтобы помочь вам избежать распространенных ошибок и эффективно использовать LLM в вашем бизнесе.

Присоединяйтесь к моему выступлению, и вы узнаете, как можно быстро и эффективно внедрить LLM в вашу компанию, сокращая время и затраты на разработку, а также повышая качество обслуживания клиентов.

Я расскажу про то, как мы построили систему, которая держит миллионы RPS и позволяет во всех частях рекламы в режиме реального времени иметь точную и актуальную информацию о рекламном событии со всей его многодневной историей изменений.

Таким образом, мы решили проблему того, чтобы в MapReduce-мире обогатить событие информацией из всех предшествовавших ему в течение 100 дней шагов — долго и дорого, особенно когда счет этих событий идет на миллиарды. А ещё мы нашей системой решили проблему того, что в разных частях рекламы одни и те же статистики показывали разные значения, что осложняло жизнь аналитикам и вызывало вопросы у наших пользователей.

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

Приходите, будет интересно!

Построение собственного Feature Store — это не классическая задача, которую можно сделать за пару недель.

В докладе я расскажу о том, как мы последовательно внедряли наше решение в существующие пайплайны «на ходу» и параллельно успевали решать бизнес-задачи. Покажу, с какими сложностями сталкивались и что ожидает большую компанию, которая уже имеет зоопарк ML-моделей и хочет сделать пайплайн лучше.

В современном мире генерацией любого текстового контента на LLM уже никого не удивишь. Однако в практическом применении больших языковых моделей (LLM) все еще возникают значительные сложности, такие как галлюцинации, проблемы производительности, высокая стоимость обработки, а также проблемы интеграции с реальными системами.

В своем докладе я поделюсь двумя практическими кейсами, как мы решали реальные задачи с использованием LLM.

Первая задача связана с парсингом информации из открытых источников и ее оценкой с помощью LLM. В этом кейсе мы рассмотрим, как экономично извлекать тональность отзывов на веб-сайтах, обрабатывать различные типы страниц и обеспечивать высокое качество анализа.

Вторая задача касается разработки бота для онлайн-библиотеки, который должен одновременно быть креативным и иметь фантазию, но при этом рекомендовать только имеющиеся в наличии книги. Мы обсудим, как интегрировать знания LLM о литературе с конкретным ассортиментом онлайн-библиотеки и как решать проблемы интеграции бота с поисковым API.

Проекту SPYT, обеспечивающему интеграцию Apache Spark с YTsaurus, больше 5 лет. Несколько лет назад мы уже рассказывали о том, как нам удалось их подружить так, чтобы всё работало эффективно (https://highload.ru/spring/2021/abstracts/7266). С тех пор в проекте произошел ряд важных событий, и самое главное из них — выход YTsaurus в Open Source весной 2023 года.

Выход в Open Source принёс в проект ряд новых требований. Во-первых, как и многие другие компании, мы использовали свой форк спарка, в котором сделали ряд модификаций. И при выходе в Open Source нам пришлось включить весь код модифицированного спарка в свой репозиторий (а это больше 2 миллионов строк), хотя в целом изменения там были не очень существенные. Это сильно усложнило как понимание самого кода для сторонних разработчиков, так и процесс его сборки и модификации.

Ещё одним требованием, возникшим после выхода в Open Source, стала одновременная поддержка нескольких версий спарка. И если внутренних пользователей в целом устраивала версия спарка, на которой был основан форк, то внешние пользователи хотели использовать произвольную версию спарка, не ограничиваясь лишь той версией, на базе которой мы сделали свой форк.

Перед нами встала задача: перенести все наши доработки из форка в SPYT и перейти на использование оригинальных дистрибутивов спарка. Другой сопутствующей задачей стал уход от жёсткой привязки к определённой версии спарка и обеспечение возможности работать с произвольной версией таким образом, чтобы сохранился весь функционал и не была нарушена бинарная совместимость между SPYT и спарком.

В своём докладе я расскажу о том, зачем изначально нам потребовалось сделать форк и пропатчить Apache Spark, какие это вносило неудобства, и как мы справились с самыми главными вызовами после выхода проекта в Open Source: отказ от форка Apache Spark и поддержка работы SPYT, используя произвольную версию Apache Spark.

Опираясь на свой опыт, расскажем о том, как на основе стриминга удалось достичь синергии развития аналитических платформ (real-time-аналитика и ML, BigData&DWH, feature store, A/B-платформа, etc.). Мы рассмотрим предпосылки для данного решения и кратко коснемся логики выбора из ряда альтернатив.

Рассмотрим практический пример реализации сложного stateful-стриминга, расскажем, с какими сложностями столкнулись и какой результат получили на выходе, пройдя через тернии.

Расскажу об опыте внедрения ML Feature Store в нашей компании. Мы проделали большой путь от использования стандартных backend-хранилищ до создания собственного Feature Store, оптимизированного для нужд Data Science- и Machine Learning-проектов.

Мы изучили существующие фреймворки (Feast, Tecton, Featureform) и поделимся, почему из коробки не удастся получить готовый ML Feature Store.

Методом проб и ошибок мы нашли простое решение, и на его внедрение у нас ушло 3 месяца одного разработчика. Хотим донести, почему мы делали конкретные решения на каждом шаге внедрения.

Наш ML Feature Store ускорил время вывода фич для ML-алгоритмов с трёх месяцев до одного дня.

Мы использовали Trino / S3, Yandex DB, Spark, Python, но покажем общее архитектурное решение, и вы сможете адаптировать его под свой стек. Сейчас наше решение держит нагрузку ~1.5К RPS на чтение, хранит > 200 GB данных, из них ежедневно обновляется около 15 GB, время ответа < 80 ms. Путём горизонтального масштабирования планируем нарастить эти цифры до 30К RPS, 1 TB данных с сохранением SLA.

Уже более двух лет создаем MLOps-платформу для создания рекомендательных сценариев.

В докладе будет рассказано:
* как реализовали работу со Spark-нагрузками на RecSys-платформе;
* какие были проблемы со Spark и почему пришли к текущему решению:
* как использовать Spark в Multi-tenant-архитектуре;
* также поговорим о проблемах использования Spark in K8s.

Расскажу, как мы быстро и дешево сделали полноценный инструмент Data Lineage для Apache Spark в одном из крупнейших хранилищ страны. Data Lineage — информация о взаимосвязях данных от источников до конечных потребителей. Слушатели смогут понять, как воспроизвести способ формирования Data Lineage в своей компании, как его можно использовать и какие есть ограничения.

Многие из задач машинного обучения требуют, чтобы ответ от модели был получен как можно быстрее. Обычно ответ на вопрос ускорения модели достаточно прост — задеплоить на ГПУ. Но не всегда это возможно по тем или иным причинам. И что же делать?

В докладе расскажу, как в Домклике используют нейронные сети для голосовых и текстовых ботов. Поговорим о том, почему переезд нейронки на ГПУ — это не всегда лучшее решение. Препарируем трансформер RoBERTa, посмотрим, из чего он состоит и как ускорить выполнение каждой части отдельно. Обсудим, как задеплоить полученные артефакты в прод и какие еще методы ускорения модели и ускорения постобработки можно применить.

В заключение посмотрим, какого результата удалось добиться и стоило ли оно того, а также рассмотрим ситуации, когда без ускорения моделей ну никак не обойтись.

В наше время бизнес все больше зависит от данных, их ценность возрастает, на их основе строятся различные продукты и принимаются критичные решения. Но что, если данные «плохие»? Я хотел бы поделиться, почему лучше считать, что все данные по умолчанию не очень, если не доказано обратное. Расскажу о таком процессе, как обеспечение качества данных или Data Quality и как оно связано с Data Governance.

На базе пресловутого DMbook посмотрим на базовые метрики DQ: Accuracy, Completeness, Consistency, Timeliness, Validity, Uniqueness, и обсудим, почему не всегда хорошо их использовать. Расскажу про текущих лидеров в Open Source и не только: Soda, Great_expetations, Deequ и т. д. Чем они хороши, и когда не стоит писать свой велосипед. Расскажу, как мы в Wildberries построили процесс проверки качества данных на дата-платформе, затрону нетривиальные кейсы на основе самописного холодного хранилища Blob Storage — как тут могут помочь эксперименты и непопулярные у нас технологии.

Мэтчинг товаров (выяснение, являются ли два товара одинаковыми) очень важен для бизнеса Wildberries и других маркетплейсов. Современные LLM (large language model) органично дополняют классические алгоритмы машинного обучения. Рассмотрим конкретные примеры использования LLM для извлечения атрибутов товаров и их дальнейшего мэтчинга.

В докладе я расскажу о том, какие фичи мы извлекаем, чтобы найти нужный кадр среди 40 тысяч видео. Что нужно сделать, чтоб векторная база при этом не распухла до ужасных размеров. О том, как заставить англоязычную мультимодальную модель понимать русский язык. Про борьбу с галлюцинациями Whisper и о том, как объединить результаты поиска по огромному массиву разнородных эмбеддингов.

У нас получилось ускорить наши претрейны в полтора раза, а соседние сценарии Alignment/DPO в 5-10 раз! Как и за счет чего можно достичь такой скорости?

В докладе я расскажу про:
* особенности обучения на больших кластерах и узкие места в современных претрейнах;
* библиотеку YaFSDP как способ побороть неэффективности в коммуникациях;
* оптимизации памяти;
* ценность 3d-4d-параллелизма для обучения реально больших моделей;
* о том, как мы ускорили MoE.

Возможно, будут и другие секретные оптимизации. Мы ускоряем наши обучения постоянно, поэтому к моменту выступления доклад может наполниться еще одним-двумя трюками.

В моем докладе:
1. влияние модерации на клиентский опыт: как стандартные подходы к модерации, такие как блокировка, ухудшают пользовательский опыт и почему скрытие нарушений на изображении может стать отличной альтернативой;
2. поговорим про блюр как инструмент модерации: эффективное применение блюра для маскировки нарушений на изображениях, или как мы сократили количество ручных проверок изображений в 10 раз;
3. восстановление изображений с помощью inpainting: как создать систему, которая удаляет нарушения с фотографий, сохраняя их исходный вид или даже улучшая. Обсудим применение передовых методов, таких как LaMa, LDM и SAM, и как эти SOTA-подходы в inpainting и сегментации могут быть использованы для повышения эффективности модерации;
4. результаты внедрения и оценка рисков: реальные примеры успеха и неудач, анализ возможных рисков.

В докладе рассматриваются ключевые аспекты подготовки данных для обучения LLM на примере Gigachat. Качество данных не менее важно, чем архитектура модели, ведь от их состава зависит, насколько эффективно модель сможет обучаться (вы удивитесь, насколько велика может быть разница между наборами данных). Однако собрать данные с интернета — это только начало: необходимо тщательно отбирать данные, которые действительно помогут модели «умнеть», так как не все доступные данные одинаково полезны.

Мы обсудим, что такое претрейн-данные и как выглядит карта кластеров веб-данных, охватывающая русскоязычные и англоязычные сегменты сети. Поговорим про отбор данных: удаление дубликатов на больших объемах, классификацию по обучающей ценности, и эксперименты, которые помогают оценить их качество. Также рассмотрим вызовы кластеризации эмбеддингов с миллиардами объектов.

Кроме того, уделим особое внимание кодовым и математическим данным: их классификации, генерации и проверке на корректность. Например, если вы создаете задачу для олимпиадного программирования — как убедиться, что решение, реализованное вами, действительно правильное? Поделимся результатами экспериментов и методами оценки качества таких данных.

С появлением различных фундаментальных моделей все большее количество привычных задач решается нейронками практически «из коробки». А если не решается сходу, то можно улучшиться небольшим файнтюнингом.

Whisper базово неплохо справляется с транскрибацией речи, LLM правят текстами, yolo значительно ускоряет задачи компьютерного зрения и таких примеров — много. Игнорировать эти большие изменения в процессах разметки невозможно, поэтому мы активно встраиваем различные модели в наши привычные пайплайны с людьми. И часто эта авторазметка позволяет значительно повысить эффективность всех процессов и улучшить результаты.

Я поделюсь проблемами сложной разметки, расскажу о том, как нейронки уже стали неотъемлемой частью процесса разметки, заглянем под капот нашей системы, поговорим про метрики, создаваемые нагрузки и сравнимся во всем с людьми.

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

Будет:
1. почему мы решили отказаться от подрядчика?
2. с чего можно начинать? Смотрим, что у подрядчика под капотом;
3. когда простые методы не работают?
4. как отбирать модели, исходя из требований?
5. как учесть изменчивость интересов пользователей?
6. как извлечь пользу из плохой модели, совместив ее с хорошей?

Внедрение решений на базе искусственного интеллекта в производственные процессы позволяет значительно повысить показатели и быстрее достигать поставленных целей.

В ходе доклада обсудим современные технологии, использующиеся на рынке, разберем архитектуру и принцип работы подобных систем на примере продукта GigaCode, обсудим группы задач, которые решает ИИ, и метрики, повышающиеся благодаря его интеграции, а также затронем будущее и перспективы развития AI-решений в сфере разработки ПО.

Распределенное обучение на примере ранжирующей модели в отделе рекламы Яндекса — это:
1. датасеты в 1+ PiB с требованием распределенного сортированного чтения;
2. шардированный parameter server в несколько TB параметров и рабочей нагрузкой в 300+ Gbps (37 GB/s) на хост;
3. сотни миллиардов рублей в год, с т.з. бизнеса.

В рекламе действует правило «больше модель и быстрее доставка до прода = кратно больше денег». В докладе мы расскажем про оптимизации производительности распределенного обучения нейросетей для рекомендательных систем:
* как обсуждать техническую сложность и зоопарк сетевых коммуникаций на GPU-серверах в красивый клиент-серверный интерфейс;
* как выжать физический предел производительности сетевых карт InfiniBand до 800 Gbps на каждом хосте и как это помогает зарабатывать рекламе деньги;
* какими знаниями должен обладать обычный бэкендер, использующий CPU-only-хосты и TCP/IP-протоколы, чтобы вкатиться в разработку под на порядки более мощное железо.

С развитием оплаты по лицу, подтверждения личности по биометрии и дистанционного обслуживания растет необходимость защиты от идентификационного фрода, и Face Liveness становится ключевым инструментом для этого. Liveness-решения VisionLabs уже используются в московском транспорте, сервисе МТС ID KYC и крупнейших банках.

В рамках доклада обсудим ключевые аспекты технологии, включая её отличия от детекции дипфейков, актуальные тенденции и устаревающие подходы в этой области. Рассмотрим, что эффективнее: универсальная или специализированные модели. Результаты получены в рамках собственных исследований VisionLabs и сравнения работы порядка десяти Liveness-решений. Завершим обсуждение сочетанием Face Liveness с другими методами защиты.