AvitoTech передаёт привет и ждёт в зале и на стенде.

В зале с докладом: «Opentelemetry и эволюция распределенного пайплайна трейсинга в Авито» —бэкенд-разработчик Сергей Ларионенко.

На стенде с целой командой: инженеры, техлид и IPM-менеджер. Все те, для кого хайлоад — стиль жизни.

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

Реклама ООО «Авито Тех» erid: LjN8KHnyB

Ждём вас с 14:00 у Фестивальной зоны, чтобы подарить мерч Saint HighLoad++ 2024 😎

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

🖐 Ловите анонс докладов, которые начнутся в 14:50
⠀
🏰 «00 Зал - Башня». Streaming Processing на данных BigData для рекламных кампаний МТС. Евгений Ненахов (МТС Диджитал)

Вы узнаете, как делать процессинг очень больших потоков данных в режиме реального времени из Kafka на голой Java с использованием минимального количества железа.
⠀
🔘 Зал «08 Шатер Голубой». Opentelemetry и эволюция распределенного пайплайна трейсинга в Авито. Сергей Ларионенко (Авито)

Opentelemetry — де-факто стандарт современной телеметрии. Сергей Ларионенко расскажет о подводных камнях при построении распределенного пайплайна трейсинга, какие модули пришлось переписать, чтобы собирать 14 млн спанов в секунду с 2к микросервисов почти без потерь. Много деталей, очень интересно!
⠀
🔹 «03 Зал Синий». Чего не хватает обычному сервису, чтобы стать cloud-native. Дмитрий Некрылов (Яндекс 360)

Как встроить в платформу или облако сервис, который по дефолту для этого не был рассчитан? Дмитрий расскажет о том, как встраивали Jitsi в Яндекс 360, обеспечивали много девяток и отказоустойчивость под нагрузкой и встреченных подводных камнях на этом пути.
⠀
🟣 «04 Зал Красный». «А так можно было?» — обзор нестандартной криптографии в применении к практическим задачам. Сергей Прилуцкий (MixBytes)

Изучите передовые криптографические алгоритмы, решающие реальные задачи. Узнайте, как они могут быть полезны для вашего проекта и внести вклад в развитие вашей работы.
Сергей расскажет теорию и представит примеры их применения в реальных технических задачах.
⠀
🟢 «06 Зал Зеленый». Highload MLOPs: ускорение и автоматизация. Павел Николаев (Альфа-банк)

Доклад будет интересен широкой публике ML-разработчиков. Из доклада вы узнаете, как в условиях ограниченных вычислительных ресурсов может выживать большая DS-команда. Также вы узнаете, как на небольших серверах оптимально крутить не менее 300 моделей.
⠀
🔵 Зал «09 Шатер Фиолетовый». Оптимизация баннерного демона в условиях резкого роста нагрузки. Артем Букин (VK, VK Реклама)

Арбитраж рекламы — технически сложно. Сотни тысяч рекламных компаний и только 40 миллисекунд, чтобы найти лучшее объявление. Спикер из VK расскажет, какие технические приемы применила команда разработки, чтобы справиться с ростом нагрузки, который увеличил количество серверов до 1500.

🔸 Зал «07 Шатер Оранжевый». Как продакту инфраструктурного софта через телеметрию познать клиента. Аркадий Велькер (erlyvideo)

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

#Highload Иван Чернов (Островок). Как работать с поставщиками на примере поиска доступных отелей. Чем отличается Островок от Букинга? В силу своей позиции на рынке букинг может от отелей потребовать работать в своей админке, описывать там условия отелей, и резервирование проводить внутри. А еще у него каждый отель представлен однократно. Хотя у каждого отеля есть своя система управления номерами, они очень разные, но проблемы интеграции их с букингом он отдает отелю. Островок сейчас работает как агрегатор, отели продаются через разные каналы, островок все это забирает и предлагает наиболее выгодные цены. В им надо при резервировании получать подтверждение отеля. А еще им важно кешировать запросы, чтобы сокращать число обращений к системам отелей. При этом учитывать, что данные устаревают. Динамика не столь высокая, как для динамического ценообразования в такси, но довольно высокая, при этом сильно различается в зависимости от спроса на конкретный период. При этом у отелей свое ценообразование, для раннего заказа могут быть скидки, для длинных сроков проживания тоже, плюс посредники, предлагающие отели, предлагают скидки по своим правилам. То есть ключ запроса - длинный, включает много данных. В докладе был рассказ про архитектуру решения для кеширования. Использовался redis, но там были сложности, связанные с большими ключами и большим объемом возвращаемых данных. Поэтому перешли на aerospike. В какой-то момент тоже отвалился, при разборе оказалось, что есть два вида ответов: описание доступных номеров и просто отказ, что номеров нет, без информации. И они разделили эти кэши, для кеширования отказов вернулись к redis, в котором использовали фильтр Блума. И тут сои хитрости, потому что некоторые поставщики, если у них проблемы, делают вид, что сервис работает, просто он перестает выдавать доступные номера, и эту ситуацию надо ловить, чтобы временно переставать обращаться. В целом - это был рассказ о решении задачи, в которой у авторов появилась довольно витиеватая схема. Ну и попробовали альтернативу redis.

