Текущая версия на 13:55, 28 августа 2024

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

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

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

Максим Цепков. Что такое хорошая интеграция

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

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

Оригинал Филиппа Кулина

Максим Цепков. Полный зал. Что такое хорошая интеграция?

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

Устойчивые шаблоны. Шаблон UPSERT, как в Cassandra. Использовать идемпотентные операции, но их надо проектировать. Но можно работать без транзакций. Распредеоенные транзакции - зло. Консистентность без транзакций. Устойчивость к потерям и дублям. Понимание межсистемных взаимодействий. Синхронное. Асинхронное. Асинхронное реализовывать сложно. Реактивное, с коллбэком. Есть много сахара async. И потом много докладов как это не работает. Хаха. Надо рисовать взаимодействие. Ода против абстракций асинхронности.

Транспорт данных. По прежнему файловый транспорт - хорошая штука. Смешной пример про файлы почтой. Любой транспорт можно использовать для любых целей.

Устойчивость к расширению.

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

Олег Уткин из Tarantool

Пост на FB Олег Уткин из Tarantool. Ускорение разработки с Rust. В Tarantul два основных языка: Lua для быстрой разработки, и C для высоконагруженных частей. Проблемы C - не безопасная работа с памятью, и довольно низкоуровневая работа, которая приводит к увеличению объема кода, например, для явного вызова сериализации-десериализации, которая в Lua скрыта языком. И они открыли для себя Rust как способ писать столь же удобно, как в Lua, но с таким же быстрым исполнением как в С. И Олег рассказывал про сам язык и кейсы использования.

Rust на уровне языка позволяет безопасно работать с памятью. Но не полностью скрыто, как в Java или C# и других языках, где это скрыто за сборщиком мусора, а через явную типизацию для разных случаев - для локальных переменных, для разным разделением данных, для счетчика ссылок и для циклических ссылок и так далее. Все они гарантируют вызов деструктора по правилам, которые различаются для разных типов, и отсутствие не актуальных ссылок, и все это - на уровне проверки компилятором, а не в runtime. И, с моей точки зрения, это удобнее, чем неявное управление для ситуации, когда ты хочешь держать это под контролем. Потому что я слышал немало докладов, где разработчикам на Java объясняли: вы должны представлять как работает управление памятью и сборка мусора для эффективной разработки. При этом "представлять" означало "догадываться", как с оптимизатором БД: алгоритмы меняются и догадки становятся неверными, а тут - явное управление. Которое требует думать, зато не требуется догадываться. Понятно, что при вызове библиотек на C такая безопасность теряется, но подробно проработано, как писать safe-wrapper над unsafe-библиотекой.

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

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

Дальше были примеры из реальных проектов. Показан код на Lua, его вариант на C, который получается более длинный и менее понятный, и код на Rust, который по компактности и понятности аналогичен Lua, а по скорости - сравним с реализацией на C, об этом были цифры. Собственно, все.

Николай Ижиков из Сбербанк Технологии. Apache Ignite теперь с CDC (Change Data Capture)

Пост на FB Николай Ижиков из Сбербанк Технологии. Apache Ignite теперь с CDC (Change Data Capture)! Это хороший пример как для целей прикладной разработки развивают базовый уровень софта - распределенную базу данных Apache Ignite. При этом доработки выложены в master, их можно уже собрать самим, а в 2.12 они появятся в бинарниках. То есть они становятся доступными для всех пользователей данных.

Технически это механизм с понятными и многочисленными прикладными применениями: переложить данные из оперативной БД в аналитическую, послать приветственное письмо, запустить модерацию записи в БД и так далее. CDC работает в отдельном процессе на архивных WAL-сегментах, которые уже есть, они обеспечивают восстановление при сбоях, поэтому не возникает дополнительного использования диска, хотя время хранения архивных сегментов может увеличиться, чтобы CDC успел его обработать. В рассказе были детали технической реализации - API для включения CDC, конфигурирование архива, так как оперативность CDC может потребовать уменьшения таймаутов, API для consumer и обработки событий. И еще есть реализации на основе механизма CDC для разных целей - логическая репликация в Ignite с разрешением конфликтов, репликация в Kafka и из нее. В перспективе - добавление метрик и поддержка in memory кэшей, а не только persistent.

Серия докладов Вконтакте о переходе на QUIC с TCP - Александр Тоболь, Илья Щербак, Олег Смирнов, Сергей Никитин

