Доклады

Хранение данных — это всегда боль, у которой может быть больше 50 оттенков: железо, кэш, гарантии, производительность, скорость восстановления при проблемах, удобство и так далее. Как бы решить большинство проблем, при этом получив что-то легко обслуживаемое да ещё бесплатно?

Поcмотрим на проверенную боем OpenZFS, почему её хочется использовать (кто сказал "деградация данных"?) и когда её использовать не стоит (ммм, zero copy в Copy-on-Write).

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

Взгляд со стороны контрибьютора.

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

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

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

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

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

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

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

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

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

YTsaurus — основная платформа Яндекса для хранения и обработки больших данных, ad hoc-аналитики, построения ETL-задач и регулярных batch-процессов. Сегодня самый большой кластер YTsaurus содержит более 20К хостов различной конфигурации — от 4 до 24 дисков, суммарно более 180К дисков.

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

1. Почему графы.
2. Бизнес-сценарий: цели, задачи и результаты.
3. Модели данных — "реляционка" против графа.
4. Области применения.
5. Наши планы по развитию.

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

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

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

В Тинькофф тысячи сервисов, и все эти сервисы пишут логи. За сбор логов и метрик отвечает Sage — платформа мониторинга собственной разработки с Elasticsearch под капотом. Объемы логов постоянно росли и сейчас это 7 ПБ, а суммарное количество нод на 15 кластерах в двух ДЦ достигло 370 штук. На таких объемах вылезает много проблем: под нагрузкой кластеры могут разваливаться, встроенный ILM уже неудобен, да и сопровождать это непросто. В докладе автор расскажет, как эти проблемы были решены в Sage, а также поделится информацией о внутреннем устройстве Elastic.

В современном мире ни один средний или крупный IТ-проект и/или решение не обходится без аналитики. В высоконагруженных информационных системах с большим объемом данных это особенно актуально.

Аналитическая подсистема позволяет анализировать как данные, поступающие в реальном времени, так и исторические данные, диагностировать проблемы, выявлять тренды, строить прогнозы и планы на будущее, список можно продолжать бесконечно… Казалось бы, в чем тут проблема? Прикрути BI-систему и строй себе отчеты на оперативных данных. К сожалению, когда речь заходит про объемы данных, характерные для систем класса BigData, то это перестает работать и нужно строить отдельный аналитический кластер, который синхронизируется с оперативным хранилищем.

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

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

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

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

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

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

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

Всего пять лет назад в Яндекс Вертикалях разработчики деплоили приложения deb-пакетами. Логи писались в файлы, деплой был долгим и неудобным, мониторинг и алерты лежали на плечах админов — и им же звонили. Мы жили на железе и ручном приводе. Из такой точки А начался наш путь к прекрасному PaaS будущего.

Теперь мы живем в облаке, у админов много автоматики, и звонки только по ops-проблемам. Разработчики наших сервисов деплоят по кнопке из телеграм-бота или Web UI, пользуются автосгенерированными дашбордами, просматривают логи сервисов в Grafana и анализируют трейсы. В нашей платформе доступны canary- и branch-деплои и запуск периодических задач. Процесс подготовки сервиса к запуску — это написание карты сервиса и манифеста деплоя, что занимает минимум времени. И все это — без вовлечения в процесс службы эксплуатации.

В нашем докладе расскажем о трудностях, которые мы преодолели при переходе к концепции PaaS:
* Как мы переехали с железа в Яндекс Облако: сервера приложений, базы данных, инфраструктурные сервера.
* Как мы выбирали компоненты инфраструктуры под капотом PaaS.
* Как мы перешли от статической конфигурации балансеров руками админов к динамической.
* Как писали Shiva — систему деплоя и инструменты автоматизации для упрощения жизни разработки.

* Перенос legacy PHP-FPM в Kubernetes.
* Горизонтальное масштабирование PHP-FPM.
* Деплой во время нагрузки.

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

Расскажем:
* как управляем более чем 1000 хостов при помощи ansible с постоянным деплоем изменений на все сервера;
* как мы написали ansible-agent и ansible-server, который экономит нам ресурсы и время, как он работает и деплоится на сервера;
* как мы строим свой проект и как применяем AWX.

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

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

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

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