🖐 Приходите на доклады и мастер-классы, которые начинаются в 16:00
⠀
🏰 «00 Зал - Башня». Как мигрировать тысячи сервисов между любыми дистрибутивами Kubernetes без единой правки чего-либо. Максим Чудновский (СберТех)

Постараемся обойтись без спойлеров: Максим и команда получили на вход очень сложную и тяжёлую задачу и успешно её решили, причём крайне остроумным способом. В конце доклада вас ждёт open source-анонс.
⠀
🔘 Зал «08 Шатер Голубой». Как сделать тесты надежными: property-based-тестирование и fuzzing на практике. Николай Климов (VK, ВКонтакте)

Property-based-тестирование существует уже более 20 лет, но используется довольно редко. А зря, ведь этот подход может избавить от необходимости придумывать кучу тест-кейсов для юнит-тестов. Николай расскажет, чем этот подход отличается от фаззинга и как его применить в вашем проекте.
⠀
🔹 «03 Зал Синий». Мастер-класс «Разделим данные». Алексей Лосев (Яндекс Маркет)

Продолжение серии мастер-классов от Алексея. В этот раз будет разобран кейс создания системы с разделенными и слабо связанными мастер-системами.
⠀
🟣 «04 Зал Красный». Психологический возраст кибербезопасности. Антон Бочкарев (Третья сторона)

Внимание к кибербезопасности сегодня повышенное и невозможно обойти стороной такую её сторону, как готовность организации. Обычно оценивают технологии с помощью опросов и аудита. Антон пошёл дальше и расскажет, как всё это работает и как определить психологическую зрелость кибербеза в компании.
⠀
🟢 «06 Зал Зеленый». Выбор стримингового фреймворка в 2024 году. Максим Буйлин (Т-Банк)

Spark, Flink, Nifi или что-то другое — какой стриминговый фреймворк выбрать в текущем году? Из доклада вы узнаете основные критерии для выбора, на что обращать особое внимание. И все это на основе практического опыта.
⠀
🔵 Зал «09 Шатер Фиолетовый». Мастер-класс «Создание модульной (и желательно эффективной) RAG-системы». Антон Белоусов (Raft AI Labs)

В результате воркшопа каждый участник поймет, как строить системы RAG (Retrieval Augmented Generation), узнает их особенности и получит собственную работоспособную систему.

🔸 Зал «07 Шатер Оранжевый». Механизм пререндера в браузерах. Алексей Кузнецов (Chromium contributor и энтузиаст)

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

#Highload Чему нас учит черный квадрат и причем здесь программирование. Это была идея Олега Бунина: расширить сознание и посмотреть на другую область. Основной рассказ вел Александр Кибасов (Doctrina et Nobiles), а Олег и Вирна Штерн давали реплики и повросы. А тема Малевича была выбрана потому, что онтико использует стиль супрематизма в оформлении презентаций, а с этого года еще начала делать сувенирку - матрешки, расписанные в этом стиле как приз за лучшие вопросы, докладчикам и членам ПК.

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

