Доклады

Какую файловую систему выбрать? В чём разница? Почему автор доклада стал контрибьютором OpenZFS?

Поcмотрим на проверенную боем Zettabyte file system, изучим её архитектуру и концепты в сравнении с другими файловыми системами, почему её хочется использовать (кто сказал "деградация данных"?), и когда её использовать не стоит (ммм, zero copy в Copy-on-Write).

Также не забудем о людях - обсудим коммьюнити, основные драйверы, как ФС может быть по настоящему кроссплатформенной, пережить родную ОС, и как ФС может жить вне ядра, не скатываясь в совсем нишевый продукт.

В докладе я хочу рассказать об эволюции системы поиска для онлайн магазина на примере крупного гипермаркета с примерно 1,5М уникальных товарных предложений и непростой системой их географического распределения. Система основана на ElasticSearch + Golang. Это будет повествование с несколькими примерами продуктовых и технических задач, каждая из которых познакомит вас с каким-то аспектом работы с Elatic

Разберем вопросы хранения и обновления данных в реальном времени, методы ускорения товарных выдач, допущенные при проектировании и разработке ошибки и их цену.

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

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

Данные баннера нужно постоянно обновлять — они включаются, выключаются, обновляют какие-то свои данные, по ним пересчитываются эмбеддинги. Так что у нас потоковая обработка данных с результатом в виде актуального состояния данных баннеров в таблице (в YT).

Вроде все просто, какие тут могут быть проблемы? На самом деле проблемы ожидаемые, у нас же Highload, и, если работать с нашей таблицей с баннерами наивным способом, то будем создавать слишком большую нагрузку.

Наивный способ — это когда мы данные одного баннера храним в таблице в одной бинарной строке в сериализованном виде. А проблема с нагрузкой в том, что мы на каждое, даже очень маленькое изменение (допустим, изменилось 20 байт в состоянии), загружаем и пишем обратно все состояние (десятки килобайт).

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

Приходите, чтобы узнать новое, обсудить известное и поделиться своими идеями про работу с состояниями.

Sage — платформа мониторинга, позволяет собирать и анализировать логи и метрики со всех сервисов компании. Объемы логов постоянно росли и сейчас это 6 ПТ, а кол-во кластеров достигло 15 штук в двух ДЦ. На таких объемах вылезает много проблем: под нагрузкой кластера могут разваливаться, встроенный ILM уже не удобен, да и сопровождать это непросто. В докладе автор расскажет, как эти проблемы были решены в Sage, а также поделится информацией о внутреннем устройстве Elastic.

В современном мире ни один средний или крупный ИТ-проект и/или решение не обходится без аналитики. В высоконагруженных информационных системах с большим объемом данных – это особенно актуально. Аналитическая подсистема позволяет анализировать как данные, поступающие в реальном времени, так и исторические данные, диагностировать проблемы, выявлять тренды, строить прогнозы и планы на будущее, список можно продолжать бесконечно… Казалось бы, в чем тут проблема? Прикрути BI-систему и строй себе отчеты на оперативных данных. К сожалению, когда речь заходит про объемы данных, характерные для систем класса BigData, то это перестает работать и нужно строить отдельный аналитический кластер, который синхронизируется с оперативным хранилищем. Почему не работает подход с единой СУБД при очень больших объемах данных и как это сделать так, чтобы данные в аналитическом слое не отставали от оперативных и при этом не растерять эти данные по дороге, я расскажу в своем докладе.

Какова максимальная производительность MS SQL Server AlwaysOn.
Что нужно сделать чтобы достичь максимальной производительности.
Какие есть варианты если не хватает максимальной производительности.
С какими проблемами можно столкнуться на высоконагруженных БД. Варианты решения этих проблем.
Советы по настройке.
Про одну существенную неточность в официальной документации Microsoft по AlwaysOn.

Графовые СУБД в последнее время стали очень популярны для аналитических задач. Традиционно к графовым СУБД относились скептически из-за их производительности и масштабируемости: например, очень популярная СУБД Neo4j пока практически не масштабируется на несколько узлов. Но появились новые системы, изначально разработанные как распределенные графовые СУБД, которые в состоянии уже хранить и обрабатывать десятки терабайт данных, а в скором будущем смогут масштабироваться до петабайт.

В чем существенные отличия графовых СУБД, какие преимущества и новые методы они предлагают для аналитики, и почему будущее аналитики на Больших Данных может оказаться именно за графовыми СУБД?

