Доклады

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

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

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

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

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

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

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

FSM-фреймворк на Go

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

Программный комитет ещё не принял решения по этому докладу

Как мы монолит в Kubernetes затолкали, эволюция архитектуры Авито

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

Программный комитет ещё не принял решения по этому докладу

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

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

Подробнее на простом примере:
Пусть у нас есть много входных очередей (например, kafka) с событиями, каждое событие содержит идентификатор стейта StateId и относится к соответствующему стейту. И мы хотим в реальном времени считать аггрегаты произвольной сложности (= обновлять стейты) по входным событиям с семантикой exactly once.
Для эффективной работы такой схемы для обновления стейтов в хранилище нужна какая-то локальность по ключам, поэтому входные данные нужно сначала пошардировать примерно так же, как шардированы данные в хранилище.
Тогда в этом простом случае получается, что нужно два сервиса: один читает входные события и пишет их в промежуточную очередь пошардированно (resharder), другой читает уже шардированные события и обновляет стейты в соответствии с ними (aggregator).
Что плохо в этой схеме? В том, что весь поток событий необходимо писать через промежуточную очередь, а это большой поток на записи на диски и соответственно много железа! А ведь еще есть небольшая задержка.

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

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

Строим мультикластерные сервисы Kubernetes вместе с Istio Service Mesh

Сегодня Kubernetes становится де-факто одним из стандартов для запуска Cloud-Native решений, а Service Mesh - типовым подходом для решения интеграционных проблем в контейнеризованных средах.

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

В рамках доклада мы узнаем, как можно построить федеративную межкластерную маршрутизацию на базе Istio Service Mesh, и ответим на вопросы:

1 Что предлагает Istio «из коробки», и что делать, если стандартные схемы мультикластерной деплоймента вам не подходят;
2 Как реализовать управление межкластерным трафиком и делать мультикластерные канареечные релизы;
3 Как обеспечить сетевую локальность для межкластерного трафика;
4 Как реализовать мультикластерные механизмы для работы таких паттернов, как retries, timeouts, circuit breakers.

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

В ногу со временем или как мы модернизировали устаревшую систему

Николай Кувыркин

Raiffeisen Bank Russia

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

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

Обдумывая варианты решений, мы использовали Apache Ignite в качестве горизонтально масштабируемого хранилища, чтобы обеспечить локальность хранения данных и минимизировать сетевые задержки. Упрощение контроля за изменениями было обеспечено благодаря кластеризации функционала – использования отдельных кластеров хранения данных, интеграции и обработки бизнес-логики. Автоматизация процессов CI/CD и применение Docker/Kubernetes позволили нам снизить стоимость эксплуатации и внесения изменений. А использование технологий Prometheus, FileBeat, Kibana, Grafana, AlertManager обеспечили прозрачность функционирования новой системы.

Программный комитет ещё не принял решения по этому докладу

Как вырастить поисковый индекс в 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 событий в сутки. И еще фильтровать данные по произвольным срезам, строить графики, считать метрики, сравнивать сегменты, настраивать алерты.

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

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

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

Юрий Бабак

Мир Plat.Form

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

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

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

Для более полного погружения в тему рекомендую посмотреть первую часть моего доклада — "Высоконагруженная платежная система "Мир": что под капотом" (HL++ 2021 Весна).

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

Highload-платформа для realtime-решений в банке

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

Программный комитет ещё не принял решения по этому докладу

Масштабируем архитектуру в условиях кратного увеличения числа пользовательских заказов

Давайте поговорим о масштабировании архитектуры.

Самокат растёт. Год назад мы доставляли 1.6 миллиона заказов в месяц в 4 городах, сейчас – 6.8 миллионов заказов в месяц в 22 городах.

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

А ведь кроме внешней стороны роста есть ещё внутренняя. За год у нас в два раза выросло число дарксторов – тех самых складов, где специальным образом хранятся товары и откуда курьеры отвозят их нашим пользователям за те самые 15 минут.

Что делать, если на дарксторах плохой интернет? Как минимизировать время обработки заказа?

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

Программный комитет ещё не принял решения по этому докладу

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, а когда не использовать ни то, ни другое. Наконец, запустим примеры кода и посмотрим, насколько быстро это все работает.

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

Как мы сшили две системы телефонии и стали обрабатывать 5 миллионов звонков в день

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

«Подход к построению архитектуры при работе с музыкальным контентом»

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Heavy load: большие blob’ы в ваших сетях

Андрей Рикунов

Яндекс.Медиалаб

Онлайн-кинотеатры работают с большими каталогами фильмов, непрерывно обновляя и перерабатывая каталог. Фильмы — это большие и сложно структурированные данные. Размер одного фильма может составлять несколько терабайт, весь каталог исчисляется петабайтами. Подготовка фильма для последующей доставки — это длительная и ресурсоемкая операция. Расскажу о том, сколько нужно ресурсов и какие использовать технологии, чтобы такие большие blob'ы не раздавили вас.

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

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) — совершенно обычная ситуация. Проблемы в работе с сетью, перебои в работе зависимостей и банальный человеческий фактор — та цена, которую мы платим за общую стабильность системы, лёгкую масштабируемость и гибкость в разработке.

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

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

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

О методах реализации pub-sub систем на основе Тарантул

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

Технологии подписок pub/sub под капотом часто опираются на лонг-пулинг или канал. Во всех подходах есть преимущества и недостатки.

Об этих проблемах мы поговорим в этом докладе, а так же будет рассказано о новом механизме поддержки pub/sub приложений, который появится в следующем релизе Tarantool.

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

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

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

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

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

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

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

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

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

Как Яндекс.Афиша 2 раза переезжала на GraphQL

Мы расскажем о том, как переписали API Я.Афиша с REST на GraphQL на node.js + Python. А затем, в рамках оптимизации, избавились от node.js + Python и переписали весь GraphQL на Java.
Поясним, почему мы выбрали технологию GraphQL, какие проблемы и задачи решали с ее помощью. Расскажем и покажем как эволюционировала наша архитектура. Дадим несколько практических советов по тому, как лучше всего начинать работать с GraphQL. Расскажем для каких команд и проектов подходит наше решение, а для каких нет и почему.

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

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

