Стрим о защите контейнеров, который нельзя пропустить

Утёнок — для привлечения внимания.

28 мая в 11:00 на стриме разберём угрозы для контейнерных сред и где их ловить по пути от кода до кластера. Покажем, как новинки в Kaspersky Container Security меняют игру в защите контейнеров: от глубинного анализа образов с помощью ИИ до кастомных политик в пару кликов. За комплексный взгляд на тему отвечает специальный гость из платформы «Штурвал».

Чтобы не пропустить, регистрируйтесь.

О бенчмаркинге, часть 1

Бенчмаркинг занимает значительную часть моей повседневной работы, поэтому важно понимать его основы, типы и ограничения.

По сути, это способ оценить производительность системы под нагрузкой.

Брендан Грегг в своё время ввёл наглядную терминологию: 
* Passive Benchmarking
* Active Benchmarking

———

Passive Benchmarking простой и распространённый подход: настраиваешь окружение, запускаешь нагрузку, получаешь на выходе цифры и в дальнейшем ими руководствуешься.

Но это как раз тот случай, когда «просто» не значит «лучше».

Проблемы таких замеров:
* риск измерить не то, что планировалось изначально
* непонятно, что именно ограничивает производительность
* нельзя отличить систематическое отклонение от шума (об этом позже)
* остаемся без ответа, почему получены именно такие результаты
* сами бенчмарки могут содержать баги, что останется от нас скрыто

«Бенчмаркаешь A, на самом деле измеряешь B, а выводы делаешь о C». ©

В итоге решения на основе таких данных могут оказаться даже хуже, чем если бы данных не было вовсе.

———

В противовес ему стоит Active Benchmarking (AB).

Помимо настройки окружения требуется активное наблюдение за системой во время прогона.

Задача понять:
* то ли мы меряем, что планировали
* что ограничивает производительность
* согласуется ли наблюдаемое поведение с нашей моделью системы
* что нужно изменить, чтобы улучшить результат

AB способен дать более надёжный результат.

Цена этого: более высокие требования к проведению эксперимента. Нужно не только уметь настроить окружение, но и верно интерпретировать наблюдаемое.

Алгоритм:
1. Собрать данные о работе системы, тулинг в помощь (perf, bcc, iostat, bpftrace, tcpdump, ...)
2. Интерпретировать, как реагирует система (методологии USE, RED, off-CPU, TSA, ...)
3. Применять в цикле:

запустил
 └─ пронаблюдал
    └─ сформулировал гипотезу во что упираемся
       └─ проверил в следующем прогоне
          └─ повторил

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

———

Вывод

Сырые цифры от Passive Benchmarking могут выглядеть правдоподобно и при этом вести к неверным и дорогим решениям.

Слепо доверяясь им, мы фактически надеемся, что угадали с сетапом с первого раза и учли все нюансы.

Не похоже на надёжную стратегию

Active Benchmarking напротив, позволяет избежать ловушки «бенчмаркаешь A, измеряешь B, делаешь выводы о C».

Цифры, полученные таким методом, поддаются объяснению, их можно оспорить и воспроизвести.

И на них уже можно опираться при принятии инженерных решений.

———

Что почитать
- Active Benchmarking
- CPU Benchmarks and Bad Tinder Dates
- Performance Methodologies
- Producing Wrong Data Without Doing Anything Obviously Wrong (тут может помочь заметка о чтении white paper)

To be continued...

———

Поддержать лайком на Linkedin.

Аудитные логи в облаке — отдельная распределённая система со своими требованиями к надёжности и стоимости хранения, а не «таблица с событиями».

Команда MWS Cloud Platform выложила подробный разбор архитектуры своего сервиса: от библиотеки, которую подключают сервисы облака, до хранилища на Apache Iceberg и движка StarRocks, с объяснением, почему выбрали именно такой набор технологий и где спрятаны неочевидные грабли.

Полезно всем, кто разрабатывает ИБ-инструменты, работает с большим количеством событий или просто интересуется инструментами безопасности в облаке.

Читать статью на Хабре