В докладе расскажу про то, как мы в СберМаркете решали проблемы производительности on-prem Sentry — учили обрабатывать 60 миллионов событий в сутки, для чего пришлось провести оптимизацию почти каждого компонента.

Оптимизировали БД Postgres — научили Sentry работать не только с мастером, но и с репликами. Перенесли хранение событий в s3 и сэкономили 12 ТБ на БД (которые лежали в одной таблице!). Оптимизировали обработку событий из kafka — даже если у тебя есть буфер, не значит, что все будет стабильно. Научили работать с шардированным ClickHouse и максимально глубоко погрузились в архитектуру, чтобы достичь производительности, которую не позволяет даже Cloud Sentry.

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

Всего пять лет назад в Яндекс Вертикалях разработчики деплоили приложения deb-пакетами. Логи писались в файлы, деплой был долгим и неудобным, мониторинг и алерты лежали на плечах админов - и им же звонили. Мы жили на железе и ручном приводе. Из такой точки А начался наш путь к прекрасному PaaS будущего.
Теперь мы живем в облаке, у админов много автоматики и звонки только по ops-проблемам. Разработчики наших сервисов деплоят по кнопке из телеграм-бота или Web UI, пользуются автосгенерированными дашбордами, просматривают логи сервисов в Grafana и анализируют трейсы. В нашей платформе доступны canary- и branch-деплои и запуск периодических задач. Процесс подготовки сервиса к запуску - это написание карты сервиса и манифеста деплоя, что занимает минимум времени. И все это - без вовлечения в процесс службы эксплуатации.
В нашем докладе расскажем о трудностях, которые мы преодолели при переходе к концепции PaaS:
Как мы переехали с железа в Яндекс Облако: сервера приложений, базы данных, инфраструктурные сервера
Как мы выбирали компоненты инфраструктуры под капотом PaaS
Как мы перешли от статической конфигурации балансеров руками админов к динамической
Как писали Shiva - систему деплоя и инструменты автоматизации для упрощения жизни разработки

Мы хотим, чтобы конфигурация в гите всегда соответствовала конфигурации на серверах. Пока серверов было мало - конфигурация применялась быстро, но с ростом количества хостов - стало слишком долго.

Расскажем:
как управляем более 1000 хостов при помощи ansible с постоянным деплоем изменений на все сервера.
как мы написали ansible-agent, который экономит нам ресурсы и время, как он работает и деплоится на сервера.
как мы строим свой проект и как применяем AWX

Всё, что вы хотели узнать про Дата-центр Яндекса, но боялись спросить.
Пора узнать, как Яндекс подходит к процессу проектирования, строительства и эксплуатации своих Дата-центров.
Как собственные разработки Яндекса влияют на применение и повсеместное внедрение новых технологий в своих Дата-центрах и какую роль в этом играют серверы собственной разработки и производства.
Поговорим о том, как охлаждать серверы воздухом с улицы и не тратить при этом дополнительные деньги. А также узнаем, сколько человек нужно, чтобы обслуживать Дата-центр, по мощности равный небольшому городу.

Почему иногда во время звонка зависает видео от кого-то из участников? Почему видео может “пикселить” или напоминать слайд-шоу, и что из этого больше расстраивает пользователей видеоконференций? Как оценить качество видео и выразить эту оценку в виде одного числа?

Постараюсь раскрыть эти вопросы в своем докладе на примере VK Звонков — высоконагруженного сервиса видеоконференций, в которой ежедневно общаются миллионы людей. В докладе я расскажу, с какими вызовами мы сталкиваемся при передаче видео от участников звонка, как справляемся с ними, а так же как измеряем качество видео, чтобы быть уверенным, что действительно предоставляем нашим пользователям сервис высокого уровня.

Есть во вселенной такой алгоритм — raft. Он широко используется для решения задач консенсуса в распределенных системах (для наглядности — сервисы Etcd или Consul, как наиболее известные проекты его использующие).

Мастер-класс предлагает участникам поучаствовать в своеобразной настольной ролевой игре: каждый участник — это отдельный сервер. Вместо жесткого диска — листок бумаги и карандаш, вместо сообщений по сети — записки под партой. Игроки образуют единый кластер и стараются консистентно реплицировать данные, не страшась сбоев сети. Правила игры — это и есть алгоритм Raft, и мастер-класс дает возможность потренироваться исполнять его вручную.

