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

Эволюция API Gateway — как не допустить хаоса при цифровой трансформации на примере телеком-оператора

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

Аутентификация и авторизация "всех со всеми", если у вас несколько поставщиков идентификационной информации (Identity Providers), множество сервисов, а безопасностью взаимодействия нельзя пренебречь.

"Купить или не купить — вот в чем вопрос". Вопрос выбора API Gateway, и почему мы решили пойти своим путем.

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

Exactly once-передача данных без материализации

Доклад будет о том, как мы научились более эффективно передавать данные между нашими сервисами.
С сохранением exactly once и отказоустойчивости мы уменьшили материализацию потока промежуточных данных на дисках на 90% и примерно на столько же снизили latency.

Подробнее на простом примере:
Пусть у нас есть много входных очередей (например, kafka) с событиями, каждое событие содержит идентификатор стейта StateId и относится к соответствующему стейту. И мы хотим в реальном времени считать агрегаты произвольной сложности (= обновлять стейты) по входным событиям с семантикой exactly once.

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

Тогда в этом простом случае получается, что нужно два сервиса: один читает входные события и пишет их в промежуточную очередь пошардировано (resharder), другой читает уже шардированные события и обновляет стейты в соответствии с ними (aggregator).

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

То есть мы решаем проблему: как передать данные от resharder'а aggregator'у с наименьшей материализацией на дисках, с наименьшими задержками и при этом отказоустойчиво и с exactly once.

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

Istio Service Mesh в федеративных топологиях Kubernetes

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

В докладе я расскажу, как можно построить федеративную межкластерную маршрутизацию на базе Istio Service Mesh. Что предлагает Istio «из коробки», и что делать, если стандартные схемы мультикластерного деплоймента вам не подходят. Как реализовать управление межкластерным трафиком и делать мультикластерные канареечные релизы. Как обеспечить сетевую локальность для межкластерного трафика. И, наконец, как реализовать мультикластерные механизмы для работы таких паттернов, как retries, timeouts и circuit breakers.

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

Как вырастить поисковый индекс в 3 раза, трафик в 2 раза и сэкономить 30% CPU

Алексей Салмин

Яндекс.Поиск

В этом докладе я расскажу краткую историю развития ядра веб-поиска Яндекса за последние несколько лет. Основной задачей команды, которая разрабатывает наш движок, можно назвать экономию ресурсов. Экономия не является самостоятельной целью, но при этом имеет огромное значение: она позволяет на том же железе наращивать поисковую базу, внедрять новые фичи и модели в ранжирование, принимать растущий пользовательский трафик. С конца 2017 года мы прошли интересный путь: входящий трафик и поисковая база выросли в несколько раз, и при этом мы не только не нарастили потребление CPU и RAM, но и смогли передать десятки процентов мощностей на другие проекты поиска. Конечно, это сравнение неполное, т.к. за это время мы проапгрейдили сеть и диски, но интегральное потребление именно по CPU и RAM у нас не растет.

Вы узнаете, как снизить потребление CPU с помощью:
* сжатия (sic!);
* микросервисов (sic!);
* асинхронного IO (???);
* заменой горизонтального шардирования на вертикальное и наоборот.
И другие интересные технологические решения: erasure-recovery в реальном времени, key-value storage на десятки миллионов RPS, e2e-сжатие со словарем, батчевание применения нейросетей и деревьев.

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

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

Чем мы смотрим на прод Яндекса, и как это вам поможет

Иван Карев

Яндекс

Расскажу о том, как решение одной частной проблемы выросло в систему, с которой работает сотня команд и которая позволяет в режиме реального времени ответить на большинство вопросов про то, что происходит с продакшном. Мы объединили разбор ошибок клиентов и бэкендов, клиентскую скорость, телеметрию видео, клики по элементам интерфейсов, access_log сервисов, логи балансеров, CSP, CDN статики, CDN видео в общий набор инструментов, который позволяет навигироваться по более чем 150B событий в сутки. И еще фильтровать данные по произвольным срезам, строить графики, считать метрики, сравнивать сегменты, настраивать алерты.

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

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

GraphQL: как не выстрелить себе в ногу

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

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

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

Что такое клиринг, как он работает и реализован на примере платежной системы "Мир"

Юрий Бабак

Мир Plat.Form

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

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

Иными словами, в этом докладе я расскажу, как устроена и работает клиринговая система ПС "Мир".

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

Визуальное проектирование масштабируемых приложений

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

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

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

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

Serverless yet Stateful в Azure. Сервисы с хранимым состоянием на Azure Durable Functions и Durable Entities

В бессерверной экосистеме Azure Functions теперь есть сразу два инструмента для создания Сервисов с Хранимым Состоянием — Durable Orchestrations и Durable Entities. Эти инструменты построены на общей платформе, но реализуют различные архитектурные подходы — Saga/Workflow и Virtual Actors, соответственно.

Мы заглянем под капот подсистемы Azure Durable Functions и разберем ее внутреннее устройство. Затем обсудим, когда лучше использовать Durable Orchestrations, когда Durable Entities, а когда не использовать ни то, ни другое. Наконец, запустим примеры кода и посмотрим, насколько быстро это все работает.

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

Распределенная трассировка — подключить всех и не умереть!

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

В докладе я расскажу, как мы собираем 100% трассировки с 50+ продуктов при помощи Jaeger. Как обрабатываем и храним 500 Гб трассировки в сутки с помощью Elasticsearch. Как справляемся с постоянно растущим потоком данных в 15 тысяч документов в секунду. Затрону вопросы мониторинга и влияния сбора трассировки на наблюдаемою систему.

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

Эволюция акторной системы

Алексей Станкевичус

Яндекс.Технологии

Существует несколько подходов к созданию эффективных многопоточных приложений на С++. В Yandex Database (YDB) мы выбрали модель акторов и с нуля создали свою акторную систему. С тех пор прошло более 7 лет, и сегодня акторная система исполняется на десятках тысяч серверов. Чтобы пройти путь к созданию сложных модульных распределенных систем с помощью модели акторов нам пришлось решить множество проблем. В докладе я расскажу о некоторых из них:
* как совместить интерактивную нагрузку и фоновые задачи в одном приложении;
* как обеспечить гарантии latency и высокую утилизацию;
* как изолировать подсистемы и обойтись без резервирования CPU.
И, конечно, расскажу, почему выбрали именно модель акторов.

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

Хайлоад, которого не ждали

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

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

Звучит скучно, не правда ли?

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

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

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

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

SLI/SLO/SLA в микросервисном приложении

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

Доклад про понятия SLI/SLO/SLA и то, как мы трактуем их в Авито. Слушатели узнают о подходах к измерению надёжности как микросервисов, в частности, так и микросервисного приложения в общем.
Также я расскажу, для чего вообще стоит этим заниматься.

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

Как мы придумали API для управления кластерами K8s

Можно ли деплоить Kubernetes-кластеры так же просто, как мы деплоим приложения? Да, мы сделали Kubernetes проще.

Декларативные API и инструменты для автоматизации развертывания и сопровождения жизненного цикла отдельных узлов и целых кластеров OpenShift.

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

Как устроена AWS Lambda

Serverless-подход становится все более популярным, и самым часто используемым Serverless-сервисом является AWS Lambda.

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

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

Паттерны отказоустойчивой архитектуры

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

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

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

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

Управляем состоянием распределенных систем без боли

Управление состоянием в сложном микросервисном ландшафте — задача не из легких. Как только процесс изменения затрагивает несколько слабосвязанных сущностей, проблема их консистентности встает поперек горла архитектора. На помощь приходят многофазные транзакции, Saga, X/Open XA... Теперь вместо одной проблемы у вас две.

В процессе разработки сервиса Containerum Kubernetes Service мы пошли другим путем — построили распределенную систему на основе доменной модели, управляемой конечными автоматами, и синхронно-асинхронной коммуникации между сервисами посредством gRPC и Kafka. Это позволило нам управлять сложными иерархическими сущностями, разбросанными на полдюжины сервисов, гибко обрабатывать ошибки и забыть про неконсистентность и болезненные роллбэки. Нашим опытом, ошибками и успехами я с вами и поделюсь.

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

Поиск GPS-аномалий среди сотен тысяч водителей

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

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

Я расскажу про:
- сonsistent hashing для разделения вычислений в микросервисном кластере;
- работу с geospatial-данными в Redis;
- разные типы и характеристики location provider'ов: GPS, WiFi LBS, GSM LBS, Android Fused;
- способы детектирования и борьбы с аномалиями GPS.

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

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

Миллион RPS в YDB: история одного переезда метрики

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

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

Приняли решение перестраивать и сформулировали следующие требования:
1. новое хранилище должно быть прозрачно масштабируемым как по месту, так и по производительности;
2. обработчики должны быть stateless;
3. количество обработчиков должно наращиваться "по кнопке".