Итак, тезисы Александра о Малевиче, супрематизме и искусстве в целом. Отмечу, что он в лекции не разделял явно то, что Малевич говорил явно от позднейших интерпретаций.
* До Малевича искусство - это голые или обнаженные женщины, пейзажи или сюжеты с пресонажами, и для понимания предполагалось знание контекста. Малевич черным квадратом сломал этот стереотип, и сделал искусство без явного смысла и контекста, а для прямого восприятия.
* Искусство предназначено для созерцания, а не для интерпретаций и смыслов. Оно не должно иметь смысла, и это - правильно. Идея бессмысленного жеста - спасительна. Потому что жизнь полна смысла. В чем смысл жизни? Конечно, чтобы ходить к вам на работу. Искусство без смысла разрывает такую логику.
* Искусство без смысла, для созерцания - слом мира мещан, которые везде искали смысл, потому что так принято.
* Черный квадрат сломал элитарность художников: черный квадрат может нарисовать любой, он не требует мастерства. При том, что у Малевича мастерство - было.
* В те времена Петербургская и Московская академии каждый год выпускали художников с классическим подходом, их было много. Черный квадрат ломал традицию.
* Были последователи, ученики и те, кто тоже творил и творит в том стиле. Есть художник, который рисует синие картины, просто закрашивает одним цветом, есть - кто черные, устраивают выставки.
* Кандинский - как Малевич, но для тех, кто любит цвета. Вкусы различны, одним нравится кока, другим - пепси. У него еще была бредовая конструкция, как его картины работают и какие эмоции вызывают.
* После Малевича было еще три соразмерных события. Фонтан Мишеля Дюшана (1917) - нестандартно повешенный писсуар: главное, идея, а создавать предмет не обязательно, можно взять готовый, мастерство не нужно вообще. Один и три стула Джозева Кошута (1965) - инсталляция: стул, его описание и его фото; идея - язык - не рабочая структура, он не передает смыслы, провал коммуникации. И Дерьмо художника Пьетро Мандзони (1961) - вообще подвешивает сферу искусства как таковую.

Теперь мои комментарии, тоже в виде тезисов.
* У черного квадрата и последовавшего за ним направления супрематизма был вполне утилитарный смысл: для славы надо было отличаться от других, причем сильно. За счет мастерства это не получается, оно есть, но не экстра-уровня - значит делаем оригинально. Прием не новый, кто-то из скульпторов, творивших в Италии после возрождения ввел в моду барельефы, где фигуры едва намечены, почти рисунок на мраморе - чтобы отличаться от глубоких барельефов Возрожедния, которые уже у всех были. Здесь логика - та же.
* Как мне рассказали после лекции, первый черный квадрат был вполне утилитарной вещью - это часть декорации к спектаклю, где такая картина, наверное, была уместна по замыслу. А дальше - идея зацепила.
* Очень забавно: Чехов критикует мещан за отсутствие смысла, а Малевич - за то, что они везде ищут смысл. Хотя тут можно понять: у тех, кого называли мещанами, понятный смысл жизни из простых человеческих радостей. Они не ищут высокого предназначения, и не признают непонятное, художнику с ними сложно. Это целенаправлено разрушали, и в 1920-е, пока основным мотивом в СССР было низвержение старого супрематизм был в почете. А потом пошли эпоха, когда потребовалось конструирование нового.
* По сути, супрематизм - начало движение деконструкции смыслов. Тогда оно было в форме протестов против предписываемой традицией формы, которая застыла настолько, что тоже была лишена смысла. Но позднее, во второй половине 20 века у деконструкции появилось идеологическое обоснование, и объявлена долгом. И деконструкция искусства - часть этого мейнстрима. В этой концепции ценность искусства определяется замыслом автора и мерой его страдания, оцениваемой по его собственным заявлениям. За подробностями могут оправить в мой пост https://mtsepkov.org/Snowflake и пост https://ivanov-petrov.livejournal.com/2287616.html Это - гораздо более поздняя история, и отдельный вопрос - в каком объеме это было у Малевича, а насколько это - поздние интерпретации. Потому как сейчас любят говорить, что Достоевский воспевал страдающих, а он их не воспевал, он лишь показывал, что бедные - тоже люди, они живут и страдают также как остальные, сообщение было другим.

На этом все. В комментариях можно обсуждать подробнее. Или очно на конференциях.

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

🖐 Не пропустите доклады, которые начинаются в 17:10
⠀
🏰 «00 Зал - Башня». Архитектура биллинга: как не стать единой точкой отказа. Илья Иванов (Яндекс 360)

Интересный архитектурный кейс от Яндекса по созданию высоконагруженного биллинга.
⠀
🔘 Зал «08 Шатер Голубой». Быстро — не всегда хорошо: рейтлимиты в мультикластерном окружении. Дмитрий Виноградов (Wildberries)