Миллион 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-движки должны эффективно обрабатывать данные, расположенные на нескольких серверах. В докладе на примере Apache Flink и Presto я расскажу, как устроены распределенные SQL-движки, и какие подходы они используют для увеличения производительности запросов.

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

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

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

Воркшоп: Инструменты и подходы для обеспечения прозрачности (observability) при работе с MySQL/MariaDB

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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 под различными нагрузками.

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

Как в MongoDB сделать распределённую очередь

Распределённая очередь на базе MongoDB используется в Яндекс Толоке как буффер для эффективной записи в ClickHouse. Она обрабатывает 1000 RPS на вставку и через неё прошло 1.5 ТБ данных. В докладе спроектируем распределённую очередь и отметим сильные стороны MongoDB. И представим нашу opensource-библиотеку для Java.

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

История перехода от 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, как мы мониторим систему и на что обращаем внимание.

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

Компиляция запросов в ClickHouse

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

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

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

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

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

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

How to fix "built in" storage problems in Kubernetes

We have been keeping the pulse of the storage world for 21 years and evaluate the demands of those who need primary storage in the open source world. We develop block storage solutions in this direction.

LINSTOR, a world-class SDS for persistent container storage for Kubernetes, works seamlessly with most critical and intensive business applications.

However, k8s has some "built in" problems. These;

Lack of disk localization, slow pod failover times, external storage integration difficulty and management problems.

What we build in open source, is solving all of these problems. With the help of DRBD replication and STORK we fix disk localization. HA controller decreases 60 second pod failover into less than 15 second. LINSTOR operator makes it easy to deploy & manage storage solutions in K8s. Splitting the data & management layer is making day2 operations easy. 

In the session, we'll explain all of these features technically and how they work wisely.  

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

Типичные ошибки при использовании NoSQL

Игорь Золотарев

Mail.Ru, Tarantool

Разработчики высоконагруженных приложений очень часто сталкиваются с проблемой выбора новой технологии для хранения данных. Кто-то привык к SQL-решениям, но бывает так, что хочется попробовать что-то новое и более подходящее для конкретного проекта, и очень часто ответом становится NoSQL БД.
Но любую новую технологию нужно уметь правильно приготовить, и это не всегда очевидно для людей, которые привыкли к SQL. В докладе я расскажу, с какими проблемами вы можете столкнуться, взяв на борт новую технологию, и как можно их избежать, а именно:
- неправильный выбор технологии
- подводные камни выбора места размещения БД
- архитектурные антипаттерны NoSQL
- неудачная схема хранения
- плохие подходы к написанию запросов


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

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

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

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

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

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

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

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

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

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

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

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

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

Teradata replication DIY - как мы создали аналог Data Mover

Владимир Корж

АО Тандер (Магнит)

Нам нужно было научиться не просто переносить данные, а гибко настраивать их количество и преобразование в процессе репликации. Мы сделали собственный инструмент, который более гибок по сравнению с Teradata Data Mover и более быстрый в передаче данных, по сравнению с популярными ETL инструментами, в разрезе работы с Teradata. При этом, добавление потоков происходит в "пару кликов". В докладе расскажу, какой путь прошли, с какими проблемами столкнулись, а также что потребовалось улучшить в процессе использования инструмента.

Программный комитет ещё не принял решения по этому докладу

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

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

«Перкона» (Percona)

Зимой 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;
• практический профит: как облегчает жизнь разным командам разработки и не только;
• дальнейшие планы развития кластера в рамках компании.

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

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

Я расскажу про путь, который прошла команда Timeweb за 10 лет: от rsync, LVM и DRBD до ZFS. Этот доклад интересен тем кто занимается построением серверной инфраструктуры, планирует делать бэкапы и заботится о бесперебойной работе систем.
Как выглядит файл в файловой системе ext4
Чем отличается файловое копирование от блочного
Что может быть плохого в блочном копировании
Как сделать блочное копирование хорошим
Как превратить ZFS pool в тыкву и что нужно делать, чтобы этого не случилось
Дружба MySQL и ZFS

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

Введение в 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!

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

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

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

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

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

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

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

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

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

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

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

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

Резервный ЦОД на Ansible: как мы сделали DR по одной кнопке для PostgreSQL, MongoDB, Kafka, AMQ

Иван Кабанов

АО "Инфосистемы Джет"

Ansible не нуждается в представлении. Система повсеместно используется для выполнения рутинных задач в ИТ-инфраструктуре. Мы применили Ansible для нетиповой задачи - переключения и восстановления системы в резервном ЦОДе в случае потери основного.

Бизнесом была поставлена задача обеспечить катастрофоустойичивость, продолжить работу в случае выхода одной зоны доступности из строя c минимальным простоем. Проект довольно масштабный - 100+ баз Postgres и Mongo, сотни серверов приложений, кластеры Kafka, сервисы очередей AMQ, десятки файловых серверов.

Из доклада вы узнаете:
• Зачем вообще автоматизировать процесс Disaster Recovery
• Разница между Switchover и Failover c точки зрения Ansible
• Нюансы автоматизации управления репликациями БД
• Как мы защитили perisistence ActiveMQ и Kafka
• Что можно сделать с Legacy-файлопомойкой
• Как организовать доступность приложений

Программный комитет ещё не принял решения по этому докладу

Log Management with Loki

В этом выступлении я расскажу о своем видении современной системы Log Management. Буду рассматривать на примере нового игрока на этом рынке — Loki, сравнивая его с конкурентами.

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

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

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

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

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

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

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

Кажется чудом, но при помощи OpenSource-инструментов, Neo4j, VictoriaMertics, Telegraf, AlertManager и немного программирования на Go это становится реальностью.

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

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

Как мы в Ситимобил пишем, собираем и обрабатываем 100 ТБ логов в день

Сергей Фролов

Ситимобил

