Доклады

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

В высоконагруженных проектах на первый план выходит оптимизация производительности. Кроме привычных методов оптимизаций: отсутствие лишних операций, уменьшение числа создаваемых объектов, есть еще один способ оптимизировать наше приложение - PGO. Profile-guided optimization (оптимизация с использованием профилировки) позволяет нам в полуавтоматическом режиме ускорить выполнение кода с минимальным числом ручных действий.

В докладе мы поговорим о:
- inlining (встраивание) вызовов;
- девиртуализации вызовов;
- профилировке, как части жизненного цикла CI;
- как применение оптимизаций компилятором выглядит под капотом;
- какие будущие оптимизации нас ждут.

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

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

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

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

После этого я хочу поговорить о wrapping (оборачивание), который позволяет получить stack trace и место, где произошла ошибка. Так же wrapping дает возможность получить данные для повторения ошибки, разделить общедоступные и частные сообщения об ошибках для логирования и ответа клиента, а также поговорю о других возможностях wrapping.

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

Речь пойдет про использование Go для сквозной разработки приложений: от бэкенда до графического интерфейса

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

Вы узнаете:

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

Avito RE-Arm — платформа, на базе которой, сотрудники любого профиля могут реализовывать бизнес процессы. Более того это не просто платформа, это огромный опыт, которая получала моя команда и я начиная от формирование самой команды и требований, заканчивая уже конкретно поставленных задач. Начиная от простых по типу "Поставил задачу - Закрыл задачу" и более сложных "А еще хочу уведомлять, автораспределять, звонить, а еще и статистику хранить".

На таком объёме поставленных требований, на первый взгляд, задача "Сейчас сделаю сервис и кучеряво заживем" обрастает большим количеством проблем, которые затрагивали как формирования процесса, так и создание самой платформы:
* как создать роадмап если бизнес не совсем определился с требованиями
* как выжить в течении квартала с двумя мидлами и одним стажером
* что может помочь если новые тиммейты видели Go только на картинках
* как хранить данные и как их обрабатывать
* как предвидеть резкое увеличение нагрузки
* как обеспечить внесение изменения в платформу другими командами и не умереть
* как быть с авторизацией и к чему может привести не правильный выбор
* как написать распределение тасок для покрытия бизнес процессов разных направлений

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

Большинство разработчиков считают, что fuzzing - это когда какому-нибудь json-парсеру подают случайные строчки в надежде найти segfault. Это важный кейс, но если посмотреть шире, эта технология может предоставить гораздо больше возможностей практически каждому разработчику. Например, можно особым образом генерировать входные параметры для вашей системы и проверять, всегда ли она работает так, как вы ожидали. То есть проверять не набор отобранных примеров, а свойство системы.

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

Рассмотрим недостатки проекта opentelemetry, с которыми мы столкнулись при развитии пайплайна трейсинга в Авито, и расскажем, как мы их решали:
* performance проблемы;
* несовместимость модулей;
* неоднозначные архитектурные решения;
* проблемы протокола передачи данных (OTLP);
* backpresure;
* etc.

В докладе я расскажу о своём опыте написания интеграции Xiaomi Gateway 3 для open source-платформы умного дома Home Assistant, где непоследнюю роль сыграл язык Go. Именно на нём написан «демон» для нескольких шлюзов экосистемы Mi Home:
* Xiaomi Multimode Gateway (архитектура MIPS),
* Xiaomi Multimode Gateway 2 (архитектура ARM),
* Aqara Hub E1 (архитектура ARM).

GitHub проекта — https://github.com/AlexxIT/XiaomiGateway3

Мой подход при реализации проекта отличается от большинства подобных решений в мире open source. Обычно разработчики берут готовое устройство, удаляют с него заводскую прошивку и заменяют своей. Примеры таких проектов — OpenWRT для роутеров и OpenIPC для камер.

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

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

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

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

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

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

Мы вместе пройдем через реальный пример небольшого Go-приложения, и я покажу, как автоматизировать каждый этап разработки, начиная от проверки линтера и заканчивая развертыванием в продакшен. С помощью Github Actions мы настроим базовые процессы CI/CD, а затем реализуем деплой приложения в инфраструктуру Yandex Cloud. Присоединяйтесь, чтобы открыть новые горизонты автоматизации и сделать вашу разработку более удобной и эффективной.

* Как устроена музыка в современных компьютерах.
* Как можно использовать Go в современных DAW.
* Как написать свою собственную эмуляцию гитарной педали на Go.
* Какие возникают трудности при разработке плагинов для DAW.

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

Примерно 4 года назад мы занялись экспериментальным для Яндекс.Маркета проектом — рантайм-сервисом расчёта путей по логистическому графу на Golang. Этот эксперимент вылился в критичный и высоконагруженный сервис с порядка 40k RPS и примерно 50 RPS/CPU, благодаря которому вы можете видеть дату доставки вашей посылки на Маркете.

Мы рассмотрим, как различаются подходы и концепции C++ и Golang, глазами человека, который до эксперимента Golang в глаза не видел, а подавляющее количество кода писал на C++. А также поговорим, чему нас научил язык Go!

К примеру, вы узнаете:
* что общего и кардинально различного есть у указателей в C++ и Go;
* точно ли за аллокацией в Go не нужно следить так же тщательно, как в плюсах;
* есть ли различия в использовании gRPC в C++- и Go-сервисах;
* на сколько полезен и опасен sync.Pool

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

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

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

Языки претерпевают изменения, но не всегда это возможно сделать внутри самого языка, есть боли, которые тяжело затащить даже в мажорный релиз, поэтому мы встречаем такие ситуации, когда появляются TypeScript, Kotlin, Elixir. А что с языком Golang? Может ли он дойти до состояния, когда родится его преемник, который будет транспилироваться в чистый го, который будет просто обладать всеми прелестями рантайма го и горутинами, но синтаксически будет другим?

Цель моего доклада - обсудить данную тему в контексте 2024 года и немножко посмотреть в будущее, рассмотреть варианты, которые уже есть на рынке https://github.com/goplus/gop и другие.

