Доклады

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

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

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

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

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

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

В большой компании число микросервисов, участвующих в обработке пользовательского запроса может составлять несколько сотен, а иногда даже и тысяч. В такой ситуации встает вопрос, как организовать их взаимодействие и не потеряться в логике обработки запроса.
В Яндексе для этого разработали собственное решение - AppHost.
Мы расскажем:
- Как работает Аппхост и какие проблемы он решает;
- Каким образом мы всегда можем посмотреть, из чего состоит запрос в наши сервисы;
- Как наш подход помогает в траблшутинге;
- Обсудим плюсы и минусы нашего подхода.

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

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

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

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

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

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

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

Тезисы:
На протяжении 4х лет в Авито мои команды разрабатывали звонки через приложение. Мы создали и запустили платформу с нуля до миллиона звонков в сутки. Это доклад не про кишки webrtc, а про построение архитектуры нагруженной системы и какие сложности нам пришлось преодолеть, учитывая сложный технологический домен звонков;

Что расскажу в докладе:
- Зачем нам вообще потребовались звонки через интернет;
- Как спланировать и построить архитектуру так, чтобы не было мучительно больно ее переделывать при масштабировании
- Каким образом связаны архитектура проекта, хранение данных и законодательство РФ;
- Как мы переводили "хейт" и негативную обратную связь в десятки моделирований и доработок, чтобы сделать качество связи значительно лучше;
Бонус: как мобильному разработчику сделать все перечисленное выше и не "сгореть"

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

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

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

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

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

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

Как перевезти сервис с 120к рпс? а дважды ?
Как раздавать 100500 вариантов картинок на лету и не потратить все деньги мира на железо?
Почему не тупо с3?


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этом докладе я расскажу как мы перепридумали систему работы с товарными данными.
Товаров у нас почти миллиард, а обрабатывать их нужно раз в 10 минут.
Я рассажу что интресного мы обнаружили в наших процессах обработки данных.
Какую архитектуру выбрали и как она помогла нам посторить систему которая позволяет раз в 5 минут обновлять остатки для миллиарда товаров.
Решение оказалось вполне универсальным и подошло и для других задач обработки и обогащения данных в Яндекс Еде.

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

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

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

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

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

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

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

Особенности создания anycast-сети с протоколом BGP в рамках построения CDN национального видеохостинга RUTUBE:
• Дублирование информации с площадки и быстрая раздача на территории РФ и стран СНГ;
• Контроль баланса нагрузки: настройка серверов и использование multicast-маршрутизации.
Увеличение ёмкости глобального CDN национального видеохостинга RUTUBE с 1,5 до 5 Тбит за год
Разработка плана построения крупнейшего CDN на территории РФ и стран СНГ с ёмкостью 10 Тбит к концу 2024 года — опыт национального видеохостинга RUTUBE
Проблемы при построении крупнейшего CDN на территории РФ и стран СНГ:
• Неэффективная раздача «холодного» контента и поиск оптимального решения;
• Трудности при обработке большого объёма контента.

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

Мой доклад про то, как мы делали изолированную архитектуру в существующих сервисах бекенда Яндекс.Лавки, а именно

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

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

Я расскажу, как мы это сделали и как решили следующие проблемы:
- Скорость ответа, как начать отвечать пользователю не за десять секунд, а быстрее
- Цена запроса, как не тратить тысячи 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 операциях и доставлялись непосредственно к движку.

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

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

У нас была железка с ксеоном и 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 архитектуры, редизайна модели данных и интеграционного слоя как основных подходов в процессе выделения.

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

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

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

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

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

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

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

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

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

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

У нас большая дата платформа с несколькими системами хранения и обработки данных. Но не во всех системах есть хороший data governance и правильные процессы. Иногда это приводит к тому, что данные можно легко удалить по ошибке, что и произошло.
Но в этот раз рассказ будет не только про ошибку, но и про то, как нам удалось (почти полностью) ее исправить и что мы делаем, чтобы ее не повторить.
В программе:
- полная остановка боевого кластера Hadoop
- поднятие еще двух кластеров для пользователей
- восстановление данных с дисков после удаления (и очистки корзины)
- игрища с побайтовыми чтениями и поиском parquet magic numbers в петабайтном стогу сена