- Почему так много и зачем нам это нужно
- Особенности логов
- Флоу доставки логов - от лог-файла до Kibana
- Filebeat - лучше всех
- Kafka - отказоустойчивый брокер и буфер перед Elasticsearch
- Батарея Logstash
- Elasticsearch - сердце ELK-стека
- "Единый Логин" (FreeIPA + Authelia + NGINX)
- Всюду SSL
- Алертинг (ElastAlert, Grafana)
- Как все это мониторится
- Для чего еще используем эластик (кроме логов)

Программный комитет ещё не принял решения по этому докладу

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

У нас было 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.

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

LINSTOR - это как Kubernetes, но для блочных устройств

В этом докладе поговорим про LINSTOR - open source хранилище от компании LINBIT (разработчика DRBD).

Начиная с девятой версии DRBD сменил курс с «‎одно большое отказоустойчивое устройство на всех»‎ на «‎по отдельному DRBD-устройству на виртуалку»‎, стал поддердживать diskless-реплики, появился оркестратор, поддержка снапшотов, шифрования и много другого.

Тезисы:

- Почему LINSTOR - это просто хранилище, а скорее оркестратор блочных устройств. В чём его схожесть с Kubernetes?
- Выделим преимущества и недостатки DRBD перед Ceph и другими кластерными файловыми системами.
- Копнём чуть глубже и посмотрим как работает DRBD9, LINSTOR и что находится у него под капотом.
- Разберём сущности LINSTOR и как его правильно настроить.
- Как работают снапшоты, бэкапы, дедупликация, шифрование
- Почему не рекомендуется использовать опцию allow-two-primaries, и зачем вообще она нужна
- Какие есть проблемы. Как устранять неполадки и чинить split-brain, если потребуется.

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

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

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

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

Они способны рассказать многое:
1. Про культуру разработки и тренды развития или стагнации инженерии.
2. Про качество нашего продукта и рядом стоящие показатели доступности, SLO и SLA.
3. Про развитость процессов внутри тех.депа.
4. И еще многое веселое, что покажу в докладе.
Собирать такие данные руками весьма накладно и, главное, медленно, но автоматизировать это реально.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ян Ашенкампф

Газпромбанк

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mail.ru Cloud Solutions

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

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

На выходе мы получим готовый шаблон для реализации DevSecOps-пайплайна для кластера 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-анализа у себя в компании с целью уменьшения времени жизни инцидентов.

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

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

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

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

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

Open Policy Agent - серебряная пуля для Kubernetes. И не только для него

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

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

Но кажется, что сообщество обратило на это внимание и сейчас активно выходят фичи, которые позволяют гибко настроить политики безопасности. И одной из очень перспективных на мой взгляд технологий является Open Policy Agent, который реализован в Kubernetes с помощью Gatekeeper.

В рамках доклада мы с вами разберемся:

- Что такое Open Policy Agent (OPA) и почему за ним будущее?
- Как можно валидировать вообще все объекты, что создаются в Kubernetes, с помощью только одного admission-controller'а?
- Как и чем заменить устаревший PSP, получив при этом кучу дополнительной полезной функциональности?
- Как внедрить Gatekeeper в большой работающий кластер на продакшн и при этом ничего не сломать?
- Какие важные аспекты и подводные камни необходимо учитывать при внедрении у себя OPA/Gatekeeper?

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

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

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

Дзеты – тестовый контур для микросервисов в Дзене

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

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

Программный комитет ещё не принял решения по этому докладу

Performance as a service: ускоряем и удешевляем нагрузочное тестирование через переход от продуктовой модели к внутреннему сервису

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

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

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

Расскажем, почему поиск — это не просто совпадения по полям данных. Поделимся опытом на примере Delivery Club, как добиться бОльшей релевантности в выдаче с помощью современных ML-инструментов и не потерять в скорости ответа сервиса.

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

Как мы переводим 10M+ товаров на 20 языков

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

Эволюция сервиса таргетирования от ClickHouse, натянутого на глобус, до BitMagic-based in-memory engine

МТС Маркетолог — сервис для запуска таргетированной рекламы: SMS-рассылок, баннеров и даже рекламы в соцсетях.

В основе сервиса лежит Big Data МТС — анонимные данные о ~100 млн профилей, которые Big Data передаёт в МТС Маркетолог. Это ~60 млрд фактов о сегментах аудитории и их активности. И это только часть данных.

Расскажем, как быстро создавали сервис таргетирования на основе ClickHouse, а потом перешли к быстрому in-memory-хранению и обработке данных. И оставили ClickHouse только в качестве «холодного» хранилища.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Почему RedTeam это не продвинутый пентест? Можно ли построить DevSecOps без SAST? Если код проверен сканером его можно катить в прод? Есть ли альтернативы у Bug Bounty? В докладе мы поделимся своим опытом построения безопасности в крупных компаниях, наглядно покажем чем ИБД и buzzword отличаются от лучших практик наносящих прямую пользу безопасности компании.

Программный комитет ещё не принял решения по этому докладу

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

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

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

Рассмотрим, что доступно для обеспечения безопасности в Kubernenetes:
- нативные функции Kubernetes — RBAC, AuditLog;
- политики — OPA Gatekeeper, Kyverno;
- сканирование уязвимостей — Clair, Trivy;
- аудит — Kyverno policy-reporter, Compliance-operator;
- Runtime Security — Falco, Clamav;
- сеть — Calico (enterprise), Cilium (enterprise);
- Risc and analysis — Sysdig, Snyk, Aquasecurity.

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

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

В докладе мы рассмотрим двухэтапный подход к такому хранилищу, когда слой сырых данных мы отправляем в промежуточное объектное хранилище, а потом перекладываем в SIEM-систему. Практически у себя мы реализовали первый слой в виде S3-хранилища, а в качестве SIEM-системы использовали Elastic.

В итоге вы поймете, как интегрировать множество opensource и вендорских инструментов анализа состояния Kuberntes-инфраструктуры в свою SIEM-систему. Также я расскажу, как воспользоваться terraform-модулями, которые уже внедряют описанный нами подход и как их можно адаптировать для своей iaas-инфрасруктуры.

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

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

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

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

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

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

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

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