Художники, копирайтеры и журналисты уже на заводе. Пора ли безопасникам идти в магазин за робой?

В рамках доклада разберем, как уже используются GPT3+-модели ИБ-шниками, разработчиками и администраторами.

Кто нам ChatGPT? Друг, враг или так?

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

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

В докладе расскажем, что такое система управления привилегированным доступом (PAM), зачем она нужна и каким критериям она должна соответствовать. Проведём краткое сравнение различных подходов к управлению доступом в высоконагруженных и распределённых Linux-инфраструктурах. Расскажем про свой опыт проектирования и внедрения системы управления доступом на основе open source-решений и собственных разработок. Подробно остановимся на том, как внедрение таких систем влияет на изменение процессов эксплуатации, разработки и DevOps, а также разберёмся, влияют ли эти системы на time to market.

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

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

В докладе рассмотрим, как можно быстро и эффективно развернуть как Task-Based-, так и Attack-Defence-соревнования, как их грамотно настроить, чтобы не упасть при запуске соревнований и не быть взломанными, а также как настроить GitOps и какие подводные камни есть при разворачивании.

Еще сделаем краткий обзор доступных open-source-средств и платформ для проведения разных форматов CTF.

В докладе обсудим основные подходы к построению мониторинга информационной безопасности для высоконагруженной и распределённой Linux-инфраструктуры. Разберёмся, чем средства мониторинга ИБ отличаются от классических средств мониторинга. Проведём анализ и сравнение существующих решений, таких как go-audit, osquery, Wazuh, Elastic Agent и некоторых других. Расскажем, почему мы выбрали osquery в качестве ядра нашей системы. Поделимся проблемами, с которыми мы столкнулись при внедрении osquery, а также расскажем, как мы их решали. На практических примерах покажем, как внедрение системы мониторинга упрощает расследование атак. Обсудим, может ли такая система быть полезна командам эксплуатации и разработки.

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

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

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

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

В ходе доклада мы разберемся, как защищаться от основных угроз в CI/CD.

* К концу 2022 года мы должны были построить хранилище вместимостью 30 PT с ростом данных в 10 PT в год и наличием жестких SLA по времени доставки данных.
* Мы пробовали делать это так, как принято сейчас — Greeenplum для ядра DWH и MapReduce для остального, оно не взлетало.
* Мы упростили всю архитектуру и сделали DWH на одном YTsaurus.

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

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

В докладе разберём:
* как устроены форматы ORC и Parquet;
* в чём секрет их эффективности;
* каких правил придерживаться при настройке таблиц на примере ORC;
* реальный пример оптимизации таблицы на 500 миллионов записей и ускорения ее обработки в 3 раза.

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

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

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

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

При обработке больших данных с помощью Apache Spark наиболее трудозатратным этапом считается Shuffle stage, когда вся информация активно перемещается. А возникает он в вашем плане, как только вы задумываетесь о группировке или джойнах. Но всегда ли он необходим? Нет! Дело в том, что зачастую Spark не знает, как эффективно использовать метаданные источника данных, поэтому строит универсальные способы исполнения.

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

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

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

Также хочется рассказать об очень интересном опыте масштабирования MinIO — как мы расширили своё присутствие с 3 до 4 дата-центров, какой реальный прирост производительности дал переход от обычных дисков к дисковым массивам. С какими сложностями можно столкнуться при работе с этими массивами.

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

В докладе сначала будет рассказано про диффузионный подход для задачи генерации изображений по тексту: что такое диффузионный процесс, какие бывают диффузии и как это всё связано с генерацией изображений. После этого детально рассмотрим архитектуру модели Kandinsky 2.1, а также возможные режимы её использования: генерация, совмещение изображений, изменение изображений по тексту, генерация похожих на заданное изображений и inpainting/outpainting. Далее приводятся результаты сравнительных экспериментов с другими моделями как на примере самих генераций, так и на уровне метрики FID. После этого расскажу про официальный запуск проекта, достигнутые показатели по уникальным пользователям и числу запросов, кратко опишу структуру бэкенда для такой нагрузки по инференсу модели и приведу статистические данные за первые недели запуска с точки зрения highload-нагрузки.

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

