Для чего действительно нужны нейронные сети? Разбираемся на примере чатбота, когда нужно реализовывать state-of-the-art научную статью, в каких случаях можно обойтись логистической регрессией, а когда лучше вспомнить про старое-доброе префиксное дерево.

В сети X5 Retail Group 14к+ магазинов, в которых будет развернута видеоаналитика по определению различных показателей и явлений на полках с продуктами. А именно: детектирование возникновения пустот, определение расстановки товара, определение факта подхода сотрудников или покупателей.

В докладе будет рассказано про основные подходы к решению задачи: сегментация пустот, сегментация людей, детектирование + классификация товара, детектирование промо-ценников. Будет описан процесс разработки пайплайна на примере соревнований по машинному обучению на платформе kaggle.

Также будут показаны примеры работы решения на реальных данных за разные временные отрезки.

Машинное обучение - это не только веб-сервисы на сверхпроизводительных TPU. В реальных условиях может потребоваться возможность применять ML-модели на конечных устройствах.

Например, мобильное приложение, которое должно работать в оффлайн, или Enterprise-сервис, который работает в закрытом контуре.

При этом не всегда есть возможность вместе с моделью внедрить специализированное оборудование и приходится запускаться на чем есть.

В этом докладе на примере одной конкретной модели машинного зрения я покажу, как её запустить:
- в облаке на GPU;
- в браузере клиента;
- на мобильном устройстве;
- на ноутбуке без видеокарты;
- на микросхеме за $10.

Покажу, какой trade-off требуется в каждом случае и что происходит с производительностью и качеством.

Команда Computer Vision Mail.ru предоставляет решения для нескольких продуктов Mail.ru: Облако, Vision (b2b-продукт), Почта. Спектр проектов достаточно широкий и включает в себя такие задачи (но не ограничивается ими), как Face Recognition, OCR и реставрация фотографий. За несколько лет работы мы споткнулись обо всевозможные грабли и встречаем одни и те же челленжи:
* Какие архитектуры нейросеток, подходы, хаки работают на большом спектре задач ?
* Как организовать инфраструктуру для удобного обучения моделей ?
* Каким образом катить и сервить модели в проде, чтобы это было удобно для всех?

В своем докладе расскажу о полном жизненном цикле проектов в Computer Vision: от постановки задачи до запуска в production.

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

Новые вызовы и трехскоростное ИТ
Поговорим о том, как ускорить время разработки новых API-сервисов, которые должны быть надежными и выдерживать большую нагрузку. В каких кейсах лучше применять микросервисы и agile-подход, в каких использовать старый добрый waterfall и зрелые технологии.

Платформа микросервисов (CI&CD)
Опыт создания цифровой экосистемы микросервисов, архитектура и используемые технологии. Практический опыт создания микросервисов от идеи до запуска в промышленную эксплуатацию.

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

Нас ждет:
* архитектура любого сервиса звонков;
* разбор топологий построения конференц-звонков и сравнение подходов конкурентов;
* сделаем конференции на 100 участников на WEB, iOS, Android;
* узнаем, почему в WhatsApp максимальное количество участников в конференции 4, в Hangouts - 20, а в Zoom - 100.

Расскажу, как нарисовать картину мира служб и отыскать слабое звено в большом количестве сервисов. Как узнать за пять минут зону ответственности служб, и почему менять API - это не так сложно, как кажется.

Мы рассмотрим работу Zabbix с базой данных TimescaleDB в качестве backend. Покажем, как запустить с нуля и как мигрировать с Postgresql. Также приведем сравнительные тесты производительности двух конфигураций.

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

Расскажу, что вообще можно считать в банке, и как мы оптимизируем расчеты рисков по деривативам. Постараюсь объяснить, для чего нам нужен грид на 15к CPU и как оптимально загрузить его расчетам.

Посмотрим, почему уплотнение хранения и передачи имеет ценность. И можно ли вообще иногда ничего не считать и воспользоваться аппроксимацией значений. Какие есть за и против в GC free код или Immutable, protobuf или json. Как в java одновременно работать с C++ и ReactUI и при этом не уронить прод с EXCEPTION_ACCESS_VIOLATION.

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

В докладе я коротко упомяну о сделанных ранее правках (патчах), которые существенно расширяют возможности системы и готовят базу для кластера (выгрузка истории в кликхаус, асинхронный поллинг). И подробно рассмотрю вопросы, возникшие при кластеризации системы — разрешение конфликтов идентификаторов в БД, немного о "CAP theorem" и мониторинге с распределенными БД, о нюансах работы Zabbix в кластерном режиме: резервирование и координирование работы серверов и прокси, о "доменах мониторинга" и новом взгляде на архитектуру системы.

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

В докладе будут рассмотрены популярные расширения TimescaleDB и PipelineDB для PostgreSQL, позволяющие хранить и обрабатывать time series данные.