Пост на FB серия докладов Вконтакте о переходе на QUIC с TCP - Александр Тоболь, Илья Щербак, Олег Смирнов, Сергей Никитин. Это новый стандарт, предложенный в 2012 году Google. На уровень транспорта вынесены стримы и шифрование. Отсутствие стримов в tcp приводило к тому, что хотя на уровне http было много независимых потоков, при проблемах в одном потоке другие на уровне tcp ждали их решения, а не асинхронно срабатывали. QUIC дает большой выигрыш на плохих сетях и при движении устройств, которые приводят к переключению точки доступа к сети: соединения имеют свой ConnectionID для переключения, встроены управления скоростью обмена так, что клиент не шлет на сервер больше, чем тот может обработать, чтобы он не захлебнулся, и строены средства управления размерами, чтобы пакеты не резались промежуточными маршрутизаторами.

В рассказах было много техники. Но главная фишка не в технике, а в том, что реализация QUIC вынесена на пользовательский уровень. И это переворачивает привычное многоуровневое представление о передачи данных, где пользовательский слой - наверху, над http. Тут кусок пользовательского слоя вклинивается в середину, между UDP и http. При этом по стандарту основой QUIC не обязан быть udp.

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

Пересказывать все это я не буду - надо смотреть. Но это - ближайшее будущее.

Oleg Bartunov. Json or not Json

Пост на FB Oleg Bartunov. Json or not Json. Плюсы и минусы использования Json в PostgreSQL. Хранение Json стало драйвером развития PostgreSQL, это единственная РСУБД из четверки (Pg, MySQL, Oracle, MS SQL), которая растет. Потому что он востребован для хранения сообщений и объектов, удобен для микросервисов, дает быструю разработку и расширение атрибутного состава без изменений в базе данных. И не важно, что такое развитие нарушило совместимость Pg с другими базами данных, где нет таких возможностей - стартапам это не нужно, и многим другим тоже. Json проложил мостик между миром баз данных и миром серверной (и клиентской) разработки, обеспечил однородность. И много NoSQL пользователей перешли на Pg, так как ряд проблем, в частности, индексация и построение запросов по смешанным реляционным и Json-данным решаются лучше.

Доклад был о внутренних механизмах Pg и о том, как использовать Json правильно. А так же о том, какие очередные патчи они доработали для того, чтобы обеспечить высокую скорость Json. Вернее, не Json, JsonB - бинарного варианта Json, который хранит не строку, а структурное представление, что и дает возможности производительных запросов, индексации и другие плюшки, но при этом не сохраняет незначащие с точки зрения структуры элементы - пробелы, порядок ключей и т.п. Например, точно не стоит уносить внутрь json ключ. Проблема в том, что многие функциональные возможности готовы, но не апрувлены сообществом и потому их надо забирать себе отдельно, чтобы воспользоваться. И надо понимать, стоит ли оно того. Основной фокус рассказа был на производительности, связанной с размерами Json - в Pg есть механизм TOAST, который выносит данные более 2k в отдельные таблицы, а в самой таблице оставляет ссылку. Что приводит к накладным расходам. И они делали доработки поверх этого механизма с тем, чтобы JsonB работал эффективно. Это вынос маленьких ключей вперед по хранению, возможности неполной распаковки, независимая запаковка отдельных частей и многое другое. Подробности - в докладе.

Алексей Ефимов из Netcracker. Service Mesh на стероидах

Пост на FB Алексей Ефимов из Netcracker. Service Mesh на стероидах. Часть 1: как построить управляемое взаимодействие между сотнями микросервисов. Подробный рассказ про устройство service mesh, который обеспечивает версионирование сервисов по фичам и маршрутизацию обращений к нужной сборке сервиса в зависимости от того, какую фичу вы тестируете. При этом у каждого разработчика - своя песочница, в которой поднимаются только измененные сервисы, а остальные используются из стабильной версии. Нюанс в том, что вызовы могут быть в любом направлении, и надо маршрутизировать обращения от общих сервисов к измененных разработчиком, а песочница может быть развернута не только в облаке, но и у разработчика локально. Аналогичная техника применяется для A/B тестирования новых фич - тестовые сервисы для фокус-групп поднимаются отдельно и идет автоматическая маршрутизация обращение пользователя, в зависимости от его фокус-группы. А еще такая структура позволяет устроить конструкцию, когда сервисы используются для всех клиентов, а вот базы данных, к которым сервисы обращаются - отдельные для каждого клиента, что обеспечивает изоляцию данных.

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

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

Алексей Шарапов. Инфраструктура как микросервисы. Зачем и почему?