Любая СУБД должна не только предоставлять качественный сервис, но и эффективно работать на каждом этапе жизненного цикла данных, и резервное копирование -- один из ключевых этапов этого жизненного цикла. При этом возможны различные подходы к резервному копированию, но независимо от подхода необходимо обеспечить ключевые требования по производительности: минимизировать время снятия копии и ее объем, контролировать нагрузку на базу в процессе резервного копирования, уложиться в допустимые RPO и RTO. В докладе расскажем о нашем инструменте Ptrack и применяемом в нем механизме хранения изменений на основе bloom filter и сравним его с выходяшим в PostgreSQL 17 Walsummarizer и его механизмом хранения -- roaring bitmap.

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

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

Чтобы разобраться как это работает, придется научиться думать в терминах распределенной стейт-машины, но я все объясню:

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

Хранение бэкапов это всегда очень большие объемы данных и долгий срок хранения. Разрабатывая нашу систему хранения данных (СХД) для резервных копий 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;

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

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

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

Чем заменить 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) решений и расскажем о планах развития.

Mpstats - лидер на рынке аналитики маркетплейсов, а маркетплейсы - лидер роста рынка в России, как и во многих других странах. Мы собираем очень много данных. Например, на ВБ размещено 110 млн товаров. Для каждого товара мы зайдем в его карточку, запишем данные, как он выглядит, какое у него текстовое описание, сколько остатков, какие были продажи, цвета, поставщик и производитель. Запишем это в базу данных и повторим раз в сутки. Для четверти товаров мы это будем делать раз в три часа, а для 20-25 млн товаров - каждые 15 минут. Теперь добавим сюда Ozon, где товаров в два раза больше, Яндекс Маркет и параллельные разработки новых партнеров. Все это в сумме весит около 750 ТБ uncompressed данных в ClickHouse.
В процессе развития сервиса мы упирались в несколько проблем - ClickHouse не любит обновления, а для нас это критично. Объемы данных требуют буквальных объемов железа, и даже когда оно есть - мы упираемся в его производительность. Шардирование обратно зависимых таблиц тормозит скорость выдачи, а плагин укладывает БД запросами, когда должен отдавать сравнение исторических данных по товару за секунду. Расскажем, как справляемся с этими и другими задачами и делаем это быстрее конкурентов.

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 без стандартных нагрузочных тестов
- Верификация производительности БД до ввода в эксплуатацию.
- Выявление возможных узких мест и проблем в конфигурации.
- Примеры использования статистических данных для идентификации узких мест.

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

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

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

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

Valkey, в отличие от Redis, изначально построен по полностью Open Source модели, у него нет Entrerprise-версии, которая бы каким-то образом ограничивала его развитие.
С момента начала работы над ним весной 2024 года команда разработки успела принять и стабилизировать некоторое количество патчей, заметно улучшающих производительность в сравнении с версией 7.2.
В этом докладе мы посмотрим на некоторые из этих патчей, оценим (с бенчмарками) их позитивные (а местами и негативные) эффекты на производительность.

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

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

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

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

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

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

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

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

* Немного про планирование
* Проблематика или почему не Ansible
* Структура PS скриптов для HL
* "Минимальное документирование но сразу"
* Паттерн "Чек здоровья"
* Паттерн "Логирование событий"
* Явное разделение на последовательные и параллельные процессы
* Паттерн "Асинхронная обработка"
* Паттерн "Управление потоками'
* Паттерн "Пытаемся снова"
* Паттерн "Обработка ошибок"
* Паттерн "Кроссплатформенность"
* Паттерн "Идемпотентность"
* "Юнит тестирование"
* "Контроль версии при запуске"
* Паттерн "Откат изменений"
* Паттерн "Состояние"

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

