Доклады

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

Я прошел три этапа:
1) Персональное участие в максимуме процессов, участие в принятии всех решений, как орг., так и тех. Этот этап необходим. Если вы растете в техдира вместе с командой, то он ну просто естественный, эволюционный. Если вы пришли, то он необходим, чтобы у вас случилась "метанойя" с вашим новым детищем. Все, что с ним связано, должно уложиться и упаковаться внутрь вас для глубинного понимания. Здесь вы, как правило, работаете от целей, которые, как правило, довольно наивны.
2) Делегирование и взращивание. Со временем вы начинаете четко понимать, от кого из членов команды что можно ожидать, кто что потянет, кто — нет. И вы начинаете строить Управленческую команду. И это не только формально руководители. Это и лиды, обязательно техлиды и тимлиды. На этом этапе вы работаете от целей и от проблем. При этом проблемы здесь нужно уметь выявлять на базе метрик, и эти метрики начинают корёжить цели. А значит — значит вам нужно построить не статичную Управленческую команду, в которой жестко прописано, кто за что отвечает, но сформировать команду Непрерывных изменений.
3) Генерация. Очень трудно и очень важно не пропустить момент перехода к третьему этапу. Когда делегирование уже даже не вопрос, и по большому счету делегирование — это уже задача ваших "лейтенантов". Здесь мы работаем уже не от проблем, и не от целей. Мы работаем от "собственного понимания миссии компании". Звучит так себе, но все именно так. Вы должны перестать выполнять поручения, соответствовать ожиданиям. Вы должны начать формировать эти ожидания и поддерживать отлаженный механизм их воплощения. Переход на третий этап, по моему опыту, самый трудный и практически нигде в ИТ-литературе неосвещенный.

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

Также я расскажу о тех методах дисциплины мышления, которые, с моей точки зрения, критично важны для Генерации на третьем этапе. Потому что важно генерировать не "трендовые фантазии", а то, что на самом деле важно для ваших продуктов. И я убежден, что генерация — это не "умудренное годами" умствование, а техническая методичная работа, которую вы обязаны делать, потому что без ее результатов команда будет работать, в лучшем случае, на основе процессов. Но не ориентиров! А это неизбежно стагнация.

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

Что можно сказать про 5 лет работы в дата-сайенс на одном месте? Там, где подразделение выросло с 1 до 65 и продолжает расти?

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

Итак, как устроена разработка дата-сайенс? Она отделена от дата-сайентистов. Она встраивает решение в существующий монолит или в сеть микросервисов. Она мониторит, трейсит и даже выносит (noops). Она придумывает протокол общения с дата-сайентистами («ядро» и требования к нему). Она выносит «как можно быстрее».

Что еще нужно разработке? Инфраструктура. Это система, работающая в реальном времени, которая имеет всю нужную информацию для принятия решений (т.н. «профиль»). Это хранилище всего без структуры (Хадуп).

А как же дата-сайентисты? Мы попробовали все, что может быть интересно, и многое не зашло: отток, рекомендашки, супер-точные А/Б-тесты, клавиатурный почерк… Но что-то оказалось критически важным: EDA для проекта «Займы» — т.е. быстрые ответы на вопросы с учетом всех источников данных, CV — чтение доков и распознавание лиц, NLP — речевая аналитика и чат-бот.

Это рассказ о нашем пути, о месте машинного обучения в большой финтех-компании.

Количество данных в современном мире растёт с очень большой скоростью, и часто уже не хватает обычных raid хранилищ для хранения пользовательских данных. Поэтому многие задумываются о построение своих больших отказоустойчивых систем для хранения пользовательских данных и по многим причинам отказываются от "облаков". Сразу возникает вопрос: как же построить своё отказоустойчивое и надёжное S3-хранилище.
Для построения собственного S3-облака мы будем использовать Ceph.