Поделимся с участниками кейсами, как нам удалось улучшить нашу систему на 20%!

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

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

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

В докладе поговорим о диффузионных генеративных моделях и методах персонализации, а также о том, как их использовать в реальном продакшне:
* Сначала немного погрузимся в прекрасный мир теории и поймем две основные вещи: как работают диффузионные генеративные модели на примере Stable Diffusion; и как заставить их генерировать неизвестные для них объекты, например, вас или вашу любимую собаку, с помощью DreamBooth и его модификаций.
* Затем спустимся на землю, чтобы столкнуться с суровой реальностью. Однако справимся со всеми (почти) проблемами: будем кэшировать вычисления модели, считать attention эффективно, и научимся дообучать большие модели, не имея больших ресурсов.

Расскажу, как строится и что находится "под капотом" у OpenAPI-платформы (на примере TelecomAPI-платформы Exolve), а также как можно на ее базе строить конкретные приложения в парадигмах low(no)code и/или serverless и зачем. Разберем узкие места, технические находки и границы применения, а также порассуждаем о перспективах распространения таких подходов.

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

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

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

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

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

Практический опыт интеграции ML в продакшн. Как мы делали "поиск по фото" для интернет-магазинов.

Блоки:
1) Теория — эмбеддинги, векторный поиск.
2) Обработка данных — удаление фона, выделение главного объекта на изображении.
3) Хранение эмбеддингов, организация поискового индекса.
4) Организация работы серверов для работы с векторным поиском.
5) Проблема похожести цветов, восприятие цветов человеческим глазом. Алгоритмы сравнения похожести цветов.

Поговорим о том, как мы расширяли distributed tracing под нужды ВКонтакте. Сама по себе технология понятна — это сбор информации о взаимодействии между элементами системы при обработке запроса. Есть и популярные инструменты для хранения и визуализации трейсов: например, Jaeger и Sentry. А также способы их сбора из прикладного кода (tracing SDK для различных языков).

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

Я расскажу, как мы в целом переосмысливали процесс трейсинга, упёршись в подход Open Telemetry. В итоге у нас получилась более богатая модель данных, при этом сбор трейса на реальном проде получился практически zero overhead.

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

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

Также обсудим, в чём уникальность Elixir: BEAM, OTP, модель акторов и то, как Elixir расширяет ваше мышление в плане подходов к написанию кода. Посмотрим, какие компании уже применяют Elixir для разработки своих сервисов.

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

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

А также:
1. Разберем, что делать, чтобы подготовить Сбербанк Онлайн к периоду высокой нагрузки.
2. Узнаем об особенностях нашей архитектуры.
3. Как и почему появился сервис: "Вход в СБОЛ по талонам".
4. Разберемся в том, почему построение отказоустойчивого финансового сервиса — это непростая задачка.

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

Вы узнаете основные вехи в эволюции внутреннего облака, в котором разработчики Яндекса запускают свои приложения. Внутреннее облако за 5 лет выросло от прототипа до платформы с десятком тысяч сервисов, запущенных на более чем сотне тысяч серверов. В рассказе я буду опираться на свой опыт, ведь трансформация затронула и меня самого. Вместе с внутренним облаком я прошёл путь от разработчика до СТО Platform Engineering в Яндексе, частью которой является внутреннее облако.

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

Дзен — контентная платформа, которой каждый месяц пользуются 80,7 миллионов человек. Рекомендательные алгоритмы отбирают контент для персональных лент пользователей от 100 тысяч авторов из почти 5 миллионов возможных вариантов.

Первая бета-версия Дзена появилась в 2015 году: проект запустился как внутренний стартап с четырьмя разработчиками. Сейчас их больше 300 — и мне, как CTO, важно не потерять скорость разработки.

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

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

Что можно анализировать в компании, которая предоставляет банкам услуги по обработке платежей? На самом деле сама платежная система — это не только информация о платежах. В TechTalk'е разберемся подробнее, какие данные у нас есть и как мы их используем.

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

Сейчас в классическом процессе исследования производительности нужна отдельная сервисная команда, дорогостоящая инфраструктура и недели, а может, и месяцы работы. Изменяющийся мир заставляет нагрузочное тестирование, как и IТ в целом, совершать движение на ранние этапы процесса (shift left).

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

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

