Заявки на доклады

Поиск по тегам:
Показать только принятые доклады

Lua @ HighLoad++

Lua — простой язык. Базовые вещи можно выучить минут за 20 без преувеличения. Но несмотря на всю свою простоту, Lua всё-таки может преподнести сюрприз неопытному разработчику. А чтобы писать хороший код, хорошо бы понимать, что происходит за кулисами.

Одна из причин простоты языка заключается в том, что в Lua есть всего один композитный тип данных — таблицы. Таблицы призваны подойти для любых целей — их можно использовать и как массив (если ключи целочисленные), и как key-value-хранилище. А еще таблицам присуще свойство undefined behavior — о нем и рассказ:
- Для массивов с "дырками" не определено свойство длины, на результат может влиять внутреннее представление и фаза Луны.
- Добавление новых элементов во время итерирования может нарушить порядок итерации.
- Порядок итерации pairs() не детерминирован даже для массивов.

Доклад полон примеров, отсылкам к стандарту и объяснениями причин. Но даже "опасный" код может работать без сюрпризов, главное — знать, когда на это можно рассчитывать.

Доклад принят в программу конференции

С++

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

За основу мы взяли mbed TLS, которую мы практически полностью переписали, чтобы сделать в 40 раз быстрее. В разработке мы также заимствуем части кода WolfSSL — более быстрой, чем OpenSSL-реализации. WolfSSL использует алгоритмы, аналогичные OpenSSL, которым уже более 5-7 лет. Мы обнаружили, что недавно появились более эффективные алгоритмы, которые мы реализуем в Tempesta TLS.

Работа по оптимизации производительности Tempesta TLS все еще не закончена, но Tempesta TLS уже устанавливает на 40-80% больше TLS-соединений, чем OpenSSL/Nginx, и в некоторых тестах дает до 4 раз меньшее время задержки.

В докладе будут рассмотрены:
* базовые принципы эллиптических кривых и основные "горячие точки";
* возможные side channel attacks (SCA) и методы защиты от них;
* новые и быстрые алгоритмы, используемые в эллиптических кривых;
* альтернативные решения, принимаемые разработчиками OpenSSL, WolfSSL, mbed TLS и Tempesta TLS.

А еще будет много бенчмарков и забавного кода, который на C выглядит сложнее, чем на ассемблере.

Доклад принят в программу конференции

Безопасность

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

Рассказ же будет о том, как нам с этим всем жить.

Доклад принят в программу конференции

Системное администрирование

Чтобы контент у конечных пользователей загружался быстро, нужно минимизировать время доставки пакетов от компьютера пользователя до сервера и обратно (rtt, round-trip time). Этого, в свою очередь, можно достичь размещением серверов как можно ближе к конечным пользователям. Так рождаются сети доставки данных, или более привычная аббревиатура — CDN.

"Точкой входа" конечных пользователей является система доменных имён — DNS. Именно DNS отправляет пользователя на ближайшую к нему точку присутствия.

В докладе будет рассмотрена история развития инфраструктуры DNS в CDN G-Core Labs, собранных "граблях", оптимизациях (удачных и не очень), хрупкости Интернета, мониторинге, статистике, методах тестирования DNS-сервера и проблемах нетехнического характера.

Доклад принят в программу конференции

Расскажу об основных методах балансировки трафика и о том, как это можно сделать «бесплатно» (почти, с точки зрения закупки оборудования и существующих ресурсов) на основе nftables.

Доклад принят в программу конференции

DevOps и эксплуатация

- MySQL orchestrator — продукт, который необходим для построения отказоустойчивой системы на базе СУБД MySQL для резервирования мастера.
- Как работает orchestrator.
- ProxySQL — это L7-прокся для работы с MySQL, с помощью которой можно существенно облегчить жизнь.
- Через ProxySQL можно переиспользовать коннекты в MySQL, так как это L7-прокся, то можно устроить целую систему фильтров, ограничений.

Доклад принят в программу конференции

Сколько доменов у вас в оперировании? 50? 100? 1000?
А сколько записей в каждом?
А как часто вам приходится их менять?
Устали? Тогда проходите и присаживайтесь, я расскажу вам, как перестать уставать :)

В докладе пойдет речь об автоматизации рутинной работы с DNS-записями, начиная от автоматических релизов и заканчивая выписыванием Let's Encrypt-сертификатов для всех наших доменов без участия человека.

Исходные коды будут!

Доклад принят в программу конференции

Базы данных и Stateful Apps активно мигрируют в Kubernetes, неся с собой уникальные Persistent Data, требующие персонального отношения, тем самым возрождая дискуссии на тему "pets vs cattle".

Оказывается, что Persistent Data — это именно pets, но никак не cattle!

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

Доклад принят в программу конференции

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

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

Мы также рассмотрим возможность использования eBPF для постоянного мониторинга производительности в Kubernetes и рассмотрим ограничения eBPF для такого применения.

Доклад принят в программу конференции

Расскажу об успешном внедрении bleeding edge-технологии автоматического мониторинга на основе Prometheus Operator.

Prometheus Operator – это "практически" коробочное решение, позволяющее покрыть большинство потребностей Experienced DevOps/SRE-аудитории.

Позволяет исключить bottleneck в виде отдела Operationals, автоматизировать рутину мониторинга и уменьшить time to market бизнесовых метрик.

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

Что будет внутри? Разберем детали конструктивных особенностей современного инструментария мониторинга архитектуры решения, покрывающего все необходимые требования к мониторингу, которые выдвигают пользователи современных кластерных платформ конфигурирования и деплоймента оператора при помощи Ansible- / Helm-мониторинга инфраструктуры вне K8S ci/cd-практики для алертов и дашбордов.

P.S. Взлеты и падения в продакшне и подводные камни – все, как вы любите.

Доклад принят в программу конференции

В докладе мы поговорим про то, из чего состоит latency между вашими юзерами и сервером и пройдемся по каждому пункту (DNS, TCP, TLS, HTTP) в поисках современных проколов, позволяющих ускорить Time to first byte (TTFB). Обсудим статус HTTP3 (QUIC) в текущих реалиях.

Доклад принят в программу конференции

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

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

Вы услышите:
* полезные советы: как правильно использовать статический анализ, если над вашим проектом работает open-source-сообщество;
* практические примеры: как разработчики ClickHouse интегрировали PVS-Studio в свой проект;
* результаты применения: примеры реальных ошибок, найденных в ClickHouse при помощи статического анализа.

Доклад принят в программу конференции

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