Основные тезисы:
* Какие системы для построения s3-кластера существуют.
* Кратко о том как работает Сeph.
* Рекомендации по характеристикам железа, сети и тд, необходимые для построения высоконагруженного кластера.
* С чего начать построение S3-кластера. Какие способы развёртывания Ceph существуют и какой способ лучше выбрать для интеграции с ci/cd и для дальнейшей поддержки.(Rook, ceph-ansible, Cephadm и т.д.).
* Пример развёртывания кластера.
* Тюнинг параметров ядра ОС.
* Настройка RADOS Gateway. Что стоит учесть при работе с объектным хранилищем. На какие параметры ceph стоит обратить внимание.
* Репликация данных. Master-Master. Master-Slave.
* С какими проблемами мы столкнулись в процессе эксплуатации.

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

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

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

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

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

Можно ли в разы снизить затраты на хранение и обработку логов?


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

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

Я хочу рассказать, как я деплоил Tarantool без простоя и без отказа в обслуживании. Пайплайн на Jenkins, ноль посредников, 500 инстансов в production-среде за 60 минут. Опишу проблемы, с которыми мы столкнулись в процессе, и какие решения выбрали в итоге. Всё это — в опенсорсе и в моем докладе.

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

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

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

5 лет назад вышла книга про SRE от Google. Мы загорелись этой идеей и сделали ее у себя в Додо.

В докладе расскажу:
1. Как продвигалась методология в компании, как распространяли эту идею.
2. Как пришлось изменить майндсет людей, как проводили онбординг в SRE разработчиков.
3. Как боролись с рутиной, чтобы делать больше малым составом и успевать делать системные изменения.
4. Как внедрялись практики инцидент-менеджмента, постмортемов, дежурства, мониторинг.
5. Как распространяли практики SRE на разработчиков.

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

Мы расскажем, как привить разработчикам и топ-менеджменту культуру обращения с деньгами, потраченными на облачные сервисы, и покажем, как на доступных opensource-инструментах организовать минимальный FinOps внутри компании. Мы определим, так ли нужен FinOps в компании, с чего начинать его внедрение, стоит ли его включать в CI/CD-процессы и что выбрать для его реализации: самодельный комбайн или встроенные инструменты облачных провайдеров. В общем, мы расскажем, почему же приложение должно быть не только cloud native, но и cost efficient, что чрезвычайно важно в современных условиях.

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

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

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

* Обзор современной теории и практик защиты DNS.
* Кратко о защите от подделки DNS, включая историю вопроса.
* Защита от прослушки.
** История: DNSCrypt.
** DNS-over-TLS.
** DNS-over-HTTP Google API.
** DNS-over-HTTP/2.
** Минимизация QNAME.
* Немного пофантазируем.

Спикером будет рассмотрена тема киберучений/security awarness:
- какие бывают;
- для чего необходимы;
- теория vs практика;
- готовые решения;
- методы самостоятельной реализации.

Такси, Еда и Лавка — компания с устойчивой Data Driven-культурой, где все решения анализируются и проверяются с оглядкой на данные, а скрипт на Python или SQL может написать любой. Мы начали строить централизованное Хранилище Данных (Data Warehouse, DWH) в Такси порядка 4 лет назад. Год назад провели масштабный ребрендинг и стали себя гордо именовать DMP, Data Managment Platform. На текущий момент у нас порядка 5 сотен бизнес-пользователей, пара сотен продвинутых потребителей данных — аналитиков, data scientist'ов и бэкенд-разработчиков из смежных команд. Объем Data Lake на YT (in-house-аналог Hadoop, https://habr.com/ru/company/yandex/blog/311104/) более 1ПБ и ежемесячный прирост по 100 Тб. Целевое эффективное пространство в DWH на Greenplum 0.5 Пб. Каждый день в нашей инфраструктуре запускаются сотни тысяч ETL-процессов. Мы поддерживаем ETL на MapReduce, Spark, трех диалектах SQL и голом Python. Мы выстроили свои процессы и инфраструктуру таким образом, что к нам могут контрибьютить аналитики данных и бэкенд-разработчики.

