Берите пример, друзья! За это еще и кружку дают:) В 17:00 подведем итоги - еще успеваете выложить пост с хештегом #HLконспект #HLSiberia2018

https://www.facebook.com/HighLoadConference/posts/1732217530189037

Публиковать заметки по докладам прямо в ходе конференции #Highload не получалось, поэтому я решил быстро сделать отчет https://mtsepkov.org/Highload-2022 А вообще конференция ознаменовалась очень плотным общением - люди соскучились по нему, особенно на таком масштабном (почти 3000 участников) мероприятии и кулуары бурлили. Послезавтра - #Teamlead, думаю, там будет не хуже.

#Highload Олег Коровин. GraphQL: зачем на самом деле он нужен. Apollo Federation — дар бога. По этому докладу у меня возникла ассоциация с историей. Когда-то давно были базы данных без SQL, только работа с таблицами, и все join надо было вручную писать в коде. Z это еще застал. Потом пришел SQL и проблема была решена. Сейчас это повторяется: микросервисная аргиюетура разложила объекты о сервисами, для каждого есть свой набор API. GrapgQL позволяет объединять данные из разных узлов в единую схему и делать общие запросы. При этом тогда разработчики относились к появившемуся SQL настороженно: это же накладные расходы, сложно и непривычно. Так и сейчас к GraphQL относятся настороженно как к хипстерской поделке, которая не нужна "настоящим программистам" - OpenAPI достаточно. Докладчик показывал, как GraphQL решает проблемы, сокращает объем кода, делает его более компактным. А также - как решаются проблемы контроля доступа, единой точки отказа и безопасности. Решение GraphQL - легкое и масштабируемое, федерации - stateless, и можно поднимать разные федерации для разных клиентов, подключая только необходимые им сервисные данные. И страивать параллельный доступ для миграции, поднимая федерацию для доступа, но запуская через нее только новые запросы. Тут ситуация выгодно отличается от того, что было с миграцией на SQL-базы данных - там это можно было сделать только целиком. На мой взгляд, получился очень удачный доклад.

#Highload Роман Щербаков из Тинькофф. Пайплайны записи своими руками: думали — велосипед, оказалось — паттерны. Рассказ об организации высокой доступности для инфраструктурных потоков: логов, метрик, трейсов. 450 Мб/сек. Целевые хранилища там разные, а архитектура - общая. В докладе - много архитектурных схем, это надо смотреть презентацию. А тут мое краткое резюме принципов.
* Данные пишутся в том же дата-центре, в котором создаются, то есть в каждом - свой набор pipeline, и там же они остывают. А поиск - по всем датацентрам.
* Надо вести мониторинг обращений клиентов и уметь отделять тех, у кого особая нагрузка в отдельный pipeline, с которым отдельно разбираться.
* Worker записи от клиента пишет в Kafka, из которой читает Worker записи в хранилище. И worker записи работает в том темпе, в котором комфортно для БД. Kafka буферизует колебания нагрузки записи. А worker записи делает пакетную запись.
* Отказ операции - нормально. Особые случаи откидываем в отдельную retry-очередь, а если retry не проходит - в очередь ошибок, с которой разбираются вручную. Retry однократный, он на случай, если что-то моргнуло, а если что-то упало - то retry вреден. И такая схема обеспечивает оперативное поступление данных, с которыми все хорошо.
* Если база или узел деградировал - его надо отрубить, для этого фиксировать, что пошли массовые ошибки, для этого Circuit breaking pattern. Аналогично работает bulkhead pattern - ограничение на конкурентные обращения. Это бережет БД.
* Таймауты надо настраивать. Есть бюджет обработки от кафки - таймаут опроса очереди, при превышении которого она считает, что consumer отвалился, и в него надо укладываться, включая все таймауты. И для основного потока там жесткие настройки, а для retry и ошибок - свои.
* Для метрик основной поток пущен напрямую, без kafka, так как на стороне клиента обычно prometheus и у него есть свои буфера. И это экономит. Но при деградации - включается полная схема.