В рамках доклада расскажу:
1. почему остановились на YDB, как переезжали, что сломали;
2. как научились работать с таблицей в 40ТБ и 1 миллионом запросов в секунду;
3. как тестировали и масштабировали.

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

Транзакционные очереди в PostgreSQL

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

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

VictoriaMetrics: scaling to a billion metrics per second

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

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

В ходе доклада будут произведены сравнения с альтернативными решениями, рассмотрены их плюсы и минусы, а также компромиссы, допущенные разработчиками. Если вы знакомы и используете такие системы, как Prometheus, Thanos, Cortex, InfluxDB, TimescaleDB или Graphite — доклад вам будет интересен.

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

Архитектура высокопроизводительных распределенных SQL-движков

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

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

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

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

Ребаланс в распределённой базе данных. Как нагнать состояние узла до состояния кластера?

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

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

В докладе будет представлена концепция исторического ребаланса, реализованная в распределенной базе данных Apache Ignite:
* когда необходим ребаланс;
* метод восстановления согласованности данных между репликами;
* проблема обработки нагрузки;
* обработка удалённых записей;
* когда объём переносимых данных можно значительно уменьшить;
* компромисс и оптимизации;
* обработка сбоев.

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

Поиск проблем в базе данных, если ты разработчик

Задача разработчика — написать рабочий код. Если этот код должен работать со стейтом, то, скорей всего, это будет какая-то база данных, из которой можно прочитать или записать данные. Писать идеальный код получается не всегда, и проблемы на стыке приложения и базы данных случаются и часто случаются внезапно. Хорошо, когда за эксплуатацией БД следит специальный человек — можно рассчитывать на него, что он поможет найти и устранить проблему. Если же такого человека нет, приходится рассчитывать на свои знания и умения.

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

В качестве примера я буду рассматривать СУБД PostgreSQL, при этом полученные знания можно будет применять и с другими БД.

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

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

Trying to keep the bugs out: Lessions learned from 22 years of working on SQLite

SQLite is one of the most widely used pieces of software in the world. There are more instances of SQLite running right now than all other database engines combined. Because so many other systems use and depend on SQLite, it is important to keep the code as reliable and bug-free as possible. How do we do that?

This talk, by the SQLite creator and team leader, reviews what the SQLite team does in our quest to maintain the highest possible code quality. Both successes and failure will be discussed. The talk attempts to identify general principals that can be used to improve and protect code quality in other projects.

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

Yandex Database — MVCC в распределенной базе данных

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

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

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

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

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

Подсистема I/O в PostgreSQL: архитектура, проблемы, обходные пути

Несмотря на то, что подсистема ввода-вывода PostgreSQL вполне хорошо подходит для большинства решаемых задач, она все-таки имеет несколько особенностей и проблем:
* трудно предсказать задержку записи/чтения данных, особенно для баз данных, размер которых значительно больше доступной памяти;
* пропускная способность ввода-вывода, особенно в быстрых подсистемах хранения (например, в NVMe-дисках), недостаточно высока для использования на все 100%;
* бэкенды сами выполняют слишком много операций ввода-вывода, так как фоновый писатель (bgwriter) работает не очень оптимально;
* генерируется ненужная случайная запись данных (bgwriter, backends);
* двойная буферизация между страничным кэшем ОС и общими буферами (shared_buffers) памяти Postgres;
* все операции на чтение данных являются синхронными (из страничного кэша ОС);
* большой размер shared_buffers может вызвать проблемы, когда таблицы очень часто удаляются или очищаются.

Об этом и не только я расскажу в своем докладе...

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

ClickHouse в Kubernetes — это просто!

Kubernetes стремительно завоевывает популярность, в том числе и как платформа для кластеров баз данных. ClickHouse тоже не тормозит. Еще совсем недавно ClickHouse в Kubernetes казался экзотикой, но все поменялось благодаря разработанному Altinity оператору clickhouse-operator (https://github.com/Altinity/clickhouse-operator). Мы научились "готовить" ClickHouse для Kubernetes наилучшим образом и сделали это простым для всех остальных.

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

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

История перехода от REST к GraphQL на Hasura

Раньше у нас была Java с REST, а местами нет, API. Мы заменили все это и теперь у нас graphql с теми же данными, что были раньше.

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

Это история про миграцию критического компонента всей инфраструктуры Wargaming — CMDBuild, от которой зависит весь продакшн, на новую несовместимую разработку практически без даунтайма.

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

CDC В Leroy Merlin: Сбор данных из MSSQL/PostgreSQL/MongoDB-источников через Debezium

Юрий Щербаков

Леруа Мерлен Восток

Более 300 реляционных источников (MSSQL, PostgreSQL). Геораспределённость от Владивостока до Калининграда. Мы планируем рассказать о том, как мы собирали данные из наших разнообразных источников, чтобы создать единую Платформу Данных, на основе debezium'а и CDC-подхода.

Хотим поделиться проблемами, с которыми столкнулись в ходе двух лет эксплуатации с версии 0.9 до 1.6.1, как мы мониторим систему и на что обращаем внимание.

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

JIT-компиляция запросов в ClickHouse

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

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

Технологии и тенденции в мире open source-баз данных в 2022 году

Сегодня мы имеем дело с большим количеством замечательных инноваций в технологиях баз данных. Например, введение новых моделей данных, таких как time series или graph, фокус которых направлен на решение проблем SQL при масштабировании приложений и превративших NoSQL в синоним масштабирования. Также на рынке появился новый дизайн баз данных Cloud-Native, использующий возможности Kubernetes и Serverless-концепции. Особое влияние оказывает открытое ПО, рынок которого растет, но дает свои трещины. Появляется класс частично открытых СУБД.

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

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

MySQL 8 vs MariaDB 10.6: новости, отличия, возможности

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

В этой презентации я рассмотрю эти возможности, а также предоставлю рекомендации, для каких приложений какая из систем подходит лучше. Кроме этого, отдельное внимание уделю новостям Galera 4 — новой версии технологии репликации, использующейся и в MySQL 8, и в MariaDB 10.6 для организации надежных и высокопроизводительных кластеров баз данных.

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

Топ-5 провальных решений при разработке на Tarantool

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

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

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

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

Архитектура Vitastor. Тёмная сторона моей распределённой СХД

Виталий Филиппов

Личный проект

Vitastor — это мой быстрый «Ceph-заменитель». Распределённая блочная программная система хранения данных (SDS), способная, в отличие от большинства других систем, нормально работать с быстрыми твердотельными накопителями, и при этом, в отличие от большинства других систем, имеющая симметричную распределённую архитектуру без единой точки отказа. А под «нормально», конечно, понимается «так быстро, как только возможно» :-)

