Доклады
Показать только принятые докладыGolang Conf: Hardcore (3)
database/sql: плохой, хороший и злой. Опыт разработки драйвера для распределенной СУБД YDB.
Стандартная библиотека Golang, в частности пакет database/sql, предоставляет универсальный интерфейс общения с базами данных. Однако он далеко не сразу имел сегодняшний вид. Мы в команде YDB имели драйвер для нашей базы данных, начиная с версии Golang v1.11. И сталкивались с различными трудностями в процессе эксплуатации в продакшенах наших пользователей. Этот ретроспективный доклад о том, какие недочеты были в пакете database/sql, во что это выливалось при эксплуатации и как он становился все лучше от версии к версии Golang.
Доклад принят в программу конференции
Что стоит за дженериками в Go
Дженерики, которые ранее были темой для холивара, плотно вошли в нашу жизнь, но вы когда-нибудь задумывались, что стоит за [T any]? Почему дженерики Go именно такие и чем они отличаются от других языков? Какой магией они обладают и что такое "gc shape"??
Доклад принят в программу конференции
Выжимаем из Go максимум производительности
Этот доклад о том, как писать код на Go так, чтобы выжимать максимум производительности.
Например, из него вы узнаете:
- почему не все for-range циклы равны между собой,
- что такое small-size объекты,
- какие палки в колеса вставляет escape analysis и как их обойти .
Доклад принят в программу конференции
Golang Conf: Architecture (8)
Integrations @ Scale
Среди компаний можно выделить такие, где ценностью является большое количество поставщиков закрытое одним интерфейсом. Примерами таких компаний могут быть платёжные системы, сервис заправок или продажи отелей.Ostrovok оперирует больше, чем 200 поставщиками для предоставления лучших цен нашим клиентам. Такое количество накладывает ограничения на то как должны быть выстроены процессы работы с ними: подключение, мониторинг, организация кода.В своём докладе я расскажу о том, к каким практикам мы пришли на нашем объёме и почему типовые решения 1 сервис - 1 поставщик не так хороши, как кажется.
(Проблема как обслуживать поставщиков с командой в 5 человек).
Доклад принят в программу конференции
Магнит tech: сервисы остатков и цен на Go. Как справиться с большими потоками данных, быть гибким и консистентным.
В докладе расскажем, как мы делали систему управления остатками и ценами:
- Какие технические сложности возникают при больших объемах данных (~ 500000000 строк, 150к/рпс на запись);
- Монолит vs микросервисы. Что выбрали и с каким сложностями столкнулись;
- Postgres vs Tarantool. Не самый очевидный выбор;
- Работа с Kafka: конфигурация, графики, семантика "exactly-once", драйвер kafka-go от segmentio;
- Согласованность в конечном счете — когда и зачем ее можно применять, как достичь;
- Извечный вопрос: предподготовить данные или рассчитать на лету? Мы выбрали гибридный подход;
- На какие метрики ориентировались: технические и бизнесовые;
- Покажем наши дашборды, расскажем, как мы мониторим асинхронную систему и проводим нагрузочное тестирование, графики ТТХ, нагрузки, таймингов;
Доклад принят в программу конференции
Как мы разработали ядро реестра национальной доменной зоны
Создание новой версии реестра национальной доменной зоны BY и БЕЛ.
В докладе расскажем о:
- разработке GO сервиса работающего по TCP протоколу;
- выявлении узких мест, по скорости при нагрузочном тестировании;
- проблемах с надежностью работы сервиса с внешними клиентами при нестабильной работе сети;
- профилировании приложения на проде и выявлении глупых ошибок программиста.
Доклад принят в программу конференции
Прагматичная архитектура: как проектировать go-приложение, руководствуясь чисто практическими соображениями
Бытует мнение, что архитектура ПО - это сложно. Архитектурой занимаются очень умные люди в костюмах и с белой доской под мышкой, цитирующие наизусть Дядю Боба и пространно рассуждающие, "какой именно архитектурный шаблон из дюжины самых расхожих наилучшим образом применим в данной задаче".
Есть и другое мнение: архитектура ПО - это то, чем развлекают себя неспособные к написанию настоящего кода болтуны, ведь "реальная программа не имеет к архитектуре никакого отношения".
Печальная правда в том, что ошибаются и те, и другие: архитектура - это сложно только в том смысле, что требует иного взгляда на задачу, нежели принято у "кодеров", и не нужно только в том смысле, что разработка "от шаблона" обречена на провал.
Что мы сделаем: возьмем реальную задачу, и разработаем для неё архитектуру, попутно объясняя, откуда возникают те или иные требования и как формируются те или иные решения. Какую пользу принесут нам эти решения сейчас, и в перспективе, и какими проблемами чреваты.
В результате должен получится некий алгоритм разработки архитектуры. Да, именно алгоритм, ведь архитектура стандартного приложения не предполагает большой вариативности.
Программный комитет ещё не принял решения по этому докладу
Go в Domain Driven Design
Расскажу о необходимости DDD, о его плюсах и минусах, зачем стоит использовать данный подход в разработке. Как проектировать внутреннюю архитектуру сервиса так, чтобы было удобно и эффективно работать с ним в будущем. Рассмотрим пример одного из сервисов на Go, на основе которого будут разбираться основные детали.
Те, кто не знаком или не имеют опыта работы и написания кода в стиле DDD узнают, как можно и нужно проектировать сервисы, какие практики и архитектурные стили существуют, если это не обычный CRUD со стандартным подходом MVC. А те, кто знаком, смогут почерпнуть новые идеи, а также, возможно, получат ответы на вопросы, которые возникали при использовании данного подхода в разработке.
Доклад принят в программу конференции
Сложное делаем понятным. Тактические паттерны Domain Driven Design в Go.
В Авито делаю выкуп телефонов. Заявка на выкуп имеет, 5 смежных сущностей, около 20 состояний и более 40 возможных переходов на пути от продавца к покупателю через наших партнеров. Для устойчивого роста с таким клубком мы приняли DDD для себя.
В докладе я расскажу о наше опыте использование тактических паттернов DDD (Factory, Value Object, Entity, Aggregate, Repository), как мы к ним шли, что нам это дало при решение задач.
Доклад принят в программу конференции
Как мы построили ETL на Kafka + Confluent, разочаровались и переходим на Go
- Есть легаси энтерпрайз система учета товаров, написанная на Oracle EBS
- Из новой системы с ней сложно и неудобно взаимодействовать
- Из этой системы надо перетаскивать большое количество обновлений по продуктам (10-ки млн в день)
- Построили ETL на основе Kafka + Confluent + kSQL и микросерверную архитектуру на Go вокруг этого ETL
- Сделали это маленькой командой, пытаясь сэкономить время разработки и не нанимая Java-разработчиков
- Много раз пожалели о выборе технологий
- Столкнулись с проблемами, которые не решаются из-за низкой популярности инструментов
- Строим альтернативу на обычных консьюмерах, написанных на Go, отказываемся от kSQL
- От Kafka не отказываемся, она подходит для наших целей. Используем Source-коннекторы для забора данных в любом случае
Доклад принят в программу конференции
Бизнес-логика в go-микросервисах. Как выстроить процесс по обогащению предложений от продавцов до состояния карточки на сайте.
Перед нами стояла задача написать систему доведения предложений продавцов до оформленных карточек на сайте.
При решении этой задачи мы пошли по пути построения микросервисной архитектуры, что позволило нам добиться низкого time to market.
В этом докладе мы:
- расскажем, как сервис-хранилище позволил нам обеспечить изоляцию структуры данных в БД от потребителей этих данных;
- покажем, как мы решали проблему большой вариативности запросов при помощи составных индексов и партиций;
- продемонстрируем подход с реализацией логики сервиса, управляющего потоками данных, основывающемся на стейт-машине, которую мы построили на графах;
- расскажем, чем мы руководствовались при выделении сервисов обвязки, чтобы сохранить баланс между единой ответственностью сервисов и небольшим их количеством.
Доклад принят в программу конференции
Golang Conf: Best practices (8)
Разработка open source приложения для Real Time стриминга IP камер в разных форматах
В докладе я расскажу особенности построения архитектуры и тонкости применения языка Golang при разработке open source приложения для стриминга видео в реальном времени: https://github.com/AlexxIT/go2rtc
Для разработчиков уровня Senior вряд ли будет что-то новое. А остальным может быть интересно послушать особенности эффективной работы с сетью, применение интерфейсов Reader/Writer, захват сетевого подключения при обработке исходящего или входящего HTTP запроса и прочее.
Доклад принят в программу конференции
Protobuf и buf: блеск, нищета и импортозамещение
Расскажу про типовые ошибки и невероятно полезный инструмент для эксплуатации GRPC.
Доклад принят в программу конференции
FerretDB - mongoDB снаружи, PostgreSQL внутри
Это небольшая экскурсия по FerretDB - прокси-серверу с открытым исходным кодом, написанному на Go, который преобразует запросы проводного протокола MongoDB в SQL, используя PostgreSQL в качестве ядра базы данных. Посмотрим, что он уже умеет, как подключить, немного заглянем во внутрь.
Доклад принят в программу конференции
Как протестировать код на Go с базой данных?
Поговорим об интеграционных тестах с базой данных на примере PostgreSQL, как их готовить и с чем их есть.
Доклад принят в программу конференции
Как научить сервис сообщать об ошибке, чтобы это было понятно пользователям, машинам и программистам
Никаких happy path! Я расскажу, как нам перестало хватать баннера “Что-то пошло не так” и мы учились сообщать пользователю об ошибках во время выполнения запроса в большом и сложном продукте — системе хранения данных (СХД). Тогда мы внедрили свой формат ошибок для общения между сервисами и решили проблемы:
- Как определять проблему, если HTTP кодов уже не хватает?
- Как добавить в ошибку параметры, чтобы показать детали проблемы, а не общее сообщение?
- Как показать ошибку на другом языке, если в сообщении содержатся параметры и текст всегда отличается?
- Как сделать так, чтобы пользователь видел ошибки подробно, но не пропускать лишних деталей из сервиса?
- Как интерпретировать ошибки одного API для другого и не сойти с ума?
В ходе доклада мы рассмотрим, какие средства для работы с ошибками есть в Go, чем они хороши и что делать, если на пути встает сериализация. Я покажу, как работает наша библиотека для ошибок и зачем мы приручили панику. Обсудим, как заложить стандарт для ошибок, выстроить взаимодействие между сервисами для его использования, и как рефакторить уже существующий код для плавного переезда
Доклад принят в программу конференции
Собеседования на senior разработчика: проверяем softskills вопросами на hardskills
Представьте, вы пришли на интервью. Какой вопрос будет первым? Что-то про slice или map. А что потом? Ну, наверное, что-то про concurrency и как устроена многопоточка в Go. Вы думаете: “Ну почему опять эти базовые вопросы. Это же так просто.”
Оказывается, большинство ответов на вопросы по hardskills — очень много могут рассказать о разработчике.
Вы узнаете:
- Что проверяют на “простых” вопросах.
- Как задачки помогают понять, впишется разработчик в команду или нет?
- Какие черты характера можно определить на вопросах по устройству многопоточности в го.
- Все это приправлено вагоном историй и баек из более чем 50 собеседований за 2 года на различные позиции.
Доклад принят в программу конференции
Кодогенерация и как ее использовать эффективно
Это доклад о том, как выжать максимум из кодогенерации.
Расскажу:
— почему кодогенерацию не нужно бояться и избегать, а также почему не стоит с ней перебарщивать;
— когда стоит заливать сгенерированный код в репо, а когда — генерировать его в CI;
— как ускорить кодогенерацию на два порядка, когда ее становится много.
Доклад принят в программу конференции
4 алгоритмических задачи, чтобы попасть в Авито
Я готовлю разработчиков к алгоритмическим собеседованиям в big-tech компании и студенты достаточно часто успешно проходят секцию алгоритмов в Авито, ведь достаточно знать всего 4 задачи, чтобы с большой вероятностью успешно пройти алгоритмическую секцию. Об этих 4 задачах я и расскажу
Программный комитет ещё не принял решения по этому докладу
Golang Conf: Technologies (4)
Применение fuzzing тестирования на примере сервисов контента wildberries
- Проблема проверки методов валидации данных с карточки товара, в которую клиенты могут написать все, что захотят (могут скопировать текст с docx или pdf файла и ненужные байты попадут в текст карточки товара из-за чего может неверно сработать код программы или вовсе упасть с паникой). Также проверки данных на sql инъекцию.
- Для решения данной проблемы были созданы fuzzing тесты, которые помогают отлавливать различные кейсы для методов валидации КТ и устранять ошибки до выхода в продакшен среду.
- В итоге мы получили:
1. Меньше обращений с тех поддержки, где в информации о карточки товара появились непонятные символы, которые пользователи случайно добавляли к карточке товара при неверном копировании данных со своих источников.
2. Счастливые QA (валидация и нормализация работают без помех)
3. Счастливые ИБ-шники (с fuzzing тестированием стало проще проверять каждый sql запрос на уязвимость к sql инъекциям).
Доклад принят в программу конференции
Как создать отказоустойчивый и масштабируемый конвейер обработки больших файлов с помощью Cadence
Обработка больших файлов обладает рядом особенных (из-за возможных сбоев) ограничений ресурсов и необходимостью эффективного масштабирования. В этом докладе представлен опыт, полученный при создании конвейера обработки с использованием Cadence. Cadence — это распределенный, масштабируемый, надежный и высокодоступный механизм оркестрации, который разработан для создания и управления сложными, длительными и асинхронными бизнес-процессами. Поговорим о средствах мониторинга, архитектуре и о том, как Cadence используется в нашей инфраструктуре.
Доклад принят в программу конференции
Уязвимости чейнкодов Hyperledger Fabric написаных на go
Уязвимости chaincode написаных на Go влияющие на безопаность бизнес приложения на основе блокчейна Hyperledger Fabric
Архитектурные особенности исходного кода чейнкодов и Hyperledger Fabric
Программный комитет ещё не принял решения по этому докладу
Скрипты в приложениях. Как и зачем пользователям позволять писать код?
Как пользователи продуктов, мы довольно часто используем возможность исполнения скриптов. Самый очевидный пример - это написание плагинов к nginx (lua) или traefik (go). Есть и менее наглядные примеры - строка к json-элменту в утилите jq так же парсится и разбирается, как скрипт. В докладе я расскажу, какие есть возможности использовать встроенные скрипты в приложении на go. А также мы попробуем на примере создать свою систему исполнения выдуманного скриптового языка.
Доклад принят в программу конференции
Golang Conf: Обзор текущего состояния языка (2)
Эволюция Go: Как (не)изменилась наша реальность.
Все течет, все меняется. Даже Go, будучи консерватором среди языков программирования, за последние два года претерпел ряд значительных изменений. И не собирается прекращать и дальше. Наша задача понять, как именно эти новые вещи позволяют нам писать более безопасный, функциональный и быстрый код, при этом стараясь не терять простоту и ясность, к который мы все так привыкли. А начнем мы, как всегда, с дженериков...
Доклад принят в программу конференции
Deep-dive в планировщик Go или зачем мне воровать горутины?
Инженерам свойственно разбираться во внутреннем устройстве систем и залезать туда, куда не просили: кто в детстве не разбирал будильник или в молодости не дампил базу через SQL-инъекцию.Не так давно я наткнулся на термин, который используется внутри планировщиков – work stealing. Конечно же меня больше всего заинтересовал глагол “stealing” и возник вопрос: “А можно ли влезть в планировщик снаружи и украсть например горутину?”
В докладе мы затронем особенности имплементации кода планировщика, ассемблер Go, препроцессорные директивы компилятора, нарушение инкапсуляции через переопределение и рассмотрим, как же своровать горутину у планировщика и зачем же это делать?
Доклад будет особенно полезен, если вас интересует устройство модели многопоточности в Go. Вы поймете, какие методики используют разработчики самого Go, включая неочевидные возможности языка, которые могут помочь вам решить специфические проблемы.
Доклад принят в программу конференции
Golang Conf: Go для высоконагруженных систем (3)
Работа с аренами - почти избавляемся от GC
Как ускорить ваш код на Go с помощью арен? В этом докладе мы погрузимся в мир "region-based memory management", расскажем о том зачем оно нужно и дадим советы по оптимизации кода. Присоединяйтесь, чтобы сделать ваш Go-код ещё лучше!
Доклад принят в программу конференции
Нет времени объяснять, программируй! История о том, зачем исправлять «фатальные недостатки»
В жизни каждого программиста наступает момент, когда существующий ORM, библиотека для парсинга JSON или логов перестают устраивать настолько, что появляется еще один проект, лишенный всех недостатков.
А что делать, если не устраивает что-то посерьезнее, чем библиотека логов?
Мы используем свои сервера раздачи контента; готовимся к переезду в собственное распределенное хранилище объектов; используем JIT пакетирование и шифрование видео на лету и все это пишем на Go.
Разберемся:
· Почему, собственно, Go? Его плюсы и минусы для наших решений.
· Какой минимум нужно знать, чтоб решение было рабочим, и в чем тут сильно помогает Go.
· Когда наступает момент, что ввязаться в разработку своего решения нужно.
Доклад принят в программу конференции
Шардируем Postgres не своими руками
Stateless Postgres Query Router — production ready open-source решение для горизонтального масштабирования PostgreSQL через шардирование. Система работает по протоколу Postgres и написана на Go. Мы расскажем:
- как оно устроено и работает внутри;
- что нужно, чтобы собрать прокси postgesql протокола своими руками;
- почему иногда для значительного увеличения производительности достаточно просто обновить зависимости;
- как написать свой лексер запросов, если pganalyze/pg_query_go слишком медленный.
Доклад принят в программу конференции
Golang Conf: Tooling (2)
Создание тестового окружения через фикстуры
- Внутри теста остаётся только код самого теста
- Тест работает в парадигме уже созданного окружения
- Настройка окружения - ленивая, создаётся только то что нужно
- Настройка окружения умная - можно переиспользовать части окружения между тестами (по желанию).
- Особенности реализации
Доклад принят в программу конференции
Как и зачем писать свои плагины для GoLand
Знаете ли вы, что IDE можно расширять под себя? Делать что-то кастомное, уникальное, нужное лично вам. Мы, ВКонтакте, сделали несколько плагинов, которые кардинально упрощают жизнь бэкенд-разработчикам. Теперь готовы поделиться опытом: как их делать, что нужно знать, каким образом IDE хранит код, как реверс-инжинирить при отсутствии документации и даже что делать в связи с уходом JetBrains из РФ. А главное, идеи и принципы никак не зависят от специфики ВКонтакте и точно могут быть обобщены на ваши задачи и процессы.
Доклад принят в программу конференции
Golang Conf: Мастер-класс (3)
Как стать сеньором
Какой уровень golang нужен сеньорам? Разберем, чем сеньор отличается от других грейдов и какие есть сеньор-антипаттерны. Поймем, что сеньоры бывают разные. И придем к выводу, что знать алгоритмы GC нашей гошечки нужно не каждому сеньору.
Доклад принят в программу конференции
Бинарные деревья или как увеличить шансы на прохождение алгоритмической секции
Бинарные деревья все чаще начинают спрашивать на алгоритмической секции, поэтому это одна из основных тем при подготовке к собеседованию. Мы начнем с разбора базовых терминов, потом посмотрим на различные обходы деревьев и закончим разбором задач из Яндекса и Joom
Программный комитет ещё не принял решения по этому докладу
Возможно ли притвориться разработчиком Golang, не написав ни строчки кода: мастер-класс по обращению с противоестественным разумом
- Возможно ли пройти собеседование на сеньора при помощи chatGPT?
- Как использовать chatGPT эффективно отвечая на вопросы и генерируя код на golang?
- Как изменить процесс собеседования чтобы действительно проверить знания разработчика?
- Что действительно нужно учить в golang чтобы соревноваться с chatGPT?
Доклад принят в программу конференции
Базы данных и системы хранения (16)
Транзакционная репликация в YTsaurus
Репликация между инстансами СУБД позволяет повысить отказоустойчивость совокупной системы. Мы разберём как устроена репликация в YTsaurus: распределённом key-value хранилище, использующемся в Яндексе и ставшем в 2023 году оpen source продуктом. Тогда как данные внутри одного кластера YTsaurus хранятся с избыточностью и позволяют переживать выпадения отдельных машин и стоек, межкластерная репликация в YTsaurus предназначена для обеспечения отказоустойчивости на случай выключения целых кластеров. Один из важных сценариев даунтайма кластера YTsaurus - обновление на следующую версию. Мы разберём как работает межкластерная репликация в YTsaurus, какие гарантии даёт, и как позволяет строить системы без даунтайма поверх обновляющихся кластеров YTsaurus.
Доклад принят в программу конференции
Устройство индексов в почте Mail.ru
На докладе расскажу о технических особенностях реализации хранения и индексирования писем в почте Mail.ru. Остановлюсь на проблемах с которыми столкнулись при разработке и как эти проблемы решали.
Наши задачи:
- эффективная утилизация аппаратных ресурсов: уменьшение IOPS на террабайт хранилища, CPU - уменьшение % загруженности ядер
- уменьшение и как следствие удешевление инфраструктуры без потери качества сервиса, за счет более эффективной утилизации аппаратных ресурсов
- обеспечение SLA на уровне 99.999%
- автоматическое сохранение полноценного рабочего состояния сервиса при отключении датацентра
Архитектура хранения почты эволюционировала и адаптировалась к обновляющимся требованиям пользователей. Количество ящиков и писем в них растет в каждый момент времени, индексы ящиков и писем хранящихся в них не помещаются в память. В этом контексте расскажу о том, как шардируются ящики с общим xlog'ом, о том как данные в ящике всегда остаются консистентными, как происходит кеширование и перестроение индексов почты.
Доклад принят в программу конференции
BARSiC — асинхронная репликация и консенсус для 70 баз данных
Ядром ВКонтакте являются 70 специализированных баз данных (движков), организованных в 800 кластеров, имеющих в сумме 10000+ шардов.
Чтобы безболезненно переживать отказы мастера шарда, мы сделали BARSiC (Binlog Asynchronous Replication using Simple BD interface + Consensus) — в простонародье Барсик. Это система, которая обеспечивает автоматическое переключение ролей реплик и консистентность данных между ними, при этом не усложняет и не замедляет сами движки.
Расскажу, как мы проектировали BARSiC, почему отказались от стороннего консенсуса и каким образом с помощью модели TLA+ проверяем корректность кода Барсика на Go.
Доклад принят в программу конференции
Как мы построили платформу данных из 300 витрин общим размером 10,5 ПТб на базе Hadoop и GreenPlum со стабильной обработкой ежедневного инкремента в 15Тб
Расскажу:
1. Какую цель решает подразделение и почему без данных эту цель не решить
2. Какая задача стояла перед командой при старте построения дата-платформы
3. Описание реализованного решения - Архитектура и Тех. стек реализации решения
4. Как решали проблемы скорости, надежности и качества расчета
5. Результат, какое велью принесла реализация этого решения
Доклад принят в программу конференции
Как пережить спринт в 1 год и переехать в Clickhouse
Clickhouse быстро ворвался в сегмент аналитических баз данных и стал де-факто одним из стандартов индустрии. Однако погружение в эту технологию может быть не столь радужным для обычной продуктовой компании или стартапа. Путь внедрения может оказаться ночной прогулкой в диком лесу, где “не тормозят” только волки, а не как это рисуют рекламные буклеты :)
Проведем ретроспективу нашего опыта, соберем все найденные грабли и набитые шишки и конечно же постараемся из них извлечь пользу - ну или хотя бы отгрузим на маркетплейс :)
Доклад принят в программу конференции
Когда нужно делать свою базу данных
Все программисты любят велосипеды, но любой сеньор скажет вам, что их следует избегать. Но как же тогда на свет появляются новые продукты? С какими проблемами должна столкнуться компания, чтобы стало понятно -- пора?
В докладе поговорим про текущие и перспективные решения хранения логов, обсудим архитектуру, положительные стороны и недостатки, почему все делают одно и то же, но немного по разному и почему R&D-разработка это сложно.
В конце мы рассмотрим некоторые интересные особенности эффективного хранения и поиска в нашей базе данных SageDB, которые позволяют экономить терабайты памяти и трафика.
Программный комитет ещё не принял решения по этому докладу
YDB оптимизации производительности под ARM
В докладе я расскажу с какими проблемами мы столкнулись и как мы их решили при оптимизации YDB под архитектуру ARM. Детально рассмотрим основные проблемы оптимизаций высоконагруженных приложений под ARM. Расскажу про методы и инструменты с помощью которых мы тестировали производительность, находили места для оптимизации, сравнивали производительность ARM и X86-64.
Доклад будет полезен всем разработчикам высокопроизводительных систем, которые планируют оптимизировать систему под ARM.
Программный комитет ещё не принял решения по этому докладу
Частичная модификация объектов в Yandex Object Storage: как мы улучшаем работу ФС поверх S3
Объектные хранилища являются популярными системами хранения данных с отличной масштабируемостью, простым API и подходят для большого спектра задач. Однако для некоторых приложений возможностей стандартного объектного хранилища может оказаться недостаточно, а именно когда для работы требуется интерфейс ФС.
Сейчас уже есть возможность работать с Yandex Object Storage как с ФС с помощью GeeseFS, про которую мы рассказывали в прошлом году. Но для хорошего решения нам сильно не хватало возможности частичной перезаписи объектов - метода PATCH. Про него и будет доклад.
В докладе я расскажу про:
* Задачи для которых не хватает стандартного S3 API, и хочется работать с хранилищем как с ФС
* Какие возможности предоставляют в этом плане различные облачные провайдеры
* Подробности про то как мы решали эту проблему в прошлом, и чего не хватало для счастья
* Технические аспекты реализации частичной модификации объектов, проблемы с которыми мы столкнулись
* Что получилось в итоге, какие возможности дает метод PATCH и что планируется в будущем
Программный комитет ещё не принял решения по этому докладу
Как собрать граф данных на основе логов операций MapReduce системы
В компании с быстрорастущим объемом данных ориентироваться в них становится сложнее и сложнее. В этой ситуации помогают каталоги данных, однако, информация в них, как правило, заполняется пользователями собственноручно и/или из ERM-связей небольших БД. Мы же во внутреяндексовом DataCatalog научились автоматически на основе логов ETL операций и adhoc расчетов собирать Data Lineage системы YTsaurus, наладив контакты между поставщиками и потребителями и обеспечив поиск нужных сущностей данных.
Расскажем, как повторить наше решение в другой логирующейся MapReduce/Spark системе, а также ответим на главные вопросы при каталогизации:
- Что делать, если в MapReduce системе данные пишутся во временные таблицы, которые не интересны конечному пользователю?
- Как оптимально обрабатывать большие объемы данных, чтобы не потерять целостность метаинформации?
- Что делать, если в системе есть символические ссылки и почему это вообще проблема?
Программный комитет ещё не принял решения по этому докладу
Beyond Rаft: практические аспекты масштабирования больших RSM на примере YTsaurus
YTsaurus — opensource платформа для хранения и обработки больших данных от Яндекса. Сердцем кластера YTsaurus является мастер-сервер, занимающийся обслуживанием метаданных, репликацией чанков, авторизацией пользователей и многим другим. Для отказоустойчивости, мастер YTsaurus построен по модели Replicated State Machine, как и другие известные сервисы координации и управления метаданными: etcd, ZooKeeper, Consul.
В докладе я расскажу об ограничениях, которые накладывает модель RSM на разработчиков приложения и о подходах, которые использует команда YTsaurus для масштабирования и обеспечения целостности мастер-сервера.
Программный комитет ещё не принял решения по этому докладу
Как при помощи бумаги, карандаша и алгоритма Raft достичь консенсуса
Есть во вселенной такой алгоритм — Raft. Он широко используется для решения задач консенсуса в распределенных системах (для наглядности — сервисы Etcd или Consul, как наиболее известные проекты его использующие).
Мастер-класс предлагает участникам поучаствовать в своеобразной настольной ролевой игре: каждый участник — это отдельный сервер. Вместо жесткого диска — листок бумаги и карандаш, вместо сообщений по сети — записки под партой. Игроки образуют единый кластер и стараются консистентно реплицировать данные, героически переживая сбои сети. Правила игры — это и есть алгоритм Raft. Приходите, будет весело.
Доклад принят в программу конференции
YDB Topic Service: как мы повышали производительность очереди сообщений
В составе платформы YDB работает сервис очередей сообщений — Topic Service. Он обладает надёжностью, масштабируемостью, гарантиями порядка и доставки.
В этом докладе рассказывается про ускорение YDB Topic Service и приведено сравнение с конкурентами.
Доклад принят в программу конференции
Поиск по образцу на последовательностях строк в БД
Задача поиска по образцу на последовательности строк БД может возникать в различных сферах деятельности. Например, в финансовой аналитике - поиск определённых паттернов изменения цены акций; в системах управления безопасностью (SIEM) - поиск последовательностей событий, которые могут свидетельствовать об инциденте безопасности, IoT и многих других.
Для реализации таких запросов к базам данных в стандарте SQL:2016 была введена конструкция MATCH_RECOGNIZE, которая постепенно появляется в популярных базах данных с тем или иным набором ограничений, т.к. конструция довольно сложная и имеет большое количество особенностей и режимов работы.
В своём докладе я расскажу о реализации MATCH_RECOGNIZE в YDB: о том, как это работает под капотом, какие подходы и алгоритмы реализованы, с какими сложностями мы столкнулись.
Отдельная часть выступления будет посвящена отличиям в обработке аналитических запросов на табличках и обработке на потоках "живых" данных. Какие возникают ограничения при обработке потоков, как бороться с большим стейтом, необходимым для накопления цепочек совпадений на сложных образцах и пр.
И в завершении доклада, конечно же, будут представлены данные о производительности новой конструкции на различных типах запросов для табличек и потоков.
Программный комитет ещё не принял решения по этому докладу
Реализовать OLAP: как мы делали колоночное хранение в YDB
Итак, у нас есть YDB. Это платформа, которая умеет обрабатывать большой поток быстрых транзакций (OLTP, Online Transaction Processing).
Помимо этого, она даёт всю необходимую инфраструктуру для базы данных
- репликации,
- отказоустойчивый сторадж,
- автошардирование,
- query processing,
- grpс-клиенты,
- систему доставки данных и проч.
Имея такой стартовый набор, мы захотели научить YDB обрабатывать другой тип запросов — аналитические (OLAP, Online Analytical Processing).
Казалось бы, давайте поменяем систему хранения, упакуем данные по колонкам и получим профит. Но достаточно ли этого?
Ответ на данный вопрос, а также вопросы «Зачем это было нужно» и «Какая польза от таких расширений системе в целом» будет в докладе.
Доклад принят в программу конференции
Мифы и реалии архитектуры мультимастера в реляционной СУБД PostgreSQL
Существуют несколько мифов о мультимастере: он медленный, сложно интегрировать с приложением, неудобен в обслуживании. Недавно удалось получить опыт работы с мультимастером в реальных боевых условия. Теперь же хочется поделится плюсами, минусами и life-хаками при работе с мультимастером на примере продукта PostgresPro Enterprise:
- Как выжать максимальную производительность из мультимастера?
- Почему можно забыть о проксях и балансировщиках?
- Какой же trade-off и какие ещё бонусы можно получить?
Доклад принят в программу конференции
Алгоритм инкрементальных бэкапов в Apache Ignite
Реализовать функционал создания бэкапов (или снапшотов) в СУБД не просто. Задача вдвойне сложнее, когда это нужно сделать в распределённой СУБД. Втройне - когда СУБД поддерживает распределённые транзакции. И тем не менее любой хороший Crash Recovery план содержит противоречивые пункты - "Иметь под рукой полный бэкап" и "Обеспечить RPO в пределах 5 минут".
Мы реализовали в Ignite алгоритм "Consistent Cut" для снятия инкрементальных снапшотов. В докладе расскажу как нам удалось сделать снятие максимально незаметным для пользователя, а восстановление каждого узла полностью автономным. Обсудим, про что не нужно забывать при разработке production фичи, даже если ослеплен красотой алгоритма.
Доклад принят в программу конференции
Менеджмент крупных проектов (7)
По мотивам шестого подвига Геракла
Путь от техдолга в 20 лет до построения катастрофоустойчивости в IT-компании среднего размера (~260 сотрудников, ~100 продуктов).
В докладе будет упор на решения, которые позволяют не бояться отказа целого дата-центра. Так же, коснёмся влияния богатого legacy на архитектурные подходы.
Доклад принят в программу конференции
Что такое качество продукта и как его измерить
Что такое качество продукта и зачем его измерять
Измерение качества продукта
Как улучшить качество продукта
Преимущества высокого качества продукта
Резюме основных идей презентации
Программный комитет ещё не принял решения по этому докладу
Зачем нужен отдел Customer Care, когда есть тех. поддержка? И когда наступает пора его открывать?
- История Customer Care, какие факторы бизнеса и ценности компании повлияли на создание и формирование отдела.
- Ожидание от работы отдела vs суровая реальность при взаимодействии и выстраивании отношений с коллегами, клиентами и при работе над клиентскими проектами
- Результат работы в цифрах
Программный комитет ещё не принял решения по этому докладу
Современные методы построения платформы мониторинга
* Методы, их преимущества и недостатки. Метод классического водопада. Метод циклического обхода и Agile. "Государственный" подход.
* Использование “философских” принципов при построении системы. Ретроспектива технологии.
* Инструментарий. Высокоуровневый дизайн и архитектура современных платформ мониторинга на примере VK Cloud.
* Имплементация и межкомандное взаимодействие. Как строить мониторинг для большой платформы, когда уже все написано и работает.
* Организационные особенности имплементации мониторинга. Карта ответственности в оргструктуре.
Доклад принят в программу конференции
Как учиться у заказчиков
— Как работа с газпронефтью помогла нам повысить качество кода и поднять цены.
— Как мы научились управлять большими командами и уменьшили потери на больших проектах.
— Как за счёт других клиентов, мы повысили уровень доверия наших бизнес партнёров.
Программный комитет ещё не принял решения по этому докладу
Ставим облачное решение на сервера заказчику: как начать продавать SaaS как on-prem и не сойти с ума.
Однажды вы поняли, что чудо-софт, который вы написали для Сбера, можно продавать таким же серьезным компаниям. Что может быть проще: давайте обменяем программу на деньги! В этом докладе расскажем, насколько глубока эта кроличья нора:
• почему технология - это еще не продукт?
• что нужно кроме ПО для энтерпрайз заказчиков?
• как происходят большие внедрения?
Доклад принят в программу конференции
Сколько нужно разработчиков, чтобы вкрутить лампочку?
Один из главных вопросов бизнеса к разработке внутри компании касается сроков реализации глобальных задач. Как научиться планировать? Прогнозирование и планирование будет работать только при ряде условий:
- эффективное распределение ресурсов на всех уровнях разработки;
- мониторинг рабочих процессов и сбор статистики по ряду метрик;
- реализация правильного взаимодействия между командами и руководителями;
- моделирование рабочего процесса на основе статистики;
Программный комитет ещё не принял решения по этому докладу
DevOps-практики и культура (5)
SRE-практики как управление многоквартирным домом
SRE-практики как управление многоквартирным домом
Управление инфраструктурой ИТ и управление многоквартирным домом — это сравнимые процессы, которые имеют общие цели: обеспечить бесперебойную работу системы и удовлетворить потребности конечного пользователя. Обе эти задачи подразумевают работу со сложными и многокомпонентными системами, в которых важны безопасность, мониторинг и анализ данных, оптимизация процессов и ремонтоспособность.
В выступлении я на своём личном опыте председателя ТСЖ расскажу об общности и разности подходов, а также чему может научиться DevOps или SRE в эксплуатации собственных систем из реального мира.
Доклад принят в программу конференции
Team Topologies, культура DevOps и собственные наработки на страже перфоманса и психологического комфорта
В докладе мы рассмотрим типичные причины конфликтов при кросс-командном взаимодействии между командами (QA, разработки, DevOps, безопасности), а затем обсудим как их решать с помощью наработок не представленных ни в одном фреймворке, а так же с помощью подходов предлагаемых в культуре DevOps и фреймворке Team Topologies
Программный комитет ещё не принял решения по этому докладу
История одного инцидента: как парализовать работу 20к сотрудников и организовать чемпионат по игре в тетрис
Пост-мортем инцидента во внутренней инсталляции Yandex Tracker. Расскажем, как устроен инцидент-менеджмент, как мы обнаруживаем и реагируем на инциденты, что делаем, чтобы инциденты не повторялись, и попробуем показать, что стабильность сервиса - это процесс, а не результат.
Доклад принят в программу конференции
Как Nomad может выстрелить в ногу и что сделать, чтобы увернуться
Что общего у водителя, пересевшего с автоматики на механику и SRE-инженера, познавшего переход с K8s на Nomad?
Nomad выбирают за его флексабилити и админ-френдли подход, но что если вы продвинулись чуть дальше "стартовой локации". В гайде не описаны тонкости реализации кастомных решений: например, про обновление Nomad с Raft 2 на 3, когда кластер построен на основе Consul.
Рассказываем, как пытались использовать функционал K8s на примере sidecar, внедряли многопоточные тесты, как подружили GitLab и Nomad. Делимся горьким опытом, советами по кастомизации Nomad и способами безопасной передачи секретов типа .env с помощью Vault в продуктовом окружении.
Доклад принят в программу конференции
Как мы перешли от Jenkins к GitHub Actions
1) Какие бывают CI системы.
2) Причины перехода с Jenkins на GHA.
3) Проблемы с которыми столкнулись при переходе на GHA.
4) Итоги, оставшиеся проблемы, подсчитанные качественные результаты перехода.
5) Дальнейшее развитие, которое нам открылось.
Программный комитет ещё не принял решения по этому докладу
Безопасность, DevSecOps (1)
С++ и безопасность: можно ли сделать лучше?
По следам гайда от Агентства национальной безопасности (NSA), в котором языки С/C+ признаются "опасными" и требующими перехода на "безопасные" C#, Go, Java, Ruby, и Swift, поймем, так ли плохо обстоят дела с безопасностью в С++ на самом деле, и что современная индустрия предлагает для решения данного вопроса.
Доклад принят в программу конференции
Узкотематические секции (7)
Перестаньте писать свою аутентификацию!
Чтобы воспользоваться приложением, в него надо сначала войти. И без аутентификации вам не обойтись...
Тонкая грань дозволенного: писать свою аутентификацию или взять готовый продукт? На докладе поговорим о базовых принципах и вариантах аутентификации и почему писать самому аутентификацию, если вы не эксперт в безопасности, - это сложно. Я расскажу о реальных факапах в написании аутентификации в компаниях. А дальше думайте сами, решайте сами...
Программный комитет ещё не принял решения по этому докладу
Gstreamer не только для мультимедиа - потоковая обработка данных в реальном времени
GStreamer - это мощный фреймворк для стриминга мультимедиа и не только. Из доклада вы узнаете как создавать пайпланый обработки потоковых данных с помощью gstreamer. Как написать собственные элементы пайплайна и применить алгоритмы машинного обученя в реальном времени. Будет несколько live-demo с реальными примерами, а так же сравнение с другими подходами при работе с data streaming.
Программный комитет ещё не принял решения по этому докладу
От CPU к GPU: Когда ядра решают
GPU: революция в вычислениях или просто модный тренд? Узнайте, как GPU стали краеугольным камнем современных вычислительных технологий, и в каких ситуациях они могут стать вашими верными спутниками. В этом докладе мы детально рассмотрим архитектурные различия между CPU и GPU, поймем, что делает GPU столь эффективным в определенных задачах. Специфичные примеры, детальный анализ и практические советы.
Доклад принят в программу конференции
Как мы строили Telcocloud в условиях санкций
1) Специфика архитектуры и требований TelcoCloud в сравнении с облачными решениями
2) Требования предъявляемые к сетевой инфраструктуре TelcoCloud
3) Whitebox как доступное решение в построении сетевой фабрики
Программный комитет ещё не принял решения по этому докладу
Построение надежной системы алертов для реагирования на разладки элементов выдачи поиска в реальном времени
1) Для обнаружения разладок элементов выдачи поиска применили единый сервис обработки кликов
2) Надежный и простой набор алертов, который своевременно обнаружил почти все разладки избранных элементов выдачи поиска для десятков команд уже в первые полгода внедрения
Программный комитет ещё не принял решения по этому докладу
Arc - внутренняя VCS для монорепозитория Яндекса
Репозиторий Яндекса просто громадный, и для того чтобы с ним вообще можно было работать, приходится прибегать к куче хитростей. В докладе мы расскажем вам:
- Какие системы контроля мы перепробовали прежде чем прийти к своей собственной.
- Что такое виртуализация файловой системы, как она помогает в борьбе с большим количеством файлов и какие у нее есть подводные камни.
- Как мы вычисляем лог файла на графе из десятков миллионов коммитов за пару секунд, и почему так не может git.
- О наших костылях на максималках: что делать, если поверх твоей VCS не работает rsync и XCode.
- Как свести интерфейс к трем командам и перестать думать о ветках и коммитах.
Доклад принят в программу конференции
Чтобы всех отыскать, воедино созвать: система трейсинга событий в VK Звонках
Раньше расследование обращений вида «Я не могу дозвониться!», «Меня выкинуло посреди созвона!», «Я включаю демонстрацию экрана, а её никто не видит!» у нас в команде VK Звонков могло походить на поиск иголки в стоге сена или гадание на картах Таро. Мы тратили на выяснение причины жалобы огромное количество времени и сил. Но теперь всё изменилось!
Мы разработали и внедрили систему трейсинга событий, происходящих в звонке: начиная от подключения первого пользователя и заканчивая завершением звонка. В докладе я расскажу об архитектуре данной системы и об устройстве регистрации событий в условиях высокой нагрузки. А также поделюсь примерами из нашей практики, когда трейсинг в Звонках оказался крайне полезен.
Доклад принят в программу конференции
Эксплуатация систем (12)
Наш опыт обеспечения отказоустойчивости для 100+ баз с помощью автоматического фэйловера
Я расскажу о том, как мы сократили время аварийного переключения одной базы данных с 10 минут до 5 секунд при аварийном отключении датацентра и получили минимальный даунтайм при аварийной ситуации.
- Перед нами встала задача обеспечения автоматического фейловера 100+ баз в нашем продукте VK WorkMail для обеспечения бесперебойной работы нашего решения (Почты, Облака и Календаря).
- Для решения этой задачи мы разработали средство автоматического фейловера Overlord.
- Overlord написан на языке Go, работает в связке с ETCD и Envoy и не требует кворума для своей работы.
Программный комитет ещё не принял решения по этому докладу
"Mattermost" на стероидах: как мы запустили и развиваем корпоративный мессенджер
В докладе расскажем о том, с какими трудностями мы столкнулись при использовании корпоративного мессенджера Mattermost. Доклад будет полезен тем, кто только собирается развернуть собственный корпоративный мессенджер, чтобы понять, на что обратить внимание и какие узкие места можно обнаружить. Пройдем путь развития сервиса от 20 человек до 10 тысяч: что делали, чтобы улучшить его работоспособность и облегчить жизнь при поддержке/администрировании.
1) Да будет свет - или как все начиналось: почему появилась необходимость в корпоративном мессенджере. Первая версия сервера 3в1 (БД, сервер Mattermost + сервер авторизации все вместе). Добавление инструментов. Привлечение IT-команд.
2) Первый блин не комом! Реакция пользователей: плюсы и минусы. Добавление функционала на основе Обратной Связи (плагины). Увеличение функционала – самописные плагины. Как мы придумали использовать скрытые сообщения (что дало: экономия, безопасность, сокращение времени решения задачи.)
3) А нам 1 год! Увеличение пользователей и устранение узких мест. Настройка отказоустойчивости (уменьшаем время простоя; делаем общий конфиг без синхронизации). Наработка автоматизаций (скрипт автообновления, скрипт автопроверки версий, автоочистка файлового хранилища, автоочистка каналов). Вторая версия сервера + s3 хранилище. Создаем свой сервер видеозвонков на базе LiveKit.
4) Что будет дальше? Выводы, что имеем сейчас. Графики доступности сервиса (было/стало), графики нагрузок на систему (было/стало). Новый функционал, который планируем внедрить: интеграция с внутренней HR-системой, интеграция с Outlook.
Доклад принят в программу конференции
Эксплуатация cilium в кластерах VK
- Что было до cilium (параллельный интерактив "Какой у вас CNI")?
- Причины появления cilium в VK.
- Эксплуатация cilium в наших кластерах.
- С какими задачами и проблемами столкнулись при экплуатации cilium?
- Сценарии отказа cilium.
- Мониторинг cilium.
- Минусы cilium.
- Онлайн тест - надо ли вам переходить с calico на cilium?
Доклад принят в программу конференции
Создаём отказоустойчивый деплой приложений в Kubernetes. Принципы, паттерны, приёмы.
В google SRE book приводится статистика, что около 70% ошибок обработки пользовательских запросов приходится на этап деплоя новой версии. То есть создание хорошего, отказоустойчивого деплоя может принести вам до 70% успеха в деле обеспечения надёжности ваших приложений.
В процессе развития ИТ индустрии сформировалось несколько популярных подходов и стратегий деплоя.
Давайте разберём варианты их реализации в kubernetes как самой популярной инфраструктурной платформы.
Доклад принят в программу конференции
Как наши системы приобретают устойчивость, почему ошибки полезны и как начать их использовать во благо.
На текущий день не так легко найти человека, который постоянно работает только над небольшой частью кода и не затрагивает остальных частей системы вокруг него. В такой ситуации возможность ошибки или конфликта велика, а значит мы вынуждены уметь с ними бороться.
В докладе, на примере существующих информационных систем, я раскрою понятие самой "системы" и процессов взаимодействия с ней, а также помогу с новой стороны посмотреть на природу отказоустойчивости. С примерами и ссылками расскажу о том, какую реальную пользу могут принести инциденты и как эффективнее извлекать уроки из подобных событий. Не ограничимся стандартными "пишите post-mortem (с)", а затронем тему практической пользы анализа.
Доклад принят в программу конференции
Проактивное управление даунтаймом: стратегии и инструменты
Сегодняшний бизнес зависит от облачных технологий — потеря критически важного ИТ-сервиса зачастую прямо и незамедлительно приводит к сбоям в работе, потере пользователей и, как следствие, большим расходам. Более 80% клиентов уходят к конкурентам если получают негативный пользовательский опыт, в том числе из-за недоступности веб-сервиса.
Кому-то дешевле «полежать» часик-другой, чем разрабатывать регламенты, организовывать круглосуточный мониторинг и искать решения для стабильной работы своего проекта. В то же время в энтерпрайз-сегменте каждая минута простоя, например, в результате DDoS-атаки обойдется в среднем в 2 млн рублей.
В совместном докладе Кирилл Малеванов (Selectel) и Дмитрий Никонов (DDoS-Guard) расскажут, как оценить риски, избежать возможных потерь и какие практики стоит применить, чтобы даунтайм не означал «конец света».
Программный комитет ещё не принял решения по этому докладу
Мониторинг бэкэнда с нуля, или Куда смотреть и зачем
Почти у всех есть мониторинг. Часто он становится надежным инструментом обнаружения неисправностей и их предотвращения на ранней стадии. Не менее часто в качестве мониторинга выступает APM на бесплатном плане с отчетами “из коробки”, где что-то меряется, какие-то алерты падают в чат, никто на них не реагирует, и в один прекрасный солнечный день приложение ложится так, что поднимать его приходится до поздней ночи.
В докладе:
* обсудим антипаттерны мониторинга;
* научимся представлять систему в терминологии теории очередей;
* выберем самые критичные метрики и настроим их;
* разберемся, какие есть менее критичные метрики и научимся видеть смысл в их графиках;
* разберемся, зачем нужны алерты, и когда они не нужны.
Программный комитет ещё не принял решения по этому докладу
Как мы начали использовать eBPF и какую пользу нам это принесло
Начиная с 2019 года проекты на eBPF, связанные с observability, сетевыми технологиями и безопасностью, появляются как грибы после дождя. Стандартами де-факто стали cilium, Katran и Falco, и всё равно есть место для велосипедостроения - использования технологии в своих проектах, начиная с самого низкого уровня. В докладе мы расскажем, как технология позволяет нам лучше понимать, что происходит внутри наших ПАКов, а в случае необходимости - гибко и "бесплатно" рулить ими.
Программный комитет ещё не принял решения по этому докладу
Много дашбордов? Мало дашбордов!
Одним из антипаттернов наблюдаемости является wall of dashboard. Во многих компаниях существует огромное количество дашбордов, но все ли они полезны? Можно ли, посмотрев на них, понять работает ли система? Скачал дашборд с сайта графаны и поставил себе, таков путь инженеров? Нет :)
В докладе проведем аналогии с разным сферами, в которых тоже используется статус панели для определения "живости" сервиса, рассмотрим один из вариантов правильной организации дашбордов. И поймём, нужны ли борды вообще.
Доклад принят в программу конференции
Как мы сэкономили бюджет на облачные ресурсы, используя масштабирование и самописный плагин для разворачивания стендов
Разработка рекомендательной платформы с использованием ML SOTA алгоритмов требует большие CPU/RAM вычислительные ресурсы. К примеру, на одном из экземпляров нашей рекомендательной платформы до оптимизации использовалось ~ 930 CPU/4,7 Tb RAM только на ML.
Мы расскажем, как при помощи динамического выделения стендов/ресурсов на базе технологий node autoscaler, hpa, самописного плагина для автоматического развертывания стендов можно повысить эффективность разработки, сэкономив до 30% стоимости, при условии сохранения темпов роста, количества разрабатываемых фич и партнеров и сделать так, чтобы разработчики (в том числе и ML/DS) могли проводить свои эксперименты, не мешая друг другу в облаке Cloud.ru.
1. Немного о нашей рекомендательной системе и основной технический стек.
2. Как мы сделали динамические окружения для разработки моделей.
3. Как мы настроили масштабируемую систему в облаке для сокращения стоимости.
Результат: суммарная экономия до 30% на всех стендах.
Доклад принят в программу конференции
MaaS - Мониторинг как сервис
MaaS - monitoring as service
Как узнавать о проблемах с сервисами до первого обращения клиента?
Как использовать мониторинг на пользу, не подглядывая в монитор соседа?
Как не "утонуть" в постоянно дребезжащих алертах?
Как мониторинг улучшает отношения между бизнесом и ИТ?
Доклад принят в программу конференции
Сменить 4 системы мониторинга за 4 года и остаться в живых
Расскажу, как мы поменяли 4 системы мониторинга за 4 года. Покажу 5 факапов, которые стали причиной изменений (однажды мы посреди ночи разбудили десятки человек из-за сбоя системы мониторинга).
Объясню, почему нам иногда проще поменять всю систему мониторинга, чем что-то менять в текущей.
Расскажу, насколько замена системы мониторинга влияет на разработчиков, и что им приходится испытывать во время изменений. И как во время турбулентности системы мониторинга оставить веру в его адекватность и корректность.
Какие выводы мы делаем, и что делать, если хочется хранить метрики долго, а платить бесконечное количество денег не получается.
Доклад принят в программу конференции
Безопасность, информационная безопасность (6)
Актуальные угрозы безопасности в Large Language Model Applications
LLM уже давно на склоне просветления в своем маленьком цикле хайпа, а значит настало время погрузиться во все аспекты безопасности моделей и приложений их использующих.
В рамках доклада рассмотрим топ-10 угроз для LLMA, кейсы атак и способы предотвращения угроз. Проведем приоритизацию, соотнесем с знакомыми примерами и в кулуарах поделимся своими находками и "случаями на производстве".
Доклад принят в программу конференции
Уязвимости платформы Hyperledger Fabric
Уязвимости консенсусов платформы Hyperledger Fabric (Raft, Kafka, SmartBFT)
Уязвимости и архитектурные особенности платформы Hyperledger Fabric
Потенциальные атаки на протоколы и компоненты платформы
Программный комитет ещё не принял решения по этому докладу
Как собрать контейнер и не вооружить хакера
Всё, что вы положите в контейнер, может быть использовано против вас. Именно такой фразой можно описать Living off the Land (LotL) атаки. LotL – это атаки, при которых злоумышленник использует легитимные утилиты для выполнения вредоносных действий. При таких атаках злоумышленнику не потребуется установка специального «хакерского» софта, ему будет достаточно инструментов, добытых на местности. Многие стандартные инструменты детектирования становятся бесполезны против таких атак. В докладе разберём практические примеры LotL-атак в контейнерных инфраструктурах, а также обсудим, как от них защищаться.
Доклад принят в программу конференции
XXE-атаки: скрытые угрозы обработки XML
Работа с XML-файлами (и основанными на XML форматами) может нести неожиданные угрозы безопасности. SSRF? Пожалуйста. Утечка данных? Как скажете. Но в чём суть уязвимости и как защитить свои приложения от подобных проблем? Об этом и пойдёт речь.
На докладе разберём, что такое XXE, посмотрим на примеры уязвимого кода и его эксплуатации, а также поговорим о защите от подобных дефектов безопасности.
Программный комитет ещё не принял решения по этому докладу
zkSNARKs - succinct zero-knowledge proofs for scalability and security
Доклад описывает возможности технологии zkSNARKs для масштабирования сервисов и применения zero-knowledge протоколов. Эта молодая технология сейчас находится на острие развития современной криптографии, ей занимаются в топовых университетах мира, а решения на ее основе позволяют доказывать исполнение вычислений на клиентской стороне с легкой, constant-sized верификацией на стороне сервера. Она очень хорошо ложится на блокчейн технологии, но и для client-server архитектур открывает множество новых возможностей. Например управление списком пользователей и их аутентификация вообще без наличия на сервере базы пользователей и challenge-response протокола. Мы обсудим устройство арифметических circuits и покажем практические примеры простых доказательств, опишем ограничения подобных решений и дизайн некоторых протоколов. Сама технология уже успешно используется в production, где используется для масштабирования, защиты финансовых активов и имеет множество потенциальных применений. Для понимания доклада плюсом будет понимание того, как строятся логические схемы и основы криптографии на элиптических кривых
Доклад принят в программу конференции
BrainSploit. Эксплойты социальной инженерии.
Легендарный Кевин Митник рассказывал о своем практическом опыте социальной инженерии. Мы же, проводя проекты по социо-техническому тестированию на проникновение, в какой-то степени лишь повторяем его сценарии или сценарии коллег. Но почему? Потому что мы отталкиваемся только от чьего-либо опыта, а не от базы. Представьте, насколько был бы эффективен пентест в иной области, если бы все практически бездумно повторяли проверки коллег, не понимая, как оно работает изнутри? В этом докладе мы поговорим с вами о базе. О тех психологических механизмах, которые лежат в основе психологии влияния. Эти основы, подтвержденные многочисленными исследованиями и экспериментами социальных психологов 20 и 21 века, крайне эффективно используются в различных областях, от фишинга, маркетинга и продаж, до любовных аферистов и мошенников колл-центров "службы безопасности". Эти уязвимые механизмы - наше эволюционное наследие, legacy-код нашего мозга. В этом докладе мы разберём примеры скриптов, полученных из мошеннического колл-центра в Бердянске, а также примеры из собственной практики автора. Эта база позволит вам писать собственные успешные сценарии, и эффективнее противостоять вредоносным манипуляциям.
Доклад принят в программу конференции
BigData и машинное обучение (17)
Универсальный транспорт для ML/DL вычислений
Посетив доклад узнаете
1. Об универсальном транспорте для tcp, Infiniband, cuda
2. Как один интерфейс транспорта выбирает лучший доступный транспорт
3. О послойном написании транспорта - несколько уровней под разные нужды
4. Об интеграции в нейросетевые фремворки (на примере нашего)
5. О проблемах, которые можно встретить в больших С библиотеках
Программный комитет ещё не принял решения по этому докладу
Архитектура бесконечной персональной ленты Яндекс Маркета
В конце прошлого года мы запустили бесконечную персональную ленту на главной странице приложения Яндекс Маркет. Лента — это то, что пользователь видит в первую очередь, поэтому она должна работать быстро и отдавать релевантный контент.
Доклад посвящен нашему пути развития от статичных рекомендательных каруселей к бесконечной ленте.
В докладе я расскажу:
- как мы поменяли архитектуру рекомендаций, чтобы лента работала в 2 раза быстрее
- особенности ранжирования и устройства рекомендательной системы
- как мы описываем рекомендательные программы на python для рантайма на C++
Программный комитет ещё не принял решения по этому докладу
Поймать за 60 секунд: как быстро реагировать на взломы, используя поведенческие трансформеры в Почте.
Почтовый ящик для злоумышленника — это настоящая "золотая жила" чувствительной информации, доступ к которой можно получить разными сомнительными способами. Мы ставим своей целью воспрепятствовать этим атакам.
Кто такие "мы"? Мы — это направление ML Integrity в Почте Mail.ru, и мы отчетливо понимаем две вещи:
- каждая лишняя секунда, в течение которой злоумышленник имеет доступ к аккаунту, может привести к катастрофическим последствиям для пользователя;
- злоумышленники, получая доступ к почте, ведут себя, мягко говоря, аномально и крайне несвойственно для владельца ящика.
В докладе будет рассказано, как, полагаясь на эти две посылки, мы разработали систему детекта взломов — FieldMarshal (Fast Mail.Ru Supervisor Hacking Alert). FieldMarshal выявляет скомпроментированные ящики, основываясь на поведенческом эмбэддинге пользователя, причем скорость реакции на несанкционированное проникновение составляет считанные секунды.
Доклад будет полезен широкому кругу ML-аудитории. А если вы всегда мечтали анализировать поведение своих пользователей в онлайне SOTA-архитектурами, но не знали как, то в докладе вы, однозначно, найдете множество ответов на свои вопросы.
Кроме прочего в докладе мы осветим:
- как обучать transformer-based эмбэддинг пользователя и как знания текстовых моделей могут помочь вам в этом;
- как спроектировать систему, которая в online режиме будет распознавать взломы в потоке действий;
- как при помощи одного большого проекта прокачать в команде ML, System Design и разработку микросервисов.
Доклад принят в программу конференции
Mlops: как не потеряться в 10 тысячах фичах
В подразделении билайн бизнес 12 продуктовых команд. Команды работают над широкой линейкой продуктов с использованием машинного обучения для B2B клиентов. Часть продуктов относится к компьютерному зрению и аудиоаналитике, где используются нейронные сети на отдельном GPU кластере. Другая часть продуктов использует неперсонализированную информацию об абонентах и основана в основном на классическом ML с вычислениями на Hadoop кластере.
В билайне используется концепция Data Mesh распределенного управления данными. Доменными единицами являются продуктовые команды, которые строят необходимые им витрины данных и занимаются их менеджментом. Некоторые команды собирают таблицы, которые могут насчитывать около 10 тысяч фичей. Большой популярностью для построения различных моделей пользуются, например, ГЕО фичи или графовые фичи. Фичи могут обновляться на ежедневной/еженедельной/ежемесячной основе.
В билайн бизнес на проде крутится порядка 100 ml-моделей с различным расписанием их использования: от ежедневного до ежемесячного. Каждая модель запускается на разном количестве абонентов (строк): от 10 млн до 200 млн. Итого в пике ежедневная нагрузка по Spark джобам на кластере доходит до обработки 1млрд. строк. В среднем же в сутки обрабатывается около 50 млн. строк.
Большой парк моделей и фичей требует внимательного тестирования и построения прозрачных связей между ними. В докладе прозвучит бриф нашего MLOps пайплайна. Акценты будут расставлены на том, как мы организовали процесс тестирования в MlOps цикле и построили эффективный lineage между моделями и фичами. Расскажем влияние появившихся технологий на процесс разработки и деплоя моделей. Подсветим положительные эффекты, которые мы получили.
Программный комитет ещё не принял решения по этому докладу
Автоматизация, ML и мониторинг
Чем хорош мониторинг работы серверов? Стандартами. Их удобно собирать, их удобно обрабатывать и, амое главное, по ним, плюс-минус стандартные, фиксированные пороги. Но метрики по бизнес-логике и управлению продуктами :
- комплексные. Качество работы продукта определяет множество компонент
- не стандартные. Можно дать рекомендации, что мы хотим видеть, но, с точки зрения продукта, бизнес хочет видеть одно, а IT – другое
- не имеют четких порогов срабатывания и более требовательны к мониторингу динамики, а не статичных значений
И, в своем докладе, хотелось бы поделиться опытом создания системы «умного мониторинга», где решается задача ухода от статичных порогов в сторону прогнозирования и динамики с использованием ML и AI
Программный комитет ещё не принял решения по этому докладу
Рекомендации медиаконтента ВКонтакте: как мы строим персонализированную ленту "Для Вас"
Мы рассмотрим полный путь построения новой ленты рекомендаций ВКонтакте с фокусом на персонализированном медиаконтенте. Особое внимание уделим ML-ой части задачи, аналитической и бэкендной. Вместе мы узнаем, какие алгоритмы машинного обучения применимы в данной задаче, как с ними работать в рамках огромного массива данных (терабайты). Как контролируемо ставить множество АБТ-ов и тестировать сразу много гипотез в каждый момент времени, чтобы как можно быстрее двигаться к нашей конечной цели - новой ленте. А так же выясним, как построить бэкенд архитектуру вокруг такого высоконагруженного продукта, как лента рекомендаций ВКонтакте.
Доклад принят в программу конференции
Жизненный цикл данных от авиателеграм до обучения моделей
Говоря о платформах данных, мы часто рассуждаем о количестве данных, о скорости прохождения, о сложных алгоритмах, о технологиях, о безопасности. Но что насчет удобства? Как сделать платформу данные не только произведением искусства, но и удобным инструментам? Мы рассмотрим процесс прохождения данных сквозь платформу от сырого кликстрима и авиателеграм до витрин данных, которые можно найти, проанализировать, скормить модели машинного обучения, разложить в фичесторы и пустить их с моделью в прод.
Программный комитет ещё не принял решения по этому докладу
Рецепт идеальной разметки в Computer Vision
За последний год мы собрали, разметили и выложили в открытый доступ 3 больших датасета для различных задач компьютерного зрения (Computer Vision, CV): HaGRID, EasyPortrait и Slovo. Использование краудсорсинг платформ для разметки этих данных сподвигло нас создать методы агрегации разметки, которые позволили добиться максимальной точности.
Решение обобщить эти методы на другие CV задачи привело нас к созданию фреймворка агрегации, о котором и пойдет речь в докладе. Мы расскажем о:
- самых популярных способах разметки больших данных в CV: о краудсорсинге и нейронных сетях
- необходимости агрегировать разметку на примере HaGRID, EasyPortrait и Slovo
- мотивации создания фреймворка агрегации и о его реализации
В конце продемонстрируем работу фреймворка для различных типов CV разметки. Фреймворк доступен в opensource и мы планируем его поддерживать и обновлять, в том числе ориентируясь на пожелания коммьюнити!
Доклад принят в программу конференции
Угадываем вкус покупателей: персонализация ранжирования каталога в Lamoda на базе Elasticsearch и CatBoost
Хочу поделиться успешным опытом Lamoda по внедрению персонализации в ранжирование каталога: рассказать про двухуровневую архитектуру, к которой мы пришли, используя Elasticsearch, Golang и CatBoost; про полученный бизнес-эффект и дальнейшие планы. Выбранная архитектура позволяет эффективно и гибко персонализировать десятки тысяч товаров под каждого клиента, а также дает возможность продуктивно работать над дальнейшим улучшением качества ранжирования.
Программный комитет ещё не принял решения по этому докладу
Data Sketches - как съесть слона целиком (даже если он бесконечный)
При обработке и анализе данных часто возникают задачи, которые сложно масштабировать из-за огромного количества требуемых вычислительных ресурсов или значительного количества времени для получения точных результатов.
Примеры таких задач - подсчет уникальных элементов, подсчет распределения элементов, определение частоты тех или иных элементов и т.д.
Если приблизительные результаты при решении подобных задач допустимы, то существует класс алгоритмов, называемых потоковыми или скетчами, которые позволяют получить результат (в заданных пределах погрешности) на несколько порядков быстрее.
В случае пакетной обработки данных, жизнеспособных альтернатив часто может и не быть, а в случае потоковой обработки данных, скетчи - единственное известное жизнеспособное решение.
Дата скетчи (HyperLogLog, CPC, Theta, Count-min, Fdt, KLL и др.) могут стать отличным инструментом для всех, кому необходимо извлекать полезную информацию из больших объемов данных на ежедневной основе используя приемлемое количество времени и ресурсов.
Программный комитет ещё не принял решения по этому докладу
Сервис по оптимальному управлению складскими запасами на площадках ПАО НЛМК
1) Постановка задачи оптимального управления складскими запасами, вводные от заказчика.
2) Сбор, хранение и обработка данных.
3) Модель прогнозирования потребления.
4) Оценка точности прогнозов + бизнес-эффекты.
5) Архитектура решения в production.
Доклад принят в программу конференции
Использование Transformer-based моделей в поиске по музыке в голосовом ассистенте Салют
Доклад посвящен использованию современных ML-моделей на основе архитектуры Transformer в задаче информационного поиска. В рамках доклада будет рассмотрено использование моделей в контексте поиска по музыке внутри голосового ассистента Салют. В частности, будут затронуты следующие вопросы:
- Проблемы, которые призван решать векторный поиск
- Методология сбора данных и обучения моделей-эмбедингов для ранжирования поисковой выдачи
- Использование векторных моделей на всех этапах ранжирования
- Эффективный поиск по текстам песен, позволяющий бороться с проблемой длинных текстов
- Масштабирование векторного поиска на четыре поисковые вертикали
- Принцип работы совместного векторного и текстового поиска
Программный комитет ещё не принял решения по этому докладу
Как CV помогает пользователю найти товар мечты по визуальному образу
В своем докладе я расскажу, как мы вдохновились игрой “Акинатор” (https://ru.akinator.com/), которая угадывает загаданного вами персонажа с помощью наводящих вопросов, а мы взяли за основу похожий подход и создали продукт, который помогает нашим пользователям находить товар мечты.
“Хочу новую футболку, но не знаю какую…”
Как же это работает на практике, когда в голове пользователя запрос звучит не слишком конкретно? За всем этим стоит применение машинного обучения и Computer Vision, которые позволяют определять атрибуты товаров и искать похожие на них.
Заглянем под капот Laкинатора (да, да, именно так мы его и назвали) и узнаем, как путем проб и ошибок мы выстраивали логику обучения, какие бизнес-результаты принесли.
Доклад принят в программу конференции
Речевая аналитика на миллионах минут звонков в месяц
В нашей компании разрабатывается ряд продуктов, связанных с предоставлением услуг связи и ее организации. Рост бизнес-потребности в дополнительной аналитике звонков стимулировал начало разработки целого отдельного продукта под названием Речевая аналитика. Для его реализации потребовалось несколько лет работы трех отдельных команд, каждая из которых взяла на себя определенные обязательства по разработке решения для работы с входящим потоком звонков, их анализа и визуализации результатов. Корпоративные клиенты получают доступ к программному решению, функционал которого позволяет им проводить анализ аудио данных самостоятельно. На настоящий момент данный продукт обрабатывает миллионы минут аудиозаписей в месяц.
Команда анализа данных работала над моделями глубоких нейронных сетей, которые решают проблемы детектирования речевых данных в аудиосигнале (Voice activity detection) и перевода их в текстовый формат (Automatic Speech Recognition) с последующим подсчетом качественных и количественных метрик. Одним из вызовов перед командой была скорость обработки аудио данных: согласно требованиям к системе за 1 секунду необходимо обрабатывать не менее 200 секунд стерео файла. Пилотные наработки давали скорость 1 к 20, что не устраивало. В рамках доклада расскажем о том, как удалось выйти на нужные показатели: о пайплайне обработки аудиоданных, а также эксплуатации моделей машинного обучения, их дообучению и оптимизации. Особое внимание в докладе уделим технологиям и причинам, по которым их выбирали.
Программный комитет ещё не принял решения по этому докладу
Чистые метки для ML
Расскажу про связь качества моделей и меток, на которых она обучена, про способы улучшить качество меток, полученных от крауда (Toloka, MTurk и аналоги). Поделюсь историями из жизни - плохими и хорошими примерами, как можно организовать сбор меток, и как их качество помогает улучшить распознавание речи, распознавание текста по картинке, синтез речи и другие ML-модели.
Программный комитет ещё не принял решения по этому докладу
Быстрая обработка данных в data lake с помощью SQL
Популярные распределенные SQL-движки, такие как Trino, Presto и Dremio, умеют выполнять SQL-запросы непосредственно к файлам в озере данных, что позволяет компаниям более гибко и эффективно анализровать свои данные за счет уменьшения потребности в ETL и снижения нагрузки на корпоративное хранилище. Подобные продукты используют принцип разделения compute и storage, при котором обработка и хранение данных происходит на разных серверах. Несмотря на многочисленные преимущества, разделение compute и storage приводит к серьезному вызову: как обеспечить высокую производительность обработки информации, хранящейся на удаленных серверах? Конкурентоспособен ли такой подход по сравнению с классическими хранилищами данных?
В докладе мы рассмотрим реализацию ключевых оптимизаций, которые позволяют Trino, Presto и Dremio быстро "перемалывать" данные из вашего озера: использование метаданных Parquet и ORC для уменьшения количества зачитываемых данных (partition pruning, project/filter/aggregate pushdown), динамическая фильтрация (runtime filtering), материализованные представления (materialized views), а так же многочисленные кэши: кэш метаданных, кэш данных и кэш промежуточных результатов запросов.
Доклад принят в программу конференции
Hadoop в Облаке: история миграции сотен петабайт
Для OK Hadoop — это ключевой компонент инфраструктуры: он активно используется как для реализации продуктовой аналитики, так и для продакшена рекомендательных систем. С точки зрения объемов это более 200 PB в HDFS, 70k vcores, 200 TB RAM.
Вся инфраструктура в Одноклассниках (и не только) разворачивается во внутреннем контейнерном облаке, в прошлом году очередь дошла и до Hadoop.
Поговорим о проблемах железного hadoop, о том как запустить hadoop в контейнерах в Облаке, а так же о схемах миграции сотен петабайт(и конечно же о проблемах в пути).
Доклад принят в программу конференции
Нейронные сети, искусственный интеллект (19)
Генерация кода при помощи больших языковых моделей
В докладе Александр разберет как LLM помогут разработчикам поднять свою производительность на 100% и более, автоматизировать рутинные задачи, как быть тимлидом копайлота и даже написать целый проект не написав ни строчки кода используя GPT Engineer.
Программный комитет ещё не принял решения по этому докладу
Побеждаем рутину в Data Science
Data Science оптимизирует рутину в бизнес-процессах, тем не менее редко внутренние процессы работы дата сайентиста обходятся без нее. Многие компании используют следующую житейскую мудрость: "хочешь больше продуктов с ml-компонентами - найми больше дата сайентистов".
В докладе пойдет речь, как совершить переход от экстенсивного пути развития к интенсивному и наших успехах на этом тернистом пути. Приятным бонусом, переход поможет сделать профессию дата сайентиста более уважаемой как для программистов, так и для исследователей.
Программный комитет ещё не принял решения по этому докладу
Переводчик с языка, на котором нельзя говорить и писать
Представьте себе мир, где слова не используются для общения! Наш доклад раскрывает секреты создания переводчика для языка, которым нельзя говорить и писать. Узнайте, почему русский жестовый язык (РЖЯ) – не просто жесты, а мощный инструмент передачи абстрактных понятий. Какие трудности возникают при переводе РЖЯ и как их преодолеть? Будьте первыми, кто узнает о новых данных и инновационных подходах, основанных на нейросетях! Не упустите шанс овладеть новым языком – языком жестов! Готовы ли вы открыть дверь в мир без слов и звука? Мы расскажем о проблемах и особенностях русского жестового языка и как мы решаем эту задачу в нашей команде. В качестве бонуса выкладываем большой датасет в открытый доступ, что поможет ускорить реализацию AI-сервисов распознавания и генерации РЖЯ!
Доклад принят в программу конференции
Как мы учили LLM шутить
- Можно ли считать способность шутить признаком интеллекта?
- Если юмор это признак интеллекта и современный AI не обладает интеллектом, то получается современные LLM системы не должны уметь шутить. Рассмотрим примеры шуток от LLM;
- Подходы к обучению LLM с ограничением ресурсов. Как решить эту задачу на основе open source моделей и ограничений по ресурсам;
- подходы к finetunning базовой модели, краткое введение в PEFT (Parameter-Efficient Fine-Tuning);
- Где и как взять датасет? Рассмотрим разные подходы к составлению датасета для решения этой задачи;
- Рассмотрим результаты обучения и работы модели на основе разных датасетов;
- Выводы
Программный комитет ещё не принял решения по этому докладу
LLMops: Что есть кроме ChatGPT и как ты можешь развернуть это
1. ML ликбез. Про используемые в дальнейшем термины простыми словами
2. Классический MLops и его принципы
3. Почему Large Language Models действительно такие крутые
4. Эволюция генерации языка. Как мир пришел к LLM
5. Многообразие LLM: основные моделей и их особенности
6. Развернуть LLM и радоваться жизни: обзор способов, лицензий и требований к железу
7. Квантизация и файн тьюнинг убрать нельзя использовать
8. Векторные базы данных и LangChain
9. LLM всегда ли нужен?
10. Заключение
Программный комитет ещё не принял решения по этому докладу
Новые возможности в HR tech. Решаем генеративные задачи с помощью: Transformer + LoRA + RLHF.
Успех ChatGPT вдохновил многих исследователей попробовать технологии, которые лежат в основе обучения подобных моделей. Подход к Fine-tuning больших моделей с помощью LoRA адаптеров, а так же механизм RLHF для учета мнения людей, существенно упростили решение генеративных задач. А Instruction tuning позволил использовать генеративные модели в кейсах, в которых сложно формализовать задачу заранее.
Мы в Работа.ру давно планировали решить несколько генеративных задач, но с классическим подходом к обучению моделей это было слишком ресурсозатратно. Сейчас же несколько кейсов уже реализованы и ушли в прод.
В своем докладе я расскажу:
- о самих технологиях SFT, LoRA, RLHF, Instruction tuning
- покажу примеры реализации и расскажу о некоторых особенностях и подводных камнях этих технологий
- подробно расскажу о реализованных нами кейсах в сфере HR tech
- поделюсь архитектурными решениями
- расскажу о ближайших планах
Доклад принят в программу конференции
Real-time распознавание лиц: методы обучения быстрых и точных моделей для работы на мобильных девайсах
Наиболее точные решения по распознаванию лиц строятся на основе больших моделей глубокого обучения. Для успешного продуктового внедрения на мобильные платформы в условиях ограниченных вычислительных ресурсов эти модели должны быть не только точными, но также быстрыми и легковесными.
В этом докладе разберем следующие вопросы:
- Как выбрать современную компактную архитектуру с наилучшим балансом скорости и качества?
- Какие трудности могут возникнуть при распределенном обучении face recognition модели на датасетах с миллионами изображений и сотнями тысяч классов?
- При помощи каких методов передачи знаний от больших моделей к более маленьким можно минимизировать потери в точности из-за сокращения размера архитектуры?
Доклад принят в программу конференции
NeuroHD: охота на шакаллов или деплой и ускорение сеток в высоконагруженной инфраструктуре VK
NeuroHD — технология VK улучшения качества видео. С помощью NeuroHD мы увеличиваем разрешение видео, повышаем частоту кадров и убираем шумы. Под капотом NeuroHD использует две нейронные сети -- одну для улучшения качества, другую для повышения частоты кадров. Доклад посвящен тому, что случилось после обучения нейронных сетей.
- Как сетки попали в прод, и что с ними произошло.
- Как получилось ускорить пайплайн в 10 раз.
- Как удалось конвертировать сеть с нетипичной архитектурой в TensorRT.
- Как удалось удачно зарефакторить код и упростить интеграцию.
Доклад принят в программу конференции
Движки распознавания речи ВКонтакте
В докладе расскажу о движках распознавания речи ВКонтакте. Рассмотрим особенности онлайн и офлайн-движков: какие архитектуры нейронных сетей используем, как обучаем и адаптируем их под продукты. Расскажу, какие дополнительные трюки можно сделать и какие модули добавить, чтобы улучшить качество работы движка распознавания речи.
Доклад принят в программу конференции
YandexGPT: как научить нейросеть сокращать статьи и быть в ней уверенным (на 99%)
Генеративные большие языковые модели (Large Language Model, LLM) - наша новая реальность, которая становится core-технологиях во многих продуктах. То, для чего раньше требовалось собирать развесистый пайплайн из множества ML-моделей и хитрых алгоритмов обработки данных, теперь делается подбором правильного промпта.
Я расскажу про наш опыт обучения YandexGPT для задачи суммаризации статей в Яндекс Браузере и сервисе 300.ya.ru. О том, какие приемы помогли избегать ручных правил, экономить на GPU и что нас ждет в будущем.
Программный комитет ещё не принял решения по этому докладу
Как AI увеличивает применимость RPA
умные роботы
интеллектуальная автоматизация
тренды и тенденции
RPA-платформа Атом. РИТА
OCR
Программный комитет ещё не принял решения по этому докладу
Автоматизация технической поддержки через развитие собственного продукта цифрового ассистента
Что делать:
- когда у тебя много разных продуктов, по которым требуется оказания услуг технической поддержки?
- когда есть сезонные всплески активности пользователей?
- когда продукт постоянно развивается и нужно регулярно консультировать по новым функциям?
- когда готовых кандидатов нет на рынке?
- когда слово ИИ звучит из каждого утюга?
Тогда берем инструмент для автоматизации бизнес процессов и начинаем его развивать и автоматизируем работу технической поддержки.
Параллельно давая новый виток развития продукту.
Программный комитет ещё не принял решения по этому докладу
Generative AI и LLM: Новый подход к разработке ML проектов
В докладе Евгений разберёт традиционный цикл разработки проектов ML и NLP и его оптимизацию с использованием Generative AI. Подробный кейс проекта покажет, как LLM может эффективно оптимизировать обработку больших объемов текстовых данных. Евгений также обозначит потенциал для расширения и модификации существующих решений на основе ChatGPT и акцентирует внимание на подводных камнях при реализации таких подходов. Обсудим ограничения языковых моделей и принципы их успешного преодоления на практике.
Программный комитет ещё не принял решения по этому докладу
Генеративные языковые модели
В данном докладе будет рассмотрено развитие идей NLP от вероятностных моделей в прошлом до современных больших языковым моделей. Мы поговорим об интересных архитектурах и путях развития.
Доклад принят в программу конференции
ReAct: Как научить LLM думать и действовать
В докладе Александр разберет как научить LLM принимать решения используя подход ReAct и использовать сторонние сервисы и источники данных для поиска информации и принятия решений. Обсудим возможные сценарии применения данного подхода и рассмотрим реальный пример реализации приложения на языке Python с применением моделей OpenAI и фреймворка LangChain.
Программный комитет ещё не принял решения по этому докладу
Обучение больших нейронных сетей на HPC кластере AMD
Я расскажу про наш опыт работы с GPU от AMD. Поговорим о том:
- Какое желез предлагает AMD и почему оно хорошо
- Как AMD прорывается на рынок обучения нейросетей
- Про наш HPC кластер и его бенчмарки
- Про наш опыт обучения больших языковых моделей на этом кластере
Программный комитет ещё не принял решения по этому докладу
Как мы отвечаем роботом на 1000 тематик в поддержке пользователей?
В Тинькофф робот Олег для поддержки пользователей работает несколько лет и сейчас NLP команда обучает модели для более 1000 тематик (интентов) по разным направлениям и продуктам. Расскажу, как развивалась наши система классификации интентов и подходы к работе, с какими ограничениями сталкивались и как их решали. Обсудим подробно пайплайн по поиску новых тематик, сбору датасета и какие модели можно использовать. А так же поговорим про то, как поменялся мир и наши задачи после появления LLM.
Доклад принят в программу конференции
Zero-cost I/O и fault tolerance в распределенном глубоком обучении
Поделимся, как мы в Яндексе сделали zero-cost инфраструктуру распределенного обучения поверх распределенной транзакционной файловой системы:
1. Никаких модификаций однопоточного однопроцессного кода обучения на Python - экономим время DataScientist'а. Не нужно быть бекендером-профессионалом, чтобы писать распределенный код обучения.
2. Никакого дополнительного оверхеда по производительности под Python GIL при переходе к распределенному обучению - улучшаем утилизацию железа
3. Автоматическое масштабирование обучений с 1 GPU на сотни видеокарт, I/O на чтение/запись в десятки GB/s - улучшаем общую емкость систем обучения.
Программный комитет ещё не принял решения по этому докладу
Как мы запускали YandexGPT
В докладе Алексей расскажет, как Яндекс отреагировал на новый бум в языковых моделях и чат-ботах:
- как 3 года опыта в LLM помогали принимать важные решения
- как рос road-map проекта
- как отличаются метрики реального бизнеса, от метрик модели
- какие амбициозные цели стоят перед проектом и какие продукты уже базируются на YandexGPT
Программный комитет ещё не принял решения по этому докладу
Технологии будущего (2)
Prompt engineering: Путь к эффективной работе с ChatGPT
В ходе митапа мы начнем с основных принципов работы языковых моделей и детально разберем роль промптов во взаимодействии с ChatGPT. Особое внимание уделим важности хорошо сформулированных промптов для улучшения качества ответов ИИ.
Узнаем про safety layer и обсудим тему обхода ограничений (jailbreak), на примере DAN. В ходе митапа обсудим популярные плагины к ChatGPT и как добиться более эффективных промптов с их помощью.
В завершающей части митапа мы затронем вопросы эффективного написания промптов и поделимся полезными стратегиями. Участники митапа смогут на практике улучшить свои промпты и получить ценный навык для работы с современными языковыми моделями.
Программный комитет ещё не принял решения по этому докладу
Добро пожаловать в реальный мир, робот!
Прежде чем выпускать беспилотный автомобиль на дороги города необходимо удостовериться в его безопасности и эффективности.
Конечно, можно для этого улучшать тестовое покрытие компонент, выстраивать более чувствительные метрики для оценки ML-моделей, описывать сотни тестовых сценариев для анализа поведения беспилотного автомобиля в конкретных дорожных ситуациях.
Однако, реальный мир оказывается намного сложнее, чем это могла бы предвидеть любая рукописная система тестирования.
В своём докладе я расскажу:
- как мы построили систему симуляции, позволяющую тестировать новые беспилотные автомобили на произвольных кейсах из реального мира
- откуда в симуляторе берутся 2 реальности и из чего они состоят
- к каким проблемам приводит эффект бабочки и как обратить эти проблемы в преимущества
- зачем мы заставили беспилотное авто проходить тест Тьюринга, и как с помощью этого теста померили то, что не смог замерить человек
Программный комитет ещё не принял решения по этому докладу
Бэкенд, теория программирования (10)
Бои в гексагоне: как на архитектуре Ports & Adapters построить омниканальное решение
Перед командой стояла задача разрабатывать омниканальный банковский проект для платежей, с минимумом критических багов и быстро.
Это осложняется тем, что каждое действие пользователя скрывает за собой много операций - вызовы смежников, тяжелые запросы к БД. Плюс, как следует из слова "омниканальный" - одновременно существуют требования как предоставлять одинаковый опыт для пользователей, так и быть готовыми любую логику переписывать в несколько вариантов, потому что либо каналы технически устроены по-разному, либо новый функционал выкатывается неравномерно.
Чтобы избежать случайных ошибок и нежелательных побочных эффектов при разработке, сама архитектура должна направлять эти процессы и страховать команду от просачивания логики туда, куда не следует.
При дизайне решения выбрали гексагональную архитектуру и модульный монолит.
Такое решение содержит меньше неявных зависимостей, чем классический монолит, а развивается проще, чем микросервисы.
Этот выбор позволил создать систему, отвечающую высоким требованиям к продукту в банковской сфере, сохранив поддерживаемость и возможность быстро перейти на микросервисы в будущем, на стадии поддержки проекта.
Программный комитет ещё не принял решения по этому докладу
Eventual consistency в stateful сервисе
* Распределенное хранилище размером 80+ Тб
* Проблемы масштабирования
* Невозможность строгих гарантий
* Откуда взялась потребность усложнять простую схему
* Как изначально звучал продуктовый заказ
* Как устроена транзакционность в Метрике
* Какие проблемы возникают, когда появляются связи между пользователями
* Как мы пошли "в лоб" и к чему это привело
* Как мы пришли к идее "команд"
* Переход к eventual consistency
* Планировщик и decision maker как участник конвейера
Программный комитет ещё не принял решения по этому докладу
Статические анализаторы в PHP и сложности их внедрения
В докладе расскажу как выбрать анализатор исходя из задач, покажу сложности внедрения, сравню имеющиеся на рынке решения, а также поделюсь кейсами при реальном применении.
Программный комитет ещё не принял решения по этому докладу
Точки отказа в хайлоад системах. Backend
+ как разработчик видит хайлоад (джун/мидл/сеньор)
+ виды точек отказов в хайлоаде с точки зрения backend
+ память сервиса под нагрузкой
+ пулы потоков
+ пулы соединений к базе данных
+ пулы tcp соединений
+ пулы jms сессий и соединений
+ реактивность (project reactor) и распространенные ошибки (java/kotlin)
+ прокси и балансировщики
+ примеры инцидентов и их решение (как можно было предотвратить)
+ диагностика и мониторинг хай лоад проблем (практические примеры мониторинга)
Программный комитет ещё не принял решения по этому докладу
Магия JWT и ее разоблачение. Основные заблуждения при работе с технологией
JWT как технология популярна, по ней написано много статей, сделано много переводов, есть огромный простор для копирайтинга.
При этом всегда есть вполне естественное желание написать статью которая будет уникальна станет первой в поисковой выдаче. Из-за этого имеем комбинаторный взрыв статей по JWT в каждом стеке/фреимворке/библиотеке и попутно окунувшись в сессии, аутентификацию, авторизацию и аспекты безопасности.
Однако подобная популярность сыграла злую шутку с JWT и зачастую его рассматривают в качестве "серебрянной пули" для решения всех задач IAM. Ну а официальные материалы просто утопают в поиске, а даже когда на них есть ссылка, то они обычно игнорируются.
Рассмотрим чем JWT является на самом деле, его применение на примере абстрактного сервиса а так же основные заблуждения.
Программный комитет ещё не принял решения по этому докладу
Как мы сделали систему для отложенных пушей для умных устройств с Алисой
1. Расскажу про то, как устроен стык клиентских устройств и наших серверов
2. Какие проблемы возникали в ходе разработки сервиса для отправки пушей
3. Для решения каких задач нам потребовалось работать над развитией системы и создать возможность остылки пушей по расписанию
4. Какие проблемы проблемы мы смогли побороть и какой потенциал по масштабированию смогли заложить
Программный комитет ещё не принял решения по этому докладу
Как мы всё лучше и лучше познаём наш highload-сервис на Go
Раздел дополняется
Программный комитет ещё не принял решения по этому докладу
EventSoursing: как мы ускорили SQL проекции с 7 часов до 7 минут
EventSouring предлагает нам создавать два хранилища данных: append-only хранилище ивентов и read-only хранилище, оптимизированное для быстрого выполнения запросов. И иногда read проекцию нужно перегенерировать, но когда проект в проде уже несколько лет и для него накоплено много данных, этот процесс может быть долгим.
Я расскажу как мы переписали перегенерацию проекций, теперь она занимает минуты, а не часы.
Программный комитет ещё не принял решения по этому докладу
Как устроена система сканирования робота Spectro
Доклад описывает принцип работы системы сканирования на роботе Spectro (на уровне компьютерного зрения), челенжи, с которыми мы столкнулись по Perfomance во время разработки, как выполняется базовая бизнес логика робота для проведения инвентаризации робота, а также какие результаты собирает робот и как склад ими пользуется уже сейчас.
Программный комитет ещё не принял решения по этому докладу
Как делать бинарно-совместимые API на компилируемых языках?
Скажем, мы разрабатываем продукт на компилируемом языке. Рано или поздно наступает момент, когда нужно разделить продукт на несколько компонентов, развивающихся независимо. Или дать возможность расширять функциональность плагинами, разрабатываемыми отдельными коллективами или сообществом.
Здесь мы сталкиваемся с проблемой обеспечения прямой и обратной совместимости: что произойдет с при обновлении одного из компонентов независимо от другого?
Если бы компоненты были микросервисами, в качестве интерфейса выступал бы JSON поверх HTTP или другой высокоуровневый протокол RPC. Но мы хотим сочетать независимость развития компонентов с нативным вызовом функций и нативным представлением структур.
Доклад дает обзор подходов к этой проблеме и набор практических приемов.
Доклад принят в программу конференции
Цифровая культура / CTO-трек (4)
Как из Python и палок собрать детектор аномалий для highload
При эксплуатации любого сервиса рано или поздно появляются сотни и тысячи графиков, за которыми надо следить, это и RPS и время ответа и количество открытых сокетов и многие другие. В каждом из них могут появляться аномалии, о которых очень хочется своевременно узнавать. В своем докладе я расскажу о том, как на коленке написать детектор аномалий, который будет перемалывать несколько тысяч метрик в минуту и работать одновременно с данными из Zabbix, Graphite, Prometheus, Clickhose да и вообще любой БД или системой мониторинга.
Доклад принят в программу конференции
Масштабирование OpenAPI в api-first компании
Мы в Flussonic два года назад резко перешли на api-first подход к построению систем и это было необходимо для возможности расти и развиваться. Мы внедрили OpenAPI 3.1 для коммуникации сложных систем на erlang, golang, python, rust, rails, C, nodejs. Репозиторий со схемами стал местом, где бизнес может договариваться с разработкой на простом и формальном языке. В нём сейчас 56 тыс строк кода в yml файлах и 140 тыс строк кода в результирующих json файлах.
Поддержание его читаемым, понятным, лаконичным инструментом, позволяющим согласовывать сущности между различными командами, потребовало собственные доработки кодогенераторов, валидаторов и прочего инструментария для работы с OpenAPI.
В докладе будет рассказано про доработки инструментов вокруг такого репозитория с openapi схемами, который становится главным местом сборки целой компании.
Доклад принят в программу конференции
Как на практике оптимизировать расходы на облако с помощью FinOps
В своем докладе я расскажу какие FinOps-инструменты сейчас присутствуют на российском рынке, как выглядит процесс их внедрения и к каким результатам может привести.
FinOps — это развивающаяся дисциплина управления облачными финансами, основной целью которой является увеличение рентабельности бизнеса за счет повышения эффективности облачной инфраструктуры. Внедрение FinOps позволяет ответить на вопросы кто, сколько и на что тратит в организации, позволяя организовать эффективный учет и контроль расходов и привязать облачные расходы организации к конкретным бизнес-метрикам.
Основной причиной появления FinOps стало увеличение неэффективности использования облачных ресурсов. Данный показатель называется cloud waste и на текущий момент равняется 30% – это означает, что около 30% всей облачной инфраструктуры, которые используют различные организации в мире, или около 147 миллиардов долларов, потрачены впустую, не принося никакой пользы владельцам инфраструктуры.
Доклад принят в программу конференции
Нужны ли сейчас продуктовые экосистемы в российском ИТ?
Сейчас, как в ИТ, так и во многих других отраслях, мы находимся в условиях некоторой изоляции от того, что раньше нам казалось привычным и абсолютно обыденным.
Поговорим о том, почему нам с вами в ИТ важно не унывать и не жаловаться, а наоборот – пользоваться возможностью и все свои силы вкладывать в развитие качественных продуктов и чем развитие одного продукта отличается от создания экосистемы.
Программный комитет ещё не принял решения по этому докладу
Митапы (2)
5 вещей, которые чуть не убили антиспам
5 вещей, которые чуть не убили антиспам
Введение: проект антиспам от Билайна родился в декабре 2021 года для того, чтобы защищать наших абонентов от голосового спама, который уже стал сильно раздражать, при этом не сбавляя темпы роста
В докладе я не планирую рассказать о сути продукта, процессе обучения нашей ML модели и тонкостях сбора обратной связи. Но хочется поделиться тем, с какими трудностями мы столкнулись и как мы их решали. Думаю, это будет интересно и с точки зрения обмена опытом, и с точки зрения развенчивания мифов о проекта формата «на 1 день данные собрали, на 2 день обучили, на 3 запустили»
Кейс 1. Данные
У нас были супер разрозненные данные в виде транзакций из разных источников (разные части мобильной и фиксированной сети)
- часть звонков уникальна, часть присутствует в обоих источниках
- разные таймзоные и правила на разных коммутаторах
- звонки могут лежать в разных партициях
- разные виды записи номеров
Кейс 2. Обучающая выборка
Сбор обучающей выборки для построения модели был очень не простым. Помимо того, что понятие «спамера» растяжимо, о чем мы отдельно поговорим в следующем кейсе, и помимо того, что получить достоверные номера в нужном количестве (100к+ номеров) и так затруднительно, было еще сложности:
•Надо искать руками периоды активности спамеров
•Не по всем номерам мы видим достаточно трафика
•Этот процесс должен быть постоянный,
а не разовый
Кейс 3. Формализация терминов
Понятие «спамер» очень растяжимо, и есть многие кейсы, когда вынести решение «блокировать или нет» не так просто
Помимо классических спамеров в мире существуют
•Белые спамеры: организации, у которых много ПОЛЕЗНЫХ звонков (различные клиентские службы)
•Курьеры, таксисты, доставщики
•Те, кого нельзя блокировать по закону: государственные службы, коллекторы и так далее
•Различные m2m устройства, которые нужны для технических функций
Кейс 4. Задержка источников
В какой-то момент мы поняли, что из-за задержки в данных мы стали пропускать очень много трафика от новорожденных спамеров. Для этого мы помимо основной модели сделали:
- горячую модель на быстром источнике, но не по всему трафику. Задержка - 1 сутки
- Триггеры на сбор обратной связи по новым активным номерам. Задержка - десятки минут
Кейс 5. Мы сильно влияем на спамеров
Так как мы начали блокировать звонки от некоторых номеров, это начало искажать их фичи. Вследствие этого, они в какой-то момент перестанут детектироваться моделью и снова их звонки будут проходить. И так же блокирую спамеров, мы сами же обрезаем необходимые для переобучения единички (спамеры)
Итого:
Рассказать будет состоять из приветствия, введения, рассказа о вышеперечисленных кейсах и заключения
Программный комитет ещё не принял решения по этому докладу
5 вещей, которые чуть не убили антиспам
5 вещей, которые чуть не убили антиспам
Введение: проект антиспам от Билайна родился в декабре 2021 года для того, чтобы защищать наших абонентов от голосового спама, который уже стал сильно раздражать, при этом не сбавляя темпы роста
В докладе я не планирую рассказать о сути продукта, процессе обучения нашей ML модели и тонкостях сбора обратной связи. Но хочется поделиться тем, с какими трудностями мы столкнулись и как мы их решали. Думаю, это будет интересно и с точки зрения обмена опытом, и с точки зрения развенчивания мифов о проекта формата «на 1 день данные собрали, на 2 день обучили, на 3 запустили»
Кейс 1. Данные
У нас были супер разрозненные данные в виде транзакций из разных источников (разные части мобильной и фиксированной сети)
- часть звонков уникальна, часть присутствует в обоих источниках
- разные таймзоные и правила на разных коммутаторах
- звонки могут лежать в разных партициях
- разные виды записи номеров
Кейс 2. Обучающая выборка
Сбор обучающей выборки для построения модели был очень не простым. Помимо того, что понятие «спамера» растяжимо, о чем мы отдельно поговорим в следующем кейсе, и помимо того, что получить достоверные номера в нужном количестве (100к+ номеров) и так затруднительно, было еще сложности:
•Надо искать руками периоды активности спамеров
•Не по всем номерам мы видим достаточно трафика
•Этот процесс должен быть постоянный,
а не разовый
Кейс 3. Формализация терминов
Понятие «спамер» очень растяжимо, и есть многие кейсы, когда вынести решение «блокировать или нет» не так просто
Помимо классических спамеров в мире существуют
•Белые спамеры: организации, у которых много ПОЛЕЗНЫХ звонков (различные клиентские службы)
•Курьеры, таксисты, доставщики
•Те, кого нельзя блокировать по закону: государственные службы, коллекторы и так далее
•Различные m2m устройства, которые нужны для технических функций
Кейс 4. Задержка источников
В какой-то момент мы поняли, что из-за задержки в данных мы стали пропускать очень много трафика от новорожденных спамеров. Для этого мы помимо основной модели сделали:
- горячую модель на быстром источнике, но не по всему трафику. Задержка - 1 сутки
- Триггеры на сбор обратной связи по новым активным номерам. Задержка - десятки минут
Кейс 5. Мы сильно влияем на спамеров
Так как мы начали блокировать звонки от некоторых номеров, это начало искажать их фичи. Вследствие этого, они в какой-то момент перестанут детектироваться моделью и снова их звонки будут проходить. И так же блокирую спамеров, мы сами же обрезаем необходимые для переобучения единички (спамеры)
Итого:
Рассказать будет состоять из приветствия, введения, рассказа о вышеперечисленных кейсах и заключения
Программный комитет ещё не принял решения по этому докладу
Enterprise-системы (10)
Buy vs build
Начиная от установки в стойки и заканчивая обслуживанием приложений рынок вываливает огромное количество разных продуктов, которые способны помочь решить проблемы в тот же миг, уменьшить t2m и вообще улучшить состояние бизнеса. Инженеры в компаниях собираются в нелегальные банды и начинают писать свои продукты, платформы и даже могут выложить их в open source.
Как в таких случаях взять правильный вектор и выбрать верное решение, сохранить команду или наоброт, остаться на решениях vendor-lock мы и обсудим в рамках данного доклада на базе облачных платформ.
Поделюсь размышлениями о финансовой стороне вопроса в случае самописных решений и в случае покупных решений и расскажу про негативный опыт, связанный как с написанием своих систем, так и с опытом покупки решений.
Программный комитет ещё не принял решения по этому докладу
Тернистый путь инструмента цифрового проектирования
Почему C4 модели мало и сколько слоёв архитектуры нужно большой организации.
Мы начали с попытки описания API и контрактов,
Поняли, что не хватает описания взаимодействий между системами,
Перешли к автоматизации стандартов и описанию детальной архитектуры наших АС,
И наконец то добрались до открытия доступа по описанной архитектуре.
В дальнейших планах связать все слои архитектуры в прозрачную модель на любом уровне.
Автор будет рассказывать о тяжёлом пути развития инструментов архитектурного проектирования в Банке.
Доклад принят в программу конференции
LogDoc: логи здорового человека
В данном докладе мы хотим рассказать историю создания нашего продукта LogDoc и то как мы с помощью него изменяем рынок логирования и подход к обработке и анализу логов.
Программный комитет ещё не принял решения по этому докладу
Так ли легко добавить колонку в базе данных?
При развитии продуктов регулярно приходится изменять структуру базы данных - добавлять или переименовывать поля, изменять связи, исправлять ошибки. К сожалению, обычно проблеме безопасного изменения структуры данных не уделяется достаточного внимания.
На докладе хочу рассказать про основные шаблоны модификации структур, про популярные возникающие ошибки и мифы
Программный комитет ещё не принял решения по этому докладу
Jco сервер как идеальное решение для интеграции с системами SAP
Как интегрироваться с системами SAP без IDocs и SAP PI? Как отправлять большие сообщения? Как увеличить скорость передачи данных из систем SAP и повысить надежность интеграционных потоков? Что такое сервер JCO?
Я попытаюсь раскрыть эти проблемы в своем отчете на примере настроенного сервера Jco в рамках проекта “Пополнение TC5” в компании X5 Retail Group. В рамках доклада я расскажу о проблемах, с которыми мне пришлось столкнуться при интеграции с самой высоконагруженной ERP-системой SAP в России, а также о том, как они были решены. Также будет освещена тема всех нюансов настройки Jco Server-a, какая скорость передачи данных была достигнута и ограничения такого подхода.
Программный комитет ещё не принял решения по этому докладу
Total'ный контроль за сотрудниками через Telegram
Федеральная сеть салонов красоты.
20 000 сотрудников во всех городах РФ. Отчет с фото каждого сотрудника нужно собрать и проверить за 10 мин до утренней планерки... или о том как telegram боты спасают топ менеджеров в 2023 году.
Тезисы:
- Как не напугать сотрудников и подключить их к сервису слежки и контроля
- Куча контента для SMM, как приятный бонус при реализации чат-бота
- Какие есть реальные ограничения Telegram и как этично их можно преодолеть, реальные цифры требуемого железа под сервисы
- Нейронки в проде или как по фото определить соблюдение корп. стандартов
- интеграция YClients и особенности работы API
Программный комитет ещё не принял решения по этому докладу
Темные боги корпоративной архитектуры. Истории из недр варпа
Как так оказывается, что совершенно разные подходы к организации корпоративной архитектуры порождают одинаково отвратительных демонов реализации. Почему рожденные в идеальном порядке или искренней любви дизайн-документы все равно приводят нас в пучины отчаяния. Как приключение на один спринт обращается в падение в черную дыру техдолга.
Я расскажу разные истории о впадении разработки в ересь в разных обстоятельствах, иногда даже идеальных.
Доклад принят в программу конференции
Как мы работали с интерфейсом через БД и к чему это привело
Принимали ли вы когда-нибудь решения за которые потом было стыдно перед самим собой?
Потому что смалодушничал, поленился или просто решил что "и так сойдет".
Однажды мы решили что было бы очень удобно и быстро реализуемо, если бы интерфейс обновлялся постоянным чтением из БД.
Некоторые последствия этого решения мы разгребаем до сих пор. Однако первые отголоски мы почувствовали уже с первым ростом числа пользователей
Мой доклад о том как иногда тактически верные в моменте решения могут привести к проблемам на стратегическом уровне и как мы с этим справлялись.
Программный комитет ещё не принял решения по этому докладу
Как выглядит процесс разработки k8s платформы enterprise-уровня в 2023 г.
На примере NOVA Container Platform расскажу, как устроен процесс разработки K8s платформы в условиях импортозамещения, с учетом сложившихся в компании практик, потребностей инженеров бизнеса и других пользователей платформы.
Программный комитет ещё не принял решения по этому докладу
Обработка действительно больших потоков данных в 1С: опыт СберМаркета
В своем докладе я расскажу об архитектурных и технологических приемах, позволяющих обработать и загрузить большой объем информации.
Рассмотрим приемы минимизации логических связей, изоляций этапов и оптимизации загрузки повторяющихся данных. Кроме этого, расскажу об агрегации и многопоточной обработки — и все это на примере банковской выписки с более чем 1 миллионом операций в сутки.
Программный комитет ещё не принял решения по этому докладу
Тестирование, нагрузочное тестирование (3)
Профилирование микросервисов под нагрузкой.
Доводилось ли вам бывать в ситуациях, когда в вашем сервисе медленно, но верно подтекает память, а профилирование ничего не даёт? Приходилось ли принимать костыльное решение - перезапускать поды сервиса раз в несколько часов, чтобы не попадать на сбои из-за утечек? У нас было и мы нашли решение, не совсем обычное, слегка ортогональное, однако рабочее и с некоторых пор, помогающее нам в непростых ситуациях. Это решение гармонично дополнило возможности нашей платформы тестирования производительности. Приходите послушать наш доклад, X5 Digital занимательно поделится своим опытом - платформы экспресс-доставки из торговых сетей X5 . Мы динамично растем - у нас нагрузка - и нагрузка приносит не всегда простые и понятные вызовы.
Программный комитет ещё не принял решения по этому докладу
Аналитика и метрики качества
- Важности позиционирования багов в процессе разработке в разрезе Testing, QC и QC
- Практике применения аналитики качества по найденным багом, её основные этапы
- Формирование actions по улучшению процессов обеспечения качества и разработки, их реальные примеры
- Формирование релизных и продуктовых метрик
Программный комитет ещё не принял решения по этому докладу
Нагружать может каждый
Многие компании пренебрегают проведением нагрузочного тестирования, так как для организации процесса нужны узкопрофильные специалисты и специфический софт.
- Как понять, что нам нужно нагрузочное тестирование?
- Как быть, если у нас мало опыта и ресурсов?
- Как разобраться в результатах?
- Я-менеджер и что мне может дать проведение НТ?
Программный комитет ещё не принял решения по этому докладу
Архитектуры и масштабируемость (51)
«Веслосипед» для сбора логов
В докладе хотим рассказать о том, как с нуля создали собственный инструмент для сбора логов в режиме реального времени, который в дальнейшем стал ключевым для нашей системы сбора и обработки данных, позволяющей обрабатывать до 5 млн уникальных сообщений в секунду и до 120 млрд в день.
Наша система построена на стеке - Golang+Kafka+Clickhouse. Система универсальна и позволяет качественно сопровождать ключевые ИТ сервисы X5 - от анализа событий кассовых операций до сбора логов защитного периметра WAF + NGFW.
Мы разберем основные технологические и архитектурные решения, которые вам придется принять при создании приложения подобного класса.
Прогуляемся по нашим граблям и проблемами, с которыми столкнулись. Разберем и протестируем в бою стандартные инструменты для сбора логов. А также дадим базовые рекомендации для проектирования подобных систем.
Доклад принят в программу конференции
Высокая нагрузка или/и низкая задержка
Поставлена задача на переработку реальной системы:
требуется на имеющемся железе кратно увеличить пропускную способность и при этом уменьшить время отклика.
Метод - архитектурный редизайн.
Результат - успех.
В докладе представлено пошаговое решение с обоснованиями и демонстрацией модели производительности.
Доклад принят в программу конференции
Как построить OMS с помощью Temporal: опыт от нуля до десятков тысяч заказов в день
Обработка заказов - один из самых сложных доменов в e-commerce, особенно в мире микросервисов. Большинство существующих систем реализует процессинг заказов с помощью хореографии, что довольно сложно в исполнении и обычно приводит к беспорядку. Бизнес-требования разбиты на тысячу маленьких частей, а выполнение требований отказоустойчивости, даже таких как ретраи и фоллбеки, довольно сложно. В таких системах низкая прозрачность, поиск дефектов в них может занимать дни, а добавление новой функциональности - целые месяцы. Эту проблему можно решить с помощью Temporal — платформы для оркестрации рабочих процессов.
Мне в Uzum выпала уникальная возможность написать сервис для процессинга заказов с нуля и я расскажу с какими проблемами предстоит столкнуться, если вы тоже выберете Temporal для построения вашей собственной Order Management System, а так же покажу как оценить производительность подобной системы.
Доклад принят в программу конференции
Эволюция и мифы CQRS
Казалось бы, про CQRS всё уже давно сказано — но мне есть что добавить!
Если спросить 10 разных разработчиков: что такое CQRS, то получишь 10 разных ответов.
В докладе я обобщу свой многолетний опыт применения CQRS.
Обсудим, какие варианты реализации CQRS бывают. Какие преимущества дает каждый из вариантов и какие он накладывает ограничения.
Так же обсудим самые популярные вопросы и заблуждения CQRS:
Могут ли команды возвращать значения. Если нет — то почему?
Могут ли query писать логи?
Что делать, если две команды должны использовать общую логику?
Поможет ли CQRS при росте нагрузки на сервис?
Программный комитет ещё не принял решения по этому докладу
Масштабирование незаконченной системы: от приёмки скоупа до внедрения паттернов распределенных систем и кратного роста нагрузки в 1 000 раз
В докладе расскажу, как по шагам построить расширяемую систему на основе MVP, переданного в наследство.
Внутри доклада разберём по шагам, с чего начать и как масштабировать нагрузку сервиса в 1000 раз. Затронем аспекты управления командой разработки и передачи скоупа, тестирования, аналитики метрик нагрузки, рассмотрим применение паттернов распределенных систем.
— Расширение старой логики согласно концепции "test first and code later".
— Анализ метрик нагрузочного тестирования для эффективного распараллеливания операций, рефакторинга неоптимальных запросов, создания сценариев использования разных типов индексов.
— Обсудим применимость паттернов распределенных систем (Circuit Breaker, защита от состояния гонки, распределенные транзакции).
— Работа над ошибками или как принять скоуп от уходящей команды.
Программный комитет ещё не принял решения по этому докладу
Эволюция архитектуры транскодера
На докладе вы услышите:
- Как мы перекодируем видео пользователей в самые популярные разрешения, считаем видео сигнатуры, генерируем субтитры
- Как учились проиретизировать живых пользователей и batch задачи
- Как жить если у тебя тысячи воркеров, кластер на десятки тысяч ядер который нужно использовать эффективно
- Как мы обрабатываем в среднем сотни тысяч видео в сутки, длительностью в тысячи часов
- Как значительно улучшили утилизацию железа и скорость транскодирвания изменив архитектуру
- Как обработать задачу за гаранитрованое время, если твой кластер полностью загружен и ты не умеешь предсказывать eta для задач
Доклад принят в программу конференции
Как научить почтовый сервер Exim под нагрузкой 1 000 000 писем/мин переживать отказ ЦОД без простоя с помощью FUSE и Tarantool, а также развернуть такую систему в K8s
В Почте Mail.ru стояла задача: научить бэкенд на основе почтового сервера Exim с нагрузкой 1 000 000 писем/мин переживать отказ ЦОД без простоя и потери писем. Основная сложность была в том, что почтовый сервер использует локальный диск для хранения очереди писем в процессе доставки.
Для решения проблемы мы построили отказоустойчивую распределённую очередь на основе Tarantool и in-house объектного хранилища. Чтобы не менять логику почтового сервера, мы написали свою файловую систему в userspace на Tarantool и FUSE, которая инкапсулирует взаимодействие с распределенной очередью.
В своем докладе я покажу, как на уровне архитектуры очереди мы гарантируем отсутствие потерь писем, покажу Tarantool с новой стороны - как движок для реализации асинхронных приложений на C, немного расскажу о базовых концепциях файловых систем и поделюсь опытом эксплуатации FUSE в K8s на продакшене.
Программный комитет ещё не принял решения по этому докладу
Эволюция внедрения межсетевых экранов в облаке: от костылей до отказоустойчивых кластеров
Распространенное требование к построению безопасной инфраструктуры — наличие межсетевого экрана для организации разграничения сетевого взаимодействия с сетью Интернет, так и между внутренними сервисами. В докладе мы откатимся на несколько лет назад, вспомним как мы делали раньше и к чему пришли в итоге. Поделимся лучшими практиками и ответим на вопрос как делать не стоит.
Программный комитет ещё не принял решения по этому докладу
DRP & BCP для самых маленьких
Этапы проектирования и создания DRP & BCP с момента создания до роста проекта.
Как объяснить программисту особенности работы приложения в 2+ ЦОДах
“The Twelve-Factor App” в реальной жизни.
Проходим архитектурное собеседование с SRE командой.
Являются ли облака, k8s или серверная в офисе панацеей (лекарство у алхимиков, якобы помогающее от всех болезней) от всех бед?
Программный комитет ещё не принял решения по этому докладу
Надёжная аналитика: как мы собираем стату в мини-приложениях VK
VK Mini Apps — это открытая платформа для встраивания крос-платформенных приложений, расширяющих возможности ВКонтакте, как на вебе, так и на iOS- и Android-клиентах. Сейчас мини-приложения глубоко проросли в инфраструктуру VK. Их используют миллионы пользователей ВКонтакте.
Я расскажу, как отследить сессию пользователя в условиях, когда у вас 4 разные независимые платформы; как не терять события статы; как спроектировать и удержать результат; и как всё-таки начать доверять своей аналитике.
Доклад принят в программу конференции
Внутренняя платежная система Яндекса: что под капотом?
Расскажу, как устроена платежная система Яндекса, которая обрабатывает платежи от всех сервисов компании. Из доклада вы узнаете, что FinOps — это:
— не бывшие Яндекс.Деньги, а отдельная система.
— высоконагруженная платежная система, обрабатывающая до 1,2 тыс платежей в секунду.
— повышенные требования к надежности и отказоустойчивости (мы должны быть ещё более надежными, чем самый надежный сервис Яндекса). Минуты простоя — это убытки в миллионы денег.
— широкая география приема платежей, от Перу до Эмиратов.
— event sourcing система, написанная на Golang, работающая в 3 ДЦ, использующая YDB.
И ещё много чего полезного.
Доклад принят в программу конференции
Доклад про Цифровой Рубль
Что такое Цифровой Рубль
Кратко что такое Цифровой Рубль
Какие проблемы он решает для
государства
организаций
пользователей
Как задача выглядит для финтех организации
Постановка Задачи со стороны ЦБ
Финтех как посредник в операциях между пользователем и платформой Цифрового Рубля в ЦБ
Чем задача отличается от задачи добавления новой платежной системы
Добавляем третью форму рубля в проводки для Работы с бухгалтерскими книгами банка
Обеспечиваем безопасность персональных данных с учетом требований ЦБ, нашей безопасности, чтобы данные пользователей были в безопасности
Новые Юридические вопросы (Фин Мониторнг, Государство 115ФЗ, Юристы ГПБ - изменения в законодательстве)
Криптография (впервые работаем в МП с электро подписью), Классы защиты, новый Удостоверяющий центр
Архитектура Цифрового Рубля крупными мазками
Расскажу про сложность проекта и те слои которые прошила кросс-платформенная, кросс-функциональная команда ЦР
Мобильное приложение (SDK)
middleware
Бэкенд система Цифрового Рубля
Система интеграции с платформой Цифрового Рубля в ЦБ
Кратко расскажу как мы применили Vertical Sliced Architecture в реализации бизнес-процессов
Программный комитет ещё не принял решения по этому докладу
А знаете ли вы, что вы насчитали? XNumPy — расширение NumPy с оценкой точности вычислений.
Мы обсудим проблемы, возникающие при вычислениях со значениями с плавающей точкой, связанные с накоплением ошибок вычислений. В ряде случаев под сомнением могут оказаться все результаты вычислений, особенно в случаях, связанных с численным дифференцированием и большими объемами вычислений, например, при обучении нейросетей. Мы обсудим новый инструмент, позволяющий снабдить вычисления на основе широко распространенной библиотеки numpy контролем точности с оценкой ошибок снизу. Пользователь таким образом получает возможность проверить, насколько может доверять результатам вычислений, почти не внося изменений в код. Также мы обсудим, какие математические и программистские приёмы позволили сделать инструмент производительным.
Доклад принят в программу конференции
Поставка данных, имеющих сложную иерархическую структуру, в Greenplum
Поставка данных в Greenplum может превратиться в нетривиальную задачу, если речь идет о поставке данных, которые имеют иерархическую структуру и которые нужно атомарно и консистентно разложить по множеству таблиц. Сложности также добавляет необходимость в поддержке DDL-миграций и то, что набор источников может динамически меняться, а поставку останавливать не хочется. Еще интереснее становится, когда источников данных становится другая СУБД.
В этом докладе я бы хотел рассказать о том, как мы организовали подобную поставку данных, используя формат данных Avro, Apache Flink, микро-gpfdist'ы и self-service, который позволяет всем этим управлять.
Доклад принят в программу конференции
Асинхронное взаимодействие в распределенных системах
На мастер-классе мы с участниками разберем реальную задачу из жизни маркетплейсов по превращению корзины в заказ. Обсудим возможные варианты реализации распределенной транзакции, применимость различных паттернов, плюсы и минусы различных реализаций.
Доклад принят в программу конференции
Эволюция инфраструктуры. От vendor-legacy к cloud-native.
1. Что было было раньше
2. Начало трансформации ИТ-ландшафта (2021) год
3. Трансформация ИТ-ландшафта в централизованную коммунальную среду (2022) год
4. Предпосылки к созданию внутреннего облака и коммунальных сетей L3 (2023)
5. Развитие внутреннего облака и коммунальных сетей L3 (2023)
6. Наши планы по на 2024 год
Программный комитет ещё не принял решения по этому докладу
На творчестве Линуса Торвальдса NGFW не построишь. Почему для создания файрвола следующего поколения не подходит сетевой стек ОС Linux?
Разработка высокотехнологичного продукта для киберзащиты — сложный процесс, требующий глубокой экспертизы. Особенно если от него напрямую зависит стабильность бизнес-процессов компании, как в случае с NGFW.
Мы поговорим про два вызова продукта класса NGFW с точки зрения разработки:
- как быстро обрабатывать большой объем трафика? Spoiler — сетевой стек Linux нам не друг
- развеем мифы про железо. Может ли NGFW обойтись без специализированного и дорогостоящего железа? И если да, то чем за это придется заплатить?
Программный комитет ещё не принял решения по этому докладу
Multi-tenancy в условиях виртуального хостинга
Виртуальный хостинг в нашей стране не развивается на протяжени десятилетий, менялись технологии, стек, размещаемые данные.
Но это как был linux сервер с отдельными пользователями, так и остается. Провайдерам остается только работать на стабильность и экономическую эффективность.
За это время сложились практики и механизмы, которые отлично себя показали в вопросе справедливого распределения вычислительных ресурсов сервера и изоляции пользователей друг от друга.
Внедрение чего-либо нового в подобной multi-tenancy всегда предъявляет специфические требования к решению:
1. Изоляция на уровне пользователей
2. Потребление ресурсов системы только на время использования
3. Малое потребление ресурсов
На примере нового файлового менеджера продукта виртуального хостинга расскажем как мы внедряем новые функции в условиях multi-tenancy виртуального хостинга
Программный комитет ещё не принял решения по этому докладу
Шардирование: с нуля до Яндекс.Диска
Рассмотрим подробности шардирования в базах данных: зачем оно, как его избежать, какие сложности с шардированием данных были в Яндекс.Диске и как их решали.
Доклад принят в программу конференции
Как мигрировать 600к приставок на новый бэк и ничего не сломать?
- Что делать, если нужно отказаться от вендорского backend-а, а у вас есть 600к абонентских устройств, которые никак не обновить?
- Как разобрать нагрузку от приставок, выделить "полезный" и "паразитный" трафик.
- Как выбрать решение, которое позволит бесшовно перекинуть абонентов на новый бэк.
- "Шеф, все пропало, клиент уезжает!" или новый бэк еще не готов полностью, а мигрировать пора. Что делать?
Программный комитет ещё не принял решения по этому докладу
Универсальный сервис верификации действий пользователя. Как быстро подстраиваться под стремительно меняющиеся внешние условия
В сервисах Mail.ru для совершения некоторых критичных действий пользователю необходимо пройти процедуру подтверждения.
Например, для создания пароля для внешнего приложения, пользователю необходимо последовательно привязать телефон, ввести пароль и пройти Google Recaptcha.
Для обеспечения отказоустойчивости наших сервисов, было принято решение иметь возможность ротировать разные способы верификации в зависимости от внешних условий. Так, задача по замене Google Recaptcha на внутреннее решение только на создании паролей для внешних приложений была оценена примерно в человеко-месяц: разработка в старом проекте на фронтенде и на бекенде.
Если потребуется отказаться от внутреннего решения в пользу более универсального, это время потребуется потратить повторно.
А действий, требующих верификации, только в Почте более десяти.
Чтобы снизить затраты на разработку, мы придумали и реализовали гибкую архитектуру единого на все проекты сервиса, инкапсулирующего логику такого рода проверок, и уже успешно внедрили в 3 места в Почте Mail.ru.
В результате интеграции удалось сократить время на внедрение новых способов верификации более чем в 10 раз: достаточно внедрить новую технологию в наш сервис и она будет доступна везде, где он есть. В дополнение мы получили возможность гибкой и быстрой конфигурации проверок. Например, можем легко выключить отправку SMS пользователям при превышении бюджета или включить, если нужно отказаться от Google Recaptcha. Также можно настраивать специфичную для разных типов аккаунтов логику проверок.
Программный комитет ещё не принял решения по этому докладу
GraphQL: зачем на самом деле он нужен. Apollo Federation: дар бога.
Когда мы проектируем способ взаимодействия между клиентом и сервером, мы выбираем то, каким способом будет описан контракт взаимодействия. Каким языком, в каком месте, как он будет интерпретироваться. Есть разные подходы к решению этой задачи.
Наверное, все слышали про GraphQL и задумывались тоже о том, стоит не стоит брать, а какие есть трудности его внедрения.
В своем рассказе я хочу честно сравнить его с OpenApi, показать не абстрактную пользу, а конкретные преимущества, которые особенно ярко раскрываются, когда мы начинаем говорить о микросервисной архитектуре, где существенный буст в разработке приносит Apollo Federation
Я расскажу почему мы в Samokat.tech начали смотреть в его сторону, какую пользу он нам приносит.
Какую мы строим архитектуру. Какие блокеры были со стороны безопасности и эксплуатации, и как мы их преодолевали.
Программный комитет ещё не принял решения по этому докладу
Облачные технологии как тренд 2023 года, или как и зачем бизнесу внедрять подход Cloud Native?
1. Что такое монолит и почему стоит от него отказаться (плюсы и минусы)
2. Как перейти с монолита на микросервисы? Где будут основные проблемы и боли? Как их максимально избежать?
3. Почему стоит выбрать микросервисную архитектуру/ приватное облако.
4. Зачем бизнесу Cloud Native? (Масштабируемость, устойчивость, time to market, решение ключевых проблем пользователя)
5. Как этот процесс повлиял на команду и культуру в вашей компании?
Программный комитет ещё не принял решения по этому докладу
Шардирование рекомендательной системы
Я расскажу про историю архитектуры рекомендательной системы Дзена и как мы пришли к тому чтобы пошардироваться. Как мы пытались сделать распределенный item-to-item индекс а сделали вместо этого шардированный рекомендер и какой профит получили на сдачу. С какими проблемами нам пришлось столкнуться по пути, как балансируем данными чтобы не упереться в сеть и как маленькая деталь ML-кухни чуть не загубила всю идею.
Программный комитет ещё не принял решения по этому докладу
Как мы построили модерацию рекламы с нуля и достигли потока 1 млрд вердиктов в сутки.
* Из-за роста объема рекламных объявлений Яндексу требуется модерировать более 1 миллиарда различных объектов в день с минимальными задержками автоматических проверок порядка единиц секунд, при этом добиться высокого качества модерации.
* На входе у нас были две системы с неподходящими архитектурами для поставленных нами целей. Первая была написана на устаревших технологиях, что затрудняло развитие и масштабирование, а вторая батчевая система с не типизированными данными и множеством составных компонент, не укладывающаяся в требуемые тайминги.
В этих условиях было также сложно поддерживать качество вердиктов на достаточном уровне.
* Мы решили написать новую модерацию с нуля на основе стримингого фреймворка поверх YTsaurus.
* В результате мы полностью переехали на новую систему, по пути наткнувшись на множество проблем, которые не были видны со старта. В докладе будет рассказано с какими проблемами нам пришлось столкнуться и как мы их решили.
Программный комитет ещё не принял решения по этому докладу
Сервис автоматической разработки нейронных сетей - ANNA
Расскажем как мы пришли к тому, что большую часть рутинной работы DS можно автоматизировать. Опишем каким образом мы готовим все для этого: подготовка данных (Hadoop, PySpark, Airflow), инфраструктура для обучения моделей и их применения (k8s, Jenkins, MLflow). Подробно обсудим сервис ANNA (Auto Neural Network Analytics, основной стек: FastAPI, Vue, Postgres, RabbitMQ), который позволяет обучать модели и выводить их в промышленную среду без участия DS, и все что требуется это выборка для обучения. Затронем вопросы применения всего этого в реальных условиях с ограниченным количеством ресурсов.
Программный комитет ещё не принял решения по этому докладу
Распределенная трассировка с Jaeger и Clickhouse
МТС - это огромная экосистема продуктов, в которой каждую секунду происходят тысячи взаимодействий между компонентами. В 2019 году мы запустили внутренний сервис распределенной трассировки, чтобы помочь командам отслеживать ошибки в работе экосистемы. За это время мы прошли длинный путь, подключив 1000+ сервисов, научившись обрабатывать 150 тысяч спанов в секунду и несколько раз поменяв архитектуру решения.
В докладе я расскажу - как мы мигрировали с Elasticsearch на Clickhouse для хранения распределенной трассировки. Как на собственных ошибках нарабатывали экспертизу по Clickhouse и дорабатывали open source решения под наши нагрузки. Как дали возможность выполнять аналитические запросы к Clickhouse и строить дашборды по данным трассировки.
Доклад принят в программу конференции
Масштабирование пропускной способности поиска Яндекса в 4 раза
Мир постоянно меняется, Яндекс потерял кластер в Мантсале, поставки железа усложнены. Поэтому мы озаботились подготовкой к растущим нагрузкам при меньшем объеме железа
Мы расскажем:
* Как мы увеличили пропускную способность Яндекс Поиска в 4 раза, огромного продукта с десятками внутренних сервисов
* Как мы добились этого почти без использования дополнительного железа
* Как мы наладили процесс поиска узких мест
* Как мы оптимизировали кучу железа
* Какие проблемы мы нашли и решили в процессе масштабирования
* Какие механизмы деградации мы внедрили в процессе масштабирования
Программный комитет ещё не принял решения по этому докладу
Проектирование БД: От NF к денормализации данных
Когда я учился в университете нас учили проектировать БД с помощью нормальных форма(NF). Однако на работе я столкнулся с тем, что с ростом проекта, увеличения кол-ва данных этот подход работает медленно. Об этом я и хочу рассказать.
Я один из разработчиков edu.tinkoff.ru, которые строили платформу с самого начала.
Программный комитет ещё не принял решения по этому докладу
Сам себе вендор. Внедрение EVPN в VK Cloud
Облака - это не только независимая инфраструктура где-то в интернете. Это еще и непосредственные физические сетевые стыки с крупными клиентами прямо в их ЦОДах. Чаще всего, сети - это ответственность сетевых инженеров. А у них, обычно, все построено на вендорном железе. Но что делать в том случае, если привычных всем вендоров больше нет?
Поговорим о проблемах вендорных решений, использовании их на примере такой задачки как организация внешних стыков облака. Расскажем о том, как сделать то, что предоставляют вендоры из подручных материалов. Представим свою реализацию EVPN VTEP из стандартных opensource инструментов - OpenVSwitch, gobgp, Python.
Доклад принят в программу конференции
Лайфхаки проектирования высоконагруженных сервисов
Перед нами стояла задача добавить в Сбербанк Онлайн отдельный высоконагруженный (до 4000 tps) сервис по работе с депозитными и инвестиционными продуктами клиента. На примере данного сервиса расскажем и покажем, какие подводные камни возможны при проектировании высоконагруженных сервисов, какие лайфхаки следует применять, чтобы снизить нагрузку на бэкенд, и какие способы увеличения производительности бэкенда следует применять.
Программный комитет ещё не принял решения по этому докладу
Авито.Автозагрузка: от 4млн. до 80млн. активных объявлений. Как мы меняли архитектуру для поддержки роста х20
Автозагрузка это инструмент, позволяющий клиентам автоматизировать работу со своими объявлениями. Он состоит из множества сервисов и входит в топ-10 потребителей ресурсов в компании.
За все время существования мы привыкли к линейному росту - каждый год продукт увеличивался в 1,5-2 раза, но в 2021 году все изменилось. Для запуска важных продуктовых инициатив нам требовалось поддержать рост х20 и несмотря на то, что мы имели неплохой “запас прочности”, к таким цифрам мы не были готовы.
На Saint Highload++ 2023 я уже рассказывал, как мы готовили к росту один из наших сервисов - с какими проблемами столкнулись и какие архитектурные решения использовали для их устранения (https://highload.ru/spb/2023/abstracts/10416).
В этом докладе я буду говорить о том как мы решали проблему поддержки роста х20 уже на уровне всей компании и расскажу:
Как мы искали узкие места и потенциальные точки отказа среди десятков сервисов и компонентов, через которые проходит объявление прежде чем попасть на сайт.
О подходе к нагрузочному тестированию, который позволил нам за квартал справиться с задачей, которую мы изначально оценили в несколько человеко-лет.
Об основных проблемных местах в нашей архитектуре и решениях, которые помогли с ними справиться.
О концепте инструмента прогнозирования нагрузки и проактивного поиска проблемных мест, который в дальнейшем поможет нам заранее их исправлять.
Программный комитет ещё не принял решения по этому докладу
Зачем делать прожорливый софт. Архитектурные принципы построения распределённых систем
Мир не идеален - любая крупная система состоит из множества отдельных подсистем.
Не все из них мы можем контролировать при работе над нашей задачей.
А согласно закону Мёрфи - если что-нибудь может пойти не так, оно пойдёт не так.
Применительно к созданию распределённых систем это означает, что абсолютно всё вокруг когда-нибудь сломается.
И вот в таких условиях нам нужно разрабатывать софт, который не потребует постоянного внимания со стороны своего создателя.
Расскажем про практики и свой опыт создания софта с self-healing на принципах closed loop automation,
сравним с привычным в индустрии event-based подходом, и честно признаемся об увеличении накладных расходов и излишней трате денег работодателся в счёт своего спокойного сна ночью.
Программный комитет ещё не принял решения по этому докладу
Создание плагина к Trino (PrestoSQL) для высоконагруженной обработки и массовой аналитики данных в Apache Superset
В докладе поделимся опытом разработки и массового развертывания собственного плагина к Trino (PrestoSQL) на Java для эффективной замены Data Warehouse и построения масштабируемой системы BI-аналитики в Apache Superset на базе раcпределенного ANSI SQL движка запросов.
Программный комитет ещё не принял решения по этому докладу
Как эффективно ранжировать весь товарный рунет
Ранее наша команда рассказывала, как в товарном поиске Яндекса строится база: https://highload.ru/moscow/2022/abstracts/9515. А в этом докладе расскажем о рантайм и ML-части нашего поиска.
Поиск по товарам Яндекса — это сервис, работающий над базой из более, чем миллиарда документов под нагрузкой 3000 RPS. Казалось бы, разработка архитектуры поиска такого масштаба — понятная и решенная задача, но появление приставки ecom добавляет к общей схеме несколько существенных доработок. В этом докладе будет разобрана общая архитектура поиска и показано, что начинает меняться, как только мы начинаем думать о бизнес-специфике области: учет региональности, группировка офферов в модели, таргет для ML-моделей и других особенностях.
Доклад принят в программу конференции
Hazelcast, который смог: как получить молниеносный ответ на сотни запросов в секунду с использованием бесплатной библиотеки. От первых восторгов до хладнокровия.
Дано: распределённая сервисно-ориентированная система с сотнями пользовательских запросов в секунду.
Цель: получать молниеносный ответ на пользовательские запросы, без исполнения задач в IT-инфраструктуре. В докладе расскажем, как решали задачу с помощью бесплатной версии библиотеки Hazelcast. Почему выбор пал именно на неё, о первых восторгах, борьбе со скудной документацией, набитых шишках и выстраданных рецептах.
Внутри доклада:
— Подходы к работе с обработкой запросов в микросервисной архитектуре.
— Варианты доступных на рынке решений (Redis, Hazelcast, Apache Ignite, Memcached).
— Опции Hazelcast: критерии выбора Open-source vs Enterprise.
— Опыт использования: примеры проблем и рекомендации.
— Границы применимости бесплатной библиотеки Hazelcast.
Доклад принят в программу конференции
Путь осилит идущий. Миграция Антиспама Почты Mail.ru в k8s
Антиспам почты mail.ru ежедневно в режиме реального времени проверяет более 400 млн. писем в сутки. Ключевой целью нашей команды является качественная и быстрая защита пользователя от нежелательного контента в формате 24/7. Но как этого можно достичь, когда железная инфраструктура может выйти из строя, деплой сервиса может затянуться из-за очереди на выкатку, а резко пришедшая нагрузка может существенно сказаться на скорости проверки писем? Ответ для себя мы нашли во внедрении kubernetes . Сейчас антиспам в kubernetes это более 2000 подов и порядка 10000 ядер. Но так было не всегда....
В рамках своего доклада я хочу провести вас по тернистому пути, который преодолела наша команда при миграции ключевых систем Антиспама в k8s.
В ходе выступления я коснусь следующих тем:
* Более детально расскажу, как мы решили заезжать в k8s
* Как решали вопрос балансировки нагрузки
* Какую трансформацию пришлось пройти нашему монолиту, чтобы стать stateless
* Как мы учились проводить A/B-тесты для ML моделей и спам-сигнатур в условиях k8s
* Про то как незаметно для пользователя переключали нагрузку
* Как мы проверяем отказоустойчивость системы
* Проведу небольшую ретроспективу процесса миграции
Программный комитет ещё не принял решения по этому докладу
Слишком…много…асинхронщины…На что обращать внимание при работе с фичей из десятка сервисов, обрабатывающих 15 000 асинхронных задач в секунду
В клиент-серверной архитектуре каждый разработчик рано или поздно сталкивается с обработкой асинхронных задач. Это частая практика, но что делать, когда вы разрабатываете новую фичу, которая становится настолько прожорливой, что таких задач становится десятки тысяч в секунду. На примере внедрения в Яндекс.Go новой технологии Live Activity от Apple поговорим про:
* Сложность отладки и поиска проблем асинхронных задач
* Почему не нужно пытаться брать слишком много задач на каждую ноду
* Как быть если асинхронность добавляется еще и на клиенте
* Почему в таких случаях не стоит пользоваться вашей основной базой данных
* Как держать ваше состояние консистентным без возможности сервисам сообщать о своем состоянии друг другу
* Зачем нужно иметь возможность конфигурировать выполнение таких задач
Программный комитет ещё не принял решения по этому докладу
SberAds: современные технологии в legacy продукте
Часто так бывает, что бизнес живет с небольшой командой разработчиков достаточно долгое время. Нагрузки держатся на стабильном уровне, изменения редки. В результате отказы бывают редко. И вот, в один прекрасный день этот бизнес покупается крупным инвестором. Нагрузка начинает расти как на дрожжах, а накопленный годами технический долг приходится оперативно решать, чтобы и дальше успешно избегать даунтаймов. И, самое главное, бизнес требует наращивать функциональность, а не только решать технический долг.
В докладе я хочу осветить как нынешний SberAds вырос из кодовой базы, созданной еще в begun.ru, а затем долгое время жившей в Рамблере. Сейчас, когда у нас огромные планы роста, мы модернизируем наш технологичесий стек. Я расскажу как мы:
- стали переходить на Go;
- перемещаем старые сервисы в Kubernetes;
- внедряли istio и какую пользу получили от этого;
- интегрировали jaeger;
- стали использовать tarantool;
- заменили самописные "сокеты на стейройдах" на kafka;
- стандартизировали мониторинги;
- и, самое главное, стали горизонтально масштабируемыми.
Программный комитет ещё не принял решения по этому докладу
Контроль управление api компании через apigateway - достойное решение или лучше разработать самим?
Всё чаще интеграции в компаниях реализуются посредством API с использованием форматов, вроде JSON или SOAP. В мире микросервисной инфраструктуры, часто, микросервисы имеют свой SWAGGER с описанием всех методов и бизнес функций сервиса. Это не плохо, когда таких сервисов десятки и можно превентивно управлять их жизненным циклом, разделяя окружения по namespace k8s или кластерам. В данном случае у Вас каждый микросервис - это независимая единица, которая имеет свой жизненный цикл и может быть опубликована для партнёров через точку балансировки.
А что делать, когда сервисов становиться больше? Что делать, когда бизнес заказчики хотят не просто публикуемый endpoint сервиса на балансировщике, но и управлять этой публикацией, параметрами подписок партнёров, добавляя документацию, контакты, условия работы с сервисом? И тут мы подходим к интересному классу инструментов, который называется - api gateway.
Рассказ пойдёт о том, как мы решая проблемы бизнеса по публикации управляемого api сервисов для партнёров, внедрили единый инструмент управления API и стали его использовать и для других нужд.
Каких спросите Вы? Приходите на доклад и узнаете!
Программный комитет ещё не принял решения по этому докладу
От CRM к DataLake с K8s и Микросервисами
Как только система начинает разрастаться, появляться различные внешние и внутренние сервисы с которыми необходимо реализовывать интеграции. Появляться задачи по построению аналитики или построению предиктивных моделей, а система не позволяет это делать без нагрузки? Или необходимо масштабировать систему? Ответом на эти вопросы будут микросервисы, которые помогут реализовать всю необходимую логику. Как в этом помогает Kafka и Airflow и что такое ETL. Все это поможет построить хорошую архитектуру, которую можно будет масшабировать и к которой можно подключать неограниченное число интеграций и в внешних сервисов
Программный комитет ещё не принял решения по этому докладу
BPMN сервис. Как на сервисе весом в 10ТБайт ежедневно обрабатывать 1Тбайт пользовательских данных и спать спокойно
В докладе расскажем, как устроена компания Магнит изнутри. Откроем некоторые секреты про то, какие существуют бизнес-процессы и как они автоматизированы. Поделимся практическим опытом обуздания высокой нагрузки на примере одной из 829 учетных систем компании Магнит, в частности, будет подробно рассмотрен один из ее компонентов: Сервис обработки схем в нотации BPMN
- Общий обзор ит-архитектуры компании Магнит
- Роль и структура подсистемы управления ассортиментом
- Что такое сервис обработки схем в нотации BPMN и на решение каких задач он направлен
- Обоснование выбора технического решения
- Первая итерация реализации BPMN сервиса
- Вторая итерация реализации BPMN сервиса
- Анализ ошибок, выводы и что будет в третьей итерации
Программный комитет ещё не принял решения по этому докладу
5 новых способов использовать данные в вашей Kafka
Хотите получить крутой дашборд, который меняется каждую секунду? Или вам может быть вам интересно, опреедять является ли операция мошенничеством в реальном времени? Или вы просто хотите быстро и надежно отобразить клиенту ленту его операций?
Все это можно легко сделать, если ваши данные есть в Kafka. А про то, как можно данные в Kafka поставить, как их можно между собой джоинить и как потом визуализировать, я расскажу в своем докладе.
Как product owner стриминговой платформы в Raiffeisen Bank, я расскажу, как мы используем нашу платформу для всех этих целей, покажу реальные примеры кода и поделюсь граблями, на которые на пришлось наступить.
Программный комитет ещё не принял решения по этому докладу
Петабайтный стейт процессингов Метрики в YDB и S3
Речь пойдет про то, как мы пришли к идее "медленного" стейта, построенного на HDD дисках вместо SSD, откуда взялся порядковый рост размера и почему HDD для этой задачи вполне подходят. Расскажем про грабли и как мы с ними боролись, а также про то, какие новые возможности мы благодаря всему этому получили.
* Кратко расскажем про процессинги аналитических продуктов и как устроен в них стейт
* Нагрузки и требования
* Как мы пришли к порядковому росту размера стейта (с 100 терабайт до петабайта)
* Как мы на этом сэкономили
* Какие были варианты
* Какие были трудности при записи и при чтении
* Ложка дегтя в смысле загрузки ресурсов
* Как мы выбираем, куда поместить данные и как именно мы это делаем
* Как мы управляем этим стейтом
* Как мы справляемся с нагрузкой (12gbit/sec)
Программный комитет ещё не принял решения по этому докладу
Внутри S3
Яндексовая инсталяция хранилища S3 хранит миллиарды файлов. Это огромные объемы данных, а также огромные объемы метаданных. Для хранения метаданных используется множество шардов postgres. Мы научились использовать умное шардирование, мы сами управляем распределением занятого места и нагрузкой между шардами. Расскажу, как сделать так, чтобы ни один клиент даже с самым неудобным паттерном нагрузки не приложил ваш сервис.
Программный комитет ещё не принял решения по этому докладу
Как подружить Zeus с Prometheus. Мониторинг Богов
- Как мы сделали мониторинг узкопрофильных процессов и потребностей команд удобным?
- Как сделать алерты безопасными, но понятными?
- Как из простой интеграции мы сделали легко масштабируемый микросервсиный мониторинг, попав в тему с импортозамещением? Путь в ИТ компанию
Программный комитет ещё не принял решения по этому докладу
Как нам помогает Low code в разработке Control plane PaaS облака
Всем нужны платформы для организации своей разработки, чтобы повысить управляемость зоопарком технологий, упростить поддержку своих сервисов (особенно микросервисов), стандратизировать решение одних и тех же задач при запуске каждого нового сервиса.
Мы в 1С уже очень давно строим платформы для своих пользователей.
И конечно, при создании своего PaaS облака, при разработке его Control plane не могли пройти мимо соблазна использования своей технологии.
* Что за облако и для кого
* Наша технология
* Технология 1С:Элемент для создания веб и мобильных приложений
* Что мы получаем
* Поддерживаемость, которую дает платформа
* Без boilerplate и вообще велосипедов решенные куча задач
* С пагинацией
* С правами доступна
* С поиском
* С BI (!)
* Причем, не только “business” , но и вообще
* С локализацией
* С работой на мобильных
* И… много чего еще
* Что классного
* Получаешь фичи вместе с платформой — это магия
* Сама технология обкатывается на большом сложном приложении
* Что сложного
* Сложно с многопоточностью
* Привыкаешь к подходу “сначала сделаю в платформе, потом тут” — это не всегда хорошо
* Не совсем целевая задача — много где первопроходцы
Программный комитет ещё не принял решения по этому докладу
Full chaos аналитика: тренды системного анализа в эпоху ML
Работая над SaluteSpeech(синтез и распознавание речи), а затем еще и с GigaChat(gpt-like), я понял, что хочу поделиться своим опытом работы с крупными ML-based проектами. Доклад посвящен актуальным проблемам системного анализа в условиях хаотичного и стремительного развития продуктов на базе ML технологий.
Затронем следующие вопросы:
- Как собирать требования, когда они устаревают быстрее их проработки?
- Что может помочь говорить с бизнесом и ML-разработкой на одном языке?
- Зачем вообще системная аналитика в ML и что она может дать?
Программный комитет ещё не принял решения по этому докладу
Multi-tenancy в условиях виртуального хостинга
Виртуальный хостинг в нашей стране не развивается на протяжени десятилетий, менялись технологии, стек, размещаемые данные.
Но это как был linux сервер с отдельными пользователями, так и остается. Провайдерам остается только работать на стабильность и экономическую эффективность.
За это время сложились практики и механизмы, которые отлично себя показали в вопросе справедливого распределения вычислительных ресурсов сервера и изоляции пользователей друг от друга.
Внедрение чего-либо нового в подобной multi-tenancy всегда предъявляет специфические требования к решению:
1. Изоляция на уровне пользователей
2. Потребление ресурсов системы только на время использования
3. Малое потребление ресурсов
На примере нового файлового менеджера продукта виртуального хостинга расскажем как мы внедряем новые функции в условиях multi-tenancy виртуального хостинга
Программный комитет ещё не принял решения по этому докладу
Алиса 6 лет спустя
Алисе исполнилось 6 лет. Это надежный высоко нагруженный сервис с десятками миллионов пользователей в месяц, который каждые несколько лет приходится переписывать, чтобы развивать дальше. Я расскажу о том, как в 2023 году мы снова переписываем Алису т.к. появление больших языковых моделей, YaGPT, не может оставить ее в стороне. Поговорим о том, какие архитектурные изменения приносят с собой языковые модели, и как можно внедрить их в рантайм такого гиганта, как Алиса.
Доклад принят в программу конференции
Как грузить в мониторинг 8 гигабайт метрик в секунду и ничего не проливать
Yandex Monitoring используется всеми сервисами Яндекса внутри, а также доступен в Яндекс.Облако для внешних пользователей. Мы обрабатываем 700 миллионов метрик на запись ежесекундно.
У каждого клиента есть конфигурация процесса загрузки метрик. Эта конфигурация объединяется в шард.
Балансировщик распределяет шарды в кластере, чтобы утилизировать ресурсы. Но есть очень большие шарды, которые мы не успевали обрабатывать, и теряли данные. Просто создать больше шардов нельзя, потому что это значит ручную работу для пользователей. К тому же есть уже существующие шарды. Поэтому мы сделали партиционирование для шардов.
В докладе:
* Шардирование и балансировка нагрузки;
* Партиционирование метаданных;
* Партиционирование потока записи;
* Выбор ключа партиционирования и подводные камни;
* Подходы к автопартиционированию в БД и не только;
* Как делаем автопартиционирование мы, что пробовали;
Программный комитет ещё не принял решения по этому докладу
Импортозамещение (2)
Миграция витрины данных с СУБД Teradata в СУБД Greenplum
Миграция СУБД с одной технолгии на другую достаточно сложный процесс, который связан не только с ковнвертацией кода и переливкой данных, хотя и здесь есть неочевидные ньюансы. В своем докладе я хочу рассказать об одном опыте миграции витрины данных с СУБД Teradata на СУБД GreenPlum, задачи которые приходилось решать в процессе этой миграции и те подводные камни на которые мы периодически натыкались.
Доклад принят в программу конференции
Веб-сервер Angie год спустя: новые возможности и планы на будущее
В июле 2022 года, собрав команду из ведущих инженеров, работавших над разработкой и поддержкой веб-сервера nginx, мы открыли свою компанию — «Веб-Сервер» и начали разработку Angie — российского веб-сервера с открытым исходным кодом.
- Какие новые крутые возможности появились в веб-сервере Angie, отечественном форке nginx
- Коротко пройдем по инфраструктуре, которая была развернута для поддержки пользователей
- Поговорим о будущем, наших планах, чего ждать в ближайшее и может быть не самое ближайшее время
Информативно. По делу. Отчет за год, без лишней воды.
Доклад принят в программу конференции
Оффтоп (4)
Автоматизация сетевой инфраструктуры ЦОД
На просторах интернета много информации о том, как автоматизировать сеть офиса или как за три секунды раскатить типовую конфигурацию на новое железо. Мы же прошли через автоматизацию сетевой инфраструктуры одного из самых старых ЦОДов России (наша площадка ОСТ открылась в 2009 году). Расскажу о том, что мы предприняли чтобы начать автоматически конфигурировать услуги на проде и при интеграции не допустить перерыва сервиса для более чем восьмиста клиентов, какие проблемы нам удалось решить и почему в какой-то момент приняли решение начать всё заново.
Доклад принят в программу конференции
Это всё, что останется после меня: проблемы наследования программного кода и передачи прав на него
Спикер расскажет о коде как объекте интеллектуальной собственности, переведёт с законодательного на человеческий язык сложные юридические конструкции, расскажет о реестрах кода, рассмотрит варианты передачи прав на код для сотрудников по найму и на фрилансе, а также нюансах наследования кода.
Доклад принят в программу конференции
От дощечки к компьютеру. Путь от ткачества к ЭВМ
Невозможно однозначно судить о времени зарождения искусства и ремесел, корни которых теряются в глубине тысячелетий, а материальные следы непрочны и недолговечны. Но можно попробовать проследить одну из ветвей развития человечества, которая привела к созданию компьютеров и дальнейшему их повсеместному распространению.
На встрече расскажу о развитии такого ремесла как ткачество (процесс переплетения нитей и создания ткани), в результате оптимизация которого был создан ткацкий станок с перфокартами… а там и до ЭВМ пара шагов: вычислительная машина Бэббиджа, язык Ады Лавлейс для её программирования, калькулятор Шойца, табулятор Холлерита, аналоговый компьютер Буша и машина Тьюринга, ну а дальше семимильными шагами в 21 век.
Также можно будет попробовать работать с ткацкими инструментами и за станком.
Доклад принят в программу конференции
Математический хайлоад: большие, очень большие и немыслимо большие числа
Задумывались ли вы когда-нибудь, что значит вся эта наша «биг дата» в масштабах математики? Насколько миллиарды пользователей и терабайты данных далеки от по-настоящему «биг» величин?
Мы с вами увидим, что такое по-настоящему большие числа — числа, которые неподвластны осознанию, на которых ломается математика. Мы рассмотрим, какими нотациями они записываются, какой смысл имеют и как быстро они растут.
Мы начнём с приземлённых вещей, имеющих понятный смысл, и устремимся вверх, оттолкнёмся от числа Грэма, доберёмся до самого большого числа, имеющего название, дойдём до границы вычислимости, но пойдём дальше, по невычислимым полям, до понятия бесконечности, перешагнём и её, за ординалы, за пределы применимости аксиом — до самого конца математического безумия. И только там обнаружим, что это самое начало человеческого воображения, и границы наших с вами возможностей ещё бесконечно далеки.
Доклад принят в программу конференции
Хардкор (2)
Расширение возможностей отладчика GDB при помощи Python
Довольно часто при разборе проблем с проектами в контурах заказчика мы сталкиваемся с необходимостью использовать отладчик. Одним из типичных сценариев является, например, падение, при котором генерится coredump, и в дальнейшем мы используем его, чтобы разобраться с причиной падения. При этом у нас нет возможности использовать код самого Tarantool, а некоторые типовые для Тарантула действия просто неудобно делать, если использовать только базовый функционал отладчика.
К счастью, в отладчике предусмотрен механизм, с помощью которого можно расширить его возможности и упростить отладку. К тому же, зачастую, по соображениям безопасности, мы не имеем прямого доступа собственно к "корке" и вынуждены работать с ней удаленно, что также требует максимального упрощения взаимодействия с отладчиком для минимизации ошибок.
В частности нам нужен удобный способ, для:
- работы с файберами: список, стэк вызовов произвольного (не текущего) файбера
- работы с различными списками: итерирование, просмотр/поиск элементов
- просмотра msgpack с тарантульными расширениями
- просмотра тапла и его формата
- различных манипуляций с виртуальной машиной LuaJIT
Доклад принят в программу конференции
Exception Handling: сквозь мультивселенные интероперабельности
Tarantool -- это платформа для in-memory-вычислений, написанная на C/C++ и Lua. Миры Lua и С/C++ очень тесно связаны: у Tarantool есть модули на Lua, модули на Lua могут использовать модули, написанные на C/C++. В процессе исполнения и в Lua коде, и в C/C++ коде могут возникать исключения, которые иногда необходимо обрабатывать в другой компоненте, может быть написанной на другом языке.
Доклад рассказывает о том, как можно реализовать интероперабельность исключений между двумя языками на примере Lua и C. Разберемся в том, какие есть способы реализации механизма исключений на разных платформах, посмотрим на специфичные для них сложности, а также рассмотрим реализацию интероперабельности на примере LuaJIT, с помощью которого исполняется весь Lua код в Tarantool.
Доклад принят в программу конференции
Platform Engineering (10)
Как мы делаем трейсинг в условиях тысяч сервисов и миллионов спанов в секунду
Поговорим о трейсинге в Авито: какую он задачу решает и как у нас выглядит архитектура трейсинга, обрабатывающая миллионы спанов в секунду от нескольких тысяч сервисов, объединенных в service mesh (который, как оказалось, помогает). Расскажем, как мы меняли подходы к семплированию данных и почему мы ушли от Jaeger к OpenTelemetry и собственному инструменту, объединяющему трейсинг, логи и метрики.
Рассмотрим примеры из нашего опыта, когда трейсинг ускоряет нахождение проблем и отладку в распределенной среде, и попробуем ответить на вопрос «зачем нужен трейсинг и какая цена у его внедрения»?
Доклад принят в программу конференции
Высоконагруженная VDI из OpenSource для платформы киберучений «CyberCamp» в облачном Kubernetes
Для проведения Cybercamp (это созданная нами платформа киберучений, где участники выполняют задания в формате CTF) необходимо было предоставить доступ к платформе (создать рабочие места, изолировать команды друг от друга, выдать необходимые сетевые доступы) 500 участникам. Эти рабочие места содержат в себе целый арсенал инструментов для отработки навыков Red и Blue Team.
Для экономии ресурсов и улучшения управляемости мы упаковали эти рабочие места в контейнеры и расположили их в Managed Kubernetes от Яндекс.Облако, а доступ из браузера организовали с помощью Guacamole. Я расскажу, как мы обеспечивали безопасность, что еще расположили в Kubernetes, и почему была выбрана именно контейнеризация с использованием оркестратора, а не виртуализация.
В результате нам удалось 2 года подряд проводить киберучения без инцидентов ИБ и каких-либо простоев, затрачивая минимум усилий на поддержку мероприятия во время его проведения.
Доклад принят в программу конференции
Управление ожиданиями от платформы
Итак, у вас есть платформа. Всё работает, но от пользователя регулярно хотят странного и присылают странные тикеты.
А всё потому что ваше представление о платформе и их ожидания не совпадают.
Я расскажу о том,
откуда берутся ожидания пользователей,
как ими управлять,
что такое контракты и как их писать
и многое другое.
Доклад принят в программу конференции
Межсервисная авторизация в Авито.PaaS
Расскажу как мы внедрили межсервисную авторизацию на базе Open Policy Agent для более чем 2000 сервисов, работающих на PaaS и при этом не сломали прод и сознание разработчиков от написания авторизационных политик на языке rego. Мы обеспечиваем стабильность работы описываемого решения в нашем service mesh в продакшене, даем возможность управлять доступами вплоть до каждого endpoint-а, и избегаем поломок из-за случайного некорректного закрытия доступов.
Доклад принят в программу конференции
Как сделать платформу удобной или Авито PaaS спустя 5 лет
В последние годы многие компании и команды внедрили devops подход, который позволяет владеть полным жизненным циклом разработки без необходимости что-то дополнительно запрашивать у платформенных/инфраструктурных команд. В то же время уровень сервиса, удобство и возможности, которые предоставляются в продуктовые команды, очень сильно варьируется.
Мы поговорим о парадигмах и подходах, которые позволяют построить удобную и эффективную платформу, решающую потребности бизнеса. Посмотрим какие ключевые идеи лежат в основе Авито PaaS и с помощью каких технологий их получается реализовывать.
Пройдем по самым востребованным направлениям и проблемам в рамках SDLC, посмотрим какой уровень сервиса можно предоставлять на каждом этапе жизненного цикла. Какая архитектура и подходы позволяют масштабировать платформу по функциональности.
Доклад принят в программу конференции
Как мы управляем трафиком тысяч подов в мультикластерной среде Kubernetes с помощью Service Mesh.
Спойлер - никак :) Но мы умеем обеспечивать прозрачное сетевое взаимодействие подов во множестве кластеров Kubernetes так, как будто все они размещены в одном огромном "суперкластере". Мы используем Istio, но не используем Istio Multicluster. В докладе я расскажу, как все это работает.
Доклад принят в программу конференции
Внутренняя платформа для разработки и разработчиков: за что платит бизнес?
Основные тезисы
Представим, что вы предприимчивый лидер инженерной команды, которая предоставляет зрелую платформу для разработчиков широкому кругу команд в вашей компании. Компания достаточно большая и быстро растет, затраты на платформу становятся видны на основных финансовых радарах. Продукты компании являются или претендуют на то, чтобы быть самостоятельными бизнесами, в любом случае их волнует их собственный P&L. В этот самый момент вы можете столкнуться некоторыми из нижеперечисленных проблем:
- Потребители не знают, во сколько им обходится платформа. Рассматривают ее как условно бесплатное образование и медицину в СССР, с соответствующим отношением – не вдумчивым потреблением.
- Руководство компании не знает как гибко контролировать траты на платформу, на каких потребителей нужно создавать давление и какое.
- Потребители создают давление на платформу вида «перееду во внешнее облако, там лучше и дешевле»
- Руководитель платформы сталкивается со сложностями в обосновании роста команды платформы, каждый раз приходится искать новые аргументы
- Если потребители – самостоятельные бизнесы – то у них возникают сложности с расходными статьями в P&L.
В рамках доклада мы рассмотрим подход, который позволит перевести вашу платформу на новый уровень зрелости продукта, из состояния «всем все бесплатно» в состояние вдумчивого и экономного потребления с гибкой и прозрачной системой затрат. Рассмотрим техническую реализацию на примере Яндекса и обсудим варианты экономических моделей.
В моем докладе вы узнаете:
- Что такое Yandex Infrastructure и Yandex platfrom engineering, кто ее потребители и какую задачу мы решали
- Зачем брать деньги с пользователей, за что и когда целесообразно начать это делать?
- Платформа это cost center, profit center или что-то посередине
- Модель аккаунтинга – как выявить потребителя и построить иерархию потребления
- Модель тарификации – SKU, сколько стоит железо и люди. CAPEX или OPEX?
- Люди и железо – какие драйверы изменений?
Программный комитет ещё не принял решения по этому докладу
Опыт пилотирования контейнерных платформ
В докладе расскажу про наш опыт пилотирования контейнерных платформ. Что хочет закачик от контейнерной платформы, какие сложности возникают при внедрении в существующую enterprise среду и про то, что не все серверы созданны равными.
Программный комитет ещё не принял решения по этому докладу
Сколько стоит платформа?
Представим, что вы лидер инженерной команды или амбициозный инженер, который понял ценность platform engineering-а для своей компании. У вас возникла идея начать работу над внутренней платформой разработки, но вы осознаете необходимость инвестиций в эту активность со стороны руководства.
В моем докладе вы узнаете:
- технологические составляющие платформы;
- экономические составляющие платформы;
- как выбрать базовую стратегию обоснования необходимости PE для своей компании;
- модели развития платформы в зависимости от инвестиций;
- проблемы при масштабировании платформы и пути их решения;
- платформа, обязательная к использованию или по желанию команд: как лучше?
- как сравнить жизнь с платформой и без нее;
- как сделать внутренних клиентов вашей опорой перед руководством;
- кейсы из опыта MOEX Group: как мы строим единую отказоустойчивую платформу для всех компаний Группы.
В конце доклада у вас будет четкое понимание как защитить необходимость платформы не лозунгами, а конкретными цифрами именно для своей компании. Кроме этого, еще одна цель доклада состоит в формировании нового в индустрии инженерного мышления, которое направлено на основные аспекты бизнеса, клиентоориентированности, организационно-культурного состояния и технологической зрелости компании.
Программный комитет ещё не принял решения по этому докладу
Проще, удобнее, быстрее: переход на NX монорепозиторий при разработке UI-кита
1. Как полирепозиторный подход к организации кода приводит к dependecy hell в бизнес-приложениях и почему
это проблема, с которой нужно бороться?
2. Как снизить порог вхождения в разработку внутренней библиотеки компонентов для новых сотрудников?
3. Как монорепозиторный подход к организации кода помогает облегчить поддерживание большой кодовой
базы?
4. Как использование NPM Workspaces позволяет снизить количество потребляемой ПЗУ при установки
зависимостей большой кодовой базы?
5. Почему использование NX в качестве системы сборки это отличный выбор?
Программный комитет ещё не принял решения по этому докладу
Open Source (6)
Как разрабатываются свободные проекты в команде ALT?
ALT Linux Team - это международная команда разработчиков, объединённая вокруг репозитория свободного ПО - проекта Сизиф. Ключевая особенность деятельности команды ALT заключается в открытом подходе к разработке. Все, в том числе и проприетарные, продукты компании "Базальт СПО" - дистрибутивы семейства Альт - поставляются в исходном коде, а составляющие эти продукты компоненты доступны по свободным или открытым лицензиям (за исключением закрытых драйверов и программных решений некоторых известных компаний).
- Где и как можно встретить наработки команды ALT?
- Какие свободные проекты разрабатывает команда ALT для корпоративных задач?
- Как, вообще, работает модель разработки "бесплатных" программ с точки зрения разработчика?
Программный комитет ещё не принял решения по этому докладу
Дракон наносит ответный удар: создание специализированных дистрибутивов ОС для Embedded/Edge устройств на китайских СПО решениях
В 2021 году Китай опередил США по плотности внедрения технологий автоматизации и роботизации с более чем 243.300 установок/проектов показав рост в 44% по сравнению с 2020 годом. Примечательно, что все эти проекты реализованы не только на отечественной аппаратной базе но и программной и , в большинстве случаем, речь идет о кодовой базе проекта openEuler.
В нашем докладе мы расскажем о ведущих решениях СПО из Китая, которые используются для разработки специализированных дистрибутивов операционных систем для Embedded и Edge устройств. Также мы поделимся практическим опытом создания дистрибутивов для устройства Outdoor Box Nano от российского вендора Combox Technology и специализированного одноплатного компьютера FriendlyELEC NanoPi M4.
В докладе мы рассмотрим:
1. Технологические возможности кодовой базы дистрибутива OpenScaler для создания Embedded и Edge устройств. Мы расскажем о поддержке фреймворка Yocto, который позволяет создавать дистрибутивы операционных систем размером от 5 МБ и поддержке ROS/RTOS а также DsoftBus.
2. Представим процесс создания специализированного установочного IMG файла дистрибутива. Расскажем о шагах, необходимых для его создания.
3. Обсудим особенности установки специализированного дистрибутива и решения возникающих проблем В частности с выбором варианта загрузки, как Android или как PC. Настройки 3D ускорения и другие аспекты, такие как ядро, DTS и прошивки.
4. Наконец, мы представим законченное устройство, созданного с использованием специализированного дистрибутива. Продемонстрируем его функциональность и возможности.
Программный комитет ещё не принял решения по этому докладу
Open-Source AppSec Review: как сделать приемку, внедрение и харденинг open-source решения
Open-Source продукты с каждым годом все сильнее входят в нашу жизнь и активно двигают индустрию вперед. Без ряда решений уже сложно представить современную индустрию - Kubernetes, OpenStack, Prometheus, Grafana и еще множество подобных продуктов различного масштаба и выполняемых задач. Вокруг многих из них существует комьюнити. Однако далеко не весь код, хранящийся в open-source на различных git-платформах хорошо изучен и активно разрабатывается.
Очень важно не только добавить новый компонент в свою систему, но и убедиться в том, что он не принесет в нее новых бэкдоров и уязвимостей. В докладе мы расскажем вам:
+ как сделать ревью и приемку open-source решения
+ как сделать его харденинг
+ какие решения можно использовать для сканирования на уязвимости
+ дадим чек-лист по приемке open-source компонента на "боевое дежурство"
Программный комитет ещё не принял решения по этому докладу
Дракон наносит ответный удар: построение высоконагруженной системы контейнерной виртуализации на китайских СПО решениях iSula и NestOS
В нашем докладе мы расскажем о результатах исследования контейнерной виртуализации на СПО решениях от ведущих китайских сообществ разработчиков. Эти решения уже сегодня широко используются крупнейшими технологическими гигантами Китая и предлагают уникальные технологические преимущества по сравнению с классическими Docker и Podman.
Мы расскажем вам, про:
1. Систему контейнерной виртуализации iSula и результаты ее нагрузочного тестирования в сравнении с Docker и Podman при 10/100/1000 последовательном и параллельном запуске контейнеров.
2. Особенности специализированного «облачного» дистрибутива NestOS для контейнерной виртуализации. Из отличительных особенностей данного дистрибутива стоит отметить его минималистичность. Так, размер iso образа NestOS составляет всего чуть более 700 Мб, а установленная система занимает меньше 10 Гб.
Программный комитет ещё не принял решения по этому докладу
Как вложиться в open source и не прогореть?
В основе наших сервисов лежит open source распределенная база данных - Apache Ignite, точнее наш продукт на ней основанный.
Для обеспечения гарантий быстродействия, нашим кастомерам потребовалось хранить как можно больше данных в оперативной памяти и мы доработали наш продукт. Пошли мы по пути компромиса между донейшеном в open source и приватной фичей и получили плюсы от обоих подходов.
В докладе пройдем весь путь от постановки задачи до ее решения - разработки механизма сжатия данных в памяти. Разберем все варианты реализации сжатия данных в Apache Ignite, включая уже существовавшие, проанализируем подводные камни и бонусы каждого из вариантов, в том числе неожиданые.
Программный комитет ещё не принял решения по этому докладу
Качество и контроль в большом OpenSource проекте
Проект вырос, окреп, популярен. Планы были амбициозные. Мы это сделали. А вот поддерживать и развивать... как?
Про то, как эффективно управляться с популярным проектом при недостатке ресурсов. Что заменить автоматикой, где нужны регламенты, где лучше работает доверие.
Всё на примере популярного PHP-фреймворка Yii.
Программный комитет ещё не принял решения по этому докладу