На примере кейса о переводе новостного сайта на базе Drupal 8 в Kubernetes я расскажу о типовых паттернах архитектуры приложений в Kubernetes и лучших практиках миграции нагруженных приложений на контейнерную инфраструктуру, типичных ошибках и сложностях. А также разберу, как контейнеризация позволяет сделать более надежными и масштабируемыми даже «немодные» технологические решения. Для нас это был своего рода вызов: разбить этот типичный PHP-монолит на микросервисы нельзя, сайтов на Drupal было несколько, к тому же стояла задача в кратчайшие сроки увеличить количество сайтов, и обеспечить отказоустойчивость под высокой нагрузкой.

Структура доклада:
Drupal 8 — как пример классического монолита на PHP, который можно масштабировать только вертикально, а также тяжело и больно поддерживать.
Как всё было устроено до миграции в Kubernetes.
Подготовка Kubernetes-кластера под Drupal-сайты.
Миграция одного сайта в контейнеры: поды бэка падают в crashloop.
Оптимизация производительности нового решения.
Миграция в Kubernetes оставшихся сайтов и масштабирование.

Результаты:
Мы получили отказоустойчивую, самоподлечивающуюся инфраструктуру.
Мы значительно уменьшили Time-to-Market, за счет CI/CD.
Мы экономим на инфре (за счет HPA).
Мы перевариваем трафика 300+ RPS на один сайт.

Всем привет, Инженерная Культура на Масштабе: Как развивать и масштабировать DevOps практики! - это увлекательная история, которая рассказывает как DevOps практики внедрялись в компанию, как они трансформировались от обязательных стандартов к инженерной культуре и впоследствии превратились в "технические возможности" с уровнями зрелости, множеством критериев и автоматизированными проверками в it на масштабе 258 команд, среди которых работает ~3700 айтишников. Доклад поднимает вопросы связанные с инженерной культуры и мотивации инженеров и команд на развитие в этом направлении, а также решает проблему внедрения и измерения технических практик в энтерпрайзе.

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

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

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

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

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

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

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

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

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

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

Мы проследим эволюцию методов защиты от бинарных уязвимостей, таких как переполнение буфера и повреждение памяти. Рассмотрим, как с течением времени развивались способы защиты памяти: от ранних методов, таких как неисполняемый стек, до современных технологий, таких как Control Flow Integrity (CFI) и ARMv8 Memory Tagging Extension (MTE). Но главное — мы поговорим о недостатках, ограничениях и способах обхода этих методов. Обсудим их практическое применение и оценим их эффективность в современных условиях.

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

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

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

В рамках доклада мы разберем:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Отличия подходов к построению облачной инфраструктуры на базе Open Source решений
- Варианты решений построения облачной инфраструктуры которые существуют на рынке Open source
- Облако vs Виртуализация: в чем отличия и как в этом не запутаться!
- Автоматизация и построение высоконагруженных облаков на базе Open Source решений и российских аналогов .
- Вызовы цифровой трансформации и инструменты, помогающие их преодолеть.

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

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

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

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

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

В наш век повсеместного распространения контейнеров все считают их привычной магией и забывают о том, что они построены на базе самых стандартных технологий, котором не один десяток лет. Особенно это касается организации сетевого взаимодействия. Пора снять завесу тайны с этих технологий и потрогать их руками!
Всегда хотели вжух-вжух и дебажить сети в этих ваших куберах и докерах, но не знали с чего начать? Приходите, покажем-расскажем и научим основополагающим вещам в этом нелегком деле!
На нашем Workshop мы разберем те кирпичики, из которых построены все сети как под k8s, так и под стандартными облаками. Проведем лабораторные работы и выдадим домашнее задание по следующим темам:
- Набор утилит iproute2 как основной способ взаимодействия с сетевым стеком linux
- Устройство сетевых namespace в ядре linux
- Виртуальные сетевые интерфейсы: виды, особенности, применение.
- OpenVSwitch: лучший сетевой швейцарский нож.

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

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

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

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

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