В своем докладе я расскажу:
1. Немного деталей про DMP в Яндекс.Такси, Еде и Лавке: какие данные хранятся в Data Lake и в каком формате, какие слои и потоки данных есть в DWH: как мы несем данные от десятков различных источников до дашбордов в Tableau и OLAP-кубов в MS SSAS.
2. Почему мы решили вместо готового ETL-инструмента написать свой, и как он работает с такими вычислительными системами, как Spark, Greenplum, ClickHouse и YT.
3. Как устроена наша монорепа из ETL-сервисов и процесс разработки, отладки и деплоя.
4. Технические подробности: запуск ETL-процессов в двух дата-центрах, организация тяжелых потоков данных между большими хранилищами, мониторинг наших процессов, проверки качества данных и многое другое.
5. Про взаимодействие между дата-инженерами и бэкенд-разработчиками и аналитиками данных на уровне кода.

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

Реальный сектор экономики — исторически зона коммерческой тайны и закрытых дверей. Однако с каждым годом растет понимание, что кооперация лучше конкуренции. И вот уже постепенно промышленные задачи появляются на хакатонах, а внутренние разработки становятся, страшно подумать, Open Source!

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

Рекомендательная система Дзена строит персональный фид для пользователя. Фид состоит из карточек разных форматов (статьи, видео, посты и др.) и оперативно реагирует на пользовательский фидбэк. В докладе я затрону следующие вопросы:
- как из десятка миллионов документов за несколько сотен миллисекунд отобрать самые релевантные пользователю айтемы;
- как мы построили near-realtime-контур обработки пользовательских событий для подсчета embedding’ов, который суммарно за день обрабатывает больше 10 миллиардов событий;
- как мы считаем фичи для документов и доставляем их в продакшн;
- как мы обновляем ML-модели в продакшне и перестраиваем профили всех документов и всех пользователей.

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

Настала пора абстрагировать инжиниринг данных от ML-процесса. Следующий шаг или очередной слой бесполезных препятствий для ML-разработчика?

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

В этом докладе мы хотим затронуть тему практического использования Feature Store в реальной жизни, разобрать на примере Open Source-проекта Feast реализацию хранилища фич, а также рассказать про интеграцию с AWS DynamoDb.

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

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

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

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

В своем докладе я расскажу о наиболее известных и популярных фреймворках — Hyperledger Fabric, Quorum, Ethereum, Bitcoin и Corda. Мы разберем их сходства и различия, особенно с точки зрения приватности данных, масштабируемости и простоты программирования. Также поговорим о том, на что ориентируются компании при выборе конкретной технологии, и рассмотрим примеры конкретных реализаций, которые сейчас известны на рынке.

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

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

Я работаю в компании Exactpro, где руковожу DLT-дивизионом, который фокусируется на разработке и применении инструментов и методов функционального и нагрузочного тестирования в области систем распределенного реестра. Один из наших главных проектов — тестирование платформы Corda блокчейн-консорциума R3. Моя команда работает с основными продуктами консорциума Corda Open Source, Corda Enterprise и Corda Enterprise Network Manager (CENM).

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

Stateful Deployment Platform или Odin — базовая платформа для управления базами данных внутри компании. Платформа управляет сотнями тысяч баз данных, которые размещены на десятках тысяч железных серверов.

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

Из этого доклада слушатели смогут понять, что:
1) архитектура — это то, что определяет проблемы проекта и его жизненный цикл;
2) лучшее развитие — эволюционное развитие;
3) иногда маленькие вспомогательные сервисы превращаются в гигантские распределенные платформы;
4) опытные программисты тоже ошибаются;
5) IT везде одинаковое и проблемы у всех похожи :)

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