Спроектировать и показать свое решение, которое не будет таким радикальным, как gop, а внедрить систему вставок нового синтаксиса, формата макросов, которые при компиляции превращает все сахара в чистый го и только потом запускает. Управлять системой сахаров в формате yaml-файла, который позволяет настраивать транспиляцию, формат babel в JS, как вариант: данное решение можно заопенсорсить и предлагать реализовывать свои решения. Данный механизм можно использовать в формате разработки, но также как примеры пропоузелов для новых синтаксисов и предложений на гитхабе.

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

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

Join us on a journey into the world of AI-powered image discovery using TensorFlow and Go. This talk will delve into advanced techniques for image classification, object recognition, and more, all within the context of Go programming. We will explore the integration of TensorFlow's powerful machine learning capabilities with Go's efficient concurrency model, enabling developers to build intelligent image search applications. From understanding the basics of AI and machine learning to implementing complex algorithms for image analysis, this talk will provide a comprehensive guide for leveraging TensorFlow and Go in your projects. Whether you're a seasoned developer or just starting with AI, this talk will equip you with the knowledge and tools to unlock the full potential of AI-driven image discovery.

embedded, AI, Rassbery PI, Repka PI, gobot, devices, gpt

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

В докладе я расскажу о том, как Temporal работает «изнутри», начиная от архитектуры кластера до реализации конкретных бизнес-процессов. Мы затронем темы детерминизма, версионирования в Temporal и особенностей взаимодействия с помощью gRPC. Будет показано, как Temporal помогает в достижении отказоустойчивости бизнес-процессов через механизм Event History, что позволяет нам не потерять ваш заказ и гарантировать своевременную доставку.

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

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

Есть и другое мнение: архитектура ПО — это то, чем развлекают себя неспособные к написанию настоящего кода болтуны, ведь «реальная программа не имеет к архитектуре никакого отношения».

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

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

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

UUID - отличный кандидат на Primary Key в новой сущности вашего сервиса. Множество систем его используют, но он имеет свои недостатки, которые должны быть решены в версиях 7 и 8, RFC для которых почти принят. При реализации этого RFC для PostgreSQL я погрузился в детали, которыми хочу поделиться.

Расскажу, как мы в Yandex Cloud'е поняли, что нужно MongoDB бэкапить физическими бэкапами, а не логическими и реализовали это.
Начнем с того, почему мы пришли к этому, расскажем немного теории о резервном копировании MongoDB.
Далее расскажем, с чем мы по пути столкнулись, какие проблемы мы решали, как писали Wal-G.
Так же расскажем о неожиданных последствиях физических бэкапах и том, как это нам позволило реализовать резервное копирование (и восстановление) шардированных кластеров MongoDB.

Stateless Postgres Query Router — система шардирования PostgreSQL кластера с открытым исходным кодом. Роутер, главный ее компонент, по запросу понимает на каком конкретном PostgreSQL кластере надо выполнить транзакцию или запрос.

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

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

Рассматриваются базовые проблемы ненадёжной передачи данных и способы борьбы с ними: повторы и дедупликация.
Далее, на примере паттернов микропроцессорной архитектуры иллюстрируются гарантии доставки: at-most-once, at-least-once, exactly-once.
В заключение на примере двух брокеров очередей сообщений, Kafka и YDB Topics, показываются детали реализации гарантий доставки.

Мы расскажем, как интегрировали ClickHouse в ядро нашей BI-платформы Visiology для использования в кейсах Self-Service аналитики и ad-hoc запросов, где пользователи могут самостоятельно загружать и анализировать большие объемы данных, не привлекая разработчиков. Такой сценарий работы пользователей потребовал от нас разработки автоматизированной системы управления ClickHouse.

Будут рассмотрены:
- Архитектура платформы и архитектурные решения
- Процесс загрузки данных в ClickHouse: автоматизация подбора индексов и движков, преобразование исходных данных для эффективной обработки ad-hoc запросов
- Разработка транспайлера запросов аналитического движка DAX (Microsoft) в ClickHouse SQL
- Алгоритмы оптимизации SQL с учетом специфики ClickHouse

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

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

В рамках доклада мы рассмотрим три основных варианта развертывания:
• Redis Standalone
• Redis Sentinel
• Redis Cluster

Остановимся на особенностях работы Redis для каждой топологии и поговорим об отличиях при работе с Redis Standalone и Redis Cluster со стороны приложения.

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

Говоря про хранение данных в Redis, важно поговорить и про сами данные. Сделаем обзор поддерживаемых типов данных, особое внимание уделим интересным структурам данных – Streams, Sorted Set, HyperLogLog, Bitmap. На реальных примерах из жизни посмотрим, как эти структуры данных можно эффективно использовать для решения задач.

Также затронем паттерны и антипаттерны использования Redis, особенно в части использования SCAN, KEYS, DEL, EXPIRE и влияние на производительность. Приоткроем завесу тайны и узнаем какие removal policy реализованы в Redis.

Поговорим про механизмы восстановления данных на базе RDB и AOF и влияние на производительность. Какой выбрать для вашего конкретного проекта и в какой конфигурации?

Поднимем тему тюнинга как в части параметров ОС, так и в части тонкой настройки самого Redis, например, maxmemory, maxmemory-policy, lfu-decay-time. Коснемся политик вытеснения (noeviction, lru, lfu, random, ttl), которые реализует Redis.
Проведем сравнение с конкурентными продуктами, которые позиционируют себя как drop-in replacement, на примере Dragonfly и оценим его готовность к промышленному применению.

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

В 2021 году мы начали разработку собственного Software-Defined Storage(SDS) для публичного облака с нуля. За два года мы сделали решение, которое успешно вывели в production платформы Evolution Cloud.ru и хранит петабайты пользовательских данных. Наш SDS предоставляет блочное, объектное и файловое хранилище. В этом докладе мы поговорим про архитектуру самого нижнего блочного слоя и с какими сложностями мы столкнулись при его разработке.