Расскажу, как мы держим «Пульс» не ниже 99,99 – обрабатываем ежедневную нагрузку автоматизированных HR процессов более 3000rps, переживаем пики нагрузки при повседневной работе, по рассылкам об обучении или важной информации от руководства, либо High Season пользовательской активности в конце кварталов или года.
В докладе разберем подход к конфигурированию базового образа для запуска Java приложений в контейнеризированной среде без изменений кодовой базы. На основе практических исследований, выясним: как повысить утилизацию CPU; какой тип аллокатора выбрать; на что влияет выбор GC (пропускная способность, максимальная задержка, потребляемые ресурсы); как эффективно использовать всю доступную память, какие области необходимо ограничить; как защитить себя от прихода сверх пиковой нагрузки.
В итоге выработаем подход, который поможет за 20% времени получить 80% результата для всех сервисов:
• предотвратим падение по ООМ (выход за лимиты контейнера) и сделать запас на отказоустойчивость;
• в зависимости от входящего rps при нагрузочном тестировании за счет итеративного подхода сбалансируем объем heap относительно объема контейнера, повысим утилизацию RAM;
• повысим утилизацию CPU и проанализируем, когда начинает появляться тротлинг – хорошо это или плохо;
• перейдем от вертикального масштабирования к автоматическому горизонтальному (HPA) для обработки сверх расчётной нагрузки;
• как помогут probe k8s пережить нагрузку.

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

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

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

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

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

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

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

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

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

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

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

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

- Использование Wiremock не только как инструмент мокирования, но и как инструмент динамического управления траффика
- Решение линейного роста потребления памяти Wiremock'ом в K8s с помощью правильной настройки
- Проблемы проксирования большого траффика Wiremock'ом (Wiremock не мог проксировать даже 100 рпс)
- Попытка решения проблемы через изменение настроек ядра Линукса, в результате которой был обнаружен баг в K8s
- Исправление проблемы в коде библиотеки Wiremock, в результате чего пропускная способность Wiremock'а увеличилась в десятки раз

Производительность 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 и повторяемость критичных инцидентов?
Какие технические сложности проектирования и разработки нам пришлось преодолеть чтобы сделать отказоустойчивый продукт?
Инцидент менеджмент - это только про ИТ или не только?

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

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

Мы компания, работающая с большим парком разнообразных iot устройств в микромобильной области. В разные этапы жизни компании мы сталкивались с различными проблемами высокой нагрузки, масштабирования и отказоустойчивости. Разные виды протокола, особенности аппаратной части, приводило к необходимости унификации нашей IT платформы, а так же решать вопросы со statefull соединениями iot устройства и бэкенда. Доклад о том как мы изменили архитектуру для увеличения стабильности связи с iot устройствами, как не получать downtime в высокочастотном сервисе, а так же как решали вопросы с балансировкой соединений и сообщений от iot устройств и как жить в K8s с "несовременными" протоколами обмена сообщений.

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

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

Преимущества OpenRAN по аналогии с текущим состоянием рынка оборудования стека Ethernet-IP-TCP-App

Юридические и регуляторные основания и предпосылки к внедрению OpenRAN.

Политические предпосылки к внедрению OpenRAN, в частности потенциал к импортозамещению

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

На рынке уже появились серверные устройства, суперкомпьютерные кластеры и клиентские устройства на архитектуре RISC-V, а уже в следующем году она может занять 14% рынка процессорных ядер. Давайте обсудим, почему частные компании и госструктуры во всем мире сейчас проявляют такой огромный интерес к разработкам на RISC-V. А заодно:

Узнаем, как ограничения по совершенствованию процессорных технологий — от техпроцессов до малой гибкости со стороны крупных вендоров, — привели к появлению RISC-V, и как это поможет компаниям со своими ЦОДами.
Обсудим отличия RISC-V от архитектур ARM и Intel.
Разберемся, как работает сообщество RISC-V, и почему мы рассчитываем преодолеть фундаментальные проблемы именно с этой архитектурой и именно с этим сообществом. В частности, рассмотрим, как в RISC-V достигается расширяемость без фрагментации экосистемы.
Рассмотрим, в каких областях архитектура RISC-V уже добралась до практического использования как ведущими на своих рынках компаниями, так и амбициозными стартапами.