Поэтому сегодня мы поговорим про:
1. доступное, релевантное и удобное нагрузочное тестирование, или как организовать процесс НТ в компании;
2. как глубоко прокачать скилы в НТ, или какие вызовы могут бросить легаси системы.

Банки славятся медленной, бюрократизированный, грустной разработкой. Но новые проекты вроде "цифрового рубля" нужно релизить очень быстро. Что делать? Полностью менять пайплайн.

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

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

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

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

Основными тезисами будет разговор про:
* Что такое диспут в платежной системе?
* Зачем нужны диспутные процедуры в платежной системе и в каких случаях используются.
* Как работают диспутные процедуры в платежных системах.
* В чем уникальность диспутной модели ПС "Мир".
* Основные задачи, разделы и функции диспутной платформы НСПК Диспут плюс.
* Наши рекорды.

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

Я расскажу о четырех непохожих, но все равно опасных пути построения корпоративной архитектуры. Каждый из темных богов покажет свои привлекательные и отвратительные стороны: Безопасник, Системный Архитектор, Милорд-разработчик и Бизнес-заказчик.

А в конце посмотрим, чем опасен путь IТ-императора.

Мессенджер — один из критических и самых нагруженных сервисов Одноклассников, который вы также можете знать и под именем ТамТам. В цифрах это 50М МAU и более 10 миллиардов событий в день. На таких нагрузках даже простая фича — быстро и надежно доставить сообщение — становится нетривиальной задачей.

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

Для того чтобы защитить пользователей почты Mail.ru от вредоносных писем, Антиспам Почты Mail.ru проверяет более 400 млн писем ежедневно.

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

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

До встречи на докладе!

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

Но как оно на самом деле? Ждет ли вас “град на холме”?

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

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

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

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

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

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

Проблема дискаверинга и балансировки нагрузки в межсервисном взаимодействии не новы. На рынке существует ряд готовых решений, реализующий все виды дискаверинга и балансировки (reversed-proxy, client-side load balancer в связке с control-plane). Из популярных: nginx, isito и ряд других решений. Но около 3 лет назад мы в Ozon решили пойти своим путём, реализовав собственное решение для service discovery и client-side load balancing.

В докладе будут рассмотрены основные принципы и механизмы, по которым работают service discovery- и load-balancing-решения, а также обозначены проблемы, с которыми вы можете столкнуться в ходе эксплуатации готовых решений или реализации собственного, и возможные пути их решения. Также в докладе пойдет речь о всем функционале, которым собственное решение Ozon отличается от аналогов и что из него оказалось действительно полезным, а что пришлось отложить и пометить как deprecated.

Яндекс Pro — это суперапп для исполнителей, выполняющих заказы клиентов разных online-to-offline-сервисов Яндекса: Такси, Самокатов, Доставки, Еды, Лавки, Маркета. Но так было не всегда, раньше Яндекс Pro был только водительским приложением Такси. Я расскажу о том, какие архитектурные принципы позволили пройти этот путь, тем самым это поможет командам разработки множества бизнесов развивать общее высоконагруженное приложение, сохраняя и его стабильность и скорость разработки.

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

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

MediaSniper за 8 лет прошел путь от пустого репозитория до одной из ведущих рекламных платформ в России.
Когда у вас небольшой стартап и нет бесконечных аппаратных ресурсов, приходится очень тщательно принимать технические решения. Нельзя просто взять проект с github, дописать к нему немного кода и надеяться, что этого достаточно для обработки сотен тысяч RPS.

Задача платформы — отвечать на http-запрос с задержкой не более 50 мс и обслуживать тысячи запросов в секунду (сейчас более 500 000 RPS). В докладе мы покажем, какие решения принимали в области архитектуры, системного ПО, инфраструктуры и, собственно, разработки.