В докладе я расскажу:
* Из каких компонент состоит публичное облако и зачем там SDS;
* Как архитектурно устроен наш блочный SDS;
* Как сетевые диски подключаются к виртуальным машинам пользователя;
* С какими проблемами мы столкнулись при использовании Erasure Coding для кодирования данных и как мы решили эти проблемы;

Объемы обрабатываемой информации неуклонно растут, и распределенными системами уже сложно кого-либо удивить. В мир СУБД этот тренд проник с небольшим опозданием, но распределенных СУБД на рынке уже немало.

Отличаются они друг от друга почти всем, но в первую очередь нас интересует два основных компонента — это движок локального хранилища и кластер-менеджер. Так, например, в CockroachDB локальным движком выступает RocksDB, а консистентность кластера обеспечивает алгоритм Raft. В Cassandra ставка сделана на eventual consistency.

Команда Picodata долгое время разрабатывала и внедряла решения на основе Tarantool, а теперь мы переосмыслили его в cluster-first парадигме. В докладе я расскажу о продуктовых и архитектурных решениях, которые этому сопутствовали:

- Кластер-менеджер мы построили на Raft без использования внешнего state provider и объединили в нем хранение топологии и хранение схемы данных
- Для хранения данных мы используем глобальные и шардированные таблицы, а доступ к ним реализуем посредством языка SQL
- За компанию реализовали близкие к стандарту средства управления доступом
- А для расширения функциональности предоставляем Plugin API

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

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

Vault — стандартный инструмент для хранения секретов. Но он имеет ряд недостатков by design. Я хочу рассказать о том, с какими проблемами «ванильного» вольта мы сталкивались. Какие из них нам удалось решить внешними инструментами — как написанными самостоятельно, так и предлагаемыми сообществом. Какие проблемы потребовали залезать в код вольта и почему нам пришлось его форкнуть.

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

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

Что произойдет, если тысяча разработчиков одновременно смержат свой код любимым gitlab в master ветку и будут ждать деплоя в прод?
Хайлоад из кода, багов и крупнейшего фича-поезда, которому не суждено доехать до прода.

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

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

На эти вопросы я постараюсь ответить в своем докладе. Расскажу, как мы в VK Звонках построили автоматизированный стенд для измерения качества аудио и видео с физическими устройствами: мобильными телефонами и ноутбуками. Покажу результаты измерений, а также результаты сравнения по качеству видео и звука с западными сервисами.

Ozon уже более 3 лет кратно растет и будет продолжать расти по ключевым бизнес показателям: заказы, купленные товары, GMV. Для поддержания роста бизнеса нужно увеличивать число серверов, которые выливаются в многомиллионные бюджеты для закупки. Нам важно поддерживать баланс распределения общего бюджета, чтобы максимизировать инвестиции в масштабирование бизнеса и при этом иметь "железо", которое выдежит эту нагрузку.

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

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

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

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

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

В данном докладе мы поговорим о бизнес-ориентированному подходу к ИБ.
О том, почему стоит строить безопасность именно от бизнеса, а не от продуктов.
О целеполагании, как ставить действительно важные и достижимые цели. И о том как правильно отвечать на вопросы:
"От чего именно я защищаюсь", "Чего я хочу этим добиться?".
О приоритезации расходов на ИБ.
Одни компании тратят многомиллионные бюджеты на средства защиты, а потом еще столько же на выкуп операторам шифровальщиков. Дорого не значит хорошо! Бюджет не отражает зрелось.

В финале опишем универсальный "короткий путь" к зрелой ИБ и универсальный чеклист самооценки.

Рассмотрим наиболее популярные уязвимости в крупных продуктах по части построения инфраструктуры и приклада высоконагруженных систем.
Традиционно покажу уязвимости и ошибки, которые допускают администраторы и программисты в таких системах. И там таблетки как лечить и какими процессами
Более подробный перечень:
1) Уязвимости в образах и зависимостях
2) Уязвимости контейнерных сборок
3) Уязвимости интеграций микросервисов со службами
4) Уязвимости инфраструктуры подхода IaC
5) Уязвимости окружения продакшена
По каждому классу приведу реальные кейсы и методы борьбы с ними.
Рассмотрим стек ASP.NET, Python, Java, Go

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

Apache Spark - замечательный инструмент дата-инженеров, который поддерживает языки Scala, Java, Python и другие. Но что бы не было выбрано, вам неминуемо понадобится установить клиент, подключить библиотеки, настроить окружение. И для сложных расчётов это оправдано, их удобнее писать с кофе в какой-нибудь полюбившейся IDE. Однако, иногда хочется оперативно выполнить SELECT на пару строчек, проверив гипотезу, и продолжить заниматься своими делами.
Именно для этой цели в YTsaurus развивается модуль Query Tracker, позволяющий прямо в браузере запускать SQL-like запросы на разных движках: полноценном MapReduce, Clickhouse или Spark.
В этом докладе я расскажу: как строился сервис быстрых SQL запросов поверх Apache Spark, какие готовые решения принесли пользу, а также что за монстры встретились в этом приключении.

МТС в режиме реального времени получает большие объёмы данных от своих абонентов по различным прокотолам, в многочисленных физических и логических форматах данных. Эти данные можно использовать для рекламных кампаний, формируя триггеры на основе сценариев абонентов. Многие из этих данных актуальны лишь небольшой промежуток времени, а значит эти данные нужно как можно быстрее обработать, чтобы получить из них максимальную выгоду. Лучший способ это сделать - применить streaming processing.
В этом докладе я расскажу как мы в МТС реализовали триггерную систему на основе потоковой обработки данных в условиях BigData (~10 млн. событий в секунду) с помощью Java, K8s, PostgreSQL, Aerospike, Kafka и без использования популярных фреймворков (Spark, Flink, Samza, NiFi и т.п.).

Мы пишем и продаем коробочное on-premises ПО и клиенты не рассказывают нам, как они им пользуются.

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

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

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

Мы расскажем о том, как обучали гигачат:

1) о важности сбора чистых данных для претрейна, их фильтрациях
2) о возможности дообучать модели, важности выбора правильной смеси данных
3) о том, как делали SFT-пайплайн и налаживали взаимодействие гигачата с другими моделями через функции