И конечно оценим перспективы скорого появления решений на базе RISC-V по всех областях информационных технологий.

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

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

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

App.Farm – PaaS‑платформа, обеспечивающая весь интеграционный поток и среду для исполнений информационных систем в РСХБ. В докладе речь пойдет об интеграции информационных систем в платформу, ее архитектуре и выборе компонентов интеграционных взаимодействий.
Рассмотрим выбор тех или иных компонентов и их применение на практике: распространенные ошибки логирования интеграционного взаимодействия и способы их отслеживать.
Доклад будет полезен всем специалистам, которые занимаются интеграцией высоконагруженных систем и хотят обеспечить их стабильную производительность.

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

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

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

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

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

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

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

Когда переход на VXLAN в облачных сетях грозил нарушить работу системы анализа трафика и защиты от DDoS, нам нужно было найти быстрое и эффективное решение. В этом докладе поделюсь опытом использования технологии eBPF для решения этой задачи. Как eBPF помог нам решить ее без значительных изменений в архитектуре системы в целом.
Вы узнаете, как происходит обработка сетевых пакетов ядром Linux и из каких этапов она состоит. А еще — как можно использовать eBPF, чтобы внедрить дополнительную логику в сетевой стек Linux.
Расскажу, какие требования привели нас к eBPF, и как мы внедрили эту технологию для анализа и декапсуляции пакетов VXLAN на серверах, обрабатывающих до 6 миллионов пакетов в секунду.
В докладе будут раскрыты:
- Какие инструменты мы используем для анализа трафика клиентов и переход на VXLAN
- Рассмотренные решения для декапсуляции VXLAN и выбор в пользу eBPF
- Инструменты, использованные для реализации решения
- Результаты и выводы, полученные в ходе внедрения eBPF

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

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

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

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

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

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

Доклад рассматривает роль Greenplum в текущей аналитической платформе и ожиданиях, которые питали с выходом Greenplum 7. Но все изменилось после закрытия проекта как open source решения.

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

В заключение перейдем к практике, разберем успешный кейс и проблемы, с которыми столкнулись при переходе с GP на DLH.

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

В докладе рассмотрим

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

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

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

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

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

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

Подробно рассмотрим построение инфраструктуры для использования больших языковых моделей (LLM) с нуля, опираясь на опыт Х5 Tech.

Начну с объяснения, что такое LLM и почему они становятся все более важными для современных технологий. Обсудим ключевые компоненты, необходимые для создания масштабируемой и надежной инфраструктуры. Сравним три популярных бэкенда для инференса LLM: llama-cpp, TGI и vLLM, выделяя их преимущества и недостатки. Особое внимание уделим подводным камням llama-cpp и рассмотрим, действительно ли vLLM — идеальное решение. Затронем тему информационного поиска и его связь с LLM — объясню, как эти модели могут улучшить процессы поиска по базам знаний.

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

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

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

Структурированный вид здесь https://docs.google.com/document/d/1HWmmtHCSxuxDmkHXk7rrYgwpv6W43F-fA3Jf5fHWQNA/edit?usp=sharing


Название доклада
Переход от легаси к построению своего Feature Store: Активные действия

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


Тезисный план доклада (30 минут, зеленым выделены интересные для обсуждения темы)

2m Предисловие - кто мы и чего хотим
Мы - Домклик команда оценки недвижимости
Хотим - Построить решение которое ускорит разработку наших моделей, добавит прозрачность, качество и надежность в работе с данными.

2m Почему именно feature store
здесь кратко расскажем почему такой выбор - поинты указывающие на то, что нам он нужен: большие пайплайны, много моделей

5m Выбор технологий в нашем случае.
Расскажем про выбор на котором мы остановились - технологии: greenplum, airflow, clickhouse, kafka, dbt, trino, python, postgres, s3, openmetadata, soda)

