В докладе мы поговорим про:
- эволюцию и настройки сетевого стека TCP/IP в Linux и Android, iOS;
- разберем проблемы TCP: в плохих сетях, параллельной доставки данных, приоритизации, смены IP...
- поговорим про развитие QUIC и о проблемах UDP- и User Space-протоколов, особенно для HL-проектов;
- поделимся опытом написания своих сетевых протоколов в User Space поверх UDP, работающих для десятков миллионов пользователей.

Архитектура инвестиционного бизнеса Альфа-Банка была заложена в начале 2000-х годов. С тех пор мир пережил финансовый кризис 2008 года, появление криптовалют и mobile-first-революцию. Мир ценных бумаг и финансов стал доступен каждому, число торговых операций выросло на несколько порядков, усилилось регулирование рынка ценных бумаг.

В своем докладе мы:
- расскажем о том, зачем инвестиционному бизнесу Альфа-Банка понадобилось кардинально менять свою архитектуру и переходить на In-Memory СУБД;
- рассмотрим задачи, которые стояли перед нашей командой, и какую ценность инфраструктурный проект может принести бизнесу;
- поделимся опытом внедрения и тестирования прикладного решения на базе Tarantool;
- поговорим о том, какие бизнес-задачи уже решены, а также какие планируется решать на новой платформе в ближайшее время.

Давайте поговорим о том, почему Интернет вообще ещё существует?

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

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

А что у нас с "национальными" или просто очень крупными провайдерами? Авария у оператора CentruryLink в США, которая длилась больше двух суток, привела не только к перегрузке "альтернативных" операторов связи, но и к проблемам с доступностью экстренных служб 911 в пяти штатах.

С другой стороны, традиционные операторы теряют своё влияние. Google, Facebook, Amazon и другие "убивают" транзит, строя собственные сети и CDN, доставляя контент как можно ближе к пользователю, и превращают Интернет в набор независимых друг от друга сетей.

Government internet shutdown и блокировки - тема эта стала очень популярной в последнее время. И с ней тоже необходимо считаться.

Ну и, разумеется, никуда не делись старые-добрые DDoS-атаки. Последний отчёт Qrator labs наглядно показывает, что хотя их продолжительность и снижается (время - деньги!), но интенсивность растёт и появляются всё новые векторы.

Но есть же IPv6? В котором адресов хватит на всех, DDoS-атаки неэффективны за счёт разреженного пространства и трудностей в создании ботнетов? А с ним всё хорошо - вот только до сих пор присутствует проблема связности двух Tier I-операторов, так что Интернет v6 получается "разделённым" на две части.

И что же со всем этим делать? Помимо того, что обсуждать здесь, на Highload++ и других конференциях?

В первую очередь - участвовать в профильных сообществах и рабочих группах. Ну, или хотя бы мониторить. Обнаруживать блокировки в нужных вам странах, проверять доступность из тех регионов, в которых вы работаете (а лучше глобально). Ловить leak/hijack ваших префиксов (если у вас собственная автономная система). Отслеживать DDoS-атаки на ваши ресурсы и уметь от них защищаться. Наконец, использовать CDN и другие технологии для улучшения связности вашего бизнеса с клиентами.

И об этом мы тоже поговорим.

В докладе будет представлена новая платформа распределенной системы управления АЭС.

Вы узнаете, как обеспечивается управление сложнейшими объектами автоматизации в мире. В режиме жесткого реального времени обеспечивается работа более 150 специальных подсистем, управляющих различными технологическими процессами АЭС, таких как система управления реактором мощностью выше 1000 МВт и турбиной весом более 2000 тонн. Более 100К источников данных от датчиков и до 500К расчетных параметров. 5 разновидностей физических процессов: нейтронная кинетика, гидродинамика, химия, радиохимия и физика прочности.

При некоторых отклонениях вся система превращается в огромный источник DDoS полезной диагностической информации, которой всегда больше, чем способна переварить сеть и вычислительные ресурсы автоматизированной системы, что мешает нормальному управлению объектом. Вы узнаете, как мы «разруливаем» такие проблемы.

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

Но мы все же про кодинг. Никаких SSD и HDD, только InMemory, структуры данных из десятков миллионов элементов, забудьте про кэш процессора, он не работает. Ваш новый Xeon 4-го поколения потерял все преимущества и превратился в "тыкву", поэтому закатываем рукава и ковыряемся в таймингах, жесточайшей асинхронике и выжимаем из железа максимум. Кто слабое звено - процессор, память, ОС или сеть. Выясняем это.