Моя команда разрабатывает централизованную промышленную инфраструктуру MLOPS в Альфа-банке, а также управляет процессами внедрения и поддержки моделей.
> 300 моделей в бою, > 150 DS постоянно пользуются платформой.
Реализовали среду разработки моделей с гибким распределением гарантированных вычислительных ресурсов пользователям.
Более чем в 2 раза ускорили внедрение моделей за счет оптимизации пайплайнов и процесса внедрения.
Поддерживаем модели на уровне Mission Critical.
Автоматизировали переобучение моделей и внедряем AutoML.

Опыт замены Оркестратора и ELT-инструмента на высоконагруженном DWH.
Вводные на старте проекта:
- Хранилище эксплуатируют 10+ доменных команд разработки.
- Ежедневно выполняется 6000+ регламентных расчетов.
- Хранилище играет ключевую роль в процессах работы компании.
- Сохранение текущих строгих SLA подготовки данных.
- Продолжение развития хранилища в период миграции.
Расскажем какой путь прошли во время миграции с вендорного SAS DI на OpenSource экосистему из Airflow + dbt

Что если бизнесу нужны сложные аналитические витрины с актуальность данных в минуты, а выходить в стриминговую обработку на CEP движках таких как Flink дорого и overkill по скорости поставки данных?
Есть ли компромиссное решение не требующее полного разворота на 180 градусов от ETL процессов реализованных на SQL диалекте? И конечно это решение должно быть масштабируемым до cотен ТБ. Поэтому это не PostreSQL.

"И оно есть у нас"
Триплет технологий YTSaurus + YQL + динамические таблицы позволили найти архитектуру поставок данных, повторяющую подход к обработке данных заложенный в стриминге, но упрощающий реализации. Это дало нам достаточную скорость обработки данных в минуты помноженную на технологии с невысоким входом и прозрачную для потребителя структуру промежуточных и конечных данных. И конечно вишенкой на торте такие поставки интегрированы по данным классическим с T-1 поставками и их можно легко пересчитывать.

Деталями этой реализации на примере расчета быстрой Юнит Экономики в Яндекс Маркете мы и хотим поделится

Что первое приходит на ум, когда вы слышите фразу «банковское взыскание»? Незамолкающий телефон? Стук в дверь? Примитивные методы, основанные на примитивной логике?

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

Расскажем, как мы применяем data science в погоне за мечтой о взаимности:

1. Розничное взыскание - крайний, но не последней по значимости этап жизни кредита;
2. Данные для Collection: что собираем и как агрегируем;
3. Автоматизация: как и с помощью каких инструментов мы организуем процессы, почему без слаженного взаимодействия
нам никак;
4. Водопад моделей Collection от предварительного скоринга до выездной работы.
4.1. Модели Precollection: как мы помогаем клиенту не забыть о платеже и сохранить хорошую кредитную историю,
оставаясь ненавязчивыми;
4.2. Модели реструктуризации в связке с ранним скорингом: как мы предсказываем возникающие у клиента сложности и
заранее протягиваем руку помощи, подбирая оптимальное предложение и коммуникацию;
4.3. Модели средней просрочки и эмоциональные технологии: что такое Персональный Ассистент, как он может
«чувствовать» клиентов и операторов, что мы с этим делаем сейчас и планируем делать в будущем;
4.4. Глубокая просрочка. Если все же необходимо выезжать, то как мы определяем к кому стоит ехать, а для кого это
станет лишь усугубляющим фактором.

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

Apache Spark Streaming лучше подойдёт, если у вас нет потребности в real time и миллисекундных задержках. Для sub-second задержек лучше подойдёт Apache Flink. Но не Spark и Flink едиными. Есть например Apache Storm, у которого сейчас довольно мало контрибуций, но при этом он всё ещё релизится. Или Apache Samza, о которой есть доклад разработчиков из Одноклассников. Мне кажется, что и её будущее предрешено, учитывая мизерное количество новых коммитов. Можно ещё попробовать Kafka Streams, но тогда управление ресурсами это уже ваша задача.

А как обстоят дела с решением реальных задач? Кейсы, которые часто решают на стриминговой платформе - объединение(join) двух потоков. Spark и Flink справятся с этой задачей, но сделают это по-разному.

Это и не только обсудим на докладе.

До 2022 года, в Ozon была практика переезда из одного кластера Hadoop в другой при смене датацентра примерно раз в год/два.
А это значит заново создать всю инфраструктуру, переносить данные и клиентов, их код и согласовать это с тысячами интеграций завязанных на прошлый кластер. Это было очень дорого и долго.
Долго, потому что в Ozon около 25 команд разработки использующих Hadoop.
И поэтому дорого. В основном это data-science ребята, которые месяц занимались операционкой переезда.

Мы решили больше не проводить своих DE, DS и аналитиков через эти трудности, и решили попробовать то, что все гайды по Hadoop категорически не рекомендуют. А именно, растянуть Hadoop на 3 DC.

В докладе расскажу:
Зачем нам вообще hadoop.
Почему не 3 hadoop-кластера, а один растянутый. PnL.
Какие у нас были вводные по железу, по данным и клиентам
Как распределить данные. Репликация и шардирование
Как раскидать потребителей YARN.
Какие результаты мы получили
Планы. Своя BlockPlacementPolicy. 3+ DC.

В своём докладе Евгений рассмотрит новые виды атак на чатботы, использующие LLM. Разберем, как обходят safety layer моделей, как работают prompt injection и разные виды jailbreak. Разберем виды и классификации атак по разным фреймворкам. Обсудим почему OWASP создали 3 отдельных гайда по LLM Security. На докладе будет представлен чек-лист, которым можно пользоваться перед запуском приложений в прод.

Виды атак, которые будут изучены: adversarial атаки с суффиксами, конкатенация промптов, отравление обучающей выборки, уязвимости библиотек и supply chain, уязвимости AI фреймворков.