В докладе расскажу, как и зачем мы ускорили доставку контента ВКонтакте в 1,5 раза, и почему у нашего решения, которое мы выложили в OpenSource, нет альтернатив.
Спойлер: мы отказались от TCP, JSON"а, JPEG'а, gZIP'а, получили кратное ускорение передачи данных до пользователей, не остановились на достигнутом и нашли применение FPGA.

Поделюсь, как выглядит наш новый стек в API в доставке изображений и чем он отличается от того, что делают другие IT-гиганты. Также затронем возможности применения ML и статистики для ускорения доставки контента. Обсудим понятие «сетевой конкуренции» — несправедливого распределения канала между пользователями или приложениями в случае перегрузки сети, и разберемся, что делать, чтобы при любых условиях работать быстро и этим увеличивать пользовательскую активность

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

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

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

Серверы одной из новых игр Ubisoft будут работать полностью в Google Cloud.

Google Cloud имеет встроенное автомасштабирование, которое работает приемлемо для простых серверов без состояния (stateless). Например, прокси-серверы или машины с бизнес-логикой без локального хранилища. Удаление нескольких из них пользователи даже не замечают. Google масштабирует кластер, смотря на среднюю нагрузку по CPU или по памяти на машинах.

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

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

Для добавления и удаления серверов он использует Google Cloud API и имеет много дополнительных наворотов:
- он быстрый. Кластер с нуля до тысяч машин запускается за несколько минут;
- отслеживает популяцию кластера игроками, а не CPU и память;
- предсказывает рост популяции и запускает новые машины заранее;
- выводит лишние машины аккуратно, не влияя на игровой процесс;
- позволяет выкатывать пробные версии игры на часть кластера (canary deployment);
- быстро и аккуратно выводит из кластера устаревшие версии игры (rolling update);
- поддерживает баланс серверов по географическим зонам облака.

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

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

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

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

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

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

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

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

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

Обсудим, почему Linux больше любит UDP, разберем, как писать высоконагруженную сеть, и заглянем во внутренности GSO. Уделим внимание реализации TCP friendly-протоколов на userspace и поговорим про congestion control и pacer. Если хотите узнать, как мы патчили сетевой модуль nginx, оптимизировали перфоманс и запускались — ждем на докладе.

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

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

Основа доклада - мои статьи на хабре об интеграции https://habr.com/ru/company/oleg-bunin/blog/534090/ первая, https://habr.com/ru/company/oleg-bunin/blog/538156/ вторая, https://habr.com/ru/company/oleg-bunin/blog/543946/ третья.

Когда мы говорим про публичные облака, на ум сразу приходят всем известные названия — AWS, Azure или Яндекс.Облако. Сотни тысяч серверов, десятки дата-центров и команды программистов, которые могут переписать что угодно "под себя".

Если вам нужно приватное облако, то вот вам VMWare, Nutanix или решение "под ключ" от сервис-провайдера.

Но что делать, если своё (совсем своё) облако хочется, а команды разработчиков под рукой нет? Покупать "коробку" и настраивать под себя? Собирать конструктор из кубиков opensource-решений?

Мы в ECOMMPAY IT решили построить своё небольшое облако для внутренних нужд ИТ, а в перспективе — для использования во всей группе компаний.

В докладе я расскажу о первых собранных граблях и тех результатах, которые мы получили, собрав первую версию нашего облака. Вот обо всём этом (и не только):
- Зачем вообще нужно своё облако?
- Выбираем архитектуру OpenStack vs VMWare?
- Где хранить данные: CEPH или не CEPH?
- Гиперконвергентность или отдельные роли?
- Сеть, как основа всего — сколько слоёв абстракции необходимо и достаточно?
- Сколько нужно человек, чтобы запустить облако?