В рамках моего доклада я расскажу:
- Что делать, если во время Rolling Update проскакивают кратковременные 500-ые ошибки?
- Как бороться с человеческим фактором, когда одна неправильная буква или цифра в манифесте может привести к аварии?
- Как админам обновлять версию кластера или ядра ОС прямо в середине рабочего дня, не зацепив продакшн?

Обсудим эти и другие кейсы, которые возникли у нас за время эксплуатации Kubernetes.

Доклад принят в программу конференции

Опять боль и страдания!!! Внедряя NoOps в большой компании, я услышал много разного —
от простых эмоций:
- Да вы теперь просто операторы приватного облака!..
- У нас кончилось админство в компании!!!
- А что я теперь и в мидлваре должен разбираться?..

до вполне интересных вопросов:
- Оптимизацией СУБД кто теперь занимается?
- Кто отвечает за бэкап?
- А кто теперь отвечает за инциденты?

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

Самое тонкое место — это передача компетенций, как быть Томом Сойером, а не "вертухаем", заставляющим делать «чужую» работу. Все это мы прошли, причём в серьезном масштабе — 500 дев на 10 опс.

По классике жанра, мы собрали все возможные "грабли", где-то пришлось пойти на компромиссы, ибо любая концепция требует обработки напильником под себя, чтобы максимально решать свои задачи. У нас есть все — и NoOps, и DevOps, и просто Ops. Хочу рассказать про свой опыт погони за хайпом!

Доклад принят в программу конференции

Kubernetes Operator Pattern был создан для автоматизации роли человека-оператора, который управляет приложениями, имея глубокие знания о том, как их правильно готовить. Это как раз то, что необходимо для управления базами данных! А в этой презентации я расскажу о том, как Kubernetes Operator для управления базой данных может быть устроен внутри и чему мы научились, создавая операторы для MySQL и MongoDB.

Доклад принят в программу конференции

На мастер-классе мы с участниками на практике:
- разберемся, как минимизировать влияние человеческого фактора через инструменты ResourceQuota, LimitRange, PodDisruptionBudget;
- увидим, как настроить разные стратегии деплоя своего приложения в своем кластере.

Доклад принят в программу конференции

Рассказ о том, как дать кому-то кнопку деплоя в production.

Два года назад мы перенесли первое приложение в только что поднятый с нуля кластер kubernetes и запустили в него клиентский трафик. Kubernetes решил множество проблем и принёс ворох новых. После первых попыток микросервисы передаются в эксплуатацию десятками. Чтобы отдел эксплуатации перестал быть узким местом, мы изменили наши процессы с помощью GitOps-оператора от компании Weaveworks.

В докладе расскажу о том, с какими сложностями мы столкнулись, когда команды разработки распробовали k8s и почему мы выбрали pull-модель GitOps.

Вам будет интересно это узнать, если:
- вы хотите, чтобы NoOps стал реальностью в вашей компании;
- kubernetes дал возможность деплоить микросервисы десятками, а вы к этому оказались не готовы;
- на одного Ops приходится 30+ Dev;
- у вас много команд разработки и они используют разные инструменты CI/CD;
- вы только начинаете осваивать k8s, а глаза разбегаются от количества инструментов;
- вы считаете, что in git we trust.

Доклад принят в программу конференции

Когда речь заходит об автоматизации, особенно сетевой, очень быстро встаёт проблема с "Source Of Truth" — источником достоверных сведений. Когда-то давным-давно, когда даже термина NetDevOps ещё не было, а скрипты на php и expect уже были, источником правды мог выступать, например, биллинг провайдера — и все железки настраивались на основе данных из него.

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

Сейчас, когда слова NetOps, NetDevOps и прочий network automation у всех на слуху, возникает потребность в достоверном источнике данных о сети, её топологии, сущностях как никогда сильна. Но часто такую систему путают то с CMDB, то с Asset Management, то ещё с чем-нибудь.

Давайте разбираться (с)

Доклад принят в программу конференции

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

Бизнес нашей компании заключается в приеме и обработке платежей во множестве стран в режиме 365/24/7.
Одной из ключевых целей для нас является доступность наших сервисов 99,999%.
К CI/CD в таких условиях предъявляются особые требования.

Я расскажу об эволюции наших подходов к деплою нового кода: о том, как мы от ручных баш-скриптов шли к связке jenkins + ansible, с остановкой в fabric'е.

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

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

Доклад принят в программу конференции

Технологии будущего

We’ve been building software/hardware systems in a centralized manner for decades, no matter whether they were mainframes with thin clients, clients+server, or web 2.0 — there was always a central place of data storage and execution control. However, time changes and the new uprising trend is all about systems with no central point of control. Blockchain was the first solution, which most programmers still don’t understand. There will be many more solutions in the future, which some of us are yet to design and build.

Доклад принят в программу конференции

Аппаратное обеспечение, инфраструктура

Архитектура процессора Эльбрус 2000 существенно отличается от практически всех известных нам процессоров. Близок к нему, пожалуй, только Интеловсий Итаниум, но он, по сути, является последователем Эльбруса и в известной степени реализует наработки СССР.

Эльбрус — процессор, в котором параллельные вычисления управляются на 90% компилятором. Это отличает его от традиционных суперскалярных процессоров, которые пытаются во время исполнения выявлять в коде участки, пригодные для параллельного выполнения. Это позволило упростить аппаратуру процессора за счёт усложнения компилятора.

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

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

Доклад принят в программу конференции

1. HPC-оборудование в десть раз производительней обычного.
2. HPC-среда в разы, а иногда в десятки раз, проще обычного Enterprise/Highload.
3. Как писать приложения в HPC-стиле.
4. Техники для трансформации обычного/highload-приложения в HPC.
5. Пример трансформированного приложения, ставшего в 83 раза производительней.

Доклад принят в программу конференции

Switchdev — это инфраструктура в ядре Linux для отображения сетевых настроек ядра в железо. Одним из примеров подобного железа (whitebox switches) являются коммутаторы Mellanox, на которых можно запустить любой Linux-дистрибутив.

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

Доклад принят в программу конференции

Мы 10 лет занимались софтом для видеостриминга и увидели возможность спроектировать и разработать программно-аппаратный комплекс для транскодирования. Т.е. железо+софт.

Что нас подвигло на это? Насколько страшно влезть в такую разработку? Обязательно ли надо минимизировать стоимость железа до последней копейки? Можно ли ввязываться в такой проект, если стартовая партия меньше миллиона экземпляров?