IT в общем и IoT в частности продолжают непрерывно проникать во все сферы деятельности человека, требуя хранить все больше данных. Если есть экспертиза в PostgreSQL, но пока рано говорить о BIG DATA, стоит посмотреть в сторону расширений для вашей реляционной СУБД. Возможно, этого будет достаточно!

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

В докладе расскажу об архитектуре и принципах построения Shardman - расширения СУБД PostgreSQL для вычислительных систем с Shared-nothing-архитектурой, разрабатываемого компанией Postgres Professional. Приведу сравнение с Postgres-XL и GreenPlum. Опишу прогресс, достигнутый за год, и новые расширения для планнера PostgreSQL, позволяющие более эффективно задействовать узлы вычислительной системы для обработки сложных запросов.

Yandex Database – горизонтально масштабируемая геораспределенная отказоустойчивая СУБД, выдерживающая отказ дисков, серверов, стоек и дата-центров без нарушения консистентности. Для обеспечения отказоустойчивости применяется собственный алгоритм достижения распределенного консенсуса, а также ряд технических решений, которые детально рассмотрены в докладе.

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

В PostgreSQL долгое время для этого не было встроенного механизма. Вместо этого использовался способ, основанный на наследовании таблиц. Способ, откровенно говоря, не без недостатков.

Поддержка секционирования впервые была добавлена в PostgreSQL 10. Декларативный синтаксис упростил создание секционированных таблиц, вот только "под капотом" так и оставались наследуемые таблицы. В следующих версиях 11 и 12 механизм был существенно доработан, а многие недостатки и ограничения устранены.

Что же именно умеет декларативное секционирование в PostgreSQL 12 и что еще можно улучшить?

О контейнерных базах Oracle, краткий обзор технологии:
- понятие мультиарендности (Multitenant);
- преимущества технологии Multitenant;
- особенности реализации в Oracle.

Использование контейнерных баз в качестве макетов:
- Методика развертывания макетов на PDB
* Создание эталонных баз;
* Получение макетов из эталонной базы.
- Сравнение макетов на виртуальных машинах и PDB
* по затрачиваемым ресурсам (память, ЦПУ, дисковое пространство);
* по временным показателям (развертывание, обновление, удаление лишних копий);
* по удобству управления макетами;
* по пригодности для проведения нагрузочного тестирования.

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

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

Мы расскажем о самом эффективном алгоритме поиска подстроки или одновременно нескольких подстрок, о котором вы услышите впервые и который был внедрён в ClickHouse. Мы покажем, какие трюки использованы для поиска регулярных выражений, как поискать сразу по многим регулярным выражениям, как эффективно обрабатывать UTF-8 строки. Также углубимся в тему о том, как найти похожие строки и какие трудности возникают в определении "похожести".

Бывает, что практические требования конфликтуют с теорией, где не учтены важные для коммерческого продукта аспекты. В этом докладе представлен процесс выбора и комбинирования различных подходов к созданию копонентов causal consistency на основе академических исследований исходя из требований коммерческого продукта. Слушатели узнают о существующих теоретических подходах к logical clocks, dependency tracking, system security, clock synchronization, и почему MongoDB остановились на тех или иных решениях.

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

Для начала мы провели нагрузочное тестирование на части бизнес-логики, переписанной на GraphQL. Результаты, полученные в тестировании, дали нам общие ответы на вопрос - в каких проектах стоит внедрять GraphQL, а в каких эффективнее остаться на Rest.

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

Девопс кажется недостижимой мечтой, а лечь в направлении цели хочется уже сейчас? Нам тоже.

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

Расскажу нашу историю успеха и поделюсь лайфхаками и подводными камнями.

В Рекламной Платформе Тинькофф множество микросервисов. Они живут в докер-контейнерах и постоянно гоняют трафик между собой по различным протоколам, как человеко-читаемым, так и не очень. Любое API нашей Платформы подвергается тщательному автотестированию, но синтетических данных не всегда достаточно для оценки качества выпускаемого продукта. У нас было желание посмотреть, как ведут себя проверяемые системы на реалистичном боевом трафике.

Загуглив "зеркалирование трафика", мы нашли несколько миллионов результатов, но их топ – про аппаратные решения. В Рекламной Платформе у нас нет ни желания, ни ресурсов разбираться с железками для такой задачи. Вместо этого, мы нашли 8 способов отзеркалить трафик с нашего продакшна, используя только бесплатные софтовые решения.

Бонусом представим собственный инструмент, который сейчас предпочтительно используем на проекте и хотим развивать при участии opensource-сообщества.

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