Для контроля входящего RPS в сервисах применяют rate limit. Вот только он реализуется или как простой in-memory-счетчик, или более продвинуто — как счетчик во внешнем K/V. В докладе Дмитрий пошел в своей работе дальше — к более сложным решениям.
⠀
🔹 «03 Зал Синий». Продолжение мастер-класса «Разделим данные». Алексей Лосев (Яндекс Маркет)

Продолжение серии мастер-классов от Алексея. В этот раз будет разобран кейс создания системы с разделенными и слабо связанными мастер-системами.
⠀
🟣 «04 Зал Красный». Как научить MongoDB делать горячие физические бэкапы. Юрий Фролов (Yandex Cloud)

История о том, как Яндекс возвращал возможность физических бэкапов в MongoDB. Будет много подробностей про движок базы, про подход MongoDB к хранению данных и про то, как написать собственную логику бэкапа.
⠀
🟢 «06 Зал Зеленый». Как мы сделали собственный Software-Defined Storage для публичного облака Cloud.ru. Сергей Лысанов (Cloud.ru)

Глубоко технический доклад про реализацию собственного хранилища в условиях больших нагрузок и критических систем вокруг. Если вам нравится разбираться во внутрянке таких систем и специфике хранения данных — этот доклад для вас.
⠀
🔵 Зал «09 Шатер Фиолетовый». Продолжение мастер-класса «Создание модульной (и желательно эффективной) RAG-системы». Антон Белоусов (Raft AI Labs)

В результате воркшопа каждый участник поймет, как строить системы RAG (Retrieval Augmented Generation), узнает их особенности и получит собственную работоспособную систему.

#Highload Филипп Дельгядо. Enterprise deploy: почему это больно. Рассказ о технике повышения безопасности деплоя. Особенно важно это для enterprise-решений, которые разворачиваются у клиента: мы не контролируем процесс обновлений и их использование.

Когда-то были монолиты, которые для обновлений останавливали. Сейчас у нас много экземпляров серверов, которые работают с общей базой данных, которая тоже может быть в нескольких экземплярах, и остановить работу для изменения невозможно. Изменения правильно делить не на совместимые и несовместимые, а по безопасности: почти безопасные, возможно опасные и точно опасные. Создать новую таблицу - безопасно. Добавить поле - практически безопасно, но требует краткой блокировки таблицы, и на смеси olap и oltp транзакций под высокой нагрузкой это может выстрелить: oltp задержат дольше допустимого. А создание индекса во многих базах блокирует таблицу надолго, а в PostgreSQL есть специальные методы, как это сделать безопасно, ими надо владеть. Добавление нового значения в enum - опасность больше, надо разбираться с работой старых сервисов с объектами, у которых новое значение. Может быть, что такие записи в них в принципе не попадут, но это всегда не точно.

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

Теперь от базы данных к взаимодействию сервисов. В случае синхронного взаимодействия (http, grpc) применяем:
* Версионирование по методам, а не целиком.
* Изменения окружаем флагами для котроля нового поведения
* Используем тольо безопасные изменения внутри endpoint
* Маршрутизация запросов - чтобы метод получал только понятное
* Контроль жизненного цикла: состояния draft, unstable, deprecated. C разными обязательствами.
* Нужен инструмент управление фича-флагами: рассылка по сервисам, контроль зависимостей, канареечные флаги вместо разнесения по узлам сети, удаление неактуальных флагов

Асинхронные взаимодействия через очереди. Тут нет мгновенного изменения, в очереди живут необработанные события старых версий. И на них нельзя запустить обновление, они придут в виде, в котором посланы. Мы не всегда знаем участников взаимодействия - что читает, кто пишет. И делать версии событий базовые инструменты не позволяют. И тут хороших решений нет.
* Самое простое - новый топик для новых событий. Но при этом мы теряем порядок и партиционирование, нужно сложное переключение и администрирование.
* Сначала обновляем консьюмеров, потом продьюсера. Тогда сервисы перестали быть автономны по деплою, и пояляются проблемы с откатом консьюмеров - для этого надо отвалить продьюсер. Частичное решение - фича-флаг в продьюсере, но то, что в очереди - лежит.
* Отправка нескольких версий - и консьюмер выбирает нужную. Это сложно в реализации, потому что стандартные способы передачи и контроля перестают работать - у вас несколько схем на одно событие, например.
* Можно возложить маршрутизацию на service mesh - чтобы он отправлял на нужных консьюмеров.

А еще - можно не делать асинхронное. Вам нужно сглаживать пики - уберите этот буфер внутрь сервиса, а не располагайте между.