Что делать с материнской платой дальше? Какие вопросы и слова стоит ожидать от дизайнеров, которые будут делать схемотехнику и разводку, если у вас одни программисты в компании?

Как проектировать материнку в расчете на автоматизацию тестирования?

Доклад принят в программу конференции

Цифровая культура / CTO-трек

Хранилище данных (DWH) – фундамент любой data driven-компании, источник обработанных данных для аналитиков и платформа для расчета метрик и показателей, вместилище накопленной информации по всем источникам внутри компании. Но что, если одним из источников данных будет само DWH – та информация, которая создается в процессе работы пользователей с хранилищем? На базе этой простой и даже очевидной идеи можно реализовать огромный пласт интересных и практически полезных решений.

В своем условно разбитом на три части докладе я покажу, как в Яндекс.Go покрыли работу пользователей (более 500, DAU 200) с данными (2Пт в YT и 0.5Пт в GP в пределе) в DWH и какую практическую пользу мы из этого извлекли.

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

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

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

Доклад принят в программу конференции

Data Lake в Яндекс.Такси развивается с 2016 года. В то время как наши технологии совершенствуются, зреют фреймворки, растёт скорость и надуваются объёмы, у нас остаются многие сотни процессов, написанных на устаревших решениях, порой откровенно неудачных, и их поддержка иногда сильно отвлекает нас от движения вперёд. Мы запустили постоянный процесс рефакторинга старой кодовой базы. Я расскажу о принципах, которые позволяют балансировать между укрощением техдолга и продуктовым развитием.

Ключевые вопросы:
* Как объяснить себе и другим, зачем тратить силы на рефакторинг.
* Приоритизация рефакторинга — что делать сейчас, а что может гнить дальше.
* Конфигурация команды и её мотивация.
* Специфика рефакторинга Data Lake в сравнении с бэкендом.
* Архитектура кодовой базы и технические трюки, упрощающие рефакторинг.

Доклад принят в программу конференции

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

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

Интересно, что трансформация роли настолько значительная, что зачастую роль меняется с изменением человека, который ее исполняет, так как редко кто может одинаково эффективно исполнять эту роль на всех этапах развития компании:)

В рассказе буду опираться на свой опыт, а я прокачивался по ветке разработчика, пройдя за 15 лет путь от junior'а до роли CTO в одном из больших управлений в Tinkoff.

Доклад принят в программу конференции

Блокчейн

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

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

Доклад принят в программу конференции

Бэкенд, теория программирования

В докладе расскажем про эволюцию разработки высоконагруженного сетевого кластера отправки пуш-уведомлений с использованием технологий от unix/bash и PHP до асинхронных неблокируемых многопоточных соединений на базе Rust/Tokio. Поговорим о тонкостях разработки на Rust, особенностях языка, подводных камнях и способах его быстрого изучения и использования веб-разработчиками с навыками LAMP. Поговорим также о Go, Java и причинах принятых технологических решений.

Доклад принят в программу конференции

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

А рассказать хочется про совершенно другие структуры данных.

Существует несколько СД, которые немного сложнее и интереснее вектора; вполне себе практически применимы; но при этом в среднем (среднем!) скорее неизвестны. Heaps, tries, B-trees/LSMs, Bloom filters, CountMin + HyperLogLog, KLL + T-digest. А ещё для как бы стандартных СД существуют всякие интересные реализации или техники. И тоже вполне практически применимые. Judy arrays, parallel_hashmap, google/btree, facebook/rocksdb.

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

Доклад принят в программу конференции

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

Единственное, что остается в таких случаях — это анализировать текст сообщения.

В своем докладе я расскажу про то, как мы исследовали миллионы спам-писем и разработали систему под названием Spam Term Generator. Эта технология объединила в себе использование CTPH (Context Triggered Piecewise Hashing), DBSCAN (Density-Based Spatial Clustering of Applications with Noise) и LCS (Longest Common Substring) для того, чтобы автоматически определять похожие спам-письма и извлекать из них кусочки повторяющегося текста, которые могут быть использованы для детектирования спам-рассылок.

Во время презентации я расскажу, как наша технология устроена изнутри, с какими сложностями мы столкнулись в процессе разработки, как мы избежали "brute force" анализа исходных текстов и каких результатов нам удалось достичь.

Доклад принят в программу конференции

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

Прямая работа с диском при файловом I/O — не самая дешевая операция и современные ОС применяют различные оптимизации, такие как кэширование и readahead, чтобы уменьшить ее влияние на производительность. В некоторых случаях обращений к диску можно почти полностью избежать, читая большую часть данных из кэша.

В докладе мы рассмотрим методы оптимизации I/O в JVM и копирования памяти в ядре Linux и как это позволяет увеличить пропускную способность передачи данных на 20%.

Доклад принят в программу конференции

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

Доклад будет наполнен знаниями, поработав над которыми в практике, вы начнёте писать более эффективный код, просто потому что так привыкли. Тут не будет какой-то преждевременной оптимизации а-ля "пишите for(var x = length; x > 0; x -= 4) вместо прямого цикла i++". Мы поговорим о том, чем можно пользоваться ежедневно и не задумываясь: обсудим алгоритмы работы с памятью в .NET: от кучи до стека и поговорим, так ли страшны кучи и как правильно (и в каких случаях) мигрировать в стек: ref structs, стримы и прочие нововведения платформы, до которых у многих либо не "дошли руки", либо просто не было практики использования, а оттого — и полного понимания, "когда и как".

Доклад принят в программу конференции

Нейронные сети, искусственный интеллект

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

Презентация - https://docs.google.com/presentation/d/1amBu57gzR4z7vqfHUXB_umTpH9hPycQcg3_glON91EI/edit?usp=sharing

Доклад принят в программу конференции

Задачи Natural Language Processing в последнее время становятся локомотивом исследований всего глубокого обучения в целом. Это неизбежно порождает внимание ML-сообщества и разумную долю хайпа вокруг новых моделей. И мы в антиспаме Почты Mail.ru тоже не остаемся в стороне и радостно предвкушаем адаптацию SOTA-достижений.

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

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

Доклад принят в программу конференции

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

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

Мы в ОК построили процесс, в котором:
- все параметры обучения, зависимости и артефакты фиксируются в git;
- модели обучаются автоматически в контролируемом окружении;
- модели проходят ревью и попадают в мастер;
- из мастера улетают в прод.

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

Доклад принят в программу конференции

BigData и машинное обучение

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

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

Доклад принят в программу конференции

