Доклады секции "Бэкенд, теория программирования"

В нашем продакшене ML-модели используются давно, и во многих сервисах они развивались параллельно и реализованы у кого как. Настало время унифицировать инференс и повысить производительность. Чтобы избежать требования переписать весь ML, мы решили написать общее ядро для инференса деревьев решений, которое бы работало идентично xgboost/catboost, только в рамках наших ограничений (CPU и один поток). В итоге получилось сделать отдельные алгоритмы, работающие как оригинальные, но обгоняющие их по скорости.

В докладе будет как про низкоуровневые оптимизации (включая cache locality и доступ к памяти), так и про ML-специфику, и про внутренности xgboost. Попробую дать общие советы, как лучше обучать модельки, если вы хотите сильно запариться, но ускорить их вычисление под нагрузкой.

0. Введение:
- Немного про логические и бинарные бэкапы
- В MongoDB Community убрали возможность физических бэкапов
- Следовательно, нужно добавить её обратно

1. Про движок MongoDB - WiredTiger:
- Немного про MMapV1 - предшественника WiredTiger
- Общая архитектура WiredTiger

2. Как бэкапить WiredTiger:
- Низкоуровневая организация хранения данных в WiredTger
- Как уплотненяются данные
- Курсоры - способ доступа к данным(и не только)
- WT_CURSOR_BACKUP - способ создания резервных копий
- Что, если скопировать WT_CURSOR_BACKUP?

3. Применяем знания на практике:
- Пишем новые стадии агрегации, чтобы соответствовать интерфейсу MongoDB Enterprise и PSMDB
- $backupCursor и $backupCursorExtend - описание
- $backupCursor и $backupCursorExtend - реализация
- Как воспользваться ими для снятия бэкапа

Доклад посвящён паттерну запуска задач по расписанию на бэкенде.

Мы подробно рассмотрим сам паттерн, какие проблемы он решает и варианты его реализации на Go, Python и Java.
Самые часто возникающие ситуации - это пакетная обработка большого количества запросов и ретраи.
Я выделяю как минимум четыре разных подхода к реализации: в памяти, персистентный, встроенный во фреймворки и внешний.

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

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

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

Все мы знаем, что для эффективной балансировки необходим хороший алгоритм. Современные алгоритмы могут динамически определять перегруженные инстансы сервисов и эффективно снижать квантилии ResponseTime сервиса. Но так ли это? Обсудим то, что мы, в OzonTech, смогли увидеть на своих сервисах под нагрузкой более 1 миллиона RPS.

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

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

Бэкенд Яндекс Вертикалей живёт в монорепе. В ней четыре миллиона строк кода, за которые ответственны 15 команд, и эти числа постоянно растут.

Flaky тесты — наша болезнь роста. С ней концепция 100% зелёных тестов становится проблематичной, т.к. юнит-тесты всё время флакают и краснят билд.

Мы, как команда монорепы, эффективно решили проблему с flaky тестами всех наших команд, не разбираясь детально с каждым проблемным тестом — в режиме blackbox. Мы пришли от кошмарных >= 5% фейлов сборок от flaky — к приятным <= 1%.

Слушатели узнают про эффективные способы борьбы с flaky тестами — в первую очередь, карантин. И поймут на нашем опыте, какие у этих способов есть подводные камни, и как их обходить.