#Highload Николай Никитин из ИТМО. Как обеспечить воспроизводимость научных исследований в AI/ML с помощью Open Source? Основной тезис доклада, на мой взгляд, остался за рамкой: смысл научного исследования в том, что его результаты могут быть использованы другими в своих разработках. Именно это подразумевается под воспроизводимостью, не ограничиваясь просто проверкой результатов. Для Николая это тезис очевиден, в то время, как в социальных реалиях современной науки это далеко не так. Если же принять этот тезис, то для современных исследований, особенно в области AI/ML, просто публикации статьи недостаточно, к статье должен прилагаться код и наборы данных, которые обеспечат легкое использование результатов, включая его проверку, но не ограничиваясь ей. В open source есть площадки для этого. Но ученые - не программисты, разработка и создание open source для них - не профильная работа, получается довольно высокий порог входа, который полезно снизить. Они в 2020 годы в ИТМО начали это делать, и сейчас у них 10+ различных проектов. Был более подробный рассказ про фреймворк FEDOT. Тут есть особенности, связанные с тем, что есть 2-3 человека в ядре команды и ассоциированные стажры, которые делают студенческие работы. Но для успеха ядро должно быть увлеченным, в том числе проводить менторинг для студентов - и административно это не масштабируется. Такие проекты делают пиар, показывают что университет способен достигать серьезных результатов. Однако, несмотря на это уровень энтузиазма довольно велик. Тут есть вопрос финансирования, если на новые версии его еще можно получить, то на поддержку - не получается. Но сейчас есть возможность получить гранты, и то, что продуктом будет не просто публикация. а open source эксперты оценивают. И коммерческие компании тоже становятся толерантными к выкладке результатов в open source, хотя тут это каждый раз вопрос переговоров. Лично я желаю ИТМО всяческих успехов, и надеюсь, что этот опыт будет распространяться.

#Highload Николай Никитин из ИТМО. Как обеспечить воспроизводимость научных исследований в AI/ML с помощью Open Source? Основной тезис доклада, на мой взгляд, остался за рамкой: смысл научного исследования в том, что его результаты могут быть использованы другими в своих разработках. Именно это подразумевается под воспроизводимостью, не ограничиваясь просто проверкой результатов. Для Николая это тезис очевиден, в то время, как в социальных реалиях современной науки это далеко не так. Если же принять этот тезис, то для современных исследований, особенно в области AI/ML, просто публикации статьи недостаточно, к статье должен прилагаться код и наборы данных, которые обеспечат легкое использование результатов, включая его проверку, но не ограничиваясь ей. В open source есть площадки для этого. Но ученые - не программисты, разработка и создание open source для них - не профильная работа, получается довольно высокий порог входа, который полезно снизить. Они в 2020 годы в ИТМО начали это делать, и сейчас у них 10+ различных проектов. Был более подробный рассказ про фреймворк FEDOT. Тут есть особенности, связанные с тем, что есть 2-3 человека в ядре команды и ассоциированные стажры, которые делают студенческие работы. Но для успеха ядро должно быть увлеченным, в том числе проводить менторинг для студентов - и административно это не масштабируется. Такие проекты делают пиар, показывают что университет способен достигать серьезных результатов. Однако, несмотря на это уровень энтузиазма довольно велик. Тут есть вопрос финансирования, если на новые версии его еще можно получить, то на поддержку - не получается. Но сейчас есть возможность получить гранты, и то, что продуктом будет не просто публикация. а open source эксперты оценивают. И коммерческие компании тоже становятся толерантными к выкладке результатов в open source, хотя тут это каждый раз вопрос переговоров. Лично я желаю ИТМО всяческих успехов, и надеюсь, что этот опыт будет распространяться.

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

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

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

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

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

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

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

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

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

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

#Highload Дмитрий Кривопальцев и Вадим Клеба. Как выбрать технологии для высоконагруженного проекта и не привлечь внимание санитаров. Доклад - обзор вопросов, которые надо решать при выборе технологий. Но по факту на все вопросы есть общий ответ: включить мозг, а не следовать за модой. А подробнее: (1) понимайте вашу задачу, (2) потребности бизнеса и (3) возможности вашей команды. Любая технология имеет плюсы и минусы, для разных задач подходит разное. И с любой технологией потмо долго жить, нужны люди, которые ей владеют. А теперь по содержанию детально.

Первое - язык. Тут в командах обоих докладчиков два языка, у одной - java + python, при чем на python ядро? а на java - высокопроизводительные конкретные сервисы, в другой java + Go, при этом java - основа, а go - для кусочков, которые общаются по http. B это иллюстрация к уместности языков для задач. При этом надо помнить, что быстрый язык сам по себе не дает производительности, производительность обеспечивается устройством кода. По умолчанию - используем что знаем. Но обязательно помните про команду - возможность изучения новых языков командой, возможность найма разработчиков, владеющих языком.

Второе - база данных. В 9 случаях из 10 подходит PostgreSQL. А в том одном случае - выбирайте по характеристикам, понимая зачем это нужно. Но помните про сопровождения, был кейс, когда выбрали Кассандру, она подходила идеально по характеристикам, но через два года выяснилось, что поддерживать некому, и лучше бы накостылили что-то на PostgreSQL.

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

С чего началась конференция HighLoad++? Узнайте из этого видео 😉

#HighLoad2025 #highload

Клуб анонимных СТО: заседание второе 😎

Здесь звучат только честные ответы на неудобные вопросы: от вайб-кодинга до выгорания команд. Участники узнают инсайды, которые никогда не попадут в блоги и интервью!

#HighLoad2025 #highload