Диалоговый агент на базе ChatGPT - это сейчас одно из наиболее эффективных средств автоматизации общения в практически любых бизнес-процессах, где это общение возникает, будь то деловая переписка, модерация контента в интернет-магазине или анализ диалогов в контакт-центре. А если общение - это не только текст, а ещё и, например, картинки (в духе "глянь, подходящий ли стиль у этой картинки для новогодней рекламы" или "эй, посмотри, на этой фотке точно нет запрещёнки"), то здесь поможет ChatGPT Vision.

Но в текущих реалиях далеко не всегда есть доступ к серверам OpenAI, на которых работает ChatGPT Vision. Также не всегда оправдана отправка данных на сторонние сервера по соображениям безопасности или экономики. Таких вот "не всегда" очень много. И что же делать в этом случае? Делать свою мультимодальную LLM! В своём докладе я расскажу, как можно собрать такую мультимодальную LLM из опенсорсных компонент на вашем железе, как правильно подготовить датасет для кастомизации этой мультимодальной LLM под вашу бизнес-специфику и, наконец, как оценить качество того, что получилось.

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

Доклад посвящен MERA: Multimodal Evaluation for Russian-language Architectures - новому инструктивному бенчмарку для тестирования и оценки фундаментальных моделей нового поколения. MERA представляет из себя открытую платформу для исследования способностей фундаментальных моделей, которая включает в себя широкий набор заданий для оценки интеллектуальных способностей моделей (от общего знания о мире, до умения писать код и способности решить ЕГЭ), кодовую базу для оценки и открытый лидерборд. Проект собирает всех игроков индустрии и академии в одном месте, а его ключевыми чертами проекта являются открытость и прозрачность процедуры оценки.

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

Мы немного коснемся архитектуры на основе Dagster, Celery живущих в Kubernetes и кейсах у заказчиков

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

Мы рассмотрим:
1. Основные этапы процесса создания музыкального хита
2. Наши подходы к созданию полноценных музыкальных треков (музыкальная композиция, вокал, аранжировка)
3. Нейросетевая композиция - сложности и вызовы
4. Особенности реализации синтеза пения по произвольному тексту
5. Автоматизированный саунд дизайн и рендеринг в реальном времени
6. Результаты и примеры использования

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

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

Я расскажу о том, как на протяжении нескольких лет помогаю превращать результаты научных исследований Университета ИТМО в открытые библиотеки и фреймворки (разберем фреймворк автоматического обучения FEDOT в качестве примера такого проекта). Обсудим как технические аспекты вывода ИИ-решений в Open Source, так и нюансы развития сообщества открытого кода в академической среде.

Хотели бы вы управлять устройствами на расстоянии не используя пульт, голос, касание? Мы расскажем вам, как вы можете сами сделать управление жестами, используя только камеру. Как с помощью всего двух статичных картинок, можно предсказать движение. Зачем мы балансировали между качеством, объемом, уникальностью и расовой принадлежности при сборе данных. Как небольшое исследование внутри Российской компании стали использовать большие мировые корпорации (Intel, Google). Полученные State-of-the-Art решения в области распознавания жестов находят применение в любом устройстве: от кофеварки и настольного девайса до сложных систем в робототехнике и авто-индустрии.

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

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

— как обогатить индекс дополнительной информацией и знать больше о документах;

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

— как использовать эмбеддинги от LLM в проде для улучшения семантического поиска;

— как сформировать позапросный индекс дообучая LLM и в чем его преимущества по сравнению с эмбеддиноговым поиском.

* Что такое нормализация текста и зачем она нужна
* Что такое конечные автоматы, принципы работы конечных автоматов
* Использование конечных автоматов для обработки текста
* Оптимизация FST, принципы построения сложных конечных автоматов
* Декомпозиция процесса нормализации
* Продвинутые способы построения FST для выполнения сложной многоэтапной обработки текста
* Использование недетерминированных FST для повышения качества нормализации

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

В этом докладе расскажем, как мы разрабатывали наш движок для запуска ML моделей в web-браузере на примере видеоконференций SberJazz. Подробно обсудим мотивацию делать свой движок вместо использования открытых решений, покажем, как построить эффективный Inference моделей используя возможности WebGL. При работе на клиентском устройстве важно экономить вычислительные ресурсы, и мы пройдемся по тому, как это делаем в наших пайплайнах. Расскажем и об устройстве нашего графового движка, дающего возможность оптимизировать вычисления, но при этом аккуратно структурировать код. Обсудим вопрос тестирования технологии с использованием CI среды, где недоступны физические GPU. А для ML-инженеров мы дадим полезные советы, как можно облегчить внедрение моделей в продукт не потеряв при этом метрики.

Вы часто слышите, что квантовый компьютер взломает RSA и это только дело времени. Некоторые пробовали написать программу на Qiskit и ждут, когда это можно будет запускать на реальном квантовом железе. Наша небольшая группа из подразделения R&D занимается вопросом, может ли быть полезен квантовый компьютер для бизнеса в близкой перспективе. Но мы используем эмуляторы квантовых вычислений, развернутые в облаке Cloud.ru

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

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

В докладе будет как про низкоуровневые оптимизации (включая cache locality и доступ к памяти), так и про ML-специфику, и про внутренности xgboost. Попробую дать общие советы, как лучше обучать модельки, если вы хотите сильно запариться, но ускорить их вычисление под нагрузкой.

0. Введение:
- Немного про логические и бинарные бэкапы
- В MongoDB Community убрали возможность физических бэкапов
- Следовательно, нужно добавить её обратно

1. Про движок MongoDB - WiredTiger:
- Немного про MMapV1 - предшественника WiredTiger
- Общая архитектура WiredTiger

2. Как бэкапить WiredTiger:
- Низкоуровневая организация хранения данных в WiredTger
- Как уплотненяются данные
- Курсоры - способ доступа к данным(и не только)
- WT_CURSOR_BACKUP - способ создания резервных копий
- Что, если скопировать WT_CURSOR_BACKUP?

3. Применяем знания на практике:
- Пишем новые стадии агрегации, чтобы соответствовать интерфейсу MongoDB Enterprise и PSMDB
- $backupCursor и $backupCursorExtend - описание
- $backupCursor и $backupCursorExtend - реализация
- Как воспользваться ими для снятия бэкапа

