2022-05-15: Highload - люди очень соскучились по живому общению

Короткая ссылка: Highload-2022

Ссылки сюда (2) →

О других конференциях

#Highload ознаменовался очень плотным общением — приехало очень много знакомых, с которыми получаются содержательные разговоры на очень разные темы. Спохватываешься, когда очередной слот доклада оказывается безнадежно пропущен. Впрочем, так и надо: доклады можно посмотреть в записи, а содержательные обсуждения и мысли иначе не получишь. И это — не только мое впечатление, люди явно соскучились по общению на таком масштабном событии. Да, осенью был Highload и Teamlead в Питере, но они — сильно меньше. А такие масштабные офлайн-конференции были еще до ковида, Highload осенью 2019, а Teamlead успел пройти в феврале 2020. И вот эта атмосфера общения, бурление кулуаров — основное впечатление конференции. Она проходила в Крокус-Экспо, собрала почти 3 тысячи участников, 4.6 тысяч было онлайн. И я предвкушаю аналогичное общение на Teamlead, которая пройдет во вторник-среду. Многие будут на обоих, но часть приезжала только на Highload — а значит на Teamlead будет кто-то еще.

Но все-таки общение не отменило доклады. Публиковать заметки прямо в ходе конференции у меня не очень получалось, поэтому я решил не тянуть с отчетом. Особенно отметить хочу два. Доклад Александра Кривощекова из Яндекс-Еды про паттерны отказоустойчивой архитектуры, и доклад Константина Кичинского из Касперского «Секретная карта IT-экосистемы, из которой становится понятно, к чему готовиться», на который, правда, я зашел уже ближе к концу, так что еще буду смотреть в записи. Но в любом случае, я видел малую часть конференции — на ней было восемь треков. А еще — множество (десятки) стендов разных компаний, на которых были реальные технические эксперты, и с ними можно было обсудить свои проблемы.

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

А теперь — про конкретные доклады.

Павел Грязнов. Что дженерики нам готовят

Рассказ про дженерики в Go в сравнении с python, с примерами кода и метриками производительности. Интересно. Заодно освежил вообще эту тему.

Александр Кривощеков, Яндекс-Еда. Паттерны отказоустойчивой архитектуры

Много конкретных шаблонов, обеспечивающих устойчивость работы сервиса в реальной среде, в которой сеть и сервисы сбоят или медленно отвечают по разным причинам. В докладе — постепенное усложнение модельного сервиса разными фичами — рейтинги, статистика, сложная и точная алгоритмика вместо легкой, с соответствующим усложнением применяемых шаблонов: retry, требующий для set идемпотентных идентификаторов, deadlines, rate и burst limiting, circuit breaker, rich client, dummy или pumpkin. C примерами и разными стратегиями. Включая способы вынести такую работу с запросами с прикладного на базовый уровень. Хотя часть он рассказать не успел.

Дополнение от Александра по отчету. Мне самому очень жаль, что я не успел полностью уложиться в тайминги. Однако сам доклад тоже отказоустойчивый :), я уже выступал с этим ним на другой конференции, и там успел рассказать всё. Вот тут есть версия моего выступления где я рассказал и про Rich Client, и про Dummy: https://youtu.be/8GlwkWxf3hk?t=6866 (начало: 1:54:26). Там чуть проще слайды, делал их в power point. Но смысл и структура рассказа почти идентичны (я чуть больше делал упор на C++). Однако можно открыть в соседнем окне новую версию слайдов с интерактивными визуализациями и самостоятельно их полистать во время моего доклада: https://presentations.superpaintman.com/highload-foundation/2022/1 (лучше открывать с компьютера или планшета, на телефоне может выглядеть плохо). Возможно, те кто хотели бы увидеть полную версию, найдут это полезным.

Никита Старичков. 1С:Предприятие — low-code платформа для цифровизации бизнеса

Представление 1С как платформы. В целом я это себе представлял. Но мне было интересно про три варианта разработки для мобилок: платформа для своих приложений, мобильный клиент и гибридный вариант, который может работать offline и online, когда для методов размечена возможность offline-рабты, когда реальный вызов бует после восстановления связи. Правда, серверная часть должна дополнительно решать конфликты отложенных вызовов в тез случаях, когда они возникают. И я не знал про Дата акселератор — собственное in-memory СУБД для OLAP. И был анонс 1С.Элемент — платформы для создания приложений, ориентирвоанных на конечного пользователя, которую, правда, начали разрабатывать в сентябре, и пока нет даже беты. Посмотрим, что из этого получится. А еще был любопытный пример — полная автоматизация на 1С белорусско-китайского автозавода Geely, включая, судя по всему, работу с оборудованием или тесную интеграцию с управляющими программами.

Павел Лакосников из Авито. SLI/SLO/SLA в микросервисном приложении