В предыдущем докладе на DevOpsConf (https://devopsconf.io/moscow/2021/abstracts/7458) я рассказал о ситуации с SDS («нечего надеть»), причинах создания Vitastor и общих принципах его разработки.

В этом докладе я хочу остановиться на технической стороне. Тёмной, архитектурной технической стороне.

Что такое «симметричная распределённая архитектура»? Как конкретно обеспечивается консистентность? Как реализованы снапшоты и клоны? Зачем нужен io_uring? Как Vitastor использует RDMA? Что ещё за монитор на node.js и откуда там LP-солвер (утилита решения задач линейного программирования)?

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

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

Высоконагруженный сервис пользовательских корзин Яндекс.Маркета

История о том, как мы сервис масштабировали под нагрузку, в 100 раз превышающую текущую.

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

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

Pluggable TOAST or One TOAST fits ALL

Олег Бартунов

Postgres Professional

Никита Глухов

Postgres Professional

Федор Сигаев

Postgres Professional

Одной из "родовых" проблем постгреса является технология TOAST (The Oversized-Attribute Storage Technique или методика хранения сверхбольших атрибутов) в ее применении к современным типам данных с внутренней структурой, наиболее ярким представителем которых является JSONB. Проблема состоит в том, что TOAST работает с JSONB как с черным ящиком и это приводит к очень большим оверхедам как в простом доступе по ключу, так и в обновлении JSONB.

Мы расскажем про нашу работу по улучшению TOAST, который мы научили работать с типом данных так, как сам тип считает наиболее эффективно, то есть теперь большие колонки могут "нарезаться "и сжиматься не единым для всех способом, а с учетом особенностей конкретного типа данных, что в случае JSONB означает громадное улучшение производительности, про которое мы говорили весь прошлый год. Pluggable TOAST позволит реализовать все наши улучшения в виде расширений, и речь пойдет про несколько примеров его использования — стрим bytea в постгрес со скоростью диска и JSONB. Мы планируем закоммитить Pluggable TOAST в ядро PG15, чтобы иметь возможность впоследствии доработать эти примеры и отдать в сообщество как расширения.

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

Поваренная книга MySQL. Рецепты для вашего бизнеса

Зимой 2022 года планируется выход четвёртого издания книги MySQL Cookbook. Я — один из авторов книги и в своём докладе покажу, как "готовить" MySQL, используя рецепты, вошедшие в книгу. Я покажу несколько вариантов для задач с разными приоритетами. Например, JSON в MySQL для тех, кому нужна гибкость; поддержка современного SQL-стандарта для аналитики и Group Replication для надёжности. Также я покажу, как программировать на JavaScript и Python в MySQL Shell.

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

Менеджмент крупных проектов (1)

Проект АГХК — как проектировать максимально безлюдное производство глазами ИТ

Егор Плечистов

Сибур-Диджитал

* Целевой ландшафт ИТ-архитектуры.
* Производственный домен.
* Проектирование ИТ-систем производства.

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

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

Инвентаризация пакетов, уязвимостей и обновлений на коленке

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

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

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

Elasticsearch для логов в особо крупных масштабах

Петр Зайцев

Одноклассники

* Холодное хранилище на Elasticsearch для архивных данных;
* особенности использования HDD и SSD в рамках Elasticsearch;
* отказоустойчивость Elasticsearch размером ~1к нод, или что нам принес Elasticsearch 7;
* практический профит: как облегчает жизнь разным командам разработки и не только;
* дальнейшие планы развития кластера в рамках компании.

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

Введение в KernelShark

1 Введение в Kernelshark.
1.1 Рассказ про ftrace, ptrace, ebpf.
1.2 Установка Kernelshark, trace простой функции в ядре.
2 Сравнение с Wireshark.
2.1 Отличия и сходства для более быстрого знакомства с Kernelshark.
2.2 Как создать свой tcpdump с помощью trace bcc в одну строку.
2.3 Как отслеживать проблемы в сетевом стеке с помощью Kernelshark.
3 Kernelshark как инструмент для траблшутинга.
3.1 Пример с обнаружением проблем ARP-запроса.
Часто у нас есть счётчики и логи для анализа поведения системы. Но что, если у нас нет под рукой нужной статистики или мы не знаем, где смотреть? Kernelshark поможет разобраться в проблеме.
4 Kernelshark как инструмент для анализа производительности.
4.1 Пример со сравнением времени работы при использовании файлового кэша при обращениях приложения к файловой системе. Рассмотрим, как сильно влияет файловый кэш, как его можно сбросить, какие функции в ядре работают в каждом случае.
4.2 Пример с замерами времени исполнения функции шифрования в сетевом модуле ядра.
Иногда нам нужно добавить какое-либо поведение в код, но не всегда понятно, какой вклад в latency будет привнесён изменениями при работе в контексте ядра. С Kernelshark можно будет заглянуть в прерывания и сравнить время выполнения. Особенно с -p function_graph!

Обзор полезных ссылок.

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

ZFS как архитектурное решение для резервного копирования хостинга

Я расскажу о том, как и почему компания Timeweb перевела хостинг на ZFS и отказалась от LVM и DRBD.

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

* Как выглядела архитектура с LVM и DRBD.
* Что не устроило в существующей архитектуре.
* Как выглядит новая архитектура файловой системы хостинга.
* С какими сложностями столкнулись.

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

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

Kubernetes и Enterprise. Опыт «Фланта»

Вот уже несколько лет «Флант» помогает крупным компаниям внедрять Kubernetes. В этом докладе я поделюсь накопленным в десятках проектах опытом и расскажу всё, что знаю о Kubernetes в Enterprise.

Среди тем доклада:
1. Зачем Kubernetes крупным компаниям. Какие он решает вопросы. Что от него ожидать на практике.
2. Как правильно составить требования к «платформе на базе Kubernetes». Какие существуют подходы к построению таких платформ. Какие возможности должна обеспечивать платформа.
3. Как выглядит типовая архитектура кластера Kubernetes в Enterprise. Как оптимально построить архитектуру при наличии нескольких ЦОД и облака.
4. Как выстроить CI/CD, мониторинг, логирование и другие необходимые элементы платформы.

Доклад полностью посвящен платформам на базе «ванильного» Kubernetes и не затрагивает семейство продуктов OpenShift.

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

Интернет вещей. Построение цифрового двойника машины непрерывного литья заготовки. Опыт цифрового преобразования в металлургии

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

Как пример реализации проекта:
Строим цифровой двойник машины непрерывного литья заготовки, с получением данных в реальном времени, с целью решения задач:
* Предиктивная аналитика состояния оборудования.
* Предсказание дефектов заготовки.
* Вводные:
5 000 метрик в 0.25 секунды, в режиме онлайн. 2 стана.
Вес заготовки 20 тонн.
Скорость: 1 метр в 1 минуту.

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

Мониторинг на стероидах в IPONWEB

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

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

12 практик для эффективного решения инцидентов

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

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

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

Как повысить уровень доступности сервиса и подружить Сеть с ИТ

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

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

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

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

Мониторинг от инфраструктуры до бизнеса. Обработка трех петабайт данных о событиях в Тинькофф в одной системе

У нас было 3 000 сервисов, 3 петабайта логов и миллионы метрик, едва живой Prometheus, Splunk, объявивший об уходе из России, 200 команд и десяток бизнес-линий. Не то чтобы у нас не было мониторинга, но ситуация становилась всё более запутанной, и особенно нас беспокоило то, что до отказа от Splunk оставался всего 1 год. В мире нет никого более беспомощного, безответственного и безнравственного, чем инженер без мониторинга. Но мы знали, что довольно скоро выход найдётся.

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

Как наладить CI-процесс в монорепозитории и сохранить спокойствие разработчиков

Алина Власова

Лаборатория Касперского

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

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

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

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

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

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

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

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

eBPF в production-условиях

О eBPF слышали уже все и даже, возможно, запускали какие-то небольшие инструменты на ней. Но мало кто разрабатывает решения с использованием данной технологии и работает со множеством различных окружений клиентов: от bare-metal до managed Kubernetes в популярных облачных провайдерах.

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

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

Как создать автоматизацию детекции и оценки сбоев в Production

* У вас происходят сбои в production и они вас беспокоят?
* Вы чувствуете, что ваша разработка стагнирует, но прозрачности получить неоткуда?
* Вы хотите понимать, насколько в production'е всё хорошо или плохо и о чем стоит беспокоиться?
Тогда этот доклад для вас! :)

Каждый день мы катим изменения в production иногда десятками, да и сотнями в сутки и, конечно же, что-то ломаем. Ломаем по-разному, чаще по мелочи — на 5-10 минут, иногда и по-крупному — этак на час, и совсем редко гремит так, что в СМИ можно попасть, если вы крупная компания. Сбои неодинаковые, ведут себя по-разному, имеют витиеватые корни и различные последствия.

Они способны рассказать многое:
* про культуру разработки и тренды развития или стагнации инженерии;
* про качество продукта и рядом стоящие показатели доступности, SLO и SLA;
* про развитость процессов внутри тех. депа;
* и еще многое веселое, что покажу в докладе.
Собирать такие данные руками весьма накладно и, главное, медленно, но автоматизировать — это реально.

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

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

Настраиваем инцидент-менеджмент: от хаоса до автоматизации

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

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

В докладе будет описана работа текущего процесса инцидент-менеджмента и автоматики вокруг него. Для мониторинга наших сервисов мы используем схему Prometheus + Alertmanager + Pagerduty, постмортемы с недавнего времени храним в Notion, а сам процесс инцидент-менеджмента автоматизирован при помощи Slack-бота.

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

Как сделать операцию на сердце бегущему марафонцу, или Опыт и приколы эксплуатации сети одного видеосервиса

1. Все самые крутые, интересные и разрушительные аварии сервисов устраивают сетевики.
Рассказ про парочку интересных факапов.

2. Резервируй ЭТО.
Что вы тут нам голову морочите? Всё уже давно придумали: стекируй компоненты сети — и будет тебе счастье!

3. Резервируй ЭТО v.2.0.
Стекировать — это хорошо. Но вы всё ещё верите в ISSU?
Ну тогда я пошёл за чем-нибудь вкусным и буду смотреть, как вы без прерывания связности сервисов мажорное обновление софта сделаете.
Разноси control plane! Делай MLAG! И будет хорошо!

4. Балансируй ЭТО.
Хочешь, чтобы тебя ругала половина компании?
Засунь побольше трафика в:
* один линк;
* один роутер;
* один ЦОД.
Нет… мы так делать не будем 😊

5. Считай, прогнозируй, предсказывай ЭТО.
Считаем, предсказываем и умощняем заранее.

6. Товарищ! Будь бдителен! Пандемия может выскочить из-за любого угла!
Как же любят кино пользователи, когда не могут на улицу ходить!

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

Конфигурационное управление большой облачной инфраструктурой на основе OWL-онтологии и Neo4J

Инфраструктура телекоммуникационных сервисов, в разработке которых участвует DINS, включает десятки тысяч серверов в более чем 20 дата-центрах на 5 континентах, как в собственных дата-центрах, так и в публичных облаках.