В 2ГИС есть информация о 4.5 миллионах компаний в сотне городов, и для всех мы хотим отображать информацию о товарах и услугах, которые они представляют. У нас есть разные способы загрузить информацию о товарах и услугах: с помощью прайс-листа, поштучно через CRUD-интерфейс, настроить синхронизацию с 1С, получать данные от внешних партнеров (Booking, DeliveryClub, Yclients, СберЗдоровье). У каждого из этих источников своя периодичность обновления, объем данных и формат.

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

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

Раньше мы использовали NGINX для раздачи контента — это классическое и проверенное решение. Однако, мы столкнулись с рядом проблем, в процессе решения которых было принято решение написать собственный CDN EDGE-сервер.

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

КШД (корпоративная шина данных) — это система, которая выполняет у нас функцию интеграции между всеми нашими сервисами (более 300).

Расскажем:
1. Для чего такая система и архитектура системы.
2. Как мы выбирали, на чем построить систему, инфраструктурные требования.
3. Производительность системы, метрики, стабильность.
4. С какими проблемами пришлось столкнуться и как решали.

Доклад основан на кейсе по разработке Enterprise-grade-приложения, состоящего из десятков приложений, слабо связанных друг с другом, разрабатываемых разными командами, с разными моделями релиза и т.д. Суммарно размер такого решения может составлять несколько сотен различных юнитов, преимущественно микросервисов. Между этими юнитами нужно построить управляемое взаимодействие, учитывая множество специфических ограничений и условий, таких как:
• распределенность микросервисов по различным дата-центрам,
• поддержка "session stickiness",
• поддержка canary- и blue-green-модели,
• для входящих потоков нужно чётко разделять — какие API публикуются из приложения для каких клиентов
• multitenancy,
• и этот список можно продолжать.

На помощь приходит такая концепция, как Service Mesh и идея применить "микросервисную модель" и к структуре Service Mesh. В результате был разработан Non Uniform Service Mesh (NUM), который представляет собой продукт и набор паттернов его применения.

В докладе я на примере крупного приложения разберу типовые паттерны применения NUM:
• интеграция разнородных приложений в единый service mesh и управление связями,
• реализация application security (authentication, M2M),
• условная маршрутизация запросов в зависимости от бизнес-параметра,
• "stickiness" между микросервисом (kubernetes pod) и запросом (ордером, пользователем, HTTP-сессией),
• выкатывание обновлений по canary-модели,
• multitenancy с применением модели instance per tenant и shared multitenant instance,
• кастомизация логики гейтвея,
• интеграция с 3rd party-системами (серверная, южная).

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

Обсудим платформенные отличия и доступные возможности для работы с сетью на iOS и Android. Поделимся результатами от перехода на новый протокол: как изменилось поведение нашей аудитории и потребление ресурсов приложениями. А также ответим на вопрос: всегда ли UDP — хорошо?

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

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

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

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

Существуют случаи, когда требуется использовать языки, компилируемые в машинный код или совместимые с C ABI. Например: разработка для встраиваемых систем, написание библиотек для других языков (Python, JS, Lua, C, C++) или разработка модулей, встраиваемых в другие приложения (Tarantool, Redis, Oracle).

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

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

Сравним Rust с ближайшими аналогами и рассмотрим кейсы, в которых переход на Rust может повысить надежность и дать прирост в скорости разработки по сравнению с C и C++.

Расскажем, как нам удалось ускорить код на Lua в 20 раз, при этом написав кода в 5 раз меньше чем на С. А также как мы за час реализовали десериализатор данных из Kafka для Lua с помощью Rust.

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

Находить такие ошибки можно, даже не написав ни строчки кода — если пользоваться методами формальной верификации алгоритмов. Таких методов много, но один из них — разработанный в 1999 г. Лесли Лампортом (Leslie Lamport) формализм TLA+ и инструмент верификации TLC — оказался ближе всего инженерам и приобретает все большую популярность.

Мы поговорим про TLA+/TLC, про PlusCal — транслируемый в TLA+ язык спецификации алгоритмов специально для инженеров, про инструментарий, а также про практики применения TLA+/TLC в реальных проектах.

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