Интересный разбор, что реально означают метрики отказоустойчивой работы. SLI, например, 99,99 % у AWS — это вовсе не гарантия. Это лишь целевая функция, нарушение которой трактуется как ошибка. И если нарушают сильно, то наступают последствия, например, если ошибок будет 1 % (то есть 99 вместо 99.99 — то вернут 30 %, а если 5 % ошибок (то есть 95 %) — то тогда полностью возвращают деньги за период. По сути SLI превращается в рекламную фишку высокой надежности. Дальше у нас SLO — реальная метрика, и SLA, где описаны последствия. Дальше Павел рассказывал про выбор подходящей метрики для их приложений, и работу с ними. Интересно, что у них в роли метрики выступает доступность страниц входа, и он объяснял альтернативы и причины именно такого выбора. А еще рассказывал про работу: когда у вас есть метрика, то автоматически возникает бюджет ошибок, и часть этого бюджета едят реальные ошибки, а другую часть можно потреблять в ходе экспериментов над улучшением сервиса — ведь любое улучшение может обернуться ухудшением.

Дмитрий Липин и Евгений Сидоров рассказывали историю работы кризисных штабов в Яндексе после событий 24.02

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

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

Евгений Росинский из ivi. Генерация хайлайтов

Всем известны трейлеры к фильмам, это законченные произведения на 2-3 минуты. А хайлайт — еще короче, 40 сек, чтобы зацепить человека. Зачем генерить? Есть страничка фильма, там статический постер. Для 20-30 фильмов руками собрали хайлайты — хайлайт в 4 раза повышает просмотры, поэтому если раскатать на все — будет профит около 20М. И возникла идея порождать хайлайты автоматически. Потому что в реальном мире трейлер делают 1.5 месяца — это долго и дорого. Про решение этой задачи Евгений рассказывал. Идея: фильм состоит из сцен, сцены — из шотов — коротких фрагментов, в которых план съемки не меняется, на шоты можно автоматически нарезать. Будем считать, что в существующие трейлеры создатели отобрали хорошие шоты, обучим модель их отбирать. Для оценки используют три кадра: первый, последний и середина. Еще проверяют, что граница шота совпадает с границей звука, и отсеивают шоты по длительности. А чтобы исключить спойлеры берут первую половину фильма. Дальше была куча техники — про нарезку на шоты, про работу с разными разрешениями, потому что резать и выбирать лучше по сжатому видео — оно меньше, а монтировать хайлайт — по исходному качеству, и не переходе есть проблемы с FPS, регулярная смена хайлайтов при показе предложения, и многое другое, путь от идеи до продакшена, как обычно, имеет много нюансов. В целом получилось так, что автоматические хайлайты не уступают созданным вручную, для оценки использовали респондентов, набранных через Яндекс. Толоку. Трейлеры вручную создают лучше — на более длинном ролике качество монтажа имеет значение. Метод не подходит для мультиков — у них сложнее с выделением персонажей, и для спортивных передач, но для спорта есть альтернатива — по комментариям и реакции в трансляциях выделяются ключевые моменты. В целом интересно и познавательно.

Алексей Коновкин из Nexign. API Gateway

Есть много стандартных, и Мегафон выбирал. Пока выбирал — они сделали свой, вроде как прототип для осознанного выбора, а в результате именно его и взяли в продакшн. Рассказ был про функциональные задачи API Gateway, которых довольно много: хранение конфигурации, версионирование, маршрутизация с учетом работоспособности узлов, балансировка, аутентификация, авторизация, логгирование, преобразование запросов, защита и квотирование и так далее. И для каждой функции есть различные подходы, о которых рассказывали с примерами реализации в стандартных продуктах, и о своем выборе реализации, который выступал как пример. Доклад не был рекламой продукта, тем более, что отдельно они его не продают, а именно рассказом о функциях и вариантах реализации, уместных в зависимости от среды использования. Включая такие штуки, как token exchange, необходимый в гетерогенной среде со многими провайдерами токенов, используемыми разными системами, так что на интеграции токены надо подменять.

Алексей Станкевючис, Яндекс. Эволюция акторной системы

Технический рассказ об организации системы акторов. Первоначально система была на разделяемой памяти, получалось сложно. И они переделывали на независимых акторов, которые обмениваются сообщениями. Акторы — однопоточные state-машины — получают сообщения, обрабатывают, отправляют другие. Хорошо переходят в параллельном и распределенном вариантах. Пример — актор надежной записи: запустил сообщения акторам для записи на конкретные диски, посчитал ответы. Система доступна под Apachе 2.0.

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

Константин Кичинский из Касперского. Секретная карта IT-экосистемы, из которой становится понятно, к чему готовиться

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

И разные стратегии поведения:

• продляем жизнь старых решений
• выбор между тотальной зависимости от США и от Китая
• антиграница и червоточина — открываем api, а за границей делаем второе лицо
• отказ от замещения — нам точно нужен word или powerpoint? Может можно перейти на совсем другое?

И еще 4 антистратегии, тоже были на слайде. Постарайтесь их не делать.

Сначала надо спасти себя, потом соседа. Но когда спас себя — спасать соседа важно.

Владимир Озеров, Алексей Гончарук. Архитектура распределенных SQL-движков

Реализация SQL для своей хранилки открывает много возможностей — интеграция, утилиты, работа пользователей. Это не надо делать с нуля, надо использовать стандартные библиотеки и решения, которых довольно много. Но для этого надо представлять архитектуру решения, о которой и был рассказ. Два этапа: планирование запроса, и его выполнение. При планировании — предсказания, есть разные подходы. При этом глобальная оптимизация делает выбор недопустимо долгим, поэтому планирование всегда разбивается на фазы, и надо получить приемлемый результат за приемлемое время. Распределенное хранение накладывает дополнительный уровень — помимо операций считывания с диска у нас появляются операции пересылки между нодами со своей стоимостью. А выполнение идет по выработанному плану, но при этом еще и оценивает, насколько предсказания оказались реалистичными, сравнивая их с фактом, и при сильном расхождении может быть запущено перепланирование. И отдельная ветка — обратный ход на хранение. Как при односерверном варианте часто используемые небольшие таблицы могут быть предзагружены в кэш, так и в распределенном варианте какие-то небольшие таблицы могут дублироваться по узлам полностью, чтобы джойн можно было стрить на каждом узле.

На этом — все.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 13:19, 15 мая 2022 • нет комментариев