• Data Mesh — что это и зачем он нам (зачем Data Mesh в ритейле, и где Леруа Мерлен нашёл свой особый путь).
• Не весь Open Source одинаково полезен. Карго-культ в open source, и как мы натягивали технологии на подход и философию.
• Мета-принципы для Data Mesh в Леруа Мерлен: Cloud native, Open Source, API First, Scalable by default, Fault tolerance.
• Как и зачем доносить мета-принципы до линейных сотрудников?
• Технологии и подходы к эволюции технологий.
• Из чего состоит наша платформа и как она строится? Как мы работаем с клиентами в ее построении — Customer Development.
• Таймлайн совершенствования платформы.
• Как мерить эффективность? Деньгами? Нет — довольными клиентами!
• Как уравновесить хотелки клиента и базовые мета-принципы?
• Fail fast Fail cheap-подход.

Доклад принят в программу конференции

Мы реализуем продукт, который позволяет преобразовать пользовательскую историю web-браузера в n-значный числовой вектор (embedding). Для преобразования неструктурированной информации о пользователе в векторный вид используется совокупность методов и моделей машинного обучения.

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

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

Доклад принят в программу конференции

Два года назад мы (компания Scentbird), пережив серьезный рост, решили строить свою систему аналитики для обеспечения необходимой гибкости. Мы постоянно совершенствуемся в этом направлении, и самым качественным изменением в нашей архитектуре за последнее время стал переход от ETL к ELT-концепции посредством инструмента DBT. Это позволило нам сосредоточится на бизнес-смысле перевозимых данных, вместо технических особенностей процесса трансформации данных.

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

Доклад принят в программу конференции

Автоматизация и алгоритмизация — один из векторов развития Delivery Club. Мы стремимся минимизировать ручной труд, сократить субъективное принятие решений и максимально опираться на данные в построении процессов.

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

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

Доклад принят в программу конференции

В Delivery Club есть много задач, которые успешно решаются при помощи алгоритмов машинного обучения (например, планирование количества курьеров, которых мы выводим на смены). Эти алгоритмы используются в offline-режиме.

Однако, есть целый класс задач, для которых требуется наличие в production-инфраструктуре сервисов, способных отдавать предсказания ML-моделей в режиме online.

Мы расскажем, как создавали в Delivery Club первые сервисы, использующие под капотом ML-модели, как мы обеспечиваем безопасность деплоя таких сервисов и как оцениваем качество их работы.

Обсудим следующие темы:
1. особенности ML-сервисов в сравнении с обычными микросервисами;
2. построение инфраструктуры для обучения ML-моделей в production;
3. особенности деплоя и тестирования ML-приложений;
4. как организовать процесс совместной работы Data Science и ML-инженеров.

Доклад принят в программу конференции

Apache Airflow широко используется для оркестрации ETL data-пайплайнов.
Давайте более детально взглянем на Airflow с точки зрения разработки и эксплуатации: какие особенности помогут избежать проблем, а какие могут потенциально привести к отказу работы распределенных систем.

Кроме того, обсудим:
- Какие есть альтернативы и почему именно Airflow?
- Как выглядит типичный Airflow pipeline и какую функциональность предоставляет?
- С какими трудностями предстоит столкнуться при разработке?
- Можно ли иметь гибкую оркестрацию as a code, с тестами, CI/CD и документацией?
- Способы мониторинга и восстановления после отказов.
- Как можно упростить процесс поддержки кода?
- Интеграция с облачными сервисами и внешними системами: стоит ли пробовать?

Доклад принят в программу конференции

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

Я расскажу о своём опыте прикручивания Spark к проприетарному хранилищу Яндекса YT. На примерах покажу, с какими трудностями пришлось столкнуться, какие есть тонкости и подводные камни. Расскажу, как написать свой коннектор: просто и быстро, или сложнее, но более эффективный. Я объясню внутреннее устройство Spark'а в этой области, обращая внимание на неочевидное поведение и места для расширения.

Доклад принят в программу конференции

Мы представим DeepQuarantine — облачную технологию для обнаружения и карантина потенциальных спам-сообщений.

Спам-атаки становятся все более разнообразными и могут нанести существенный вред пользователям электронной почты. Стандартные методы борьбы со спамом основаны на создании сигнатур, которые описывают уже известный спам, например, пойманный в специальные ловушки. В большинстве случаев такой подход позволяет обнаружить и описать атаку быстрее, чем она дойдет до клиентов. Однако, иногда это условие не выполняется, и часть нежелательных сообщений может попасть пользователям. Для того чтобы выиграть время для обнаружения спама в ловушках, мы создали решение, которое определяет подозрительные письма и откладывает их в карантин на некоторый срок для повторной проверки. Благодаря высокой точности классификатора большая часть почты, помещенной на карантин, является спамом, что позволяет клиентам использовать электронную почту без задержки. Наше решение основано на применении сверточных нейронных сетей на заголовках MIME для извлечения нетривиальных признаков из большого объема исторических данных. Мы оценили предложенный метод на реальных коллекциях и показали, что решение снижает False-Negative на 30%.

Доклад принят в программу конференции

Практический опыт создания и эволюции одного из крупнейших в России Озера Данных. Задачи, которые приходится решать, и как удается совмещать технические желания и бизнес-рационализм. Как совместить классические и более современные подходы к архитектуре данных с Hadoop-экосистемой, концептуальная архитектура данных — современные подходы, в чем разница концепций Data Lake и Data Mesh.

Доклад принят в программу конференции

Тестирование, нагрузочное тестирование

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

В этом докладе я расскажу о методике online-оценки ёмкости сервиса и планирования ресурсов, применяемой в Яндекс.Маркете.

Доклад принят в программу конференции

Бизнес-модели клиентов создают разные сценарии использования продукта и разные профили нагрузки. Подготовить под каждого индивидуальную тестовую среду невозможно и не имеет смысла. Достаточно создать усредненный вариант и покрыть там самые популярные кейсы использования платформы.

Расскажу, как был написан PoC Tester — фреймворк для описания логики работы клиентских узлов, которые симулируют реальную нагрузку на тестовый кластер — и какие задачи пришлось решить в процессе:
* как оптимально сконфигурировать тестовый стенд по количеству узлов;
* как добавить в один тестовый сценарий наибольшее количество пользовательских кейсов;
* какие внешние воздействия можно внедрить в сценарий для проверки надежности и устойчивости кластера при возникновении нештатных ситуаций;
* как после прогона настолько сложного сценария понять, что он успешен.

Доклад принят в программу конференции

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

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