Путь каждой компании к тому, чтобы наконец заняться кибербезопасностью - индивидуален. Но он всегда похож на 5 стадий принятия неизбежного “Отрицание”, “Гнев”, “Торг”, “Депрессия”, “Смирение”. Каждая из этих стадий сопровождается одним и тем же набором предубеждений о кибербезе, ошибочных действий и откровенного противодействия различных структур компании, вне зависимости от типа бизнеса. Я расскажу какие аргументы использовать и какие действия предпринимать для того, чтобы максимально быстро и безболезненно эти стадии пройти. А кто подумал, что их придется пройти лишь один раз? Уже существующему подразделению безопасности постоянно приходится доказывать свою необходимость и возвращаться к этим этапам.

В докладе расскажем, что такое система управления привилегированным доступом (PAM), зачем она нужна и каким критериям она должна соответствовать. Проведём краткое сравнение различных подходов к управлению доступом в высоконагруженных и распределённых Linux-инфраструктурах. Расскажем про свой опыт проектирования и внедрения системы управления доступом на основе open source решений и собственных разработок. Подробно остановимся на том, как внедрение таких систем влияет на изменение процессов эксплуатации, разработки и DevOps, а также разберёмся, влияют ли эти системы на time to market.

В докладе обсудим основные подходы к построению мониторинга информационной безопасности для высоконагруженной и распределённой Linux-инфраструктуры. Разберёмся, чем средства мониторинга ИБ отличаются от классических средств мониторинга. Проведём анализ и сравнение существующих решений, таких как go-audit, osquery, Wazuh, Elastic Agent и некоторых других. Расскажем, почему мы выбрали osquery в качестве ядра нашей системы. Поделимся проблемами, с которыми мы столкнулись при внедрении osquery, а также расскажем, как мы их решали. На практических примерах покажем, как внедрение системы мониторинга упрощает расследование атак. Обсудим, может ли такая система быть полезна командам эксплуатации и разработки.

Мир стремительно меняется и в настоящее время нужно быть максимально быстро реагировать на стремительно меняющиеся обстоятельства. Поэтому, все сложнее преставить себе высоконагруженное приложение без автоматизированной системы доставки и сборки (CI/CD), ведь использование CI/CD существенно ускоряет разработку и выкатку фич на продакшен. Вместе с ростом использования автоматизированных систем сборки и доставки растет и внимание злоумышленников к этим системам. А ведь действительно, использование этих систем таит в себе новые опасности.
В ходе доклада мы разберемся как защищаться от основных угроз в CI/CD

О форматах
Сравнение orc и parquet
Оптимизация хранения и доступа к данным

1. Что Такое MIR Accept 2.0 и как это работает
2. Сервис Принятия Решений (СПР) - антифрод наоборот
3. Frictionless зона
4. Зачем это банкам
5.Как использование ML улучшает точность рисковой модели СПР
6. Признаковое пространство ML алгоритма
7. Результаты применения ML: примеры оценки качества и финансовые выгоды для владельцев сервиса принятия решений и их потребителей

На прошлогоднем HighLoad я рассказывал пр свой опыт разворачивания геораспределённого отказоустойчивого S3-совместимого хранилища на базе MinIO. После этого мне на почту, что приятно, пришло множество вопросов касательно различных ньюансов. В этом году я бы хотел систематизировать ответы на них и представить в виде доклада широкой публике. Кроме того, я планирую рассказать о том, как развивался MinIO в течение прошедшего года, от каких минусов разработчикам удалось избавиться, а что до сих пор остаётся в виде подводных камней, на которые можно легко наступить и порезаться. Так же хочется рассказать об очень интересном опыте масштабирования MinIO - как мы расширили своё присутствие с 3 до 4 дата-центров, какой реальный прирост производительности дал переход от обычных дисков к дисковым массивам. С какими сложностями можно столкнуться при работе с этими массивами. Доклад ориентирован не на мостодонтов, создающих свои облака, таких как ребята и Яндекса или ВК, а на архитектров из компаний, представляющих малый и средний бизнес, у которых, однако, есть серьёзный потенциал роста и потребность в хранении данных в собственном периметре.

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

В докладе пойдет речь о том, как интегрировать обработку большого объема данных в онлайн- и офлайн-процессы кредитного конвейера.

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

Дано: высокая нагрузка, простои недопустимы. Нужно добавить новую фичу, а мы стажёр/новичок/впервые-видим-проект

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

Практический опыт интеграции ML в продакшн. Как мы делали "поиск по фото" для интернет магазинов
Блоки
1) Теория - эмбеддинги, векторный поиск
2) Обработка данных - удаление фона, выделение главного объекта на изображении
3) Хранение эмбеддингов, организация поискового индекса
4) Организация работы серверов для работы с векторным поиском.
5) Проблема похожести цветов, восприятие цветов человеческим глазом. Алгоритмы сравнения похожести цветов.