Работая с облачной инфраструктурой, приходится думать о безопасности и учитывать это при планировании нагрузки. Общей практикой стало шифрование данных при передаче и хранении, но менеджмент ключей и обработка в открытом виде оставались уязвимыми этапами в жизни ценных байтов. Для решения этой фундаментальной проблемы внутри процессора были созданы анклавы для изоляции кода и данных от внешней среды, включая админа с рут-правами и физическим доступом к машине. Первые анклавы на базе технологии Intel SGX появились в 2015 году и в течении пяти лет развивалась теория и практика их применения. Сейчас SGX-анклавы пришли в мощные двухсокетные серверы общего назначения и стали доступны для решения интереснейщих задач - совместного обучения моделей без раскрытия датасетов партнерам (federative learning), размещение критических баз данных целиком в анклаве и построения сервисов децентрализованных вычислений над конфиденциальными данными. Мы рассмотрим анклав с точки зрения разработчика высоконагруженных систем, открытый инструментарий и уровни производительности на конкретных примерах.
А так же пригласим в лабораторию Selectel протестировать все вышеперечисленное на серверах Intel Xeon Scalable третьего поколения.

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

DoS <-> Pwn

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

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

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

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

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

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

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

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

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

ВКонтакте

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

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

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

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

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

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

Леруа Мерлен

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

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

Как автоматически оптимизировать Spark-расчёты в высоконагруженном кластере

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

В своём докладе я расскажу:
– Как извлечь полезную информацию из логов Spark
– Как подбирать оптимальную память для расчёта на основе истории запусков
– Как полностью автоматизировать этот процесс

Программный комитет ещё не принял решения по этому докладу

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

Обучение нейронных сетей требует большого количества ресурсов. Зачастую, обучение даже нейронных сетей среднего размера на небольшом объеме данных может занимать дни и недели, а результат эксперимента хотелось бы увидеть сразу.
В докладе я расскажу какие есть способы ускорить обучение нейронных сетей с помощью распределенного обучения (когда задействуется несколько GPU), что необходимо сделать чтобы обучение шло не только в пределах одного сервера, но и на нескольких нодах.
Мы рассмотрим организацию распределенное обучение на GPU с использованием PyTorch Lightning и ускорение обучения на CPU c помощью PyTorch и инструментов Intel® oneAPI

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

Машинное обучение под высокими нагрузками в Ситимобил

Максим Шаланкин

Ситимобил

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

Для ее реализации нам силами Machine Learning Engineer’ов удалось разработать микросервис, внутри которого живут модели машинного обучения.
Микросервис написан на python с использованием фреймворка sanic.

Программный комитет ещё не принял решения по этому докладу

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

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

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

Архитектура A/B экспериментов в рекомендательной системе рекламной сети

PropellerAds - это рекламный нетворк. Наша основная задача - разработать систему подбирающую релевантную рекламу для каждого пользователя, такую где он с высокой вероятностью совершит конверсию. Для решения этой задачи мы используем алгоритмы Machine Learning.

Через эту систему проходит более 100K пользователей в секунду и происходит выбор их десятков тысяч рекламных банеров.

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

В своем докладе я расскажу:

1. Три варианта дизайна A/B экспериментов в интернет рекламе - чем они отличаются и когда используются. Как их можно обобщить для тестирования любой рекомендательной системы
2. Как эволюционировали наши подходы и инструменты A/B экспериментов. К каким требованиям по надежности системы и процедурам запуска мы пришли.
3. Использование A/B экспериментов как инструмента масштабирования при обучении тяжелых моделей Machine Learning
4. Как разработанная система влияет на культуру экспериментирования во всей компании

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

Как мы строили и развивали инфраструктуру вокруг задачи прогнозирования спроса

На базе работающей задачи прогнозирования поговорим об эволюции инфрастрктуры в рамках Компании Магнит.
Расскажем про миграцию вычислений и построения DataLake на базе Hadoop под задачу с большими данными, расскажем о транспорте и механизмах оркестрации задач и данных.
Поговорим о том как мы повышали производительность инженерных и распределенновычислительных задач в рамках достижения SLA расчета. Коснемся темы того, как мы переходим от классического ML к глубокому обучению, используя кластера GPU

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

Практический опыт построения архитектуры больших данных на Hadoop.

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

Программный комитет ещё не принял решения по этому докладу

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

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

AliExpress Россия

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

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

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

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

Андрей Ильин

Сбербанк

* Для чего нужно проксированние данных — HDFS/Hive/Sentry?
* Как проксировать данные для Hadoop?
* Особенности при разработке продуктов на основе библиотек Hadoop'а.

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

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

Денис Занков

«Газпромбанк»

- Работа с качеством данных актуальна не только для задач моделирования, но и в целом для тех, кто использует data driven подход.
⁃ Задачи поиска новых решений работы с качеством данных стала актуальная для Газпромбанка при работе с оттоком с помощью ML подходов, где был найден значительный бизнес эффект.
⁃ Для вывода таких моделей в пром необходима витрина с признаками по клиенту, в т.ч. по всем продуктам клиента 2000+ (а планируется 7000+) колонок-признаков на 33 месяца (состояние клиента) х 10 млн клиентов.
⁃ Как принять прототип такой витрины, а потом согласовать промышленный расчет и поддерживать далее кд на приемлемом уровне, при вечном недостатке ресурсов?
⁃ Не один алгоритм поиска аномалий с таким объемом данных не справится напрямую. А если бы исправился, то как правильно определить отсечку, что считать аномалией?
⁃ Можно сделать 2000 дашбордов на каждую переменную, но отсматривать каждый признак на графиках довольно проблематично и трудозатратно.
⁃ Мы подумали про подход ml для ml и начали разработку своего алгоритма на базе модели без учителя.
⁃ Основная идея в том, что не рассматривать переменную построчно (поклиентно), а описать распределение переменной за каждый временной срез через описательные статистики ее распределения..
⁃ В виду неоднородности статистик (как сравнить между собой количество пропусков и среднее значение самой переменной) и других причин, нам больше всего подошел ML алгоритм изолированного леса в core самого алгоритма.
⁃ Core алгоритм - изолированный лес и почему он работает в данной задаче.
⁃ Преимущества и ограничения изолированного леса в качестве core алгоритма.
⁃ Просто так алгоритм не работает, нужна еще дополнительная ранжирующая функция, а также алгоритм интерпретации результата.
⁃ По итогам ранжируем всю витрину по аномальности, и проверяем по какой-то отсечки сами статистики.
- Как планируется применять данный алгоритм. Как выглядит прототип дашборда. Как будут устроены триггеры (оповещения) по аномалиям качества данных.
⁃ Развитие фичей алгоритма. Какие дополнительные переменные использовать? Что мы планируем доработать?
⁃ Эффект от внедрения в промышленную эксплуатацию и почему он нам помогает HIGHLOAD.