Мы покажем только интересное о том, как:
1. смоделировать большую распределенную сеть на одном узле?
2. подключить внешние сервисы?
3. смотреть за сообщениями в протоколе?
4. интерактивно динамически мучить сервисы и сеть;
5. описать процесс в виде воспроизводимого теста (из кода).

Вся эта магия средствами ПО с открытым исходным кодом. С автоматизацией процесса за 300 строк или меньше!

Доклад принят в программу конференции

Не тормозить — основное продуктовое качество ClickHouse, которое возникает как результат целостной работы по многим направлениям: подходящих архитектурных решений, алгоритмической оптимизации, и небольшого количества связующей магии. За последний месяц в основную ветку ClickHouse добавилось 650 самостоятельных изменений — всевозможные улучшения, новая функциональность, исправления багов. Как при такой скорости разработки не потерять достигнутого? Ответ известен: автоматические тесты. Любое важное продуктовое качество необходимо тестировать, чтобы не потерять его в постоянном потоке изменений. Это верно и для производительности.

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

Доклад принят в программу конференции

Базы данных и системы хранения

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

На самом деле это не так: ошибки будут всегда и надо уметь с ними правильно обращаться.

Доклад принят в программу конференции

Есть нагруженная SQL-база данных известного вендора, есть потребность: получать изменения из этой базы в realtime, желательно, не переписывая все сервисы, которые пишут в эту базу данные, и отправлять их дальше. Расскажем, как мы сделали Change Data Capture из Oracle, какие способы опробовали, какие грабли собрали и как их обошли.

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

Мы сделали change data capture и стриминг событий из Oracle в витрины на Tarantool с использованием GoldenGate и Tarantool. У нас получилось довольно простое и производительное решение, которое встало в существующую архитектуру.

Расскажем:
- что такое и зачем нужен change data capture;
- варианты встраивания в существующую архитектуру;
- как мы делали загрузку и репликацию данных из Oracle в Tarantool;
- про грабли и как мы их побороли.

Доклад принят в программу конференции

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

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

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

Доклад принят в программу конференции

Обзор подходов к версионированию данных, сравнение достоинств и недостатков. Примеры реализации на Tarantool.

Доклад принят в программу конференции

Реляционные СУБД нанесли очередной удар NoSQL — это стандартизация работы с JSON на языке SQL, что открывает богатые возможности для разработчиков приложений. Я расскажу про то, что уже реализовано в постгресе, что ожидается в ближайшем релизе и каким мы видим будущее JSON.

Доклад принят в программу конференции

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

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

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

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

Доклад принят в программу конференции

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

Рано или поздно вопрос перебалансировки данных напомнит о себе. С использованием virtual buckets решардинг однозначно станет проще.

Правильное взаимодействие с распределенной системой — нетривиальное занятие. Выучи наизусть, что такое retry, ratelimit, throttling, circuit breaker до начала шардирования.

Доклад принят в программу конференции

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

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

Доклад принят в программу конференции

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

В данном докладе мы расскажем о том, с какими проблемами сталкивались в Яндексе, когда эти надежды не оправдывались, и как, благодаря этим проблемам, мы придумали и реализовали решения, позволяющие создавать с помощью WAL-G более надежные бэкапы и восстанавливать их еще быстрее.

WAL-G — простой и эффективный инструмент резервного копирования PostgreSQL (и не только) в облака. В основной функциональности WAL-G является наследником WAL-E, написан на Go. Доклад будет посвящён новым возможностям WAL-G, реализованным в ходе Google Summer of Code, базовая функциональность резервного копирования будет рассмотрена предельно сжато.

Доклад принят в программу конференции

Каждый владелец большой базы данных, разработчик и DBA должен понимать возможности по модификации структуры базы данных. В мире MySQL уже есть несколько технологий, которые помогают справиться с этой проблемой: online DDL, pt-online-schema-change, gh-ost, JSON поля. Репликация и синхронные кластеры (InnoDB Cluster, Galera) позволяют работать с отличиями в схемах на узлах и обновлять кластер постепенно узел за узлом. Презентация позволит детально понимать ограничения каждого из методов и научит не убивать боевую базу дурацким ALTER TABLE.

Доклад принят в программу конференции

Вы когда-нибудь задумывались о том, чтобы сделать свою собственную SQL-базу данных? Или о том, чтобы запускать SQL-запросы в вашей NoSQL-базе данных? Это кажется очень непростой задачей: нужно научиться парсить, оптимизировать и исполнять пользовательские запросы. А если мы говорим о распределенной базе данных, то сложность задачи многократно возрастает. К счастью, благодаря фреймворку с открытым кодом под названием Apache Calcite, вы сможете сделать это довольно легко.

В докладе я расскажу об опыте интеграции Apache Calcite в распределенную in-memory-платформу Apache Ignite. Покажу примеры кода и поделюсь универсальным планом интеграции SQL на основе Apache Calcite в любую другую систему.

Доклад принят в программу конференции

Один из самых простых и популярных способов «устроить highload на ровном месте» — это написать пару необдуманных строк, изменяющих схему БД, и выложить это в «прод» без обстоятельного тестирования.

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

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

И наконец, основываясь на многолетнем опыте работы с быстрорастущими командами, обсудим организационные вопросы — как выстроить процессы разработки так, чтобы риски простоя и деградации производительности были сведены к минимуму, а команды разработчиков развивались и постоянно наращивали экспертизу работы с БД.

Доклад принят в программу конференции

К конференции уже будет окончательно определено, какие фичи попадут в состав 13-й версии PostgreSQL. Мы обсудим те из них, которые повышают производительность СУБД и помогают создавать устойчивые к высоким нагрузками архитектуры систем.

Будут затронуты вопросы: вакуума, секционирования таблиц, настроек и другие.
Самое интересное будет снабжено практическими примерами и иллюстрациями.

Доклад принят в программу конференции

GitLab.com has an aggressive SLA, that made us research and development for solutions to improve our performance in all the directions, on one of the most important components in our architecture, the PostgreSQL relational database.
During this talk, we would like to invite you to explore the details about how we improve the performance of the main PostgreSQL relational database of GitLab.com in a high demanding environment with a load between 40k to 60k transactions per sec.

We would share with you our projects, processes and tools, and all the components that we have developed with our partner Postgres.ai, which makes possible deep analysis in several aspects from our database ecosystem.

Доклад принят в программу конференции

Мы разрабатываем Badoo и Bumble — дейтинг-приложения для миллионов пользователей по всему миру. Для анализа такой нагрузки мы создали инструмент поиска аномалий на графиках.