Ключевым элементом нашей внутренней инфраструктуры тестирования производительности являются генераторы нагрузки, в качестве которых мы используем решения на базе Yandex.Tank (phantom) и Yandex.Pandora, но не ограничиваемся ими. Для обеспечения качественных результатов тестирования мы хотим быть уверены, что выбранные (или выбираемые) нами генераторы нагрузки соответствуют накладываемым на них функциональным и нефункциональным требованиям. Для решения этой задачи мы используем отдельную среду для тестирования компонентов инфраструктуры тестирования производительности, в том числе генераторов нагрузки.

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

Команда Computer Vision Mail.ru предоставляет решения для нескольких продуктов Mail.ru: Почта, Облако, Vision (b2b-продукт).

Количество работающих в проде нейросеток исчисляется десятками, но количество запросов к каждой модели разное: от 1 запроса с лендинга до 300,000 в минуту от Облака@Mail.ru. Разные архитектуры, разные паттерны нагрузки, разные фреймворки, постоянно нарастающая нагрузка на бэкенд — все это порождает серьезные сложности на пути построения универсального бэкенда. В рамках своего доклада я расскажу про самые удачные рецепты, которые зашли у нас.

Я также расскажу о том, как нам удаётся поддерживать зоопарк фреймворков (pytroch, TF, caffe, ...). Как мы используем Kubernetes для шедулинга моделей по серверам. Расскажу о преимуществе использования nvidia-docker при запуске приложений, работающих на GPU.

Я расскажу об использовании NodeJS на примере Bolt (платформа, предоставляющая услуги райд-шеринга, такси и проката электросамокатов 25 миллионам пользователей в 30 странах) и поделюсь практическим опытом разработки высоконагруженного бэкенда на TypeScript/JavaScript:
* как эффективно использовать плюсы и нивелировать минусы NodeJS;
* микросервисная архитектура и масштабируемость;
* интеграционное тестирование;
* мониторинг.

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

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

Проблема, которая стояла перед разработкой:
- Предыдущая версия модуля не справляется с пиковыми нагрузками.

Задачи:
- Реализовать модуль уведомлений, который справляется с нагрузкой X2 на процессинг.
- Разработать модуль, который борется с проблемой увеличения нагрузки за счет изменения настроек системы.

Технологии:
- apache kafka;
- spring boot 2;
- oracle.

План доклада:

* Что такое распределенная очередь сообщений.
* Классификация распределенных очередей.
* Практические задачи, решаемые распределенными очередями.
* Понятие доставки сообщения.
* Семантика доставки at most once с примерами.
* Семантика доставки at least once с примерами.
* Семантика доставки exactly once с примерами.
* Комбинирование семантик доставки сообщений.
* Способы достижения exactly once при участии клиента.
* AWS SQS API: CreateQueue, SendMessage, ReceiveMessage, DeleteMessage.
* AWS SQS STD/FIFO-очереди и работа с сообщениями.
* Архитектура YMQ (AWS SQS API over YDB).
* Создание очереди при сбоях: двухфазный коммит и сборка мусора.
* Понятие мастера очереди.
* Преимущества мастера. Кэш сообщений, быстрые метрики.
* Преимущества мастера. Уменьшение конкуренции при доступе к данным.
* Преимущества мастера. Легкое квотирование.
* Преимущества мастера. Батчинг запросов.
* Универсальный батчинг для очередей с разным профилем нагрузки.
* Сложности с мастером: два мастера, ноль мастеров.
* Сложности с мастером: отказоустойчивость и масштабируемость.
* Тестирование распределенной очереди.

Изначально задача была такова – есть система обработки транзакций (процессинг), нужно было организовать сбор и хранение данных для проверки транзакции на фрод в режиме реального времени, обеспечить расчет и выдачу персонифицированных свойств сервисам для принятия маркетинговых решений опять же в RT. Далее по собранным данным предполагалось построение моделей для машинного обучения и их перепроверки в прошлой перспективе. И все это требовалось сделать так, чтобы не увеличить нагрузку на существующую процессинговую систему, а перенести ее на горизонтально масштабируемую платформу. Также требовалась возможность подключать другие системы, поставляющие другие данные, которые могут дополнить общую картину, и все это без необходимости программирования.

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

Далее был проведен анализ подходящих систем для хранения данных. В результате была выбрана Кассандра. Обновление данных было реализовано идемпотентным образом, что позволило гарантировать консистентность данных очень дешевым способом. Раскладка данных по различным хранилищам и способы их идентификации максимально используют возможности масштабируемости Кассандры, что позволяет выдавать по запросу сервиса довольно большой набор данных, который собран по параллельно исполняемым запросам к многим нодам кластера Кассандры. Это позволяет с миллисекундными задержками выдать, например, досье клиента, списки последних операций, клиентов, с которыми он взаимодействовал, страны, города, где он совершал операции, досье контрагента и связанные с ним списки и счетчики и др. Запрос данных также может быть задан с помощью описания плана запроса, клиенту лишь необходимо указать идентификатор плана запроса и параметры запроса, в результате система вернет единый JSON-документ, содержащий все требуемые сервису данные.

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

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