Доклад посвящён паттерну запуска задач по расписанию на бэкенде.

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

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

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

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

Все мы знаем, что для эффективной балансировки необходим хороший алгоритм. Современные алгоритмы могут динамически определять перегруженные инстансы сервисов и эффективно снижать квантилии ResponseTime сервиса. Но так ли это? Обсудим то, что мы, в OzonTech, смогли увидеть на своих сервисах под нагрузкой более 1 миллиона RPS.

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

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

Бэкенд Яндекс Вертикалей живёт в монорепе. В ней четыре миллиона строк кода, за которые ответственны 15 команд, и эти числа постоянно растут.

Flaky тесты — наша болезнь роста. С ней концепция 100% зелёных тестов становится проблематичной, т.к. юнит-тесты всё время флакают и краснят билд.

Мы, как команда монорепы, эффективно решили проблему с flaky тестами всех наших команд, не разбираясь детально с каждым проблемным тестом — в режиме blackbox. Мы пришли от кошмарных >= 5% фейлов сборок от flaky — к приятным <= 1%.

Слушатели узнают про эффективные способы борьбы с flaky тестами — в первую очередь, карантин. И поймут на нашем опыте, какие у этих способов есть подводные камни, и как их обходить.

Два года назад мы в Яндекс Маркете начали разрабатывать свой DI фреймворк - Scout. Это легковесный фреймворк, который предоставляет выразительный Kotlin DSL. Он не генерирует код, а делает всю работу в рантайме. Недавний переход на эту библиотеку привел к замедлению нашего приложения, но мне удалось ее ускорить, применив технологию модификации байт-кода.

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

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

1. Идея и первоначальная концепция продукта "Риалтайм конфигуратор маркетинговых предложений".
2. Где мы в архитектуре.
3. Как выбирали наш стек: Flink, Tarantool, Kafka, PostgreSQL, Scala, Java, Lua.
4. Как дойти до прода с open source и не отхватить множество багов.
5. Движение к продакшену и новые проблемы проблемы
6. Что удалось достигнуть и наши рекомендации.

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

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

- Я являюсь ведущим разработчиком платформы нагрузочного тестирования OZON;
- Основной способ взаимодействия микросервисов в компании это grpc;
- В пике деплоем порядка 1000 контейнеров с генераторами нагрузки;
- В экосистеме организации существуют сервисы, выдерживающие 1,000,000 rps;
- Чтобы экономить на железе, нам нужен эффективный генератор нагрузки;
- У нас уже был один из самых эффективных генераторов нагрузки на рынке, но теперь мы смогли ускорить его в 4х раза, реализовав свой grpc-клиент, предназначенный для нагрузочного тестирования;
- Расскажу как работает нагрузочное тестирование в OZON и какие знания нам понадобились чтобы реализовать свой эффективный grpc генератор нагрузки.

Расскажу про платформу АБ экспериментов в Яндексе, на которой проводится 35000 экспериментов в год. Как поддерживать АБ для 200 сервисов и проводить 200 экспериментов на каждый хит. Зачем нужны эксперименты с выборками на 200000 строк. Как обезопасить бизнес от плохих экспериментов. Как выкатывать успешные эксперименты в продакшен и гарантировать, что выкатка соответствует эксперименту.

1. Необходимость кластеризации системы управления гипервизорами для высокой доступности и отказоустойчивости.
2. Основные преимущества etcd при кластеризации системы управления гипервизорами.
3. Процесс кластеризации с использованием etcd.
4. Практические примеры использования etcd для кластеризации системы управления гипервизорами
5. Возможные недостатки etcd и проблемы.
6. etcd предоставляет мощные возможности для кластеризации системы управления гипервизорами.

В рамках развития продукта MyTarget в компании VK был запущен единый рекламный кабинет. Это привело к серьезному росту нагрузки на backend-компонент, который отвечает за подбор рекламы, баннерный демон. На развитие сервиса также повлияли и аппаратные ограничения, как в части пополнения серверного парка, так и в части размещения новых аппаратных мощностей.

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

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

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

В Почте Mail.ru стояла задача: научить бэкенд на основе почтового сервера Exim с нагрузкой 1 000 000 писем/мин переживать отказ ЦОД без простоя и потери писем. Основная сложность была в том, что почтовый сервер использует локальный диск для хранения очереди писем в процессе доставки.

Для решения проблемы мы построили отказоустойчивую распределённую очередь на основе Tarantool и in-house объектного хранилища. Чтобы не менять логику почтового сервера, мы написали свою файловую систему в userspace на Tarantool и FUSE, которая инкапсулирует взаимодействие с распределенной очередью.

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

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

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

Также будет рассмотрено масштабирование Redis и Redisearch. Расскажем, как реплицируем данные для поддержания высокой доступности на нужном уровне.

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

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

Давайте попробуем разобраться:
- из чего складывается задержка и почему это важно
- что влияет на путь трафика от клиента до приложения и обратно
- при чём тут облака, DDoS-защита и CDN
- что можно сделать, чтобы задержка стала меньше

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

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

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

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

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

Каждый уровень и этап такого конвейера - результат многолетней эксплуатации под большой нагрузкой в Sage, платформе мониторинга и realtime-аналитики Тинькофф.

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

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

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

Важной особенностью A/B-тестов является то, что они находятся на пересечении нескольких областей:
* бизнеса (проверка гипотез, базовый инструмент аналитика),
* математической (статистическая значимость)
* технической (обработки терабайтов данных и попадание в SLA).

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

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

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

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

Ozon - один из крупнейший e-com проектов в стране. За последние годы мы построили большую и сложную систему, состоящую из нескольких тысяч сервисов, запущенных на тысячах серверов, распределенных по нескольких ДЦ. На таком объеме всегда что-то ломается: диски, сетевые карточки, сервера, а иногда и целиком ДЦ.
В своем докладе я хочу рассказать историю о том как мы превратили крайне неприятную ситуацию падения ДЦ в абсолютно спокойный и предсказуемый для нас процесс.

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

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

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


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