Пост на FB Алексей Шарапов. Инфраструктура как микросервисы. Зачем и почему? Devops-культура была порождена усложнением процессов раскатки приложений. И это - именно культура. Шаблон отдельной devops-команды, которая работает с конвейером поставки противоречит devops культуре, он про что-то другое. B тут есть еще один парадокс, который был в фокусе доклада: devops обеспечил возможность для микросервисной архитектуры, но сборки, особенно которые делает отдельная команда - монолит или мультикаталка, как ее назвал Алексей, на bash, слабо читаемые, без code review и тестов. То есть противоречащие всему тому, как организован код разработчиков. То есть они не являются кодом в смысле тех требований, которые мы предъявляем к коду микросервисов. И были рекомендации как это делать правильно - отдельная инфраструктура и репозиторий каждому сервису, отдельные репозитории и конвейер для внешних микросервсисов и так далее. И по инструментам - не тащите старое, Cubectl, Ansible, Bash, а используйте новое - Skaffold, Helmfile, Kustomize.

Артем Каличкин. Технический директор: вроде бы ему все можно, но нельзя

Пост на FB Артем Каличкин. Технический директор: вроде бы ему все можно, но нельзя. Артема давно интересовало - а что делает технический директор? А потом он им стал, и это - как падение в пропасть. Но понимание постепенно приходило, и он сейчас им делится.

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

Есть два сценария: вы выросли вместе с командой или когда вас призвали налаживать состоявшийся продукт или команду. С его точки зрения - одинаково. 4 фазы: тимлид/техлид - процессник - наставник - СТО. Когда сам вырос эти фазы понятны. Но когда пришли со стороны - то все равно должен залезть и разобраться. Побыть роль техлида/тимлида. Понять боли. И если там все хорошо - вас бы не позвали.

Фаза-1 "Золотой век". Пилим весело продукт. Всю картинку - продукт и люди - у вас в голове.

• Вы почти член семьи
• Продукт растет - и в какой-то момент все ломается.

Фаза-2 - темные времена. Вышли в прод.

• Инциденты, сеть нестабильна, клиенты недовольны...
• Вкурить и понять, выстроить процессы исправления. highload по количеству процессов.
• Вы уже не член семьи - кого-то поругали...
• Рабочая тетрадь 3 года назад - что именно он настраивал. Около 30 пунктов. У каждого - свои и нет типовых.

Процессы выстроил и пытался всюду успевать. "Тема-гастролер" -

Фаза-3. Республика. Делаем свою управленческую команду.

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

Фаза 4. "На краю Ойкумены"

• Убери из команды - ничего не изменится
• Многие постулаты - не соблюдаются, придумали систему менеджмента - и она работает.
• Запускали девопс на базе puppet - а они переделали, уже кубер... И все хорошо.
• Ввели проблем-комитет: выявляем причины, устраняем. Работает. А потом нет проблем-комитета, разбирают в моменте после инцидента
• Включаешь паттерн удержания: пишешь код, качаешься и вдохновляешь людей, настраиваешь процессы, непосредственно управляешь. И это - антипаттерн, этого делать не нужно, в позиции тех.директора это вредно. Потому что ты подменяешь других людей.
• А реальное занятие - снова фронтир. Он сам становится источник поручений, переходит из ведомой модели в проактивную. Предвидеть изменения и готовиться к ним. Генерировать смыслы.
• Эмерджентные свойства - те, которые появляются в синергии. И они есть не только хорошие, но и плохие. Любая система имеет собственную сложность. В ней появляются паразитические настройки.
  • Например, цикл согласования. Вместо того, чтобы отменить систему - начинают совершенствовать.
  • И вы ломаете систему. И этим делаете хуже тем, кто ее сделал.
  • Но это развивает систему в целом.
• И ты снова за все в ответе. Потому что фейл - он же руководителя, а успех - у команды. И ты должен быть исправить любую проблему
• Задача: формировать правильные задачи правильным людям в правильное время. И делать это системно.

Он опирается

• Максимальная информированность на базе метрик. Ее надо выстроить, чтобы не терять связи с системой. Не через отдельные отчеты
• Постоянное поддержание компетенций Hard и Soft Skills: учимся все время
• Дисциплинированное мышление: archi, trello, obsidian, mindmap, MD, LaTex

Основная его боль - Archi и archimate. Он позволяет связывать компоненты разных моделей. С его точки зрения жесткая типизация UML по объектам - преимущество, потому что у тебя не текстовые ярлыки, а типизированные объекты.

Написал собственный язык разметки для структурирования текстов, выделив объекты и написал расцветку. И пишет в нем. Были примеры.

Оставаясь лидером

• Продажа идей
• Быть рядом, но не мешать
• Поддержание безопасной атмосферы и комьюнити
• Мини-цикл фаз 1-2-3

Дмитрий Кондрашкин из Яндекса. Архитектура рекомендательной системы Дзена