* Собственные сервера + docker, чтобы нивелировать различия в установленных версиях ОС и пакетов.
* Мы любим микросервисы и shared nothing и стараемся избегать решений с единой точкой отказа. Все, что можно задублировать — должно быть задублировано.
* KV БД Aerospike — наш главный помощник. Невозможно или слишком дорого держать вообще всю рабочую информацию на каждой ноде.
* Своя библиотека для асинхронного http client/server позволяет мультиплексировать запросы и заполнять канал, экономя соединения. Мы, как и большинство, все еще живем в мире http 1.1.
* Своя библиотека для map/reduce, чтобы обрабатывать 40 Тб данных в сутки.
* У нас нет silver bullet, мы просто хотим поделиться радостью, что оно работает :)

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

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

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

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

Онлайн-оплата на сети АЗС «Газпромнефть» стартовала в 2018 году с собственной сети. Сейчас ежедневно более 2,5 миллиона литров топлива водители покупают на сети АЗС «Газпромнефть» онлайн. Сервис интегрирован с партнерами с большой клиентской аудиторией, а также с узкопрофильными мобильными приложениями. Поговорим о пользовательском приложении, что стоит за тремя «простыми» экранами заправки?

1. Как мы начинали: low-code-платформа для быстрого старта на 30 точек продаж, 6 месяцев разработки.
2. Рост сервиса опережает функционал, разработка играет роль догоняющего, решение — только распределение нагрузки и изоляция сервисов друг от друга. Все понимаем, планируем переход на новую архитектуру, но не успеваем.
3. Тираж mvp на 1000 точек и первые проблемы low-code, дублирующие сервисы, параллельная нагрузка, функциональное разделение платформы, дополнительный сервер для асинхронных запросов и ODS. Все это на «горячую», без остановок развития функционала и самого сервиса.
4. Рост использования приложения х10 за 1,5 мес и первый серьезный даунтайм, начинаем переход на микросервисы в части транспортного слоя, сложности нагрузочного тестирования распределенных систем, CAP-теорема.

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

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

Пройдемся по всем этапам от зарождения идеи до ее реализации и разберём, как на каждом из них понять, что корректность не нарушена. Поговорим про TLA/TLC+, fuzzing и причинах, почему нам пришлось написать "свой" Jepsen.

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

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

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

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

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

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

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

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

Но! Затевая стартап, никто не рассчитывает, что он останется маленькой наколенной поделкой. Все мы ждем, что из быстро-и-грязно слепленного MVP вырастет многомиллионный бизнес с высокими нагрузками и постоянной потребностью в расширении и масштабировании. И тут как раз микросервисы пришлись бы очень кстати! Как совместить потребность в быстром и дешевом старте с желанием быть готовыми к взрывному росту? Об этом — в основной части доклада.

Доклад о том, как мы за месяц заменили SaaS-продукт Opsgenie на свое собственное решение.

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

* Когда был только Firebase, все было просто. Теперь тренды меняются, появился HMS, появляются региональные решения. Расскажем, как охватить большую аудиторию, используя не только Firebase.
* Как добиться лучшей доставляемости уведомлений, используя сразу несколько транспортов для пуш-уведомлений.
* Дополнительные плюшки — уверенность, что пуш не доставлен, локализация уведомлений, периодические кампании рассылок.
* Что будет дальше, какие альтернативные решения появятся, и что можно уже тестировать. Есть ли будущее у unifiedpush.

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

Помимо этого, расскажу и покажу, как мы строим граф взаимодействия (dependency graph) более 2 тысяч сервисов внутри Ozon, а также как благодаря трейсингу мы умеем выявлять наиболее ресурсоемкие запросы (critical path), например, при загрузке какой-либо тяжелой страницы. Дополнительно затрону тему взаимодействия системы трассировки запросов с другими системами Observability внутри Ozon.

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

На таком объёме данных простая, на первый взгляд, задача «скачай фото по ссылке» обрастает большим количеством проблем:
* что делать с медленными и нестабильными хостами;
* как не устроить DDoS-атаку на сервера клиентов;
* как обеспечить высокую производительность системы и не вызывать негатив у пользователей.

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

Путь, пройденный командой развития Сбербанка Онлайн при построении надежной и отказоустойчивой архитектуры слоя хранения, является уникальным, и опыт, полученный в процессе становления, может стать подспорьем для развивающихся проектов, идущих прямиком в «клуб HL++». Доклад призван в доступной форме рассказать об архитектуре сервиса Сбербанк Онлайн в части хранения данных и поделиться планами по импортозамещению СУБД.