Мы перед внедрением GQL много общались с ИБ и Эксплуатацией, и они проговорили нам набор проблем, без решения которых ехать в прод мы не смогли бы (ddos, overfetching, batch и пр.). Мы потратили время для того, чтобы найти решение этим проблемам или осознать, как они решаются на уровне написания кода сами. И, только когда все блокеры со стороны ИБ были закрыты, мы поехали в прод. Я расскажу о каждом кейсе отдельно с объяснением того, что за проблема и как мы ее решали: как тюнили федерацию и CI/CD, как пилили ландшафт по продуктам, как делали загрузку файлов и пр
.

В Яндексе — 50+ сервисов, которые списывают деньги. Каждый из сервисов нужно биллить по-своему с учетом множества разных требований.

В докладе на реальных примерах:

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

Ну и конечно, расскажу, с какими челенджами мы столкнулись и как мы их чинили.

Все мы привыкли, что распределённые транзакции «просто работают». Этот доклад посвящён алгоритмам выполнения распределённых транзакций (которых всего три), их «слепым пятнам» и слабым местам, а также обзору конкретных реализаций каждого из алгоритмов. Посмотрим, как разработчики пытаются преодолеть врождённые пороки этих алгоритмов. А под конец узнаем, какой же из алгоритмов выбран в Platform V — фреймворке Сбербанк-Технологий для высоконагруженных систем.

Расскажу как устроена автогенерация рекламы в Яндексе: за последний год мы перешли от шаблонных сочетаний текста/описания/цен к генерации GPT нейросетями. Масштабы нашей задачи - создание более 3 миллиардов объявлений, используя для их обработки и хранения несколько тысяч ядер и терабайты памяти. Обсудим тонкости реализации и проблемы с нагрузкой, ведь для генерации текстов и описания баннера используем всего лишь 22GPU v100. Мы разработали алгоритм умного обхода объектов и научили сервис инференса GPT нейросетей адаптироваться к изменяющейся нагрузке со стороны процессинга объявлений.
Также расскажу о подходах, используемых для выбора наилучшего заголовка для рекламного объявления: поговорим о том как мы перешли от крошечных dssm к использованию полноценных Bert в RT-процессинге.

Мы каждый день сталкиваемся с распределенными системами и в применении (как пользователи), и в разработке (как специалисты). Они бывают как сильно распределенными, так и не очень.
В чем разница? Почему у знакомого три дата-центра и у тебя три дата-центра, но есть нюанс? Когда надо думать про разные штуки с задержками и консистентностью, а когда можно поставить модную БД в режиме as-a-Service и все будет круто?

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

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

В докладе рассмотрим эволюцию архитектуры поиска под нагрузками. Так как задача выглядит IOBound, то начнём с очевидного решения. Поставим сервис, к нему подключим redis cache и поехали в прод. Однако со временем данные становятся объёмнее, потеря их может стать критичной, поэтому мы рассмотрим менее популярные альтернативы. После чего придут поставщики, и скажут что стоит снизить количество запросов. Поэтому нам придётся добавить кастомный протокол балансировки, да и настроить HAProxy дальше стандартной документации.

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

Поисковый движок в Ozon — сложная распределённая система, построенная на основе Apache Lucene. Наше решение позволяет эффективно обрабатывать более десятка тысяч разреженных полей в поисковом индексе, осуществляя поиск по миллионам документов при тысячах RPS.

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

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

Стандартная картина: у банка есть АБС (автоматизированная банковская система, ядро банка), которая процессит все сделки/счета/проводки организации. Обычно это монолитное, зачастую вендорское решение.
Агрегированные данные ядра нужны всем - начиная от регуляторной отчетности и заканчивая продуктовой аналитикой. Где-то достаточно актуальности "за вчера", где-то данные нужны онлайн.
Обычная практика - репликация данных в хранилища + API АБС (к сожалению, зачастую используются также прямые интеграции с БД АБС).
Но что, если банк решил написать собственное ядро на базе микросервисной архитектуры? Что, если данные теперь не живут в одном месте, а сервисы разрабатываются разными командами, и в них могут различаться подходы к разработке и модели данных?
Запросы потребителей при этом тоже растут - кто-то готов остаться на хранилищах (но при этом ожидает единообразие в модели данных), кто-то хотел бы получать онлайн-данные по запросу, а часть процессов заинтересована в событийной модели и хотела бы получать обновления в виде сообщений.

В рамках доклада будут разобраны следующие темы:
- АБС Райфа и основные типы бизнес-процессов потребления данных
- Что меняется во время миграции на новое ядро
- Как можно выстроить архитектуру распространения данных

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

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

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

3. Какие льготы дает использование реестра?
Для компании также дает много бонусов.
Во-первых, это коммерциализация внутренних разработок. Реестр также дает возможность выйти на новый потребительский рынок, в тч участвовать в госзакупках: государственные органы и компании должны перейти на использование отечественного ПО к 2030 году, поэтому они закупают ПО из реестра.
Во-вторых: экономия на налогах. Продукты из реестра могут продаваться без НДС, Пониженные страховые взносы - 7,6%, налог на прибыль - 0% для некоторых компаний (классифайды, рекламные площадки, маркетплейсы).
В-третьих, правообладатели ПО из реестра имеют право на IТ-аккредитацию, она в свою очередь позволяет сотрудникам получить отсрочки от армии и льготные ипотеки.

4. Что важно учесть в разработке для включения в Реестр? Можно ли использовать иностранный опенсорс в разработке?
Для включения в Реестр есть требования к техстеку: даже не все опенсорс-продукты можно использовать в программе. В докладе расскажем, какие компоненты использовать можно, а какие точно нельзя.

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

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

7. Немного о ПАК.
С недавнего времени в Реестре стало возможным зарегистрировать программно-аппаратные комплексы. Кратко пройдемся по плюшкам от включения ПАК в реестр и процедуре.

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

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

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