В докладе расскажу о практиках работы с Postgres в сервисах на Go. Поговорим о преимуществах и недостатках основных инструментов, которые принято использовать при работе с Postgres в Go. Конечно, коснёмся нюансов, которые нужно учитывать, когда ваши сервисы работают внутри Kubernetes облака. Также расскажу об опыте Avito в предоставлении базы данных разработчикам продукта.

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

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

В этом докладе будет подробно рассмотрено следующее:
1. какие знания необходимы, чтобы создавать и поддерживать свои модули для NGINX (это включает экскурсию в ядро NGINX, модульную архитектуру NGINX и основные принципы разработки кода);
2. когда надо разрабатывать собственные модули на С;
3. когда лучше использовать NJS, Lua, NGINX.conf и т.д.

Этот доклад будет довольно технический. Чтобы извлечь из него максимум пользы, участникам необходимо иметь опыт работы с кодом NGINX, как минимум на среднем уровне.

В своем докладе я покажу, как такие классические задачи на многопоточность, как “Читатели и писатели” или “Обедающие философы”, благодаря отходу от классической Java Concurrency с блокировками, могут быть решены без блокировок на vert.x: полиглотном фреймворке для создания реактивных высоконагруженных приложений на JVM.

В докладе мы расскажем о том, как Data Science-команда Grid Dynamics с нуля собрала своё приложение для точного распознавания деталей по фотографии для одного из заказчиков. Дано: огромное количество позиций в каталоге (более 1.000 различных типов болтов), громоздкость фильтров, отсутствие четких описаний товара, невозможность сравнить интересующие позиции каталога - все это головная боль для покупателей одного из крупнейших ритейлеров.

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

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

В нашей компании Adalisk (подрядчик крупнейшей в США компании по зубному протезированию Glidewelldental) мы занимаемся автоматизацией производства зубных протезов – коронок, мостов, имплантов и т.д. Самая сложная и недетерминированная часть производства – дизайн протеза, который в настоящее время выполняется в CAD-системе на компьютере. Каждый протез делается под конкретного человека и уникален по своей геометрии, отвечая конкретному челюстному слепку, при этом у каждого дизайн-техника своё субъективное видение, что такое хорошая зубная коронка. Помимо задачи генерации дизайна, мы решаем также ряд задач по автоматической классификации входных данных: определение номера реставрируемого зуба, выделение его соседей и пр. В докладе будет рассказано о том, как мы автоматизируем различные этапы производства с помощью нейронных сетей, постепенно сводя влияние человеческого фактора к минимуму.

Даже в простых «потоковых» задачах типа предварительной сортировки массива входных зубных слепков по департаментам человек склонен допускать довольно много ошибок – в наших условиях несколько процентов; с помощью несложной распознающей сети процент ошибок можно понизить до долей процента.

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

Для решения таких задач ключевым компонентом с одной стороны является быстрый доступ к данным (общий объем наших данных составляет более 5 млн. кейсов, или порядка 150 Тб, они хранятся в облаке Amazon) и удобные средства для преселекции - выборки случаев с нужным зубом и типом реставрации и пр., для этого мы используем разработанный в компании сервис CMS+Orcas. С другой стороны, необходимо оперативно тестировать натренированные локально сети (разные сети при этом используют разные фреймворки), и с наименьшими изменениями переводить их из режима тестирования в рабочий, высоконагруженный режим. Для этого мы используем внутренний сервис DLFrame, который единообразно хранит и «прогоняет» сети, обеспечивая надёжность, быстрый отклик и масштабируемость.

Наша группа сотрудничает с институтом Беркли (США) в части разработки глубоких нейронных сетей. По результатам работы написана статья.

Два популярных метода изоляции многопользовательской нагрузки - Виртуальные Машины и Контейнеры. У каждого свои преимущества и недостатки. Какой использовать? Ответ - нужно взять все самое лучшее из обоих подходов, максимально упростить и протестировать на настоящем хайлоад. Это рецепт микро-виртуалок Firecracker. Получаем непробиваемую изоляцию виртуальных машин, которые можно запускать всего за сотни миллисекунд. Именно это решение работает под капотом Amazon Lambda и Fargate, обеспечивая запуск миллионов серверлесс-функций и контейнеров AWS каждую секунду.

Теперь этот мощный инструмент доступен в OpenSource. Если вы работаете с многопользовательскими нагрузками или просто делаете свое публичное облако, возможно, часть сервисов вы реализуете на Firecracker.