Основная цель Anomaly Detection — зафиксировать аномалии в поведении метрик и сообщить об этом ответственным за них сотрудникам.

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

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

Вы увидите, что портирование математических формул в клике — не так уж и сложно.

Доклад принят в программу конференции

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

Доклад принят в программу конференции

Tarantool — это база данных и сервер приложений. В данном случае мы будем рассматривать Tarantool именно как базу данных, а в частности, движок для хранения данных в оперативной памяти — memtx. Tarantool — open source-проект: исходный код находится в открытом доступе, что открывает большие возможности для изучения того, как организованы базы данных, а также дает возможность для написания своих решений и их последующего встраивания.

Рассказ пойдет о попытке написать свою структуру данных для поиска (Z-order curve) и её встраивании в существующую экосистему Tarantool.

Данная структура используется для многомерного поиска. Часто в БД для подобных задач применяют R-Tree, но здесь возникло желание реализовать своё экзотическое решение и сравнить его с традиционными подходами. В основе лежит обычное B-дерево, поэтому данный подход должен получиться компактным и быстрым.

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

Доклад принят в программу конференции

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

Мы рассмотрим модель типа "матрешка", в которой используется Kubernetes для управления кластерами СУБД в публичных облаках (AWS, GCP), и какие дополнительные штуки нужны, чтобы сделать СУБД "дружественной" к облакам. Возможности всех трех уровней — публичного облака, Kubernetes и СУБД — должны быть согласованы друг с другом для надежной работы облачного сервиса. В принципе, это работает, но напоминает то ли "прокрустово ложе" из греческой мифологии, то ли "испанский сапог" из Средних веков.

Мы обсудим, что требуется от СУБД, чтобы она чувствовала себя удобно и комфортно в Облаке. Это включает в себя разделение вычисления и хранения, интеграция с сетевыми системами хранения, другая модель репликации и т.д.

А в конце немного помечтаем о будущих бессерверных (serverless) СУБД.

Доклад принят в программу конференции

В этом докладе пойдет речь о малоизвестной утилите под названием cluster-copier, которая включена в стандартную поставку ClickHouse.

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

Доклад принят в программу конференции

Running databases in Kubernetes attracts a lot of attention today. Orсhestration of MySQL on Kubernetes is no way a straightforward process. There are several good MySQL based solutions in the open-source world, made by Oracle, Presslabs, and Percona. Having a common base, they differ in self-healing capabilities, consistency guarantees, storage capabilities, monitoring, proxying and backup / restore support, etc. So, let’s make a fair comparison to figure out the pros and cons of their current state.

Доклад принят в программу конференции

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

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

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

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

Обычно синхронная репликация реализуется через протокол Raft. Он проверен временем, его корректность доказана. Но у него есть ограничения:
* не предполагается наличие мастер-мастер-репликации ни в каком виде;
* журнал транзакций (WAL, Write Ahead Log) должен удовлетворять определенным свойствам.

Это сильно усложняет внедрение Raft в существующую БД без поломок обратной совместимости в журнале и без запрета мастер-мастер-репликации.

Именно эта задача появилась в СУБД Тарантул. Годами продолжались попытки реализовать чистый Raft или что угодно на его замену. Задача нетривиальна, так как мастер-мастер в Тарантуле поддерживается, из-за чего его журнал имеет очень специфичный формат, использующий векторные часы.

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

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

Доклад принят в программу конференции

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

В этом докладе я расскажу о наиболее важных улучшениях наблюдаемости в MySQL 8, начиная от Performance Schema и Information Schema и заканчивая улучшенным логированием ошибок и Optimizer Trace. А также разберу одну из важнейших составляющих мониторинга – анализ запросов – на примере работы с бесплатным инструментом Percona Monitoring and Management (PMM).

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

Доклад принят в программу конференции

Архитектуры, масштабируемость

API Gateway — тема, которую обсуждают давно, технология, которую применяют уже многие компании по всему миру. Но все еще возникают вопросы: а какие функции в себе должна содержать эта технология? Зачем этим функции нужны? Что они дают, что отнимают?

В этом докладе я расскажу о том:
- какие функции API Gateway должен иметь;
- что они дают;
- когда API Gateway нужно применять, а когда это вредно.

И напоследок рассмотрим несколько популярных API Gateway и поймем, какая роль у данной технологии в Mesh Oriented-архитектуре.

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

Доклад принят в программу конференции

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

В докладе я расскажу:
- что вообще должен делать типичный игровой сервер, из каких частей он состоит;
- на каких технологиях мы остановились для разработки игровых серверов (спойлер: Vert.X Hazelcast, Postgres, Kafka, Prometheus + Grafana, Consul, Photon Cloud);
- как мы их используем (спойлер: не все по прямому назначению);
- каким образом мы устанавливаем обновления;
- несколько интересных ошибок, которые мы словили при работе с Vert.X и Hazelcast.

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

Доклад принят в программу конференции

Мы делаем платформу для работы с биометрическими данными в масштабах страны: система рассчитана на 150 миллионов человек, на высокие нагрузки в сотни транзакций в секунду, включая юридически значимую верификацию и проверку “liveness”.

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

Также рассмотрим вопросы обеспечения высокой производительности и масштабируемости, отказоустойчивости и отсутствия потерь данных при отказах оборудования. Покажем примеры использования Openshift, Hadoop, HBase, Kafka для решения этих вопросов.

Доклад принят в программу конференции

При проектировании высоконагруженных систем многие используют подход «сначала померить». Этот подход дает точный результат, но требует больших трудозатрат, особенно в случае ошибки в архитектуре.

Попытки использовать модель производительности до реализации системы предпринимаются давно. Можно вспомнить методологию SPE, которая, к сожалению, немного устарела.

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

Доклад принят в программу конференции