Деплоймент, мониторинг, обеспечение безопасности и другие задачи эксплуатации таких больших и неоднородных информационных систем требуют наличия продвинутых систем управления конфигурацией — configuration management databases (CMDB), являющейся "единым источником правды" обо всём многообразии элементов инфраструктуры и их взаимосвязях.

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

Помимо этого, рассмотрим реальные практические кейсы применения CMDB, такие как: организация "продвинутого" мониторинга бизнес-сервисов с возможностью агрегации событий и поиском первопричин; построение heat-map'ов работоспособности сервиса; безопасное планирование сервисных работ и другие.

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

Дежурство / Небинарный DevOps / Высокоэффективный гуманный on-call

Ян Ашенкампф

Газпромбанк

Чаще всего дежурства on-call / pagerduty-форматов делают в дополнение к рабочим часам. Это негуманно и не очень оптимально:
* люди выгорают,
* люди ошибаются,
* люди воспринимают это как burden.

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

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

В докладе Ян расскажет о том, как он подошёл к решению этой проблемы в команде, работающей с казначейством.

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

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

Continious Security для кластера Kubernetes

Павел Селиванов

VK Cloud Solutions

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

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

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

Построй свой Database-as-a-Service

Упростить создание и управление базами данных — именно такая идея вкладывалась в Database-as-a-Service облачными провайдерами. Рынок облачных баз данных неумолимо растет, как и vendor lock-in. Мы расскажем про построение DBaaS своими силами, зачем здесь Kubernetes, откуда берется hybrid- и multi-cloud и как с этим живут большие энтерпрайзы.

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

Авито: root cause detector

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

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

В своём докладе я расскажу о том, как мы спроектировали, разработали и запустили в эксплуатацию root cause detector. Этот доклад будет полезен для тех, кто хочет начать применять практику root cause-анализа у себя в компании с целью уменьшения времени жизни инцидентов.

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

Построение самодиагностики и этапы эволюции мониторинга в живой высоконагруженной системе

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

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

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

Что такое GitOps и почему он (почти) бесполезен

В 2017 году Alexis Richardson — CEO and co-founder широко известной в DevOps-среде компании Weaveworks представил GitOps — паттерн реализации непрерывной доставки. С тех пор специалисты компании усиленно продвигают этот подход и поддерживают вокруг него некоторый хайп (вплоть до того, что классический CIOps был ими заклеймён антипаттерном).

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

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

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

10 ошибок (высоко)нагрузочного тестирования в 2021 году. О нагрузочном тестировании для разработчиков, девопсов и тимлидов

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

Что еще интереснее, ниша нагрузочного тестирования является уделом QA-специалистов, отдельно существуют люди, которые пишут тесты, а отдельно — команды, которые что-то делают по результатам тестирования. Ситуация напоминает дев без опсов, или опс без девов образца 2008-го.

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

Хотя и есть попытки встроить нагрузочное тестирование в CI/CD, у этого есть свои сложности. Как минимум все хотят выкладываться быстрее, а тесты — штука долгая. Да и прод грузить хочется по договоренности, а не в момент выкладки. НТ становится проектом, реализующимся от случая к случаю, и набраться нужного опыта у инженеров из веб-разработки не получается.

В этих условиях может произойти настоящая беда: результаты НТ могут быть восприняты как руководство к действию для бизнеса (начать рекламную кампанию, решить не наращивать инфраструктуру или, наоборот, нарастить сверх меры, преждевременно запуститься). При том, что этим результатам нельзя верить, потому что, например:
* проект тестировали 5 минут вместо длительного времени,
* профиль тестирования был определен неправильно;
* тестировали среду, которая совсем не соответствовала тому, как работает прод;
* сайт отдавал HTTP 200, когда на самом деле не работал;
* и еще миллион причин.

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

Технологический стек: JMeter, Gatling, K6, мозг человека.

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

Performance as a service: делаем быстрее и дешевле через сервисный подход

Нагрузочное тестирование — это долго и дорого и это проблема. Почему так?

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

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

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

Какие есть альтернативы? Давайте набирать не много людей, а много знаний. Сделаем полную автоматизацию и nohands-решения, чтобы любой человек в команде (разработчик, тестировщик) мог понять идею и запустить весь нужный инструментарий. Давайте работать с нагрузочным тестированием как с сервисом.

В докладе расскажу о нашем опыте в Самокате — как мы строим PerfOps-команду. Расскажу о концепции, подходе к её реализации, инструментарии и процессе внедрения сервисной модели для нагрузочного тестирования.

Надеюсь, доклад будет интересен
* стейкхолдерам нагрузочного тестирования: как со стороны разработки, так и бизнеса — оценить плюсы и минусы сервисной модели для работы с нагрузкой, примерить эту модель на специфику своего бизнеса;
* а ещё ИТ-инженерам: надеюсь, всё большему их числу предстоит пользоваться PerfOps-инструментарием в ближайшем будущем.

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

Узкотематические секции: видео, поиск, RTB, биллинги (5)

Как мы готовили поиск в Delivery Club

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

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

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

Генерация хайлайтов

Highlight — небольшое видео, показывающее наиболее яркие моменты из фильма. Мы научились создавать highlight'ы автоматически, используя модели computer vision и наш pipeline подготовки видео к стримингу. О том, каким образом это получается, я расскажу в своем докладе.

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

Уже довольно давно мы подозревали, что контент, имеющий трейлеры и highlight’ы, начинают смотреть намного охотнее, но вот незадача — только у 30% единиц контента есть нормальные трейлеры, а коротких highlight’ов нет почти совсем. Перед тем, как ринуться с головой в массовую генерацию новых видеофайлов, мы провели полноценный А/B-тест, который доказал существенно лучшую конверсию в просмотр у контента с дополнительными материалами. Задача была следующая: создать механизм генерации highlight’ов для 80 000 единиц контента, причем нескольких типов с разной длительностью.

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

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

Таргетирование в МТС Маркетолог: ClickHouse, C++ и битовые маски

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

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

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

Биллинг в условиях распределенной системы

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

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

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

Считаем число просмотров видео и зрителей трансляций для десятков миллионов пользователей в день

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

При этом мы решали следующие задачи:
* близкое к realtime время обновления счётчиков;
* возможность горизонтального масштабирования;
* отказоустойчивость при выпадении части мощностей.

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

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

Автоматизированная сортировка. Как Почта России обрабатывает миллионы отправлений в сутки

* Как выглядит жизненный цикл посылки от заказа в интернет-магазине до доставки в почтовое отделение;
* Что такое автоматизированная сортировка и зачем она нужна;
* Как мы управляем сортировочным оборудованием;
* Как мы взаимодействуем с Федеральной Таможенной Службой;
* Какие информационные системы за этим стоят.

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

Резервирование маршрутизаторов в дата-центре: когда количество трафика не имеет значения

Непрерывность доступа в Интернет — что легко сделать на одной сети, то на 2000 сетей не взлетает.

* Почему нужно резервировать выход в Интернет.
* Что, как и зачем. Обзор технологий резервирования.
* Защита от неправильных действий клиентов.
* Как сделать active-active-решение.
* Как сделать аналогичное решение для IPv6.
* Масштабирование решения.
* Вопросы interoperability.

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

Безопасность (5)

DevSecOps и RedTeam: переводим buzzword'ы в практическую плоскость

* Почему RedTeam — это не продвинутый пентест?
* Можно ли построить DevSecOps без SAST?
* Если код проверен сканером, его можно катить в прод?
* Есть ли альтернативы у Bug Bounty?

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

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

Mēris botnet — как это было

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

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

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

Обо всем этом хотелось бы поговорить и показать на конкретных примерах, что из себя представляет новый ботнет Mēris.

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

Безопасные вычисления в высоконагруженных системах — что можно позволить себе с Intel® SGX в облаке

Все мы знаем поговорку «нет никакого облака — есть серверы в дата-центре».

Покажем, как добавить в ваши сервисы, размещенные у провайдера, новый уровень безопасности — создадим изолированный анклав в СPU с помощью технологии Intel® Software Guard Extensions (Intel SGX), к которому не имеет доступа ни гипервизор, ни сисадмин, ни сотрудник ЦОД. Это нужно для безопасного управления ключами, размещения критических функций в облаке и совместной децентрализованной обработки данных без раскрытия датасетов и моделей.

Рассмотрим SGX-анклав с точки зрения разработчика высоконагруженных систем, открытый инструментарий и уровни производительности на конкретных примерах. А также пригласим в лабораторию Selectel протестировать все вышеперечисленное на серверах Intel® Xeon® Scalable третьего поколения.

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

DoS <-> Pwn

Доклад про уязвимости и про DoS. Казалось бы, какая связь? (D)DoS-атаки зачастую считаются "тупыми", чего в них интересного? Действительно, многие злодеи ничего в них не понимают и лишь запускают стандартные варианты атак.
Но...