В рамках сессии мы поговорим об архитектуре Firecracker, о том, как он используется Amazon Lambda и как его можно прозрачно интегрировать с уже привычным способом контейнеризации containerd. Мы сравним его с альтернативными решениями, а также поговорим о планах на развитие.

Не всегда можно все взять и переписать. Не всегда можно просто отказаться от RDBMS росчерком пера. Существуют определенные стратегии работы с легаси-кодом, они понятны. Но есть еще Психология работы с легаси-кодом. И в большинстве случаев мы наблюдаем два полярных лагеря.

Сторонники "актуальных" инструментов гневно спрашивают: "Какое, вообще, у вас есть право использовать Oracle и лишать своих клиентов 24\7?".

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

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

Хочется провести митап, или круглый стол на эту тему. Обсудить объективные причины, по которым не все сервисы могут позволить себе резкий маневр на новые рельсы, как им при этом себя держать в тонусе и постоянно снижать роль легаси-ядра на системы, сервис и процессы, какие риски есть в бездумном переписывании всего на "как-бы" микросервисы, и как, работая в enterprise, совершать "революционную эволюцию", не занимаясь при этом непрерывной поставкой клиентам боли.

Два года назад мы (компания Scentbird), пережив серьезный рост, решили строить свою систему аналитики для обеспечения необходимой гибкости. На этом пути мы, конечно, не стали разрабатывать все с нуля, а использовали готовые компоненты, тем не менее даже при таком подходе, построение inhouse-аналитики оказалось нетривиальной задачей.

В отведенные 45 минут обсудим:
- какие готовые решения были выбраны нами и почему (рассмотрим наш выбор БД, ETL, BI-системы, а также вспомогательных систем);
- как из выбранных "кубиков" мы построили свою систему аналитики, и как она масштабируется;
- какие "грабли" на этом пути мы собрали;
- посмотрим на проделанный нами путь от самого начала и до текущего момента.

Доклад о том, как сделать жизнь наших пользователей лучше.

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

Одним из первых и самых живучих алгоритмов работы сервиса Яндекс.Такси был «жадный» алгоритм назначения водителей. От пользователя приходил запрос, в рамках которого мы находили самого подходящего по ряду критериев водителя. Со временем мы стали осознавать, что нам нужно что-то знать не только о том, кто из водителей находится вокруг пользователя, но и о том, какие заказы есть рядом, чтобы назначать водителей более эффективно.

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

* Serverless - другая архитектура наших прежних задач (подходы, проблемы и особенности решений).
* Зачем и почему мы сделали свое решение, и что из этого получилось.
* Примеры разработки вычислительных функций в распределенной и высокодоступной среде.
* Оптимизация и уплотнение вычислений на своих и/или облачных ресурсах.
* Пути сокращения расходов на ресурсы для "больших" вычислений.

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

Автор в докладе рассмотрит архитектуру текущего решения:
- как драматически уменьшить зависимость от внешнего API, которое ты не контролируешь;
- как не погибнуть при синхронизации данных;
- двойное кэширование и почему оно помогает работать быстро, надежно и стабильно;
- преимущества избыточной репликации данных и почему иногда дешевле поднять и переехать на новый кластер, чем пытаться оптимизировать старый;
- когда действительно нужна консистентность и почему иногда не стоит пытаться её достигать;
- за какими метриками нужно следить, чтобы не было “разрывов”.

Я расскажу про то, как мы организовали обмен информацией между серверами и кластерами в режиме реального времени с использованием UDP и Tarantool, почему взяли именно такую связку, как нам пришлось переписывать модуль tarantool с Lua на C.

В поисках улучшения масштабируемости и доступности многие команды начинают рассматривать возможности использования AP спектра CAP теоремы. В то же время разработчики программного обеспечения сосредоточены на создании отказоустойчивых систем, готовых к работе в production под нагрузкой с минимальной сложностью, а Eventual Consistency несет в себе опасность потери данных при использовании не синхронизированных состояний. Дмитрий поделится уроками, извлеченными при разработке распределенной системы на основе Eventually Consistent хранилища данных. Разработанное решение использует Conflict-free Replicated Data Types с отслеживанием причинно-следственных связей для достижения надежной согласованности критических данных при развертывании БД в нескольких дата центрах с асинхронной репликацией (Aerospike).

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

Рассмотрим следующие шаблоны проектирования, а также опыт их внедрения:
- Graceful degradation / Null object pattern.
- Bounded context.
- Circuit breaker.
- Работа с timeouts.

