Highload++ 2024

Всем привет! Появилась возможность выбраться на конференцию, поэтому хотел бы поделиться докладами, которые удалось посмотреть:

Nvidia Triton Inference Server: строим production ML без разработчиков

Не смотря на название, выступление не было скучной лекцией формата 101. В докладе разбирается продовая архитектура в части услуги развертывания gpu серверов от компании, предоставляющей облачные ресурсы. Помимо полученных лучших практик по скалированию, используя связку k8s+triton+ray+prometheus+grafana, спикер также делится полезными хаками, такие как: упаковка образов в zsdt для параллельной разархивации, kiali - для визуализации трейсов трафика в графане, табличка выбора тулов для шаринга gpu ресурсов, автобатчинг в triton.

Как масштабировать защиту от DDoS-атак на десятки миллионов RPS. Опыт Яндекса

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

Буду предвзят в силу некоторого опыта по вопросу ddos-атак:
- Тема качества рассказанной архитектуры не раскрыта. Да, было пару инцидентов, но метрик качества ML моделей/рулов/их комбинации не приведено. Также не рассказали о пропорциях трафика: какая доля отсекается на капчу/блокировку ML моделью, сколько общий первый этап классификации (кэшер), какой дифф качества у второго этапа классификации по сравнению с первым.
- Вопрос slow-ddos не затронут
- К признакам/факторам для ML модели второго уровня также возникли вопросы: тысячи признаков/факторов используются, при этом среди них есть абсолютные количественные значения (например rps), что неминуемо приведет модель к оверфиту на истории, деградация приложения будет расти стремительно по мере развития сервиса, наличия промо/праздничных дней и т.д.
- не рассказали инженерку: на чем считают фичи, как передаются данные, как хостятся модели, как составляют id пользователя

Исправлять — не искать. Разработка и внедрение AI-ассиcтента для исправления уязвимоcтей в коде

Чему посвящен доклад понятно из названия, в докладе хочется отметить следующее:
- выбран топорный sast инструмент с высоким recall, модель затачивают на precision.
- для сравнения ответов моделей проводились опросы внутри AppSec отдела (внутренняя ллм арена, хех).
- Составлен качественный бенчмарк оценки качества и представлено сравнение открытых моделей на нем
- В sast&llm проектах стоит вопрос извлечения релевантных сниппетов кода в диффах репозиториев. Понравился подход, основанный не только на ast (позволяет взять связанные методы, а не просто соседние N строк), но и на dfg с разделением на входные и выходные потоки (Позволяет сократить сниппет по ast).
- Ключ к апробации ллм проекта - принудительный резолв сканирований на всю компанию:) (с предварительным MVP на 20 команд)
- В докладе также есть слайды с большим числом лучших практик и советов из собственного опыта по проекту, где каждый может найти что-то полезное для себя.
- Доля фиксов по сработкам SAST повысилась с 4% до 14% (тут вопрос - это принудительный резолв критов или импакт ллм?), в целом есть слайд с собранными метриками, можно с появлением записи посчитать интересующие бизнесовые показатели