1. Бывают и более хитроумные атаки, которые можно придумать, если посмотреть на систему с точки зрения пентестера/хакера. Например, можно найти какой-то интерфейс, который шлёт много запросов к БД, или у него неоптимальный алгоритм, который уводит CPU в полку.

Расскажу про интересные прикладные и канальные атаки из практики DDoS-тестирования разных сервисов (ритейл, соц. сети, банки и т.д.).

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

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

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

Строим Security Сenter для Kubernetes-платформы

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

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

Мы пойдем по другому пути — посмотрим:
* на процесс деплоя и шаги, которые можно обеспечить на его этапе; конечно же, поговорим о том, как gitops поможет сделать инфраструктуру безопаснее;
* на инструменты обеспечения безопасности в кластере Kubernetes — сравним их друг с другом и дадим ссылку на результаты, которыми можно воспользоваться в будущем;
* как интегрировать все инструменты в SIEM-систему — тут же рассмотрим проблематику, как делать это в multi-cluster-среде, и покажем, как решаем их с помощью Python, s3 и ElasticSearch. Также я расскажу, куда мы для этого законтрибьютили и что планируем делать дальше.


В итоге вы получите:
* чек-лист по обеспечению безопасности k8s;
* матрицу сравнения инструментов обеспечения безопасности кубернетиса;
* terraform-плейбук для интеграции событий разных инструментов обеспечения безопасности в единое хранилище на базе Elastic.

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

BigData и машинное обучение (13)

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

Евгений Малютин

ВКонтакте

Рекомендательная система может стать как черной дырой, пожирающей железо и время разработчиков и не приносящей результат, так и управляемой точкой роста для продукта. В случае b2c-продуктов: социальных сетей, e-commerce или контентных платформ ставки еще выше — от качества рекомендаций напрямую зависит Life time value пользователя и ключевые метрики компании.

В докладе разберем, как работают рекомендательные системы и какие возникают проблемы, когда нужно рекомендовать контент 97 млн пользователей и отдавать результат на скорости 10k RPS. Покажем, как логически и технически устроены подобные системы на примере рекомендаций сообществ ВКонтакте. Обсудим плюсы и минусы трех классов систем: офлайн, онлайн и асинхронные, чем стоит руководствоваться при выборе и как жить c последствиями.

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

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

Как построить Data Mesh в компании на Open Source

Дмитрий Шостко

Adeo Group/Леруа Мерлен

* Data Mesh: поговорим коротко о концепции, необходимых аспектах, чтобы data mesh взлетел и почему все будем там.
* Суррогатный Data Mesh.
* Проблемы, с которыми мы столкнулись (legacy, двойные транзакции, семантика приложений) и как решали, а также о том, как Data Mesh влияет на архитектуру хранилища и технологический стек.
* Рассмотрим архитектуру технологического решения у нас, а также поговорим о нерешенных проблемах.
* Как масштабировать подход на 12 стран и почему Data Mesh — это на самом деле про продукт и там тоже есть клиент.

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

Особое мнение: предугадываем фрод без дата-сайнса в Sportmaster Lab

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

* Поговорим о том, что такое антифрод.
* Посмотрим на структуру и объемы данных (спойлер: их там очень много).
* Выберем инструменты для решения этой задачи: Hadoop, Spark, Airflow и т.д.
* Заглянем внутрь алгоритмики (да-да, DS там пока нет) и оптимизации вычислительных ресурсов.
* Разберём «на пальцах» реальные гипотезы: от бизнес-потребности до визуализации результата.

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

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

Поиск в HeadHunter: как подружить machine learning и production

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

Именно с такими задачами мы столкнулись в HeadHunter во время внедрения машинного обучения в сервис поиска, и на примере чего хочется обсудить возникшие проблемы и наши решения:
* для взаимодействия между обучением моделей на python и инференсом на java;
* для оптимизации архитектурных решений на java для сложных моделей;
* поведенческие признаки в production;
* а также java и mmap, сериализация и обмен данными между python и java.

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

Архитектура SberCloud MLSpace для решения задач MLOps

* Архитектура SberCloud MLSpace и его использование на суперкомпьютере Cristofari.
* Решение инженерных задач MLOps в среде SberCloud MLSpace.

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

Client as Service, или Наш опыт в разработке платформы для экспериментов

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

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

Client As Service — это проект, который помогает подготовить миллионы пользователей к экспериментам. Проект, который использует статистику покупателей, чтобы найти бизнес-инсайды и помогает составить ответ на каждый запрос.

Теперь любой запрос «необходимы покупатели из оттока, которые имеют домашних животных», имеет свой ответ «10 лояльных клиентов, которые ушли в отток и имеют домашних животных, перестали покупать из-за вероятных причин: нет необходимой категории продукта / выведен из продажи товар. С помощью … вы сможете сделать эксперимент по возврату покупателей». Над предложенным количеством можно начинать маркетинговый эксперимент и получить оценку по результату.

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

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

Как регулярно строить всё больше ML-пулов на MapReduce, а дежурить все меньше

Изначально наши пулы строились набором python-скриптов, запускаемых по cron'у. Когда число таких скриптов перевалило за 100, ситуация вышла из-под контроля. Починка прода стала занимать всё рабочее время, а любая выкатка стала подвигом. Мы решили переписать систему, чтоб исправить это, и теперь поделимся опытом.

Мы расскажем:
* как организуем разработку новых MR-задач, чтобы не тратить много сил на ревью;
* как тестируем новые задачи, чтобы (почти) не бояться выкатывать их в production;
* как выстраиваем дежурство, чтобы не чинить пайплайны все рабочее время.

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

Особенности построения и поддержки аналитического in-house data lake в EdTech

EdTech является сравнительно молодой областью, в которую внедряются Data Driven-подходы, что даёт несколько больше свободы для экспериментирования с техническим стеком. В нашем случае LMS (система управления обучением) развивалась децентрализованно с большим количеством сервисов-сателлитов (каждый со своим стеком), что приводило к тому, что аналитикам в первом приближении необходимо было выгружать данные из 3-5 источников и сводить потом данные на локальной машине, хотя всё можно было делать в рамках одного SQL-запроса.

Как мы с этим справились и причём здесь нарвалы — расскажу в рамках этого доклада, а также поговорим:
* как и почему мы выбрали именно Prefect как основной шедулер ETL, а не “классический” Airflow?
* как с помощью DBT стимулировать аналитиков писать документацию к разным уровням преобразования данных?
* что нужно сделать, чтобы подружить DWH-движок Dremio с Prefect’ом и DBT?

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

"Вы это смотрели", или Как мы построили платформу для рассылок персонализированных уведомлений пользователям AliExpress Россия

Руслан Гилемзянов

AliExpress Россия

Я расскажу, как используя гетерогенные источники данных внутри AliExpress Россия, мы построили платформу на базе семейства продуктов Apache (Hadoop, Hive, Flink, Kafka, HBase и т.д.), позволяющую отсылать персонализированные уведомления пользователям.

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

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

Проксирование данных для Hadoop

Андрей Ильин

Сбербанк

Доклад посвящен продуктам, разработанным в SberData, для прозрачного федеративного доступа пользователей к данным в экосистеме Apache Hadoop. Обсудим основные принципы работы компонентов Apache Hadoop: HDFS, Hive и Sentry/Ranger. Расскажу про особенности проксирования данных, метаданных и привилегий.

Будут затронуты основные проблемы разработки и проектирования распределенных систем, расскажу, на какие проблемы стоит обратить внимание, об аспектах безопасности и нюансах использования Kerberos. Обсудим форматы хранения данных в HDFS, в частности, формат Apache Parquet.

Коснемся особенностей работы с open source-библиотеками Apache Hadoop, их доработки и реализации функционала, который нигде не описан, и непонятно, с чего начинать.

В финале обсудим нюансы эксплуатации ПО подобного класса: проведение нагрузочного тестирования, взаимодействие со смежными системами, мониторинг, настройка health check'ов, управление конфигурацией и развертыванием.

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

ML для ML в задачах качества данных

Денис Занков

Газпромбанк

Работа с качеством данных актуальна не только для решающих задачи моделирования, но и в целом для тех, кто использует Data Driven-подход. Задача поиска новых решений в этом направлении стала особенно острой для Газпромбанка при работе с оттоком посредством ML-подходов, где был найден значительный бизнес-эффект. Такие модели характеризуют продуктовое поведение человека. Для их вывода в промышленную эксплуатацию необходимо поддерживать витрину с фичами по каждому клиенту. Это тысячи колонок с признаками миллионов клиентов по состоянию на каждый месяц за несколько лет.

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

Основная идея в том, что нужно не рассматривать фичу поклиентно, а представить распределение переменной за каждый временной срез через описательные статистики. Из-за неоднородности этих описательных статистик и других причин мы выбрали ML-метод Isolation Forest в качестве core для самого алгоритма ранжирования аномальностей — в докладе мы поговорим о преимуществах и ограничениях данного метода в качестве core-алгоритма.