17m Шаги внедрения feature store в нашей команде - здесь расскажем и покажем какой план и как мы его придерживаемся. Так чтобы не уйти в долгострой и показать первые результаты. Шаги внедрения feature store в нашей команде:
детальный разбор запросов и источников, формирование детального слоя хранилища, проектирование холодного хранилища
- проработка архитектуры пайплайнов
- проектирование концепции горячего хранилища
- доставка данных
- проработка доставки данных в горячее хранилище из холодного
- рефакторинг моделей и переобучение
- внедрение soda с блокирующим этапом
- внедрение каталога данных - openmetadata
- внедрение data lineage и отображение всех наших источников данных
- проектирование метаданных для фичей и feature-sdk для нарезки хранилища
- автогенерация фичей через sdk

4m Вспоминаем как было и что стало - быстрые запросы и высокие латенси при нагрузке в 250 rps, быстрые пайплайны с большим объемом данных

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

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

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

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

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

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

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

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

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

В своём докладе я расскажу о том, зачем изначально нам потребовалось сделать форк и пропатчить Apache Spark, какие это вносило неудобства, и как мы справились с самыми главными вызовами после выхода проекта в OpenSource: отказ от форка 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 на чтение, хранит > 200GB данных из них ежедневно обновляется около 15GB, время ответа < 80ms . Путём горизонтального масштабирования планируем нарастить эти цифры до 30К rps, 1TB данных с сохранением SLA.

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

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

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

В докладе расскажу:
* Зачем в Домклике используют RoBERTу
* Из каких частей состоит языковой трансформер 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, как они собираются, фильтруются и генерируются. Расскажу про эксперименты над данными, покажу своеобразную карту интернета.

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

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

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

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

Доклад делается в первую очередь про большие рекомендательные системы, однако слушатель может найти для себя пользу и в других приложениях, в которых свойства задачи похожи. Рекомендательная система - это ML задача со следующими свойствами:
1. Имеется постоянный поток новых данных и нестационарное распределение в этих данных. На примере рекламы в Яндексе: поведение старых пользователей меняется, рекламные кампании меняются, все меняется. Из этого следует необходимость постоянно дообучать эти модели
2. В крупных рекомендательных могут быть огромные объёмы данных (десятки TB в сутки)
3. Очень разреженные признаки. Как правило, в рекомендательных системах используются разреженных эмбеддинги
4. Необходимость сочетать эффективные реализации с гибкостью для ML исследователя

Пункты 2 и 4 накладывают жёсткие требования по производительности и одновременно требования про

Я расскажу, как в отделе качества рекламы в Яндексе подошли к построению распределенного онлайн обучения. Мы коснёмся следующих вопросов:
1. Сортированное распределенное чтение данных - как удобно для пользователя сохранить упорядоченность чтения датасетов вне зависимости от числа gpu, выравнивание итераторов
2. Работа с разреженными данными и с эмбеддингами. Как эффективно обрабатывать разреженных эмбеддинги, гетерогенное обучение cpu/gpu, как эффективно прореживать эмбеддинги без потерь к качеству, как эффективно реализовывать затухание фичей, как правильно шардировать разреженные параметры моделей
3. Эффективная эмуляция онлайн обучения на исторических данных - правильный online evaluation, детали реализации
4. Различия в предобучении онлайн моделей на исторических данных и при выкатке на регулярное дообучение

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

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

- Преимущества обучения моделей нейронных сетей на GPU перед аналогичной задачей, выполняемой на CPU.
- Как происходит вычислительный процесс на GPU.
- Существующие инструменты машинного обучения на PHP.
- Первые шаги по внедрению параллельных GPU вычислений на PHP.
- Оценка производительности.