Попробуем посмотреть на современный процессор Х86 и его векторные расширения с практической стороны — как это можно использовать повседневно и для базовых задач. Параллельный поиск в дереве, параллельное вычисление множества хэш-функций, сортировка, переупорядочивание и транслирование данных — все это может быть ускорено при корректном применении векторизации. Как и может быть существенно замедлено при некорректном. Практическое применение AVX2 и AVX-512 на примерах проб и ошибок, подчеркивая архитектурные основы векторизации и методику их применения в повседневной практике.

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

В декабре 2019 года компания AWS анонсировала новые инстансы EC2 на процессорах Graviton2 с архитектурой ARM.

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

Yandex Database (YDB) является платформой, на которой построено много сервисов — от баз данных до виртуальных дисков в Я.Облаке, на ней построены сервисы персистентных очередей и мониторинга.

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

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

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

Доклад разделён на две части:
* в первой части будет приведён краткий обзор других OpenSource-решений, удачных и не очень, которые мы рассматривали, а некоторые из них даже дошли до production, но впоследствии мы от них отказались;
* вторая часть доклада будет сосредоточена непосредственно на LINSTOR, чтобы рассказать слушателям, как именно он работает, и с какими проблемами мы столкнулись при его использовании.

Хранилище LINSTOR построено на свободных технологиях: ZFS, LVM, DRBD и ориентировано на максимальную производительность и высокую доступность данных.

В данном докладе я расскажу про наш опыт его использования в Kubernetes, Proxmox и OpenNebula:
• на наглядном примере посмотрим, как оно работает и чем отличается от того же Ceph и других решений;
• под какие цели стоит использовать LINSTOR, а когда его внедрение может быть нецелесообразным;
• разберёмся, как работает тонкая настройка и планирование ресурсов;
• проблемы DRBD и их решения.

В последнее время часто стали появляться запросы на хранение компонентов графов, а иногда и графа целиком в базе данных. Для этого есть специализированные решения типа Neo4J и др. Но чаще всего компании используют для этого решения, которые не предназначены для хранения графов, например, MySQL, PostgreSQL или Hadoop.

Однажды к нам пришли заказчики, у которых граф хранился в Hadoop, но работа с ним была довольно трудоемкой и медленной. Они хотели работать с графом быстрее, чем сейчас. Мы решили попробовать поместить его в Tarantool. Этот доклад о том, что же у нас получилось и как мы это сделали.

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

Как быстро повторить настройку "боевой" базы MySQL, MariaDB, Percona Server, Postgresql, MongoDB в "домашних" условиях? Надо решить несколько проблем:
- разные версии СУБД и дистрибутивов Linux, Docker-контейнеры, Kubernetes;
- нужно много серверов, чтобы работала репликация и кластеры;
- доступно только слабое железо, например, только ваш ноутбук или старый PC;
- все сервера и кластеры должны легко создаваться заново и удаляться.

https://github.com/ihanick/anydbver спешит на помощь.

В этом докладе вы узнаете, как запустить в одну shell-команду кластеры MySQL/MariaDB, репликацию в Postgresql и 13-узлового монстра MongoDB с шардированием и бэкапами.

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

В этом докладе я расскажу про нововведения в средствах для мониторинга, появившиеся в последних двух релизах Postgres (13 и 14), которые выйдут осенью, но уже доступны для бета-тестирования. Я расскажу о том, какие конкретно добавлены улучшения, в каких случаях они могут быть полезны и как их применять, приведу практические примеры их использования. Доклад будет полезен системным администраторам и ДБА, которые интересуются мониторингом и занимаются их поддержкой.

Тарантул долгое время поддерживал асинхронную мастер-мастер-репликацию.
В случаях, когда от системы требовалась повышенная надёжность, приходилось реализовывать собственные решения (известные под собирательным названием “wait for quorum”), позволявшие получить часть гарантий синхронной репликации. Этих техник часто было недостаточно: они не позволяли справиться с грязными чтениями, а также откатить транзакцию, которая не смогла набрать кворум.

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