Обсудим также, почему Isolation Forest не работает просто на статистиках и зачем требуется дополнительная ранжирующая функция аномальности и алгоритм интерпретации результата.

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

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

Потоковая обработка BigData для МТС

В докладе я расскажу, как мы в МТС собрали инструмент для потоковой обработки 10 миллионов событий в секунду, используя Scala(Java), Apache Spark Streaming и PostgreSQL. Почему выбрали Apache Spark Streaming, какие были проблемы на разных этапах разработки. Дам проверенные в бою рекомендации в части тюнинга Spark (concurrentJobs, speculation, memoryOverhead, memory, executors, cores и т.п.). Покажу, как мы подружили этот инструмент с Prometheus, Grafana, ELK, Kibana, и какие характеристики у железа, на котором это все работает.

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

"Акведук": open source для быстрого ML в продакшне

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

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

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

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

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

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

Нейросетевые рекомендации сообществ ВКонтакте: как сделать так, чтобы работало

Любовь Пекша

ВКонтакте

Главная проблема красивых нейросетевых подходов в рекомендациях — их только показывают.

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

На примере рекомендаций сообществ ВКонтакте, расскажу, как сделать нейросетевую архитектуру для рекома, которая действительно хорошо работает и даже (маленький спойлер) приносит приросты не только для команды Сообществ.

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

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

Оптимизация инференса нейронок на CPU с использованием SIMD и квантизаций на примере WaveNet

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

Сравним особенности сервинга WaveNet и других вокодеров и обсудим целесообразность нашего подхода.

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

Сервис распознавания речи. От моделей до production-решения

В докладе будет рассказ о внутреннем устройстве нашего сервиса распознавания речи (https://voicekit.tinkoff.ru/).

Перед нами стояла задача — обработка ~7000 параллельных аудиопотоков для распознавания, а также распознавание не в потоке с RTF (Real Time Factor) < 0.25, используя при этом ограниченные ресурсы GPU.

Расскажу о том, зачем вообще необходимо распознавание речи, дам обзор основных модулей нашего сервиса, углублюсь в технические детали реализации:
* какими метриками можно оперировать в потоковых аудиосервисах (SPS, RTF, Head/Tail latency);
* как переписать бэкенд с Python на Go из-за отсутствия в Python хорошей многопоточности;
* как перевести кодовую базу на go-pipelines (https://blog.golang.org/pipelines), чтобы каждый этап обработки аудио проходил асинхронно;
* как развертывать deep-learning-модели в проде при помощи tf-serving, балансировки grpc-запросов через envoy и бесшовной выкатки новых моделей;
* как правильно настраивать батчинг моделей, чтобы максимально утилизировать GPU.

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

Построение HPC/GPU-кластеров для машинного обучения

Яндекс в 2021 году запустил три HPC/GPU-кластера для машинного обучения, которые стали самыми мощными суперкомпьютерами в России. Мой рассказ будет о том, с какими сложностями и неожиданностями мы столкнулись на этом пути.

Из этого доклада вы узнаете:
* о революции трансформеров;
* о том, что такое современный HPC/GPU-кластер, зачем коммерческим компаниям понадобились суперкомпьютеры;
* на каком стеке технологий они строятся и почему;
* почему HPC — это сложно, а традиционные подходы часто не работают;
* как вообще устроен процесс попадания в топ-500, и как, оптимизируя
производительность для попадания в рейтинг, мы нашли проблемы, решив которые, мы ускорили наше машинное обучение.

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

Видеоаналитика на взрывоопасном заводе площадью в 700 футбольных полей

Вадим Щемелинин

СИБУР Диджитал

Три года назад перед нашей командой поставили цель: все видеокамеры в нефтехимическом холдинге СИБУР должны выводиться на экран операторам только тогда, когда в зоне их видимости "что-то идёт не так". За это время мы не раз посетили заводы, изучили производственные процессы, разработали и внедрили систему, которая покрыла 70% камер.

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

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

Fast, deep and high. Как строить Low Latency-рекомендательный трансформер на миллион RPS

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

Примерный план доклада:
* высокоуровневое описание модели, для чего она нужна и как она работает;
* зачем мы разделили полноценный рекомендательный трансформер с early fusion-подходом на независимые части;
* какие сложности возникают в обеспечении консистентных данных в рантайме и в обучении;
* почему вашу рекомендательную модель нужно регулярно дообучать;
* почему батчевание GPU-вычислений критически важно;
* как разделение СPU- и GPU-частей модели может помочь выиграть еще несколько тысяч RPS на GPU.

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

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

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

Для этого постоянно приходится решать различные NLP-задачи. Мы адаптируем и обучаем большие языковые модели на базе трансформеров (BERT, GPT), которыми делимся с сообществом в open source:
https://habr.com/ru/company/sberbank/blog/524522/
https://habr.com/ru/company/sberdevices/blog/547568/

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

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

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

Производительность мобильных приложений (1)

Как мы ускорили Яндекс Go на несколько секунд

Денис Исаев

Яндекс Go

Фокус доклада — ускорение на стыке backend/mobile для крупного и уже оптимизированного продукта. Мы не будем обсуждать базовые вещи: кэширование и оптимальный код. Примеры того, что мы затронем:
* deadline propagation и hedged requests;
* может ли префетч в приложении замедлять;
* какой RTT на 2G и в Африке;
* цена фонового запроса и паттерн API Gateway;
* как продать бизнесу ускорение.

Доклад построен на реальном опыте ускорения Яндекс Go.

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

Enterprise-системы (2)

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

Тимур Давыдов

Московская Биржа

В докладе рассмотрим архитектуру современной торгово-клиринговой системы (ТКС) и более подробно познакомимся с in-memory-базой данных, оптимизированной для работы с низкими и предсказуемыми задержками, предназначенной для хранения информации во время работы ТКС.

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

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

Как написанная нами система со временем отклика менее 2 мс помогла избавиться от финансового фрода и заработать на комиссиях

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

Спойлер: это многотредовый монолит на C, без виртуализации, но с Redis, protobuf и кэшированием внутри приложения. И это работает, и не падает (почти).

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

Интернет вещей (IoT) (1)

Как мы запускали компьютерное зрение для офисов продаж МТС по всей России

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

В МТС более 5000 точек продаж. "Ручной" подсчет количества посетителей и сбор другой аналитический информации в режиме реального времени и в таком масштабе не представляется возможным.

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

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

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

Как выжать 1 000 000 RPS

Расскажу, как мы в порядке эксперимента выжимали 1 миллион запросов в секунду из 1 физического сервера и СУБД, никогда при этом НЕ рассчитанной на именно такой workload (спойлер: СУБД всё ещё Сфинкс).

* Почему выжимали именно ~1 миллион (а не ~0.1 или ~10м).
* В каких местах обнаружились тормоза (спойлер: в разных и поначалу несколько удивительных).
* Как получилось подлечить 3+ места с разумной трудоемкостью и немедленно закатить эти успехи в бой (тизеры: не обошлось без пары строчек ассемблера, причем, что удивительно, сервер Intel, а ассемблер понадобился ARM; не обошлось без легких лок-фри-фокусов; не обошлось без переписывания простеньких системных вызовов вручную и прочей легкой наркомании).
* Чего в итоге получилось.
* Где ещё есть известные диоды, которые уже так просто не залечить.
* Ну и совсем вкратце — как теоретически атаковать следующие вершины (10+ миллионов RPS).

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

Идеальный шторм: когда готовил систему к росту нагрузки, но не успел

История о том, как мы воевали с инцидентами под растущей нагрузкой и какие выводы сделали. Действующие лица: высоконагруженная система из монолита и микросервисов, кластер posgtres, кластер kubernetes, несколько команд разработки и тестирования, менеджеры в ассортименте.

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

Обзор архитектуры быстрого сборщика логов на Go

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

Расскажем, как c помощью этого инструмента мы сократили издержки на сбор логов в 10 раз по CPU и добились 100% доставляемости логов.

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

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

Избавляемся от кэш-промахов в коде для x86-64

Это рассказ об оптимизации работы с большим объемом данных, о том, как найти, какое именно обращение к памяти вызывает задержки и как взаимодействуют ядра в разных поколениях серверных процессоров Intel с примерами кода из нашей библиотеки для работы с разделяемыми key-value-наборами данных.

* Оpen-source kv-хранилище rc-singularity, что это и для чего;
* поиск кэш-промахов с помощью perf, как понять, где они возникают;
* какие бывают инструкции предвыборки, когда их использование оправдано;
* иерархия кэшей и ее влияние на многопоточные приложения.

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

Блокчейн (1)

Современные векторы атак на DeFi-проекты

DeFi — быстрорастущий рынок, приманивающий своими высокодоходными ставками. Любой высокий доход сопровождается и высоким риском. В докладе я рассмотрю контролируемые (минимизируемые) риски. Из $100B+, вложенных в DeFi, более $14B подверглось атакам и хищениям. При этом речь идет только про публично известные случаи. По нашей оценке, непубличные хищения могут увеличить общий размер утрат на 50%.

- Контролируемые риски со стороны создателя и мейнтейнера проекта, их цена, объем потерь:
-- Misuse of Third-Party Protocols and Business Logic Errors.
-- Coding Mistakes.
-- Flash Loans, Price Manipulation, Miner attack.
-- Некомпетентность разработчика.
- Практический разбор векторов атак ($5B+ потерянных средств):
-- Flash loan, block mining attack.
-- RFI в masterchief.
-- Flash Loan.
-- Изменение кода популярных библиотек OpenZeppelin (SafeMoon $2B+ эксплойт).

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

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

Как мы в Tinkoff Data Catalog создавали

В чем главная задача аналитика? Думать головой и принимать решения. Правильные решения можно принять только при наличии нужных данных. А как найти данные в большой компании? В этом-то и проблема.

Хранилище данных в Tinkoff существует уже 14 лет и за это время мы накопили гигантский объем данных (2 петабайта данных, ± 120 000 таблиц, ± 30 000 отчетов и еще много чего). А теперь представьте себя на месте любого из 3000+ людей, которые ежедневно ищут в этом море данных нужную им информацию! Традиционно мы решали эту проблему с помощью ручного ведения документации в Confluence, но с ростом объема данных этот подход становился все менее и менее эффективным. Проблема встала ребром, мы поняли, что пришло время что-то менять, и решили внедрять у себя Data Catalog.

Первым делом мы попытались найти решение на рынке, но не нашли ничего подходящего именно нам. Поэтому решили вложиться и сделать свой продукт. В докладе мы подробно расскажем:
1) Как мы искали решения на рынке и почему решили сделать своё.
2) Какой продукт мы в итоге сделали и как применяем его в нашей Data Platform.
3) Про архитектуру продукта и как нам удалось вместить в него столь разношерстную информацию по всем нашим данным.
4) О проблемах, с которым мы столкнулись в процессе разработки, и о решениях, которые приняли.
5) Что мы планируем делать дальше?

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