Программный комитет ещё не принял решения по этому докладу

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

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

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

Production Machine Learning в Delivery Club

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

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

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

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

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

Разгоняем ML в продакшене

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

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

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

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

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

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

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

Любовь Пекша

ВКонтакте

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

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

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

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

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

Оптимизиция инференса вокодера для синтеза речи

- Хотим рассказать про инференс моделей в нашем синтезе речи.
- В докладе расскажем, с какими проблемами столкнулись при запуске синтеза речи в прод:
- особенности архитектуры вокодера (wavenet),
- сервинг модели вокодера в реальном времени,
- почему не помогало горизонтальное масштабирование.
и как их порешали с помощью своей реализации с использованием векторных инструкций и квантизации весов модели.
- Также сравним наш подход с альтернативами (parallel wavenet, waveglow).

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

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

- Хотим рассказать о внутреннем устройстве нашего сервиса распознавания речи [https://voicekit.tinkoff.ru/](https://voicekit.tinkoff.ru/). Перед нам стояла задача обрабатывать ~7000 параллельных аудио-потоков для распознавания, а так же распознавание не в потоке с RTF (Real Time Factor) < 0.25, при этом используя ограниченные ресурсы GPU.
- В докладе расскажем о том, зачем вообще необходимо распознавание речи:
- TQM
- Голосовой помощник
- Роботы
- Дадим обзор основных модулей нашего сервиса:
- Audio Decoder
- Акустическая модель
- Decoder
- VAD (Voice Activity Detector)
- Модели определения пола/негатива
- А так же углубимся в технические детали реализации.
- Расскажем, какими метриками можно оперировать в потоковых аудио-сервисах (SPS, RTF, Head/Tail latency)
- Поделимся опытом переписывания бекенда с python на go из-за отсутствия в python хорошей многопоточности.
- Предоставим информацию о том, как мы перевели кодовую базу на go-pipelines ([https://blog.golang.org/pipelines](https://blog.golang.org/pipelines)), чтобы каждый этап обработки аудио проходил асинхронно
- Поделимся опытом развертывания deep-learning моделей в проде при помощи tf-serving, балансировки grpc-запросов через envoy, и бесшовной выкатки новых моделей.
- Расскажем, как правильно настраивали батчинг моделей, чтобы максимально утилизировать GPU

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

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

Мы в Яндекс за год запустили несколько HPC/GPU кластеров для машинного обучения.
В ближайшее время они будут зарегистрированы в рейтинге мировом top500.
Мой рассказ будет о том с какими сложностями и неожиданностями мы столкнулись на этом пути.
Из этого доклада вы узнаете, что такое современный HPC/GPU кластер, зачем он нужен Яндексу.
На каком стеке технологий он строится и почему, почему HPC  это сложно, а традиционные подходы часто не работают. Как вообще устроен процесс попадания в  top500 , и как оптимизируя производительность для  попадания в рейтинг мы нашли проблемы которые ускорили наше машинное обучение.

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

Оптимизация работы скважин на нефтяных месторождениях с применением Deep Reinforcement Learning

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

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

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

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

Рабочая видеоаналитика в нефтехимии

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

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

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

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

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

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

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

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

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

ПАО Московская Биржа

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

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

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

Тимур Габец

Тинькофф

1. Как клиенты Тинькофф-Банка в 2018 году могли легко обналичить несколько миллионов рублей, не заплатив при этом ни рубля комиссии. Расскажем схему в деталях и объясним, как такое вообще смогло быть технически возможно.
2. Детали технической реализации системы, закрывшей эту дырку (многотредовый монолит на C, отсутствие виртуализации, Redis, protobuf, кэширование внутри приложения).
3. Как оно всё работает и (почти) не падает?

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

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

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

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

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

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

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

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

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

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

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

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

Зрители узнают лучшие практики, на которых основан очень быстрый сборщик логов, который мы используем в OZON.
С помощью него мы:
1. Cократили издержки на сбор логов в 10 раз по CPU
2. Добились 100% доставляемость логов ​

Основные тезисы:
1. Общая архитектура сборщика логов.
2. Как написать быстрый плагин для чтения логов из файлов.
3. Как оптимизировать внутреннюю обработку потока логов.
4. Как правильно распараллелить обработку.
5. Как гарантировать доставку

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

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

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

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

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

Блокчейн (2)

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

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

- DeFi-рынок. Размер. Темпы роста. Доходы и потери за год существования рынка. Типы проектов.
- Контролируемые риски со стороны создателя и мейнтейнера проекта, их цена, объем потерь:
-- 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+ эксплойт).

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

Bitcoin Core под нагрузкой: сохранность средств и время подписи транзакций. Ускоряем работу традиционного блокчейн софта в 100 раз.

Хашин Евгений

OOM.AG, CryptoProcessing, Embily Inc.

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

Программный комитет ещё не принял решения по этому докладу

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

Как мы в 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) Что нас ждет в ближайшем будущем - новая волна хайпа, направления роста, прогнозы.

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

Digital Transformation in Insurance: Опыт Ингосстрах в создании тех.платформы

Количество клиентов брокерского обслуживания в РФ выросла в 7 раз за 3 года. Кредитный портфель ЮЛ и ФЛ - на 32%. Однако страховой рынок растет с темпами чуть выше инфляции. СПАО "Ингосстрах" меняет стратегический фокус развития со страхования на подход "360", предложение клиентам финансовых продуктов
группы Инго, с помощью создания тех.платформы, а не экосистемы.

Программный комитет ещё не принял решения по этому докладу

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

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

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

С++ (8)

Параллелизм в современных игровых движках

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

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

Как сделать быстрый C++ коннектор и не поломать кодовую базу приложения

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

Я определил для коннектора следующие ключевые требования:
- Простота интерфейса — запрос одной строчкой.
- Максимальная производительность, но без усложнение интерфейса.
- Гибкость интеграции в конечное приложения.

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

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

Также коннектор изначально разрабатывался для встраивания в I/O приложения с произвольными событийными циклами. В частности он встраивается в сам Tarantool, хотя может работать и напрямую с epoll. Проделана большая работа по разделению работы с данными и работы с сетью.

Но скорее всего наиболее увлекательной частью будет реализация собственного msgpack кодека. Благодаря типизированной сериализации запросов, по возможности в compile time, и использованию state machine для десериализации ответов можно добиться поразительных показателей производительности. А нелёгкая борьба за лаконичный и универсальный интерфейс, уверен, не оставит равнодушным всех любителей настоящего забористого C++.

Абстракции в коннекторе придерживаются концепции zero overhead abstraction.

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

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

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

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

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

В докладе мы обсудим сами проблемы, посмотрим, что сейчас предлагает язык (а точнее, что обсуждает еще комитет по стандартизации), и выясним, что же умеют современные статические анализаторы, и как далеки компиляторы от "счастливого и безопасного" будущего в 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) и когда она бесполезна

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

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

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