Когда мониторинга и статистики становится недостаточно для поиска всех слабых мест и бутылочных горлышек, хочется получать на бэкенде больше информации, что происходит во время обработки запроса: на что тратится время, какие методы выделяют больше памяти, в какие базы упирается сервер, насколько поток выполнения асинхронный и прочее. В целом, хочется иметь подобие вкладки Network в Chrome — но для бэкенда. Это называется трейсинг. Вроде как и материалов много, предлагаемых решений тоже, но — глаза боятся, путаешься, а как грамотно масштабировать на тысячи серверов — не ясно.

Попробуем всё разложить по полочкам на примере того, как мы организовали трейсинг внутри ВКонтакте и сделали интеграцию с Sentry: с учётом микросервисов, распределённых данных и практически zero overhead.

Каждый год мы с друзьями готовимся к HighSeason (период высокой нагрузки) на сервисы Сбербанк Онлайн

1. Вместе с участниками в виде интерактива попробуем подготовить Сбербанк Онлайн к периоду высокой нагрузки
2. Разберем входящие требования к системе
Нефункциональные - 200 тыс.входов в минуту/72 млн.MAU., ограничения в инфраструктуре
3. Окажемся в ситуации "косяка": за время со старта подготовки ИТ ландшафт изменился (Бэковая система не смогла пройти нагрузочное тестирование и нам срочно нужно их спасать).
ЧТо у нас могло пойти не так в этой ситуации: как в октябре бегать с горящими пятками и почему это не всегда так страшно
4. Поговорим о том, а какие паттерны отказоустойчивости мы используем в СБербанк Онлайн + поговорим о самой архитектуре детальнее.
5. Как мы управляем масштабными изменениями.
6. Где-нибудь еще расскажу о том, как мы стараемся управлять надежностью как продуктом и почему у нас это все время не получается.

Яндекс — технологическая компания, в которой работают тысячи разработчиков, которым нужна платформа предоставляющая всё нужное для разработки и эксплуатации написанных внутри Яндекса сервисов.

Вы узнаете основные вехи в эволюции внутреннего облака, в котором разработчики Яндекса запускают свои приложения. Внутреннее облака за 5 лет выросло от прототипа до платформы с десятком тысяч сервисов запущенных на более чем сотне тысяч серверов. В рассказе я буду опираться на свой опыт, ведь трансформация затронула и меня самого. Вместе с внутренним облаком я прошёл путь от разработчика до СТО Platform Engineering в Яндексе, частью которой является внутреннее облако.

Рассказ будет полезен всем, кто хотел бы узнать из каких этапов складывается эволюция подобных продуктов и с какими вызовами придётся на этом пути столкнуться.

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

Пройдемся по всем этапам от зарождения идеи, до ее реализации и разберём, как на каждом из них понять, что корректность не нарушена. Поговорим про TLA/TLC+, fuzzing и причинах, почему нам пришлось написать "свой" Jepsen.

Для того, чтобы защитить пользователей почты mail.ru от вредоносных писем и сообщений Антиспам Почты Mail.ru проверяет более 400 млн писем ежедневно.

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

Эта накладывает дополнительные ограничения на скорость и стабильность работы архитектуры антиспама.

Антиспам сегодня это 500 серверов, 40+ сервисов, работающих в k8s (более 7000 подов), размер hadoop-кластера 5+ PB.

В своем докладе на основе нескольких примерах рассказываю как на основе анализа произошедших инцидентов и ошибок эволюционировала архитектура антиспама, какие архитектурные решения оказались наиболее эффективными, а какие не сработали и почему.

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

В данном докладе я расскажу:
- какой путь проходит товар, чтобы оказаться в выдаче поиска,
- зачем нам понадобилось создавать целую систему хранения ML-фичей с нуля,
- какие хаки мы применили для уменьшения latency всего поиска,
- что мы сделали, чтобы справляться с миллионами запросов в секунду на терабайтные базы данных,
- как data scientist’ы получили возможность ставить AB-эксперименты не только с разными моделями, но и с по-разному посчитанными фичами,
- как мы минимизировали временные затраты разработчиков на добавление новых видов фичей.

Микросервисы это все еще новый черный. Любой продукт станет лучше если в нем есть блютус, блокчейн и микросервисы. Даже моя бабушка спросила - можно ли сделать микросервисную швейную машинку.

Но как оно на самом деле? Ждет ли вас “град на холме”?

