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

Доклад будет посвящен различным подходам к DDD, способам выделения глобальных сущностей (декларативном, онтологическом и математическом), проблемам и профитам, которые они могут нести. Отдельное внимание будет уделено способам ведения единой модели данных и методах управления ею. Рассмотрим современные инструменты для описания модели данных и семантики объектов в условиях глобальных бизнес-сущностей.

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

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

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

Расскажем, как в ЛК организован сбор дампов памяти, диагностирующих критичные ошибки. В частности, как мы в С++’ном коде реализовали перехват любых нештатных ситуаций, какие при этом возникли проблемы, и как мы их решили. А затем на примерах рассмотрим анализ пары интересных дампов, связанных с современными фичами С++ (noexcept, корутины).

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 выглядит сложнее, чем на ассемблере.

Хэш-таблицы — это королевы структур данных. Нигде не сломано так много копий, как на оптимизации хэш-таблиц.

В своём докладе я расскажу ещё про одну хэш-таблицу, которая используется в ClickHouse.

Я покажу, как zero cost abstractions в современном С++ оправдывают себя, и как с помощью небольших трюков можно получить разнообразные структуры данных из общей кодовой базы.

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

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

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

RON (Replicated Object Notation) — это формат данных на основе операций, разработанный в первую очередь для реализации CRDT (Conflict-Free Replicated Data Types). От типичного оплога (бинлога и т.д.) RON-оплог отличается Лампортовой адресацией и частичным (а не линейным) порядком операций. Это значит, что много реплик могут писать в оплог одновременно и обмениваться этими правками ("мастера" нет). Для распределённых приложений это ли не технология мечты?

Однако же, при реализации RON-оплога возник ряд сложностей.

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

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

А это открывает вопросы:
* минимизации объёма метаданных (Ахиллесова пята CRDT),
* случайного доступа к логу (немного о структурах данных),
* локальности данных (удивительно долго можно ехать на связном списке операций, но не бесконечно),
* стоимости (де)сериализации (почему пришлось отказаться от protobuf varint),
* и другие вопросы, которые пришлось решать.

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

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

Автор надеется, что доклад поможет слушателям использовать суперсилу CRDT в своих проектах.

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

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

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

Попробуем систематизировать проблемы безопасности AI-систем и инфраструктуры их разработки, а также рассмотрим конкретные примеры из практики анализа защищённости.

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

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

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

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

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

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

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

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

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

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

В настоящее время Helm package manager является одним из самых популярных шаблонизаторов для Kubernetes и фактически — золотым стандартом индустрии.

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

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

Концепция "источника правды" или "source of truth" появилась не вчера, но до сих пор не все представляют, что это такое и как с ним работать.

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

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

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

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

В докладе расскажем о том, как выстроить процессы и практики DevOps для 80+ проектов, одновременно разрабатываемых в компании, как масштабировать эти процессы и практики, как реагировать на изменения, как совмещать разработку под Embedded-системы с криптографией, как использовать компонентный подход для прохождения сертификации в ФСБ (КС1-КB2)/ФСТЭК, сокращения затрат на разработку и сборку, надо ли мигрировать с локальных дата-центров в облака, как решать проблемы с тестированием в условиях изменяющихся требований и обилия аппаратных платформ и др.

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

Так что, коллеги, готовьтесь к диалогу и конструктивным спорам (TFS vs Jira — для затравочки :))

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

В ритейле прямо сейчас происходит переход к принципиально новой модели потребления.

Нечто подобное в своё время произошло с появлением водопровода. Еще каких-нибудь 100 лет назад большинство людей, которым была нужна вода, брали ведро и шли к колодцу. С точки зрения нас с вами на это уходило чудовищно много времени: дойти до колодца, наполнить ведро, вернуться. Потом в квартире каждого городского жителя появился водопровод и теперь, если вам хочется пить, вы просто открываете кран и наливаете воду. Это изменение настолько масштабно и в то же время просто в использовании, что для нас оно стало неотъемлемым атрибутом цивилизации.

В Самокате мы делаем такой “водопровод” для товаров.

Мы доставляем товары в режиме реального времени. Не нужно подстраивать свои планы под ожидание доставки, не нужно следить за телефоном, чтобы не пропустить звонок от курьера «за час». Заказал и через 15 минут курьер у твоей двери. Всё.

Мы начинали как «магазин у дома» — продавали только самое необходимое, вроде воды и туалетной бумаги; доставляли 6 заказов в неделю. Сейчас наш ассортимент сопоставим с Пятёрочкой, мы доставляем 150 000 заказов в день в 8 городах-миллионниках России и продолжаем расти.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И все это с примерами!

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

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

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

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

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

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

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

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

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

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

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

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

Доклад будет построен вокруг модификации кода чужих библиотек: когда из своего мы уже выжали максимум, а изменение кода сторонних библиотек может дать x4-x10-кратную производительность.

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

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

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

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

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

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

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