План доклада:
* общая схема работы 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.

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

GolangConf: Best practices (10)

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

Монолит на Go - это прекрасно

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

Программный комитет ещё не принял решения по этому докладу

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

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

Программный комитет ещё не принял решения по этому докладу

Best practices ≠ Rocket science

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

Распределенный запуск задач в кластере K8S через Go

Рассмотрим вопрос и возможности запуска программ, написанных на Go в кластере K8S, а также их управление своим контроллером прямо из сервиса на Go.

Программный комитет ещё не принял решения по этому докладу

Мобильные api: переход с json на бинарный формат

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

Программный комитет ещё не принял решения по этому докладу

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

В докладе вы узнаете:

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

GolangConf: Стандартная библиотека (2)

Go Map Internals

Каждый из нас является уверенным пользователем структуры данных, которая называется hash map (или просто map в Go).

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

Данный доклад является обзором внутренностей реализации map в языке Go.

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

История реализации векторного поиска на go

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

GolangConf: Обзор текущего состояния языка (2)

Go To Memory

Как и многие языки, Go часто использует магию под названием heap и обычно, когда мы пишем наши джейсоногонятели, благодаря прекрасному дизайну Go, мы просто не задумываемся об этом, хоть и знаем, что это «где то есть».
Но, если попробовать заглянуть в кроличью нору поглубже, мы увидим, не только какими методами аллокатор go старается облегчить программисту жизнь, но и почему, он это делает.
В этом докладе, я постараюсь охватить тему работы памяти на нескольких уровнях, начиная от железа, заканчивая моментом, когда вам требуется БОЛЬШЕ <s>ЗОЛОТА</s> памяти

Программный комитет ещё не принял решения по этому докладу

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

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

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

GolangConf: Go для высоконагруженных систем (9)

Методы эффективной обработки данных на Go в real-time рекомендательных системах

Мы компания Propellerads рекламный нетворк. Одна из основных задач рекламного нетворка
эффективный real-time подбор рекламы для показа конкретному пользователю. Для этих целей
используется machine learning. При real-time обработке запросов на побор рекламы сайтов,
необходимо как можно быстрее оценить вероятность что данный пользователь совершит конверсию
для множества имеющихся рекламных предложений. При больших объемах входного траффика (больших частотах запросов на подбор рекламы), больших объемах имеющихся рекламных предложений и большой вычислительной сложности machine learning моделей это становится нетривиальной задачей.

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

Филипп Кулин

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

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

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

Эксплуатация связки Go + PostgreSQL

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

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

Как обеспечить гарантию доставки сообщений в развивающихся системах ?

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

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

Быстрое декодирование AVRO -> Go struct в event-based системах

Компания PropellerAds - рекламная сеть. У нас реализована сервисно-микросервисная event-base архитектура на базе Go сервисов, которые общаются по GRPC, в качестве шины данных используют Apache Kafka, события из которой попадают в колоночную БД Vertica и другие Go сервисы, необходимые для быстрого подбора и показа рекламы.

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

В этом докладе я расскажу о том, как мы переходили с гибкой структуры schema less событий в формате JSON на формат AVRO с использованием Schema Registry. Во время перехода мы столкнулись с проблемой медленного декодирования AVRO существующими средствами Go (linkedin/goavro, actgardner/gogen-avro, mitchellh/mapstructure). Скомбинировав указанные решения, избавившись от лишних reflection удалось реализовать быстрое декодирование AVRO в существующие Go структуры в сервисах, которые читают Кафку.
Мы разработали подход, который позволяет быстро создавать и модифицировать типы событий, которые между сервисами передаются через GRPC (Protobuf), сериализуются в AVRO с использованием Schema Registry и быстро декодируются конечными сервисами в Go structs.

Программный комитет ещё не принял решения по этому докладу

Паттерн архитектуры реал-тайм веб-рекламы (МТС DSP) и примеры реализации

программатик МТС оперирует деперсонифицированными данными: ~3млрд связок ~600 млн кук, относящимся к ~100млн профилей пользователей с разбивкой по более чем 2 тысяч групп интересов. Мы разработали собственную программатик платформу и в докладе мы расскажем как сделать архитектуру программатик, который позволяет решить все "хотелки" бизнеса, не "падает" под собственным весом и практически неограниченно масштабируется.

Расскажем о простом архитектурном паттерне, работающем в реальном-масштабе времени который, позволяет обрабатывать 200к rps с латентностью порядка 20мс/ При этом горизонтально масштабируется, позволяет применять МЛ модели и различные стратегии открутки рекламы, и на горячих путях практически отсутствует копирование данных.