Круглый стол "Digital transformation в финтехе — фундамент роста или хайп"

Цифровая трансформация — модное слово, которое звучит сейчас в ИТ из каждого утюга.

1) Но что это такое? Чем трансформация отличается от автоматизации, которой мы все занимались еще со времен Союза, разрабатывая и внедряя различные АСУ?
2) Какие новые технологии можно отнести к вещам, которые дали возможность говорить именно о трансформации?
3) Являются ли эти новые технологии новыми способами решения практических задач или это маркетинговые технологии повышения ставок в борьбе за колоссальные финансы?
4) Блокчейны в DT — хайп в квадрате или практические инструменты решения задач?
5) Машинное обучение и Data Driven-подход — реальные кейсы или все заканчивается на внедрении электронных звонильщиков?
6) Что нас ждет в ближайшем будущем — новая волна хайпа, направления роста, прогнозы.

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

Индустрия 4.0 в СИБУРе

Вадим Щемелинин

СИБУР Диджитал

Что мы понимаем под Индустрией 4.0 в СИБУРе, где в ней свой написанный код, особенности разработки и внедрения интеллектуальных решений на заводах.

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

С++ (7)

Статический анализ кода++

Если судить по опросу C++ Foundation, то проблемы безопасности кода на C++, ошибки при работе с памятью и прочие типичные "боли" языка — все еще самые актуальные для разработчиков на C++. При этом, как известно, софт более высокого качества обходится дешевле в создании (а не только в поддержке, как можно было бы подумать).

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

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

С++ и msgpack: проектирование кастомных протоколов

В своем докладе я хочу рассказать, как мы используем msgpack в асинхронном сетевом протоколе СУБД и сервера приложений Tarantool в целом и о реализации его клиентской части (коннектора) на С++, в частности.

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

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

Однако самым интересным, на мой взгляд, является реализованный используемый нами подход для работы с msgpack в С++. С самого начала стояли цели удобства и максимизации производительности упаковки/распаковки msgpack, что заставило нас сделать много интересных вещей, например, compile-time-упаковку, и state-machine-распаковку данных. Все это сделано при помощи настоящей забористой шаблонной магии, что должно обязательно порадовать настоящих любителей C++.

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

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

Что могут C и C++, и когда нужен ассемблер

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

В этом докладе мы посмотрим, какой код генерируют GCC и Clang для некоторых C и C++ конструкций и как сделать этот код быстрее. Мы также копнем в специфичные для x86-64 оптимизации. Обсудим микробенчмарки.

* Как x86-64 исполняет код и как работает с памятью.
* Некоторые полезные расширения и оптимизации GCC и Clang для C и C++.
* Когда ассемблер x86-64 не только быстрее, но и проще C.
* Скользкие места программирования для многоядерных архитектур
* Защита от Spectre в компиляторах.
* Profiler guided optimization (PGO) и когда она бесполезна.

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

Почему всё сложно с оптимизацией и что с этим делать

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

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

Как работает С++-движок рекламного сервера, и с какими проблемами мы сталкиваемся

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

План доклада:
* общая схема работы myTarget;
* очереди задач;
* синхронизация индекса;
* работа с метриками и статистикой;
* как решалась проблема с бесплатным для рекламодателя показом баннеров.

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

Украшаем молоток: как автоматизировать разбор проблем в дебаггере

Сергей Козлов

Лаборатория Касперского

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

Проводим лайвкодинг-демонстрацию нескольких скриптов в отладчике, в частности:
* поиск исключений, произошедших в потоке ранее (Win);
* вывод стеков 32-битного приложения для 64-битного kernel-mode дампа (Win);
* поиск потребителей большого количества памяти:
- анализ с AppVerifier'ом
- анализ без AppVerifier'а (GDB)
* что делать, если упали в boost::coroutine (GDB).

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

Компилируем 200 000 файлов быстрее, чем distcc

Мы ВКонтакте конвертируем PHP в С++ (у нас свой компилятор — KPHP). А потом огромную кучу плюсовых файлов нужно прогнать через g++. Их очень много, и локально это чересчур долго. Нужно что-то придумывать.

Расскажу, как мы пользовались distcc, патчили его для поддержки precompiled headers, а сейчас написали ему замену — и выкладываем её в Open Source.

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

HighLoad++ Foundation - Резерв (4)

Биллинг умер, да здравствует биллинг! Правдивая история о том, как и почему мы с нуля переписали биллинг нашего облака

Сегодня VK Cloud Solutions — это крупный облачный провайдер, а пару лет назад при мне в продакшн был выкачен первый релизный пакет с кодом платформы. Такому стремительному росту и успеху можно только позавидовать, однако вряд ли с этим бы согласился наш биллинг.

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

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

Как мы строим Feature store

За пять с лишним лет Big Data МТС выросла из небольшого внутреннего стартапа в самостоятельный центр с более чем тремя сотнями сотрудников и десятками продуктовых команд. Наши наработки ML проходят этап взросления из бунтарского rnd в зрелый production. И мы словили пучок детских болезней — не могли понять, какие у нас уже собраны фичи, где они находятся, сколько же у нас всего моделей и какие данные они потребляют, не было единых средств поставки данных. Оказалось, что эти боли — универсальные для многих компаний, поэтому мы решили поискать возможные решения на рынке. Нам ничего не подошло, и вот мы уже строим свое. Об этом и расскажу.

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

«Объединяй и властвуй», или Опыт решения задачи консолидации грузов в Near Real-Time-системе

К сентябрю 2021 Самокат доставлял 6.8 миллионов заказов в месяц в 22 городах, а за год до этого — всего 1.6 миллиона заказов в месяц в 4 городах.

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

Вроде бы классическая задача для ритейла — задача коммивояжёра с ограничениями. Но что если речь заходит об онлайн-магазине, где большая часть заказов имеют SLA 15 минут?

Кроме того, что задача принадлежит к классу NP-трудных задач, она ещё усложняется возникающими ограничениями и проблемами:
* время на принятие решения исчисляется даже не секундами, а в лучшем случае парой сотен миллисекунд;
* размещение нового заказа/отмена уже размещённого/задержка курьера на предыдущем заказе/любые другие нештатные факторы тут же требуют пересчёта ранее принятого решения с учётом новых данных. Если этого не сделать, то влияние возникшего фактора на дальнейшую работу склада может быть довольно значительным;
* с одной стороны, нужно повышать агрессивность консолидации при возросшем спросе, чтобы не увеличивать опоздания к клиентам. C другой стороны, больная спина курьеров-партнеров — это явно не то, чего мы хотим достичь. Их здоровье для нас не менее важно.

И это только часть возникающих проблем. Всё это трансформируется в нетривиальную техническую задачу.

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

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

Проблемы приземления данных из Kafka и их решение на Apache Flink

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