Пост на FB Дмитрий Кондрашкин из Яндекса. Архитектура рекомендательной системы Дзена. Технический доклад о переходе от расчета вектора пользователя для рекомендации документа online, у которой ряд недостатков, к фоновым регулярным полным перерасчетам векторов пользователей раз в две недели, пересчетов векторов документов раз в полчаса, а затем обновление векторов пользователей с учетом новых документов. Что дало 20% по производительности в выдаче рекомендаций, но главное - позволило активно экспериментировать с моделями, потому что модели считают в отдельном потоке, а не в основном, который формирует ответ пользователю, и там не страшно падение или проблемы производительности.

Андрей Зубков (Евраз). ML в промышленности: задачи и проблемы

Пост на FB Андрей Зубков (Евраз). ML в промышленности: задачи и проблемы. Несколько лет назад на IT-конференции массово пришел ритейл - Ламода, Леруа, Спортмастер и другие. Сейчас - следующая волна, приходит реальное крупное производство, ему тоже нужны IT-шники, и у них есть современные интересные задачи, по которым можно получить реальный эффект. И дефицит желающих работать.

Андрей рассказывал о проекте оптимизации коксохимического производства - есть входной поток угля со своими параметрами, которые все время меняются, и надо предложить параметры шихтования, чтобы на выходе был кокс лучшего качества по некоторому набору параметров. Реальный эксперимент долог и дорог. делала команда из 7 человек, трое технологов из производства и четверо Data Scientist. При этом физико-химической модели шихтования на реальном оборудовании - нет, лабораторные данные - на малых объемах, и их недостаточно для прогноза. Простроили статистическую модель, начали рекомендовать, годовой эффект проекта 218 млн, что 0.5% для этого производства, но по сравнению с затратами на проект - кратно много. И это - первый шаг, и пример одного проекта, которых много. Поэтому те, кто хочет увидеть нанесенную пользу немедленно, и быть уверенным в том, что это - именно результат его проекта - приходите. И задача цифрового двойника для всей технологической цепи - тоже стоит, просто идти к этому будут маленькими шагами. При этом организационно - Agile и проверка гипотез, Производство и бизнес просто обозначают проблемные точки, а дальше ты порождаешь гипотезы о решениях и проверяешь их, и неверная гипотеза - тоже нормально.

Анатолий Анфиногенов. Миграция приложения Oracle PL/SQL на Postgres pl/pgSQL

Пост на FB Анатолий Анфиногенов. Миграция приложения Oracle PL/SQL на Postgres pl/pgSQL: планирование, подготовка, переход и два года жизни с новой БД. Тоже рассказ из мира enterprise. Перенос системы расчета расписаний движения поездов РЖД с Oracle на PostgreSQL. Задача возникла из импортозамещения, поэтому они не могли использовать версию про, а нужна была бесплатная международная версия. В приложении 250 таблиц, 50-150 Мб данных, 200 хранимых процедур, 60k строк кода. При этом полных аналогов для многих конструкций нет: нет автономных транзакции нет, временные таблицы работают не совсем так, null и пустая строка различаются, RowID отсутствует (вернее, устаревший), типы данных типа int лучше преобразовывать в типы с заданной точностью и так далее. Поэтому придумали инфраструктурный workaround, потом перенесли код - есть конвертер, после которого идет проход руками. А потом была оптимизация, первый расчет расписания работал 19 часов вместо 10 минут на Oracle. B был рассказ про оптимизацию и конкретные отличия. В презентации и докладе все это рассказано достаточно подробно, так что можно опираться, если стоит аналогичная задача. Проект занял у двоих человек один год, потом был старт на одной из железных дорог и параллельная эксплуатация на других, а затем - переключение.

Александр Токарев и Павел Журов. Где деньги, Лебовски?

Пост на FB Александр Токарев и Павел Журов. "Где деньги, Лебовски?", или Почему пора перейти на FinOps. У меня сложное отношение к докладу. Проблема, которая лежит в основе - понятна. После того, как перешли на облака расходы на железную инфраструктуру стали переменные, выясняются по факту, и могут быть сильно волатильными. При этом все падает в общий счет, и пока он был невелик - то это никого не волновало. А сейчас он стал большим и у ответственных за расходы появляется мысль: наверное, эту цифру можно (и нужно) уменьшить. Первый шаг тут понятен: для начала надо разметить этот счет на части, которые правильно отнести на центры затрат - бизнес-подразделения и команды. Финансисты умеют это делать равномерно или по числу сотрудников а тут надо по-другому, исходя из фактического использования.

Решение этой проблемы названо громким словом FinOps по аналогии с DevOps - устранение разрыва между разработкой и сопровождением. Хотя речь идет о взаимодействии финансистов и разработчиков, так что говоря строго уместным будет термин DevFin...

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

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

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