Применение общего архитектурного подхода проиллюстрируем двумя примерами: калькулятор охвата рекламной кампании и «горячий» и «холодный» путь биддера DSP — реалтайм ядра DSP.

Программный комитет ещё не принял решения по этому докладу

Система real-time управления предложениями туроператоров

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

Ассортимент туров у туроператоров — очень динамичная штука: цены и наличие туров меняются каждую минуту. При этом наши пользователи совершают до 35 тысяч поисков каждую минуту, а в сутки наш поиск обрабатывает до 50 ТБ данных. Мы разработали сервис, который способен не только поддерживать такую нагрузку, но и в режиме реального времени управлять результатами поиска, которые видит пользователь: добавлять спецпредложения, показывать важные примечания, известные только нашим менеджерам, убирать из выдачи сомнительные предложения и много другое.

* Супер-динамический ассортимент и проблемы хранения — работа с кешем, Redis и долговременные хранилища.
* Высоконогруженные клиентские сервисы и общая инфраструктура продукта, включающая в том числе монолит на Ruby — проблемы интеграции.
* Highload на поиске и динамическое распределение нагрузки с помощью AWS-инфраструктуры.

Программный комитет ещё не принял решения по этому докладу

Зачем Go для распределённой компиляции С++, и при чём тут PHP

Расскажу о распределённой компиляции гигантских C++ проектов, которую мы внутри ВКонтакте написали на Go и выкладываем в Open Source. Будет про стыковки технологий, хайлоад и гигантскую кодовую базу. Затронем С++, внутренности VK и немного наш компилятор KPHP.

Программный комитет ещё не принял решения по этому докладу

GolangConf: Машинное обучение: гофер против питона (2)

Зачем мы переписали сервис рекомендаций на Go и что получили в сравнении с Python.

Рекомендации Авито - это первое, что видит пользователь, когда попадает на главную страницу. Нагрузка на наш основной сервис порядка 200 тысяч запросов в минуту.
Мы постоянно боремся за качество рекомендаций, которые видит пользователь и время за которое он их получает. За последние два года мы сильно улучшили качество рекомендаций, расширяя наши базовые ML модели, но сильно проиграли в latency. Главным врагом производительности и latency стало, добавление ML модели второго уровня на основе catboost для ранжирования объявлений от базовых ML моделей первого уровня в реалтайм.

В докладе я расскажу:
- как мы приняли решение переписать все на Go, перед этим мы выжали из питона все что смогли;
- как подружили CatBoost с Go и стали использовать ML модель на основе CatBoost в Go;
- как делали сверку при переходе, ответ от сервиса рекомендаций не детерминированный;
- что получили по latency и cpu после перехода.

Программный комитет ещё не принял решения по этому докладу

Использование в Golang моделей обученных на Python

Юрий Букаткин

Программный регион

В докладе расскажу:

- почему мы используем Golang;
- какие Golang ML библиотеки и для чего используем;
- как мы дружили Python-модели ML c backend, написанном на Golang;
- про наше решение хранение хранения моделей машинного обучения;
- покажу подробный путь модели от jupyter playbook до procduction;

Программный комитет ещё не принял решения по этому докладу

GolangConf: Другое (14)

Как сделать так чтобы ваша организация начала разрабатывать на Go

Несмотря на то что Go уже более 10 лет, все еще сложно сказать что он является общепринятым языком разработки.
Я расскажу о том как "продать" Golang в вашей компании, что может помочь адаптации языка, а что помешать.

Программный комитет ещё не принял решения по этому докладу

The insane speed of esbuild - a JavaScript bundler and minifier written on Golang

Esbuild is an open-source JavaScript bundler that is extremely-fast and way better than other popular bundlers like Rollup, Webpack, and Parcel. Written solely by Evan Wallace in Go with speed in mind, fully parallelizes parsing, printing, and source map generation.

In this talk, I will explore esbuild, a JavaScript bundler and minifier built using GoLang that packages JS code for distribution on the web. I will examine how it’s able to work so fast and discuss why this tool is becoming very useful in front-end development. I will discuss the following: What is esbuild, and why is it so fast? Comparing esbuild to other bundlers (Benchmark) Is esbuild production-ready? and a quick live demo.

Программный комитет ещё не принял решения по этому докладу

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.

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

Зачем международным компаниям российские разработчики

Если вы задумываетесь о поиске новых проектов или full time работы в международных компаниях, стоит знать, какие у них ожидания, где их вообще искать, и как готовиться к интервью.
Вам также необходимо знать, как себя презентовать иностранному заказчику, особенно учитывая языковые и культурные различия.
Обсудим эти вопросы, а также - почему вообще международные компании будут искать себе Golang разработчиков в СНГ, чем их можно зацепить, чтобы получить ожидаемый контракт, работать удаленно или релоцироваться в другую страну.

Программный комитет ещё не принял решения по этому докладу

Enjoy OOP with Golang

Hiroki Inoue

Whiteplus, Inc

I’ll present a way to improve the maintainability of the system with Go using OOP. Go does not have some of what other languages that support OOP have, but it can embody the idea of OOP. This fact gave me the opportunity, which I’d like to share with you, to abstract and re-understand OOP.

Overview
In this session, I’ll explain the idea and procedure for incorporating Object-Oriented ideas into code using Go by showing sample code.

The problem I’d like to solve
I’d like to challenge the problem of difficulty to maintain a system that has been in operation for a long time. We make use of OOP as a means of achieving this. I also would like to tackle the difficulty of applying OOP to our code effectively.

Go has no classes, no constructors, no inheritance, no implements keywords. However, we can write code in an Object-Oriented way. This experience gave me the opportunity to review and re-understand what is OOP.

As a software engineer, my desire is to develop a system that is easy to maintain, which enforces our service to be flexible and continue to grow. To do that, I focus on OOP and agile development. And I try to show you how to put them into practice with Go.

Программный комитет ещё не принял решения по этому докладу