Помимо этого, рассмотрим такие аспекты как: health check, cold start.

* Убрать лишнее железо с прода – учимся правильно утилизировать ресурсы;
* делимся опытом исследований влияния масштабирования экземпляров микросервисов на производительность;
* закладываем основу под оркестрацию.

Мы рассмотрим эволюцию инфраструктуры интеграционного тестирования backend'а при переходе от монолита к микросервисам.

Будем активно использовать нововведения в JUnit5 и расширять его возможности.

При помощи docker и библиотеки test-containers будем тестировать интеграцию с базами данных (PostgreSQL, MongoDb), а также рассмотрим пример тестирования асинхронного взаимодействия с брокерами сообщений, такими как RabbitMQ или ActiveMQ.

По пути разберем некоторые подводные камни интеграционного тестирования в Spring Framework и варианты их обхода.

В докладе будет представлен проект, позволяющий расширять функциональность nginx на языке JavaScript.

Будут затронуты такие темы как:
* зачем в nginx нам понадобился скриптинг;
* зачем писать собственный интерпретатор с нуля, и почему существующие интерпретаторы нас не устраивают;
* почему именно JavaScript;
* что не так с lua/openresty;
* почему njs работает быстро;
* примеры использования.

Разработчики PVS-Studio продемонстрируют, как можно эффективно использовать инструменты статического анализа, как статический анализ может быть включен в CI (на примере стека "Docker + Jenkins + Maven + Java-анализатор PVS-Studio").

Также будет показан процесс интеграции сторонних плагинов (SonarJava, SpotBugs, PVS-Studio) в SonarQube для централизованного сбора и обработки результатов работы различных анализаторов.

С приходом Kubernetes мы получили универсальный ответ на многие вызовы инфраструктуры и CI/CD. Теперь, вне зависимости от нюансов инфраструктуры (типов серверов и облаков), мы готовим приложения одинаково. Теперь мы можем переезжать между ЦОД-ами и облаками практически безболезненно. К тому же, сам по себе Kubernetes, который обеспечивает нам этот замечательный фундамент — прост, как “пять бинарников”.

Однако, остаётся множество ситуаций, когда нам требуется как-то расширить и дополнить функционал Kubernetes. Например, оснастка в виде ingress-контроллера или сетевой подсистемы не входит в базовую поставку, а её корректная установка и настройка под кластер — это наша задача. Или нам потребовалось автоматизировать рутину, например, при создании namespace'а, подложить в него ключ для работы с registry. Казалось бы, есть и концепция оператора для написания своих обработчиков событий (SDK и многое другое) и менеджер пакетов helm для установки оснастки, но с ними все не так просто.

В этом докладе мы расскажем о том, какие решения нашли для себя. Как мы выстроили процесс управления дополнениями и как расширили функциональность в наших 75+ кластерах, расположенных в AWS, GCE, Azure, многих других частных облаках и на bare-metal. Посетив доклад, вы не только получите общее представление о проблемах и нюансах, но также получите мощные практические подходы и инструменты, которые позволят быстро и просто расширить и дополнить ваш Kubernetes.

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

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

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

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

Структура доклада:
1. Архитектура современного сложного проекта.
2. Мониторинг инфраструктуры и его специфика.
3. Мониторинг уровня виртуализации и его специфика.
4. Мониторинг уровня контейнеризации и PaaS и его специфика.
5. Мониторинг уровня приложений.
6. Трейсинг приложений.
7. Организация системы оповещения и расследования инцидентов.

Мой доклад будет состоять из нескольких мини-докладов, в которых я постараюсь рассказать про новую функциональность/улучшение/исправление и добавлю немного бэкграунда для лучшего понимания. Например, в 12 версии ожидаются поддержка KNN для SP-GiST и B-tree, но все ли знают или помнят, что такое SP-GiST и что такое KNN и как им пользоваться?

К моменту конференции будет уже известно наверняка, что попадет в PG 12, и я очень надеюсь, что удастся закоммитить долгожданный SQL/JSON (по крайней мере, мы над этим усиленно работаем). Но даже если что-то пойдет не так, я расскажу о проблемах, возникших у нас при реализации стандарта в постгресе.

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

В докладе я рассмотрю ряд паттернов использования ClickHouse, которые мы внедрили в Badoo:
1. система хранения гетерогенных событий;
2. сильно оптимизированное хранилище timeseries;
3. подсистема хранения данных об A/B-тестах;
4. Drop detection - система обнаружения отклонений в метриках в один SQL-запрос.