В докладе я расскажу: о том как Авито шло к микросервисам. Это будет таймлайн история, где покажу разные этапы микросервисной архитектуры Авито. И на какие компромиссы шли в процессе

И расскажу что же в итоге получилось, и почему старички все еще грустят по старому доброму монолиту.

Проблема дискаверинга и балансировки нагрузки в межсервисном взаимодействии не новы. Существует ряд готовых решений, реализующий все 3 вида дискаверинга и балансировки (прокси, service mesh и look-a-side load balancing). Из популярных: nginx, isito и ряд других решений. Но около 3 лет назад мы в Ozon решили пойти своим путём, реализовав свой service mesh.
В этом докладе я расскажу про то:
1. Чего нам не хватило и что нас не устроило в готовых решениях
2. Какие собственные решения мы добавили в service mesh и к чему это привело
3. Почему мы переводим Ozon на grpc и как затюнить его в домашних условиях (и как это вам поможет)
4. Как мы объединили client side и look-a-side балансировку и зачем это нам было нужно

Наше объектное хранилище умеет жить сразу на большом количестве географически распределенных площадок и соблюдать сложные правила хранения, даже когда сеть между площадками пропала полностью или, что хуже, непонятно как. Расскажем как нам удалось поверх иммутабельного хранилища предоставлять изменяемый S3, #зачемздесьблокчейн и как жить в не астрономическом времени.

В этом докладе я пролью свет на трейсинг внутри Ozon и на то, как у него получается обрабатывать 5Gb/s трейсов. Речь пойдёт об архитектуре системы трассировки запросов, пайплайне обработки трейсов, методах хранения такого большого количества данных и, конечно же, о проблемах, с которыми мы сталкивались во время разработки и поддержки системы трейсинга.

Помимо этого расскажу и покажу, как мы строим граф взаимодействия (dependency graph) более 2 тысяч сервисов внутри Ozon, а также, как благодаря трейсингу, мы умеем выявлять наиболее ресурсоемкие запросы (critical path), например при загрузке какой-либо тяжелой страницы. Дополнительно затрону тему взаимодействия системы трассировки запросов с другими системами Observability внутри Ozon.

Путь пройденный командой развития Сбербанка Онлайн при построении надежной и отказоустойчивой архитектуры слоя хранения является уникальным и опыт полученный в процессе становления может стать подспорьем для развивающихся проектов идущих прямиком в «клуб HL+». Доклад призван в доступной форме рассказать об архитектуре сервиса Сбербанк Онлайн в части хранения данных и поделиться планами по импортозамещению СУБД.

Содержание:

- СБОЛ это платформа для реализации продуктов экосистемы Сбера;
- Архитектура строится вокруг 2 клиентов: Клиент Сбера и команды развития бизнес продукта;
- Данные СБОЛа делятся на 5 типов;
- End 2 End целостный клиентский блок - основа надежного и масштабируемого сервиса;
- Client Backup Layer, который развязал нам руки;
- Микросервисная архитектура платформы помогает нам мигрировать на PostgreSQL;
- Какие данные блока не прижились в Oracle и куда их отселяем. С какими проблемами столкнулись;
- СБОЛ 2025 Целевая картина хранения данных Сбербанк Онлайн;

Сервис MirAccept - что это
Какие задачи решает протокол MirAccept 2.0
Что нового по сравнению с устаревшим протоколом MirAccept 1.0
Верхнеуровневый обзор технологии
Применение систем рискового анализа
Как в будущем изменится клиентский опыт

1. Для чего нужны аппаратные модули безопасности и их применение в финтехе.
2. Чем мы пользуемся сейчас. И почему именно Thales.
3. Аппаратное устаревание модулей - как долго они работают и как часто их нужно менять.
4. Наша история импортозамещения - что случилось и как строился процесс.
5. Организация тестирования оборудования. Тестирование криптоядра и тесты операционной применимости.
6. Что мы ожидаем от новых модулей и как мигрировать на новое оборудование.
7. Вопросы сертификации и международной дистрибуции.

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

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

От некоторых кодов ошибок в мониторинге начинают шевелится волосы. Их бодрящий эффект понятен. Системы отказоустойчивости и резервного копирования спроектированы со всем вниманием к деталям, ошибкам прошлого и учётом прогнозирования будущего. Но внутренняя ошибка СУБД может иметь драматичный эффект.
В этом докладе я попробую систематизировать то, что видел при разрушении данных в следствие багов в разных СУБД, преимущественно из семейства Постгреса.