Наш подход использует все преимущества метаданных, динамического кода SQL и кодогенерации на основе Swagger codegen и handlebars. Это решение сокращает время разработки и переконфигурации системы, а добавление новых объектов управления не требует ни единой строки нового кода.

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

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

В своем докладе мы расскажем об архитектуре системы мониторинга, созданной в Яндексе на базе NewSQL-базы данных — Yandex Database (YDB), при помощи которой нам удалось решить перечисленные выше проблемы и выдержать нагрузку в миллиарды хранимых метрик с историей в несколько лет, а также поток в несколько сотен миллионов записываемых метрик в секунду.

Доклад расскажет об основных аспектах управления трафиком в поиске на Яндекс.Маркете.
- Балансировка трафика и отказоустойчивость сервиса;
- Надёжные обновления;
- Параллельные мониторинги;
- Эксперименты и отладка новых технологий в production;
- Инструменты для тестирования производительности на всех этапах разработки и выкатки.

В докладе я расскажу о нашем решении централизованной обработки и трассировки логов для микросервисной архитектуры, которое обрабатывает более 100K событий в секунду в 10 дата-центрах.

Мы рассмотрим архитектуру и эволюцию системы, грабли, на которые мы наступили, а также практику работы с кластерами Elasticsearch и их администрирования в условиях ограниченных ресурсов.

Масштабируемость — это базовое требование к любой архитектуре. Конечно, проектируя решение, мы учитываем не только выделение CPU и RAM виртуальных машин, но и адаптивность всей инфраструктуры, включая сеть, хранилища, базы данных и пр. Потребители облака Amazon пользуются эластичными сервисами и инфраструктурой, но обычно не задумываются, как они реализованы. Да и сама AWS тоже не торопится делиться внутренними техническими деталями.

На сессии мы раскроем некоторые подробности об устройстве облака Amazon. Поговорим о том, как AWS улучшает производительность виртуальных машин, одновременно уменьшая их цену; как обеспечивается масштабируемость и изоляция мульти-тенантной сети; что находится под капотом серверлесс-функций и как реализована "магия" эластичности одного из сервисов баз данных.

Знание архитектурных подходов Amazon поможет вам более эффективно использовать сервисы AWS и, возможно, даст новые идеи по построению собственных решений.

У нас на руках был один монолитный клиент и две задачи:
1) Загрузить целевой контент пользователю как можно быстрее.
2) Сделать так, чтобы разрабатывать клиент могло гораздо больше разработчиков, чем сейчас. Например 50.

Результаты:
1) Разрезали клиент на лениво-загружающиеся модули и ускорили загрузку приложения в 3 раза.
2) Новые фичи в продукте можно писать так, чтобы они загружались отложенно и минимально влияли друг на друга.

Расскажу, как организовали файловую структуру проекта и какие проверки добавили с помощью Webpack, чтобы один случайный импорт не убил все оптимизации. Опишу, что такое ленивый модуль. Расскажу об особенностях разрезания приложения, написанного на TypeScipt и AngularJS. И опишу принципы, которым мы теперь следуем, чтобы поддерживать достигнутые показатели.

Инфраструктура любого сложного проекта сегодня представляет собой подобие многоэтажного жилого здания. Кто-то следит за состоянием здоровья жильцов в квартире, кто-то — за коммуникациями в самих квартирах, кто-то — за состоянием всего здания и коммуникаций в нем.

За последние 10 лет "многослойность" систем существенно выросла. Приложение, которое развернуто в Kubernetes, который развернут в Openstack, который, в свою очередь, уже развернут на настоящем "железе" — звучит не как безумный зоопарк, а вполне "живой" (и практически применяющийся) кейс. Сервисы приложения при этом могут коммуницировать между собой через шину на Kafka.

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

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

Я расскажу, как мы комплексно подошли к проблеме отказоустойчивости PostgreSQL, какие варианты мы рассматривали и как остановились на Patroni.

Доклад содержит этапы тестирования этого решения и примеры, как мы обеспечили быстрое внедрение на production.

ClickHouse-кластеры в Kubernetes? Зачем и как это делать. Как автоматизировать развертывание и управление кластером при помощи Altinity ClickHouse operator for Kubernetes.

Мы долго жили с самописным подсчётом метрик на местах. «Гибкость» этого подхода приводила нас в уныние. А потом мы попробовали ClickHouse и подсели. Так у нас появились те самые графики о работе:
* нашего CDN — от стандартных rps и трафика до выявления аномалий;
* транспорта статистики — вплоть до поиска потерь и дубликатов.

Мой доклад будет интересен тем, кто хотел попробовать ClickHouse, но не смог убедить себя и начальство в целесообразности его внедрения.