Ключевой составляющей инфраструктуры Яндекса является система YT, позволяющая распределенно и надежно исполнять вычисления над большими объемами данных. YT (https://habr.com/ru/company/yandex/blog/311104/, https://www.youtube.com/watch?v=VQGfH0sZi18) – это собственная разработка компании. Данная система предоставляет пользователям распределенное отказоустойчивое хранилище данных, а также богатые возможности для выполнения Map-Reduce-вычислений над этими данными.

В докладе мы поговорим про планировщик – компоненту, которая отвечает за оперативное выделение ресурсов под задачи пользователей и соблюдение гарантий, данных пользователям. В одном из предыдущих докладов (https://www.highload.ru/moscow/2019/abstracts/6085) мы рассказывали про архитектуру планировщика и используемые подходы к масштабируемости и отказоустойчивости. В этот раз мы поговорим про то, как решать непосредственно задачу планирования.

Одна из важных задач, стоящих перед компанией – экономия вычислительных ресурсов, которая позволяет уменьшить затраты на покупку и эксплуатацию серверов. Поэтому внутри компании развернуто несколько больших YT-кластеров в разных дата-центрах, в которых на одних и тех же серверах сосуществуют batch-вычисления самых разных проектов: от регулярного построения поискового индекса и решения задач маршрутизации до ad-hoc-аналитики и экспериментов с обучением нейронных сетей на GPU-картах.

Описанная ситуация накладывает на планировщик следующие требования:
1. Отказоустойчивость: любой даунтайм планировщика – это простой десятков тысяч серверов в кластере и нарушение гарантий на время выполнения production-задач.
2. Эффективность: каждую секунду на кластере завершаются тысячи задач; чтобы обеспечивать хорошую утилизацию, планировщик должен оперативно планировать на их место новые задачи.
3. Честность: одним кластером пользуется множество различных потребителей; из продуктовых соображений разным потребителям полагаются те или иные гарантии. Планировщик должен уметь соблюдать гарантии, отраженные в его конфигурации, и оперативно выделять проектам полагающиеся им ресурсы.

Свойство честности, хотя и звучит достаточно просто, на практике накладывает сложные (а временами даже противоречивые!) требования. Политики разделения ресурсов могут быть довольно специфичными. Одновременно могут исполняться различные задачи: и длинные машинные обучения, требующие много памяти и страдающие от вытеснений; и production-процессы, состоящие из десятков тысяч коротких подзадач; и аналитические вычисления, которые не должны мешать production-процессам, но при этом хотят гарантированно получать ресурсы на длительном промежутке времени.

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

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

Доклад принят в программу конференции

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

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

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

Доклад принят в программу конференции

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

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

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

Доклад принят в программу конференции

Любой облачный провайдер ставит своим приоритетом сохранность пользовательских данных, и резервное копирование — один из инструментов, который используется для решения этой задачи. При развертывании сервиса резервного копирования у себя в Mail.ru Cloud Solutions мы столкнулись с серьезной проблемой. Средства резервного копирования, предоставляемые программным обеспечением платформы, не могли обеспечить копирование требуемых объемов данных за заданное время.

Несколько попыток обойтись “малой кровью” ясно обозначили — мы ограничены со всех сторон: производительность систем хранения, производительность самих драйверов резервного копирования дисков, производительность процессора, способы работы Runtime Environment с системой хранения. Для нас это означало невозможность реализовать бизнес-сценарии и вынудило к реализации своего драйвера копирования дисков виртуальной платформы, который обходил эти ограничения.

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

Доклад принят в программу конференции

* Как совместить параллельную разработку интернет-банка на 200+ команд и короткий релизный цикл с высокой надежностью и отказоустойчивостью решения.
* Как жить, когда микросервисы — это не менее больно, чем монолит.
* Как обложить производство кучей проверок, но не остановить его.

Эти и другие интересные вопросы я рассмотрю в докладе о том, как устроена разработка Сбербанк Онлайн.

Доклад принят в программу конференции

В докладе расскажу, как в Авито перешли от программирования формочек до полноценной Metadata Management System или, как мы ее называем, — Infomodel.

Цель доклада — поделиться опытом построения архитектуры управления метаданными. Наша система объединяет все этапы работы с метаданными сайтов объявлений и маркетплейсов: от построения форм, построения url для SERP до индексации данных и поисковых фильтров. Раскрою технические детали системы, которая обрабатывает десятки тысяч запросов в секунду. Расскажу, зачем мы написали свою read only-базу данных с интерпретируемым DSL и как у нас выглядит EAV.

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

Доклад принят в программу конференции

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

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

Доклад принят в программу конференции

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

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

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

Доклад принят в программу конференции

Hazelcast IMDG — это распределенное key-value-хранилище. В докладе я расскажу, как мы добавляли поддержку SQL в продукт и с какими трудностями столкнулись:
- реализация оптимизатора распределенных запросов на основе Apache Calcite;
- адаптация существующей key-value-архитектуры продукта под потребности SQL;
- проблемы отказоустойчивости и масштабируемости SQL в кластере.

Доклад принят в программу конференции

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

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

Доклад принят в программу конференции

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

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

Рассмотрим, как вообще устроены звонки и какие проблемы предстоит решить, чтобы сделать ваши звонки лучше звонков конкурентов. Из доклада вы узнаете:
* Как внедрить групповые звонки в web, iOS, Android.
* Зачем в звонках CDN и как выбрать географию.
* Как еще можно уменьшить latency.
* Что нужно, чтобы реализовать конференции на 1000+ участников.
* Отказоустойчивость уровня дата-центра.
* Как работать со звуком и сделать шумоподавление.
* Как искусственный интеллект помогает сделать видеозвонки лучше.

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

Доклад принят в программу конференции

При недоступности приложения Такси пользователь в пару кликов уходит к конкуренту. Поэтому отказоустойчивость — наш приоритет.

Я расскажу:
- как мы незаметно переживаем отказ почти любых сервисов: сервиса конфигов, A/B-тестов, оплаты поездок и других;
- как мы незаметно переживаем отказ различных СУБД;
- как и зачем мы сделали свой circuit breaker;
- как наша микросервисная архитектура помогает отказоустойчивости и она же постоянно провоцирует факапы;
- как hot-reload-конфиги и A/B-тесты спасают;
- зачем мы обернули основные API endpoints в декларативно конфигурируемый API Gateway.

Доклад принят в программу конференции

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

Исследовав варианты решения, мы пришли к Apollo Federation – технологии, которая с одной стороны позволила нам разбить монолитную схему основного gateway, а с другой – объединиться со схемами других бизнес-юнитов.

Мы поделимся своим опытом использования GraphQL на примере большого сервиса: от внедрения первого легковесного gateway до распределенной схемы с использованием Apollo Federation.

Доклад принят в программу конференции

Иногда серверы “умирают”.

Все начинается с необычного скачка нагрузки на веб-сервере — повышенное потребление памяти и CPU. У клиентов сайт грузится медленно, DevOps наблюдают увеличение задержек на графиках. Через несколько минут база данных дает сбой, и вскоре еще несколько серверов “отваливаются” один за другим. Перезапуск серверов не помогает, поскольку при запуске сервер сразу попадает в аварийный цикл, и становится понятно, что хотя изначальный всплеск нагрузки давно позади, ситуация уже не исправится сама собой. Характерно то, что в коде нет очевидного “бага”, и трудно понять, почему возник аварийный цикл перезагрузок.

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

Если человеку дать больше работы, чем он может выполнить, то может случиться так, что будет выполнена только часть работы, но мы обычно не ожидаем смертельных случаев. Должны ли наши серверы отличаться в этом отношении?

> Вопрос на миллион долларов — должен-ли сервер умирать из-за нагрузки?

К сожалению, ситуация аварийного цикла (crash loop) знакома многим инженерам, и цель этого доклада — вооружить инженеров всем необходимым для защиты от нее.

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

Кратко познакомимся с концепцией: Не абстрактный Дизайн Больших Систем (NALSD).
Научимся защищать сервер от аварийного цикла с помощью Примитивов Мгновенной Отказоустойчивости. Поймем, как примитивы сочетаются между собой и как их настраивать.
Классифицируем виды отказов сервера и для каждого типичного сценария вникнем в суть проблемы досконально:
* Проанализируем состояние сервера с помощью математики и Теории Очередей.
* Проведем численное моделирование каждого вида отказа.
* Сравним лабораторные результаты с реальной системой.
* Обсудим возможное решение.
* Разберем примеры кода.

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

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

Доклад принят в программу конференции

Когда пропадает простой способ масштабировать сервис под нагрузкой — появляется хайлоад. Но случается такое не сразу, не у всех и не всегда. Многие сервисы годами работают на "нехайлоадных" PHP, Python и Ruby, обрабатывая тысячи веб-запросов в секунду и не чувствуя необходимости писать свой компилятор PHP или переходить на Go с Rust.

В докладе я расскажу о том, когда именно наступает переломный момент для Python и Ruby, двух "хипстерско-хайповых" стеков, первый из которых нам регулярно приносят дейта-сайентисты, а второй все никак не может умереть и время от времени демонстрирует проекты вроде "hey.com".

Взяв за основу "типовые" Python- и Ruby-проекты, как их модно делать в 2020 году, я покажу, что именно происходит после nginx, как современные application-сервера для этих языков взаимодействуют с виртуальными машинами, что дают и отнимают веб-фреймворки и чем это все отличается по скорости от "си-шного" хайлоада, способного выдавать сотни тысяч запросов в секунду. Python и Ruby действительно медленные и с GIL, но при правильном использовании это не проблема, а статья расходов — и я расскажу, что мы можем получить за эти деньги.

Доклад принят в программу конференции

Мой доклад будет посвящён вопросам, которые у вас возникнут при внедрении или эксплуатации публичных облаков от компаний AWS, Google, Azure, Yandex.

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

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

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

План доклада:
1. Что такое публичное облако в 2020 году.
2. Какие парадигмы меняет публичное облако.
3. Зачем публичное облако действительно нужно.
4. Рекомендации для обеспечения масштабирования, высокой доступности и мультитенантности.

1. IaaS.
2. PaaS — Databases.
3. PaaS — Containers.
4. PaaS — Serverless.

Доклад принят в программу конференции

В OZON мы разработали и успешно внедрили инструмент DMP (Data Management Platform), который автоматизирует процесс создания сегментов через фильтрацию пользовательских событий. DMP — программная платформа для сбора, хранения, систематизации и анализа данных о взаимодействии пользователей с OZON.

Ежедневно мы обрабатываем более 1,5 млрд. событий от миллионов пользователей. Эти данные мы используем для построения сегментов с целью планирования рекламных кампаний, проведения маркетинговых акций и персонализированных коммуникаций.

В своем докладе я расскажу:
- как мы пришли к необходимости разработки собственной платформы DMP;
- об архитектуре платформы и как храним сегменты в PostgreSQL;
- как обеспечивается время ответа < 10 мс;
- как мы используем ClickHouse для хранения пользовательских событий;
- каким было сегментирование до внедрения конструктора сегментов и как используем сегменты для повышения бизнес-метрик;
- о плюсах и минусах нашего решения и с какими проблемами мы столкнулись в процессе эксплуатации.

Доклад принят в программу конференции

Kafka в Авито постоянно развивается, и вот настало время начать жить на 3 ДЦ. Мы провели исследование различных топологий размещения кластеров, разных способов межкластерной репликации и реализовали итоговое решение.

В докладе я расскажу, какие вызовы может встретить компания при использовании Kafka в нескольких ДЦ и как эти вызовы решили мы в Авито. Также пройдемся по возможностям Kafka (версия 2.4+) и технологиям из Kafka-экосистемы, помогающим организовать мультиДЦ-кластеры.

Доклад принят в программу конференции

Рассмотрим одну из базовых задач, которую решает любая мировая биржа — быструю доставку данных о заявках до клиентов. На первый взгляд, задача не выглядит сложной, но есть отягчающие обстоятельства:
- поток данных может достигать нескольких сотен тысяч запросов в секунду;
- потребителей может быть сотни, а то и тысячи;
- время между генерацией ордера и попаданием его конечному потребителю должно быть не более 5 мс в 99% случаев.

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

Доклад принят в программу конференции

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

В своём докладе я расскажу, на что нужно смотреть при выборе очереди, а также приведу сравнительные характеристики RabbitMQ, Kafka, NSQ и других кандидатов.

Доклад принят в программу конференции

* Создать stateless-платежный шлюз — это реально. Достаточно кодировать данные о платежной транзакции в подписанный url.
* Не спешите использовать реляционные базы данных для хранения информации о платежах, обратите внимание на S3-хранилище — оно легко масштабируется и, как показывает практика, его можно подружить с PCIDSS.
* etcd — это хорошее решение для недопущения двойных списаний со счетов клиентов по одной платежной транзакции.
* Кролики — это не только ценный мех, но и еще и хороший инструмент для реализации паттерна retry (с использованием RabbitMQ).

Доклад принят в программу конференции

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

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

Доклад принят в программу конференции

Мы используем распределенное хранилище Apache Ignite в продакшне, как следствие — предъявляем к нему высокие требования по надежности и доступности.

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

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

Доклад принят в программу конференции

JIT (Just in Time) компиляция – неотъемлемая часть многих популярных платформ (JavaScript, Java). Задача компиляции в момент выполнения существенно отличается от классической AOT (Ahead of Time) компиляции.

Эволюция технологий JIT- и AOT-компиляции во многом идут параллельными путями.

В докладе будет рассказано о новейших достижениях JIT-компиляторов для Java- и JavaScript-платформ, а также о фундаментальных отличиях JIT- и AOT-компиляторов.

Доклад принят в программу конференции