Паксос — алгоритм принятия решений в распределённых системах, лежащий в основе многих современных инструментов — Consul, Zookeeper, etcd и других. Только сам автор Лесли Лампорт сделал много попыток объяснить, как работает алгоритм — в работах "Part time parliament", "Paxos made simple", многочисленных выступлениях. Неавторских интерпретаций тысячи. Большинству из нас это мало помогает понять алгоритм. В одном из своих выступлений Лесли признаётся, что в нескольких известных ему реализациях есть ошибки. В презентации я попробую объяснить Паксос с помощью картинок. Цель доклада не прикладная — я попробую объяснить принципы и ограничения, лежащие в основе алгоритма.

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

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

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

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

На примере одной из наших задач обсудим:
- как использовать обученные ML модели в продакшне;
- как мы мониторим модели и почему это важно;
- путь ML-модели от постановки задачи в Jira до прода;
- как реализуем переобучение (если это необходимо).

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

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

- Несмотря на головокружительный прогресс последних трех лет в области NLP, вывод полностью автоматического решения в продакшн все еще не такая простая задача: те самые несколько процентов ошибок на валидации могут стать настоящей головной болью для продакт-менеджеров. Ведь именно этот несчастный неудачный кейс норовит попасть на главную страницу и испортить впечатление от системы или же сорвет сделку о партнерстве.
- Мы в Whisk (часть SamsungNext) уже более 7 лет разрабатываем продукт по глубокому анализу кулинарных рецептов, и МЛ является ключевой технологией, питающей наш продукт. На базе нашего решения построена система работы с рецептами в холодильниках Samsung FamilyHub — внутренний продукт по интеграции сайтов рецептов с крупнейшими ритейлерами (Walmart, Tesco, etc) и собственный B2C-продукт Whisk (победитель Google Play Awards 2020).
- В связи с такой разноплановостью применения нашей ключевой технологии нам очень важно давать гарантии по качеству, что привело к большому количеству инженерных и организационных решений вокруг МЛ-моделей, и некоторыми из них хотелось бы поделиться.

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

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

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

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

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

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

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

MLOps — термин, который уже успел набить оскомину у всего AI/ML-комьюнити. И, тем не менее, внедрение MLOps как никогда критично, потому что каждый день появляются новые практики и инструменты по работе с данными. Осталось только разобраться, почему критично и причем тут данные — об этом и поговорим.

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

Затем мы поговорим про данные:
- Откуда взялся тренд на важность данных?
- Имеет ли он вообще смысл?
- Обсудим последние исследования.
- Поговорим о том, что думают лидеры рынка, такие как Andrew Ng.
- Затронем и мой собственный опыт в Provectus.

Наконец, нельзя не обсудить решения — расскажу, как про общие моменты (например, как прокачать дата-пайплайны), так и о конкретных решениях, в том числе и об OpenDataCatalog, который разрабатывается командой Provectus.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В докладе я расскажу про разработку и использование платформы для автоматизации тестирования финтех-приложений th2. Я работаю в компании Exactpro и руковожу проектом по разработке этой платформы. В моей команде сейчас 40 человек.

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

Я расскажу про процесс разработки и технологический стек платформы th2, который включает в себя Kubernetes, Cassandra, RabbitMQ.

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Правда ли, что распаковать данные — быстрее, чем просто скопировать их? Ответ: "нет и да", а вообще всё сложнее. Как быстрее всего транспонировать Structure of Arrays в Array of Structures и зачем это нужно? Как лучше читать файлы — read, O_DIRECT, mmap, io_uring? Ответ снова нетривиален. Почему MergeTree-таблицы в ClickHouse могут работать лучше, чем in-memory-таблицы?

В своём докладе я расскажу про некоторые интересные случаи исследования и оптимизации производительности, с которыми разработчики ClickHouse сталкиваются на практике.

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

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

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

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

Когда в очередной версии СУБД появляются фичи, способные решить проблемы вашей системы с производительностью и отказоустойчивостью, то жизнь налаживается, и краски становятся ярче. Обычно именно в такие моменты и приходит понимание того, что на самом деле все не так уж и просто — особенно, когда в сети нет достаточного количества примеров и постов об успешном внедрении. Не теряйте времени — делайте план внедрения/перехода и пробуйте! Болван с планом всегда эффективнее умного без плана!

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я расскажу:
- что часто приводит к проблемам в больших сервисах;
- какие подходы (паттерны отказоустойчивости) помогают переживать их незаметно;
- как паттерны "делают стабильность" и как применить их в любом проекте;
- зачем сделали свой circuit breaker, чем полезен API Gateway, как приготовить конфиги; как пережить отказ критической СУБД.

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

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

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

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

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

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

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

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

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

Рассмотрим ошибки, проблемы и особенности систем мониторинга транспорта в реальном времени на примере конкретной микросервисной архитектуры Python + Rabbit + Clickhouse, обслуживающей взаимодействие 40 тысяч движущихся и 2 миллионов статичных объектов на карте.

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

Пройдемся по всем сервисам от источников данных до клиентского приложения. Коснемся даже оптимизации фронтенда при работе с картами в режиме многослойного интерактивного мониторинга.

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

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

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

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

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

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

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

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

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

В этом докладе я расскажу, что происходит под капотом: от "приложил карту" в магазине до "получил "ок" на POS-терминале.

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

Ключевой составляющей инфраструктуры Яндекса является система 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-процессам, но при этом хотят гарантированно получать ресурсы на длительном промежутке времени.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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