Рассмотрим вопросы надёжной доставки данных в ClickHouse, а также ряд фич из последних релизов (кодеки сжатия данных).

MariaDB давно переросла своего родителя MySQL за счёт функционала, добавляемого в MDB. Одной из таких фич стал engine для аналитической нагрузки - Columnstore AKA MariaDB AX, который отлично укладывается в парадигму MariaDB: каждой нагрузке свой движок.

В рамках доклада я познакомлю аудиторию с архитектурой, возможностями и установкой Columnstore.

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

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

Что делать, когда мастер сервер PostgreSQL погибает под нагрузкой?

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

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

Доклад посвящен реализации поискового движка IResearch (https://github.com/iresearch-toolkit/iresearch) и его интеграции в нативную мультимодельную базу данных ArangoDB (https://github.com/arangodb/arangodb), поддерживающую важнейшие модели данных. Ценность такого решения определяется тем, что в многих практических ситуациях мы сталкиваемся с задачами хранения/поиска/анализа, требующими совместной работы с различными типами данных, включая:
- структурированные таблицы;
- списки объектов с переменной схемой;
- сильно связанные данные (деревья, графы);
- неструктурированные данные (текст).

Как правило, это приводит к появлению "зоопарка" специализированных решений для множества типовых сценариев: большого числа узкоспециализированных СУБД, а также программных инструментов (требующих постоянной поддержки), обеспечивающих «прозрачность» для пользователя.

Наш подход позволяет избежать возникновения этого "зоопарка" и связанных с ним проблем. Наше решение интегрирует функционал и скорость поисковых движков (таких, как ElasticSearch/Solr/Sphinx) в ядро ArangoDB, позволяя обеспечить оптимальный план выполнения запросов и максимальную производительность (особенно в кластере), сильно сократить объем данных, пересылаемых между узлами, а также гарантировать ACID. Весь функционал доступен пользователю через SQL-like язык, позволяющий комбинировать различные модели данных в одном запросе, что придает решению ряд очень интересных свойств.

В докладе мы опишем основные черты ArangoDB и IResearch, а также расскажем:
- об интеграции IResearch в транзакционную модель ArangoDB;
- о подходе, использованном для интеграции в кластер;
- об интеграции IResearch в ArangoDB Query Language (AQL);
- об отличиях и особенностях IResearch и Lucene;
- о новых ценных возможностях ArangoDB после интеграции, например, о работе с графом одновременно и как с плоской, и как со связанной структурой.

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

* Почему СУБД часто становится узким местом проекта, и как этого избежать?
* Как снизить нагрузку на СУБД? Как распределить (расшардить) её?
* Структурированная экскурсия вокруг основных "грабель", разбросанных на поляне Highload специально для постгресистов. Надевайте каски и вперёд!

В вашей компании есть данные, представляющие коммерческую ценность. Такие данные нельзя просто так никому давать.

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

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

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

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

Из доклада вы узнаете, как мы сделали всё это возможным в GridGain, а именно:

— Какие варианты репликации возможны и какие применяются в существующих решениях;
— Как начать репликацию, сделав два кластера эквивалентными, и как поддерживать актуальное состояние replica-кластера;
— Как обеспечить транзакционную целостность на replica-кластере;
— Как поменять кластера ролями - плановое переключение (с продолжением репликации в обратную сторону) и аварийное переключение;
— Что делать, если кластера начинают шалить, причём каждый по-своему — хэндлинг выхода узлов на master и replica кластере;
— Мета-репликация: как улучшить usability, реплицируя не только данные, но и изменения бинарных схем пользовательских данных и даже изменения топологии кластера.

С 2011 года игровая студия Pixonic разрабатывает свою аналитическую систему AppMetr. При ее создании использовались Apache Kafka, Apache Cassandra и свои велосипеды на Java.

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

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

Расскажем о проблемах, с которыми столкнулись на этом пути.

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

Внедрение и эксплуатация машинного обучения в антиспаме имеет свои особенности в сравнении с другими доменами. Это связано с непрекращающейся адаптацией спамеров под системы защиты, которая происходит днем, ночью, на выходных и когда вы в отпуске без Интернета. Постоянная гонка вооружений между силами добра и зла порождает много вызовов:
* Как добиться эффективности ML в течение продолжительного времени? А не только первые 30 минут (true story!)
* Как убедиться, что качественные метрики на выборках подтвердятся в проде?
* Как гарантировать, что ночью/на выходных/под Новый Год модель не сойдет с ума после очередного обучения?
* и многие другие...

Эти вопросы становятся все более актуальными и в других бизнесах: adversarial атаки уже характерны для систем face recognition, банковского скоринга, поиска, social медиа. И на горизонте - атаки с использованием машинного обучения. Одно из решений всех этих вызовов лежит в ускорении цикла дообучения всевозможных моделей на новые паттерны, а также в формировании быстрого и эффективного пайплайна их выкатки в продакшн. Все это требует как кастомизации обучения самих моделей, так и построения качественной ML-инфраструктуры.

Как мы прошли этот путь в Почте Mail.ru, я расскажу в рамках своего доклада.

В Одноклассниках идет активная борьба со спамерами, которые тоже умеют в ML и быстро адаптируются. В связи с этим родился проект под кодовым названием "Рябина", который объединяет под собой платформу разметки данных, обучение моделей и выкатку их в прод - и все это максимально автоматизированно и быстро.

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

В декабре 2017 года Тинькофф Банк выпустил обновление мобильного приложения, в котором самым заметным изменением стало появление раздела "Истории". Каждый месяц редакторы в Tinkoff.ru выпускают около 200 новых историй, а одновременно за право быть показанными пользователю соревнуются более полутора тысяч единиц контента, месячная аудитория которого составляет более 3 млн человек, по данным на начало ноября 2018 года. Большая часть историй узко таргетирована, и при этом решение о показе той или иной истории клиенту принимается в режиме реального времени с учетом множества факторов: начиная от банковского профиля клиента и заканчивая местом, где клиент открывает приложение мобильного банка.

В докладе мы расскажем о том, что рекомендательная система раздела "Истории" основана на ставшем уже классическим протоколе OpenRTB и специально модифицированных платформах DMP, DSP, SSP. На принятие решения о показе той или иной истории с учетом аудиторных и технических таргетингов нам требуется не более 100 млс, мы используем быстрые фильтры и их интервальную модификацию. Статистика раздела "Истории" доступна менеджерам в режиме реального времени посредством реализации лямбды-архитектуры, и одновременно с этим мы сделали ее доступной для внутренних чат-ботов.

Яркость и цвета, использованные на обложке истории влияют на ее популярность, а сохраненные в закладки клиентом истории позволяют нам точнее понимать его интересы. Для каждого региона, города и для каждого человека облачная редакция регулярно готовит большое количество контента, анализируя инфоповоды, городские ленты, социальные сети и другие источники данных в полуавтоматическом режиме. Мы рассматриваем подходы к полной автоматизации задачи поиска инфоповодов, различные интеллектуальные агенты могут подсказывать редакции актуальные темы и характеризовать их целевые аудитории. Обратная связь о качестве контента — пользователи могут оценить материал, поставить лайк или дизлайк, позволяет обучать и измерять качество работы интеллектуальных систем. Истории в мобильном банке не только увеличивают частоту использования приложения и длину сессии — это также и канал для получения обратной связи и проведения маркетинговых исследований, все это в совокупности позволяет непрерывно улучшать качество сервисов в экосистеме Tinkoff.ru.

В 2018 году Тинькофф Банк признан лучшим розничным онлайн-банком в мире (Best Consumer Digital Bank) в рамках премии Best Digital Bank Award международного журнала о банках и финансах Global Finance, а мобильное приложение Тинькофф стало лучшим в мире среди всех розничных банков (Best Mobile Banking App). В октябре 2018 года состоялась презентация "Историй" на одной из главных мировых площадок финтех-достижений Finovate Fall в Нью-Йорке.

Давайте признаем: все ненавидят обновлять свой production. И если ваши пользователи — крупные корпорации, банки и финтех, это приносит не только деньги, но и требования поддерживать старые версии и их стабильность.

Поддержка нескольких версий продукта — это сложно. Если пустить всё на самотёк, то рано или поздно случится коллапс: будут появляться регрессии (фикс попадёт в 1.1, но потеряется в 1.2), выпуск версий будет замедляться из-за хаоса в release scope.

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

Расскажу:
— как мы поняли, что нам нужен формализованный процесс по работе с версиями;
— почему git-flow — не панацея;
— почему мы запрещаем merge, не ставим tags и не делаем forward ports;
— как выглядит наш workflow сегодня и как построить такой же у себя;
— почему наш workflow — тоже не панацея.