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

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-тестами — в первую очередь, карантин. И поймут на нашем опыте, какие у этих способов есть подводные камни и как их обходить.