Со временем мы поняли, что необходимо поддержать синхронную репликацию и выборы лидера в ядре Тарантула. Синхронная репликация поддерживается, начиная с версии 2.5, а выборы лидера появились в версии 2.6, выпущенной в сентябре 2020.

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

Об этих отклонениях от протокола и багах, которые они породили, вы услышите в докладе.

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

Основные возможности Tarantool Cartridge:
- автоматизированное оркестрирование кластера;
- автоматическое шардирование;
- возможность настроить master-master-репликацию;
- управление кластером с помощью GUI и API;
- встроенные failover и switchover.

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

Рассмотрим практические подходы к построению высокоэффективной аналитической системы управления базой данных для обработки больших объемов информации:
- на уровне архитектуры (shared nothing архитектура, надежность хранения данных и защита от сбоев);
- на уровне развертывания — динамические кластеры в Kubernetes;
- на уровне хранения данных (диски и формат хранения);
- на уровне сетевого взаимодействия (оптимизация сетевого трафика);
- на уровне планирования исполнения (распределение задач и сборка результата) — работа с блокировками;
- перенос вычислений в БД (начиная от простых агрегаций до обучения и применения моделей машинного обучения).

И конечно, посмотрим, как это работает на практике в унифицированном аналитическом хранилище Vertica.

* Что такое Change Data Capture и зачем оно нужно.
* Как применять CDC, use-case'ы.
* Как сделан CDC в Apache Ignite.
* Как реализована логическая межкластерная репликация на основе CDC.
* Что еще предстоит сделать в этой фиче.

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

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

Json сейчас является де-факто стандартом для разработчиков стартапов. Почему это происходит и что надо делать — учить разработчиков приложений, как правильно проектировать базу данных согласно канонам реляционной теории (которой Postgres очень хорошо соответствует) или сделать СУБД более дружественной для Json?

Доклад посвящен опыту переноса распределенного серверного приложения, работающего 24/7 на полигоне 16 железных дорог от Калининграда до Хабаровска плюс несколько БД центрального уровня, с Oracle 11g Standard Edition на ванильный PostgreSQL 11.9, а также об опыте миграции БД и эксплуатации новой системы в течение двух лет.

На момент начала миграции база данных одного узла насчитывала порядка 200 хранимых процедур на языке Oracle PL/SQL общим объемом порядка 60000 строк (которые создавались с 2006 года, т.е. уже более 12 лет), около 250 таблиц и порядка 100 Гбайт данных для каждого дорожного узла и 1,5 Тбайт данных для центральных узлов.

Особое внимание уделяется "подводным камням", с которыми мы столкнулись в ходе планирования и миграции приложения Oracle PL/SQL на Postgres pl/pgSQL, связанных не только с различиями и неполным соответствием возможностей Oracle и Postgres, но и с различиями в практических подходах к обеспечению высокой производительности приложения, а также отличиям и особенностям Postgres с позиции бывшего пользователя Oracle.

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

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

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

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

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

Общественный транспорт на карте и бесконтактные заправки — как это работает под капотом, расскажут Семён Павлов, Ден Иванов и Илья Таратухин из питерского 2ГИС.

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

1. Требования бизнеса к платформе по сбору данных.
2. Что пробовали использовать (Кассандра пошла, но не очень).
3. К какому решению пришли? (интегрировали гриды)
4. Какую грид-систему выбрали, по каким признакам.
5. Как развиваете этот подход? (планируем использовать гриды не только как кэш над данными, а как платформу для распределенной работы с данными используя Entry-процессоры, в которых мы исполняем код на собственном DSL. Этот код мы можем динамически обновлять, мы можем иметь несколько версий кода, производить проверки гипотез, канареечное развертывание)