Attack-Defence CTF - это отличный способ на практике познакомить сотрудников вашей компании с реальными уязвимостями, дать им возможность почувствовать себя как злоумышленниками, так и сотрудниками SoC, пытающимися им противостоять, примерить на себя на 6 часов костюмы на. Качественный CTF привлекает к вам студентов, которые потенциально могут стать вашими сотрудниками. Плюс каждое AD в России - это большое событие в мире CTF, позволяющее вам повысить свою известность и лояльность в IT и ИБ сообществе.

В докладе будет рассказано:
* Какие существуют платформы для AD, какие у них есть плюсы и недостатки
* Как правильно подходить к созданию задач и интегрировать их в инфраструктуру AD
* Как правильно подготовить сеть - полезные советы по сетевому харденингу
* Как защитить свою инфраструктуру от игроков
* Презентуем OpenSource решение: KuberAD - полностью Cloud-незавимое решение для развертывания AD на любой инфраструктуре на базе Kubernetes

По итогу дадим чек-лист -- что нужно сделать, чтобы подготовить свой Attack-Defence и сохранить свои нервы

Создаваемые в 2022 и 2023 году RAG (retrieval augmented generation) системы постепенно усложняются, превращаясь в монстров обработки данных - от простой схемы "ретривер-генератор" решения переходят к модульным системам с множеством асинхронных источников данных, несколькими моделями, сложными сценариями, поддержкой самостоятельного принятия решений.

В рамках данного воркшопа мы:
* быстренько слепим не очень простую RAG систему на Python, langchain и llamaindex, на облачных отечественных моделях
* освоим модные техники и исследования в области создания модульных и гибридных RAG - актуализированные на момент проведения конференции, так как новые публикации и библиотеки появляются практически каждый день
* применим методы автоматической оценки эффективности (точности и полноты) систем с RAG

В июле начинается первый коммитфест - процесс рассмотрения разработок от сообщества, которые могут быть приняты в Postgres 18. Внушительное количество разработок уже перенесено из версии 17, что-то ещё добавится до июля.
https://commitfest.postgresql.org/48/
В преддверии коммитфеста, предлагается встретиться разработчикам патчей и договорится о совместной работе. Приоритезировать какие-то разработки, продвинуть среди потенциальных ревьюеров свой патч, услышать быстрый feedback от сообщества, собравшегося на StHL.
Если вы хотите попробовать найти ревьюера - подготовьте короткий 2-3 минуты рассказ о своём патче. Предлагаю заранее предложить свою работу к обсуждению мне в телеграмм или как-то ещё.

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

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

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

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

Одной из ключевых характеристик системы хранения данных является величина задержек при работе с данными, так как эти задержки могут напрямую влиять на производительность клиентских приложений: гипервизоров, файловых хранилищ, бизнес-приложений. Для сокращения задержек СХД оснащаются большими объемами DRAM-памяти, отведенной под кэш пользовательских данных.

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

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

SPQR — система для горизонтального масштабирования PostgreSQL посредством шардирования.

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

В PostgreSQL реализована поддержка Point-in-Time Recovery -восстановление состояния базы данных на определенный момент во времени. Хотелось иметь этот функционал и в SPQR, но для этого необходимо было научиться делать PITR в ETCD.

В докладе я расскажу о том, что такое Point-in-Time Recovery, как происходила реализация этой технологии в базе данных ETCD и с какими трудностями пришлось столкнуться.

Уже более двух лет создаем MLops платформу для создания рекомендательных сценариев.
В докладе будет рассказано
- Как реализовали работу со Spark нагрузками на RecSys платформе
- Какие были проблемы со Spark и почему пришли к текущему решению
- Как использовать Spark в Multi-tenant архитектуре.
- Также поговорим о проблемах использования Spark in k8s.

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

Я расскажу вам всё про процесс пререндера в браузере

1. Мы познакомимся с современным движком браузера
2. Увидим из каких компонент он состоит и как они взаимодействуют
3. Познакомимся с механизмами пререндера и префетча
4. И Заглянем в светлое будущее

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

Сегодня существуют существенно более дешевые и достаточно прилично работающие альтернативы от Rockchip, причем уже в форм-факторе IP камер.

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

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

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

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

Мы поговорим о том, как устроена система транспортного предпроцессинга федерального уровня, реализованная в Мир Plat.Form (НПСК), о способах оплаты, о том, что находится за кадром смс об успешном списании средств, и почему такая смс может появиться в уведомлениях совсем не сразу после оплаты.

Изначально в KION мы пользовались решениями известных ИТ-гигантов. Но в какой-то момент нам стало их не хватать: выросло количество пользователей и продуктовых событий.

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

На смену процессу классического мониторинга в ИТ-индустрию приходит новая концепция Observability (наблюдаемость), характеризующаяся более комплексными и расширенными подходами к извлечению и интерпретации телеметрии объектов наблюдения, а также, вовлечением в дисциплину большего числа участников технологических процессов разработки и эксплуатации ИТ-систем и сервисов. В рамках техтолка расскажем о том, как все это внедряется в Мир Plat.Form (НСПК).

Некоторые до сих пор сидят на восьмерке. Это неправильно. Мы регулярно своевременно обновляем технологический стек, чтобы не застрять в легаси.
Переходим с 17-й на 21-ю. После того как мы переходили с 8-й на 11-ю и с 11-й на 17-ю нам ничего не должно быть страшно. Однако то, что мы обнаружили, нас сильно удивило.
Обычно как? Обновляем JDK, но собираемся в режиме совместимости. Тестируем. Затем начинаем использовать новые фичи и обновлять прочие компоненты. При переходе на 21-ю версию JDK нам пришлось сразу обновить вообще все.
Провели анализ, чтобы понять, почему так получилось. Расскажу о наших открытиях и как со всем этим справляться в реальной разработке.

Расскажет о нашей существующей архитектуре (API -> REDIS -> Kafka -> msSQL), почему был выбран Redis на момент возникновения проблем, поднимет вопрос с какими проблемами мы столкнулись используя эту реализацию (так называемая проблема BIG_KEY), поделится какие решения мы нашли. А также поговорит о перфомансах и возможностях использования noSql.