Все эти события реального мира у нас отражаются сообщениями в Кафка. Но эти сообщения кто-то должен получить и обработать, чтобы посылки не терялись. На стороне обработки есть разные задачи:
* нужно писать лог событий. В Кафке у нас JSON или avro, а лог мы пишем в Hadoop, и там нужен ORC или Parquet;
* поверх получаемых данных нужна real-time-аналитика. Например, хочется понимать пропускную способность всей логистической компании;
* нужно сопоставлять факт отправки и получения и поднимать тревогу, если посылка задерживается. Для этого нужно где-то до нескольких дней помнить про отправку.

Для всех этих задач нужно иметь компонент, который делает real-time-обработку и пишет лог. В нашем случае это Apache Flink. Он берет на себя горизонтальное масштабирование обработки, отказоустойчивость и мониторинг.

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

В докладе рассмотрим принципы проектирования пайплайнов на основе Flink, которые позволяют забирать и приземлять данные из Kafka максимально безболезненно.

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

TechTalk (1)

Почему никто не умеет делать экспертные системы в промышленности?

* Что такое экспертная система (ЭС)?
* Зачем ЭС нужны?
* Почему делать ЭС сложно?
* Что обычно умеют люди?
* Чего не хватает специалистам, чтобы создавать ЭС?
* Чему нужно учиться и учить, чтобы серийно создавать и внедрять ЭС?
* И почему это все ещё боль? :)

Обсудим на техтолке!

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

GolangConf: Best practices (1)

Как Go выполняет встраивание (inlining) функций

Это обзорный доклад о том, как происходит встраивание (inlining) функций в Go. Из него вы узнаете:
* зачем, вообще, встраивание нужно, какие преимущества и недостатки несет в себе;
* как Go встраивает функции, и как эта стратегия менялась со временем;
* какие есть ограничения и как некоторые из них можно обойти.

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

GolangConf: Technologies (5)

Обработка больших объемов событий в real-time-рекомендательных системах на Go

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

Для реализации данной задачи в нашей компании созданы несколько микросервисов на языке Go. Система обрабатывает более 200K запросов в секунду и хранит в памяти Go-процесса около 120 Gb данных. При этом в секунду рассчитываются вероятности конверсии для 25M рекламных предложений.

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

* Чтение большого объема данных из нашей шины событий (kafka).
* Расчет агрегатов событий в различных разрезах (счетчиков) с наименьшими затратами по CPU и memory footprint, и какие структуры данных мы для этого используем.
* Уменьшение contention при обработке событий.

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

Go и Machine Learning: не Python'ом единым...

Дмитрий Вишин

СберМаркет

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

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

Как работать с секретами в Golang, чтобы минимизировать хаос в менеджменте секретов

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

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

Идем по приборам вместе с gRPC

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

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

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

Паттерн Outbox: как не растерять сообщения в микросервисной архитектуре

В своем докладе расскажу, почему мы решили пойти по пути at-least-once и не полностью положились на работу брокера сообщений? Что из себя представляет паттерн Outbox, который и стал ключом к решению проблемы потери данных? Почему мы выбрали именно его, написав реализацию в виде библиотеки на Go?

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

GolangConf: Hardcore (5)

Кэш в оперативной памяти своими руками

Что делать, когда вам нужно отвечать настолько быстро, что позволить себе ~1-3 ms для похода в Redis за кэшем — это очень дорого? Можно же хранить кэш прямо в памяти приложения. Но тогда встают вопросы:
* Память кончается, надо что-то выбросить из кэша! Но что именно?
* Как обновлять значения в кэше так, чтобы не завалить внешние ресурсы большой нагрузкой (предотвратить эффект Cache Stampede)?
* Если приложение распределенное, и нам подобный кэш надо держать согласованным, то каким образом это сделать (согласованность кэшей)?

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

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

Profile-guided-анализ кода

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

* Как отличить хороший CPU профиль от плохого;
* какова структура profile.proto файлов и как их парсить;
* как раскрасить горячие строки кода в редакторе;
* что такое структурный поиск кода по горячим местам;
* статический анализ производительности на основе профилей исполнения;
* несколько полезных рецептов для pprof;
* альтернативные способы агрегации без pprof.

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

Go Map Internals

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

Доклад будет разбит на три части (две большие и одна не очень):
1) теоретическая часть (hash, hashmap, виды адресации);
2) изучение исходников и небольшое сравнение с другими языками;
3) sync.Map и немножко "горячих обсуждений".

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

Go To Memory. Разбираем аллокатор Go по полочкам

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

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

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

Golang. Быстро/медленно

Филипп Кулин

СПбЭК-Майнинг

* Выбор эталона для сравнения... если сможем.
* switch, slice или map?
* slice или map? Когда?
* Использовать ли defer?
* Насколько "прожорливое" оборачивание ошибок?
* Ох уж эти дженерики...

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

GolangConf: Architecture and frameworks (5)

Разработка отказоустойчивого приложения с запланированной деградацией

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

В докладе рассматриваются:
1. Использование технологий компании HashiCorp: Nomad, Consul, Vault.
2. Деление production && staging окружения. "Отбор" staging в случае аварий, автоматически перераспределяя нагрузку.
3. Почему nomad, а не k8s.
4. Чек-лист, который мы составили для себя при разработке graceful degradation для сервиса.

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

Бардак в main, стандартизация и uber.fx. Продакшн-применение библиотеки и почему стоит и не стоит бояться контейнеров

Данила Проценко

Лаборатория Касперского

uber.fx — это не только DI-контейнер, но и библиотека управления жизненным циклом приложения и его компонентов.

Запуск/остановка приложения, остановка по требованию, graceful shutdown vs аварийная установка.
* Бест-практисы и как не класть приложение в тихую
Компоненты приложения и управление их запуском и остановкой.
* Паттерн Start Stop в формате fx.
* Аварийная установка отдельного компонента.
Стейджи запуска приложения.
* Логирование стейджей и проблем.
DI-контейнер — расстановка зависимостей, бест-практисы.
* (доп. тема) Аннотации, именованные инстансы.
Тестирование целостности DI-контейнера.
* (доп. тема) Модули — группы компонентов.

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

Что дженерики нам готовят

Много раз при обсуждении преимуществ и прелестей Go как языка разработки мне приходилось слышать что-то типа «у вас ДАЖЕ нет дженериков» или «вот завезут дженерики, тогда и поговорим». Так вот, дженерики завезли, попробовать можно уже сейчас, а доступно для всех будет с релиза 1.18 (намечен на февраль 2022). Сообщество окончательно определилось, как именно всё будет реализовано и что мы получим в результате.

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

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

Ent: Making Data Easy in Go

Dmitry Vinnik

Facebook

Ent is an entity framework built for Go programming language. This framework provides developers with a Graph-based ORM.

In this talk, we will learn how to use Ent when dealing with data schemas, including types, relations and constraints. It’s a hands-on talk, so get ready to follow along!

What do most applications do these days? They interact with data in one way or another. As your app’s scale increases, it becomes more challenging to manage databases, schemas, queries and constraints. These challenges are why a technique called Object-Relational Mapping, or ORM, was created.

At Facebook, we tend to think about data modeling in graph concepts and as we were working with Go, it led us to create a new open source project, Ent.

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

Работа с полиморфным поведением в большой кодовой базе

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

В своём докладе я расскажу, как организована наша кодовая база из 1M+ строк на Go, как мы используем и как не используем фичи Go, как добиваемся масштабируемой архитектуры на уровне кода и как проектируем API в проекте, где новые А/B-тесты запускаются каждый день.

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

GolangConf: Резерв (2)

Пишем Key-Value СУБД на Go

Создание СУБД на Go — сложная задача по двум причинам:
1. в Go плохо со средствами обобщенного программирования;
2. производительность Go не дотягивает до языков, традиционно используемых для написания СУБД — C, C++, Java.

Да, на Go уже написаны несколько СУБД, самая известная из которых — CockroachDB. И да, показать в одном докладе процесс создания продукта такого масштаба невозможно.

Но мы не привыкли отступать!

Для СУБД нам нужны:
1. Надежный производительный движок хранения. Движков на Go написано уже несколько, но все они, насколько известно автору, вдохновлены LSM Tree, со всеми его плюсами и минусами. Мы пойдем другим путем!
2. Сетевой доступ к хранимым данным. Это, на самом деле, самая простая из задач, но и тут есть о чем рассказать.
3. Система кластеризации с обеспечением отказоустойчивости — никому в XXI веке не нужна односерверная Key-Value СУБД.
4. Система управления кластером. Вывод серверов из кластера, ввод новых, ребалансировка... Очень увлекательно!
5. Клиент с поддержкой шардирования.

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

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

Go deeper

Интересно ли вам, как именно в Go реализованы анонимные функции? А замыкание параметров? Как реализуется логика defer, и почему раньше он был медленнее, чем в актуальных версиях языка? Как map работает с любыми типами без generics?

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

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