Test-Driven Development для Go: зачем и как

«Как это вообще — писать тесты на Go, когда ещё нет кода?»

С концепцией Test-Driven Development я познакомился в те времена, когда ещё писал на Python. Идея была интересная: лучше понимаешь требования задачи, потому что нужно сразу написать тесты.

После перехода на Go захотелось взять с собой в новый стек уже знакомые best practices — в частности, TDD. Но не всё прошло гладко. Python — динамический, там можно глубоко залезть в структуру класса, удобно мокать. В Go с этим оказалось сложнее.

Но при более пристальном вглядывании выяснилось, что и в Go не всё так плохо: есть готовые библиотеки, нет значительных барьеров и, главное, — есть профит от TDD.

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

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

Программный комитет ещё не принял решения по этому докладу

Использование внешних скриптов в Go приложениях

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

Программный комитет ещё не принял решения по этому докладу

Leveraging Functional Programming when Go Generics come

Doni Rubiagatra

Zero One Group

At dotGo 2015 there was a talk by Francesc Campoy called “Functional Go?”. He said, “If Go had generics, Go doesn’t have Generics thought”.

In this talk, We will revisit Functional Programming / Functional thinking and try to answer how we can maximize FP potential when generics come in Go.

In the talk “Functional Go?” Francesc Campoy explains that Functional Programming is doable in Golang but slower in performance and requires reflection magic. He also said, “If Go had generics, Go doesn’t have Generics thought”. So, It would be interesting if we revisit FP when generics come in Go. It’s better? It’s the performance still the problem? We are gonna explore that in this talk.

This talk will be exploring FP in Go in 3 parts.

How we can implement and get the benefit of Functional Thinking / Data-Oriented Programming in Go. We will explore how to separate the Go program into Action, Computation, and Data.
Look back once more on how FP was implemented in Go before generics, how it compares to other FP languages.
Let’s Try multiple concepts of FP in Go generics (Map, Filter, Reduce, Functor), it is easier than before? Let’s see
And finally, the takeaway, what are will do after this? Just implement Functional Thinking in Go? Creating a new library for Hardcore FP in Go? The sky is the limit!

Программный комитет ещё не принял решения по этому докладу

Будущее Golang разработчика - рыночный запрос и тенденции

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

Программный комитет ещё не принял решения по этому докладу

Get your applications cached: yes and without Varnish

Discover where, how and why to setup different cache systems to multiple places of your applications will give you performances boost and save lot of money. Obviously without Varnish.

We’re all expose services either on the web or internally to serve clients. For most of them, there are web APIs and get or manage data via HTTP requests. In the most cases we serve the same content at multiple times and run our code as much as the requests number. With the APIs and the stateless, this execution is unavoidable because the state isn’t saved between requests. From applicative to reverse-proxy one, see together how to implement it.

Программный комитет ещё не принял решения по этому докладу

Golang learning by project: Souin

I’m Træfik user since v1.4 but there was no caching system. I scrolled over the internet to know if any solution exists but nothing appear then I decided to write my own Træfik cache system. This talk it will be a feedback on Golang learning, issues, tips and tricks to start on this awesome language

I discovered Golang language but didn’t have any time to follow multiples tutorials to learn it. But one day I discovered Træfik reverse-proxy project when I wanted to switch my infrastructure into fully dockerized one. I’m Træfik user since v1.4 but after many months using it I encountered an issue : there were no caching system in this reverse-proxy. I scrolled over the internet to know if any solution exists but nothing appears.

Then I decided to write my own Træfik cache system, but the main question was “Which language?”

PHP ? Nah. Nodejs ? What a joke ! C++ ? I didn’t learn this language at school and it’s really insane to learn. Then I was on Træfik github repository when I decided to write it in Golang. Another good point: that’s compatible with docker integration.

So I started the project and called it Souin This talk will be a feedback on Golang learning, issues, tips and tricks to start on this awesome language.

Программный комитет ещё не принял решения по этому докладу

Go - Best practices

We would like to share the best development practices that has helped us reduce the amount of time/effort spent in maintaining the application. Even Golang beginners can attend and a GitHub repository containing the sample code/notes used in this presentation for future reference will be provided.

With the ever rising adoption of Go, it is of paramount importance to develop applications that need minimum maintenance. We would like to share some of our best development practices that we have realized and accumulated over time that has helped us reduce the amount of time and effort spent in maintaining the application.

Программный комитет ещё не принял решения по этому докладу

How I made a powerful cache system using Go

I’m Træfik user since v1.4 but there was no caching system. I scrolled over the internet to know if any solution exists but nothing appear then I decided to write my own Træfik cache system. Now it’s compatible with all reverse-proxies and have lot of cool features.

I discovered Go language but didn’t have any time to follow multiples tutorials to learn it. But one day I discovered Træfik reverse-proxy project when I wanted to switch my infrastructure into fully dockerized one. I’m Træfik user since v1.4 but after many months using it I encountered an issue : there were no caching system in this reverse-proxy. I scrolled over the internet to know if any solution exists but nothing appears.

Then I decided to write my own Træfik cache system, but the main question was “Which language?” - PHP ? Nah. - Nodejs ? What a joke ! - C++ ? I didn’t learn this language at school and it’s really insane to learn.

Then I was on Træfik github repository when I decided to write it in Go. Another good point: that’s compatible with docker integration.

So I started the project and called it Souin Let’s see together how I bring it up from code to deployment.

Программный комитет ещё не принял решения по этому докладу

Monitoring your services & why you should care

Most of your time on a project is spent on making sure your service is ready to go live. But how do you know if your application works properly once actual humans start using it?

In this talk, I will show you how to detect & react to production issues before your clients do.

The talk will go through what monitoring a service means, why it’s useful & helpful & what are the popular & widespread tools available for getting the job done. We will also cover alerting on production issues & going on-call. Why that is important & how it could save your enterprise from losing a lot of $$$.

The focus would be on monitoring via metrics & leveraging the most popular & useful tool for the job - Grafana \w the aid of the time-series database Prometheus.

Программный комитет ещё не принял решения по этому докладу