APCu is a very performant form of in memory cache, almost as fast as using local variables and thus a good candidate for high load applications.
Despite that it's usage is rare because it resides in a single computing node. Most high load applications use an underlying infrastructure of auto scaling VMs or K8s, which means that
there are multiple computing nodes with no cache coherency. This presentation explores these issues, possible strategies for establishing internode communications (hint: they don't reliably work), infrastructure side solutions and
how one can use the APCu despite this shortcoming. We will present in broad terms how Altenar GP incorporated APCu in our system that receives 3.5K requests per second, the failures we had
along the way and the performance benefits we saw with our final implementation. We also clarify critical shortcomings of the APCu documentation that may have severe consequences.

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

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

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

Приспосабливаемся к современности: начинаем работать в облаках по принципам The Twelve-Factor App. Погрузимся в каждый принцип и научимся настраивать приложения на базе трех популярных фреймворков (Symfony, Laravel, Yii2).

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

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

21 год и 43% Интернета — архитектурные решения доказавшие свою эффективность и новые API — заглянем внутрь WordPress и детально изучим как работает самая популярная в мире CMS, а также познакомимся с инструментами экосистемы.

Мы рассмотрим:
— Порядок загрузки системы
— Работу с базой данных
— Кеширование
— Безопасность
— Многочисленные API
— Обработку ошибок и профилирование
— Мультиязычность и мультидоменность
— Статус проекта Гутенберг
— Вспомогательные инструменты

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

На момент проведения конференции выйдет PHP 8.4 — мощнейший релиз языка со времён 8.0 и 8.1. Среди фич новый JIT, хуки и асиметричная видимость свойств, new без скобок, объектная обёртка BCMath\Number, новые функции для работы с массивами и HTTP запросами, ленивые объекты и атрибут #[Deprecated]. Одного доклада маловато, чтобы всё это подробно презентовать, но я постараюсь расставить для вас акценты. В процессе обязательно позапускаем и побенчмаркаем код и обсудим, как поскорее затащить PHP 8.4 в ваши проекты. До встречи!

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

Обзор новой большой версии фреймворка Yii. Что умеет, чем отличается от Yii2, почему сделан так, а не иначе.

Введение:

• Краткое описание IoT (Internet of Things) и его важности в современном мире.
• Преимущества MQTT протокола для IoT: легковесность, простота реализации, поддержка публикации/подписки.
• Роль PHP в контексте IoT, его сильные стороны (доступность, гибкость, масштабируемость)

MQTT на практике:

• Пояснение работы MQTT протокола: издатели, подписчики, брокеры.
• Обзор популярных MQTT библиотек для PHP.
• Демонстрация основных функций библиотек:
* Подключение к брокеру.
* Публикация сообщений (Управление устройствами).
* Подписка на темы.
* Обработка входящих сообщений.

Примеры использования:

• Реализация простого сценария:
* Сбор данных умных устройств.
* Получение команд от сервера и управление устройствами.

Заключение:

• Подведение итогов: PHP - отличный инструмент для работы с MQTT и IoT.
• Преимущества использования PHP для IoT:
* Упрощение разработки.
* Снижение затрат на разработку.
* Высокая гибкость и масштабируемость.
• Перспективы развития IoT и MQTT, включая использование PHP.

• Что такое легаси
• Как появляется легаси
• Когда рефакторинг действительно необходим
• Как оценить затраты на рефакторинг
• Методы и подходы для безопасного рефакторинга
• Признаки создания будущего легаси
• Практики для предотвращения создания легаси
• Как не превратить Rector'ом проект в тыкву
• Как не превратить CS Fixer'ом проект в тыкву

- Структуры данных для работы с криптовалютами.
- Путь транзакции: от запроса пользователя до блокчейна.
- Работа со смарт-контрактами на PHP.

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

Feature toggle (или feature flag) — это механизм, позволяющий включать или отключать функциональные возможности приложения без изменения кода и его повторного развертывания.

Unleash — это инструмент управления feature toggle с открытым исходным кодом, который позволяет контролировать развертывание функций в вашем ПО с помощью feature flag'ов, обеспечивая гибкое управление функциональностью.

В своем докладе я расскажу:
- Зачем нужны feature flag'и
- Какое место feature toggle'ы занимают в матрице технического развития продукта
- Какие есть сценарии использования
- С помощью чего можно реализовать
- На что обратить внимание при выборе feature toggle платформы
- Особенности эксплуатации Unleash

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

В эпоху активного развития ML все привыкли к стандартному подходу "Learn in Python - Serve in Go".

На первый взгляд, такая стратегия объединяет лучшие качества обоих языков: богатую экосистему библиотек Python и высокую производительность Go.

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

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

Построение архитектуры приложения, микросервисы на go, распил монолита, архитектурный комитет

Конкурентность в Go открывает широкие возможности, но также и представляет риск «выстрелить себе в ногу» — от обращения горутин к одним и тем же данным до проблем с work-stealing. В этом докладе мы рассмотрим, как дополнить и расширить идеи из выступления Роба Пайка по конкурентности в 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-приложение можно представить как пайплайн из моделей
- Напишем небольшое приложение на примитивах языка, без использования дополнительных библиотек
- Напишем небольшое приложение на нашей собственной библиотеке
- Обсудим какую пользу мы получили в команде от использования собственной библиотеки пайплайнов

Функциональное программирование - хорошо!
Функциональное программирование в Go - есть!
Программы на Go с "фунциональной" начинкой - легко тестируемые, предсказуемые и масштабируемые!

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

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

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

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

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

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

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

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

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

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

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

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

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

Тут поговорим кратко как, чем и зачем его можно терминировать

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

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

Как итог с "и 40gbps уже боль", мы отдаем 100 с достаточно старого железа

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

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

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

CGO — это классный и удобный инструмент, позволяющий вызывать любые С/С++ функции, не боясь заблокировать свою Go-программу. Но за такое удобство приходится расплачиваться. Помимо overhead на каждый С вызов, вас могут ждать еще несколько неявных проблем связанных с рантаймом Golang, которые будут просаживать производительность вашего высоконагруженного сервиса. Что за проблемы и как их решить — рассмотрим в этом докладе.

Что еще будет:
Как работает CGO под капотом.
К каким проблемам приводит долгий С вызов из Go.
Пути решения и пасхалки в исходниках Golang.
Делаем быстрый и блокирующий С вызов из Go.
Почему компилятор будет нам мешать.
Пример сервера и бенчмарки

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

В мире распределённых систем эффективные структуры данных играют ключевую роль в обеспечении производительности и масштабируемости. В этом докладе мы погрузимся в реализации Bloom Filter, CRDT (Conflict-free Replicated Data Types) и Consistent Hashing на Go. Разберёмся, как они работают, какие задачи решают и как применяются в продакшн-коде на Go, включая такие проекты, как etcd.

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

Что получат слушатели:
1. Понимание принципов работы Bloom Filter, CRDT и Consistent Hashing.
2. Знание о реализациях этих структур данных на Go.
3. Примеры использования в реальных проектах.
4. Практические советы по внедрению и оптимизации в своих приложениях на Go.

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

Обсудим зачем в Go добавили новый и весьма нетривиальный функционал - итераторы, также называемый range over funcs.

Посмотрим на бенчмарки: быстрые ли итераторы? Быстрее каналов или медленее?

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

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

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

- Что это - данные о товарах?
- Боли при обновлении миллиарда записей раз в 5 минут
- Какая архитектура обработки записей нам подойдет лучше всего?
- Чего не должно делать хранилище
- Что нужно от БД
- Как нам помогли дженерики в go
- Кода нет а ручки есть - чудеса делегирования
- Как мы загрузили железо по полной
- Что получилось в итоге

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

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

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

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

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

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

В качестве программиста я не написала ни одной строчки кода на Go, но тысячи Go-разработчиков по всему миру используют мой продукт. Дизайнеры ‒ люди, от которых меньше всего ждут вклада в опенсорс, и зря! Моя любовь к доступным продуктам и продуктовый подход позволила создать уникальную и успешную историю. У маскота языка Go изначально отсутствовала мимика, был скудный набор сложных изолированных иллюстраций, неподходящие лицензии. Сейчас Free Gopher Pack есть в листе Awesome Go и широко используется в комьюнити.

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

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

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

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

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

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

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

Какие проблемы возникали при балансировки сотен тысяч соединений по протоколу MQTT в облачном хостинге. Ограничения облачных ELB на количество одновременных соединений. Периодические разрывы соединений, приводящие к волне реконнектов устройств, которые создавали нагрузку сами на себя.