Содержание:
* СБОЛ — это платформа для реализации продуктов экосистемы Сбера;
* архитектура строится вокруг 2 клиентов: Клиент Сбера и команды развития бизнес-продукта;
* данные СБОЛ-а делятся на 5 типов;
* End 2 End — целостный клиентский блок, основа надежного и масштабируемого сервиса;
* Client Backup Layer, который развязал нам руки;
* микросервисная архитектура платформы помогает нам мигрировать на PostgreSQL;
* какие данные блока не прижились в Oracle, и куда их отселяем. С какими проблемами столкнулись;
* СБОЛ 2025. Целевая картина хранения данных Сбербанк Онлайн.

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

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

Практические примеры построения схем процессов, техники и приемы. Эволюция BPM-схем процессов в проде за 3 года, изменение подходов, работа над ошибками.

Про очевидные вещи, которые особенно ценятся на дистанции в 10 лет.

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

Расскажу, что мы сделали за полгода c веб-сервером Angie, и спрошу вас, что нужно делать дальше.
Также расскажу, что значит ^W в названии доклада :)

Yandex Monitoring используется всеми сервисами Яндекса внутри, а также доступен в Яндекс.Облако для внешних пользователей. Мы обрабатываем 700 миллионов метрик на запись ежесекундно.

У каждого клиента есть конфигурация процесса загрузки метрик. Конфигурация — это Control-Plane-объекты, которые:
* хранятся как таблицы в базе данных;
* меняются на лету;
* связаны между собой.
Чем быстрее Monitoring получает обновления объектов, тем выше доступность для пользователей.

Для хранения мы используем YDB — распределенную open-source-базу данных Яндекса.
Команды YDB и Yandex Monitoring проработали сценарий загрузки изменений с помощью YDB CDC. В результате получили архитектуру, в которой изменения объектов доставляются в тысячи компонентов менее чем за 800 миллисекунд.

В докладе:
* Сложности до перехода на Change Data Capture.
* Подходы к доставке изменений, их особенности.
* Чем YDB CDC отличается от других решений.
* Рекомендации, как правильно готовить YDB CDC, поделюсь граблями и их решением.
* Какую модель данных выбрать, чтобы решить проблемы с конкурентными изменениями.
* Мониторинг и поддержка решения.

Время и технологии не стоят на месте. Кто-то из вас, возможно, замечал, что в последнее время при оплате банковскими картами все реже запрашивается ввод PIN-кода, а при платежах в интернете далеко не всегда требуется подтверждение операции через SMS.

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

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

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

На мировом рынке тотально доминирует одна компания — французская Thales. В 2022 году она ушла из РФ и более не предоставляет лицензионную поддержку и свои модули. Но некоторые российские производители оказались готовы представить собственные разработки аппаратных криптомодулей.

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

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

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

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

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

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

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

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

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

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

Собираем в прямом эфире свой умный дом на четырех платформах.

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

Есть во вселенной такой алгоритм — Raft. Он широко используется для решения задач консенсуса в распределенных системах (для наглядности — сервисы Etcd или Consul, как наиболее известные проекты его использующие).

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

Разберем в деталях, что такое Service Discovery — когда появился паттерн, чем полезен в микросервисах и как он реализован в популярных опенсорсных облачных решениях Istio и Kubernetes. На сладкое обсудим, какие есть проблемы с Service Discovery в нагруженных кластерах и узнаем, зачем Istio пытается убить DNS в Kubernetes и как этого избежать.

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

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

В проекте выделены 2 мастер-системы: задачи и накладные. Разделение произведено в соответствии с контуром видимости: накладные — это внешняя сущность, задачи для сотрудников — внутренняя сущность, имеющая смысл только в замкнутом контуре проекта.
Все интеграции с внешними системами реализованы через ACL, взаимодействие со всеми видами фронта — через BFF.

Разделение системы на несколько максимально независимых компонентов/сервисов для устранения проблем монолита:
- ограниченный стэк технологий
- сложность контролировать четкость абстракций
- legacy код
- проблемы с ответственностью
- релиз монолита
- долгий time to market фич

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