Доклады
Базы данных и системы хранения (7)
Реинкарнация одной Zettabyte файловой системы
Какую файловую систему выбрать? В чём разница? Почему автор доклада стал контрибьютором OpenZFS?
Поcмотрим на проверенную боем Zettabyte file system, изучим её архитектуру и концепты в сравнении с другими файловыми системами, почему её хочется использовать (кто сказал "деградация данных"?), и когда её использовать не стоит (ммм, zero copy в Copy-on-Write).
Также не забудем о людях - обсудим коммьюнити, основные драйверы, как ФС может быть по настоящему кроссплатформенной, пережить родную ОС, и как ФС может жить вне ядра, не скатываясь в совсем нишевый продукт.
Доклад принят в программу конференции
Развитие сервиса товарных предложений в крупном e-commerce проекте
В докладе я хочу рассказать об эволюции системы поиска для онлайн магазина на примере крупного гипермаркета с примерно 1,5М уникальных товарных предложений и непростой системой их географического распределения. Система основана на ElasticSearch + Golang. Это будет повествование с несколькими примерами продуктовых и технических задач, каждая из которых познакомит вас с каким-то аспектом работы с Elatic
Разберем вопросы хранения и обновления данных в реальном времени, методы ускорения товарных выдач, допущенные при проектировании и разработке ошибки и их цену.
Доклад принят в программу конференции
Эффективное обновление состояний в БД
В рекламе Яндекса мы работаем со многими сложными сущностями, которые храним в базах данных.
Возьмем, например, рекламный баннер. Если взять всю полезную для показа информацию о баннере, то получится сложная развесистая структура, включающая в себя много простых полей вроде тайтла и картинки, а так же сложных — вроде посчитанных эмбеддингов.
Данные баннера нужно постоянно обновлять — они включаются, выключаются, обновляют какие-то свои данные, по ним пересчитываются эмбеддинги. Так что у нас потоковая обработка данных с результатом в виде актуального состояния данных баннеров в таблице (в YT).
Вроде все просто, какие тут могут быть проблемы? На самом деле проблемы ожидаемые, у нас же Highload, и, если работать с нашей таблицей с баннерами наивным способом, то будем создавать слишком большую нагрузку.
Наивный способ — это когда мы данные одного баннера храним в таблице в одной бинарной строке в сериализованном виде. А проблема с нагрузкой в том, что мы на каждое, даже очень маленькое изменение (допустим, изменилось 20 байт в состоянии), загружаем и пишем обратно все состояние (десятки килобайт).
В своем докладе я изложу минимум 5 независимых и взаимно совместимых идей, позволивших нам многократно снизить нагрузку на запись, и значительно — на чтение, а также несколько новых подходов, которые мы пробуем сейчас или хотим попробовать в будущем.
Приходите, чтобы узнать новое, обсудить известное и поделиться своими идеями про работу с состояниями.
Доклад принят в программу конференции
Elastic: 3,8 ГБ/с логов и 6 ПТ данных на дисках — как мы это сделали?
Sage — платформа мониторинга, позволяет собирать и анализировать логи и метрики со всех сервисов компании. Объемы логов постоянно росли и сейчас это 6 ПТ, а кол-во кластеров достигло 15 штук в двух ДЦ. На таких объемах вылезает много проблем: под нагрузкой кластера могут разваливаться, встроенный ILM уже не удобен, да и сопровождать это непросто. В докладе автор расскажет, как эти проблемы были решены в Sage, а также поделится информацией о внутреннем устройстве Elastic.
Доклад принят в программу конференции
Квест по синхронизации аналитического и оперативного хранилищ в реальном времени без потерь когда у тебя сотни терабайт данных
В современном мире ни один средний или крупный ИТ-проект и/или решение не обходится без аналитики. В высоконагруженных информационных системах с большим объемом данных – это особенно актуально. Аналитическая подсистема позволяет анализировать как данные, поступающие в реальном времени, так и исторические данные, диагностировать проблемы, выявлять тренды, строить прогнозы и планы на будущее, список можно продолжать бесконечно… Казалось бы, в чем тут проблема? Прикрути BI-систему и строй себе отчеты на оперативных данных. К сожалению, когда речь заходит про объемы данных, характерные для систем класса BigData, то это перестает работать и нужно строить отдельный аналитический кластер, который синхронизируется с оперативным хранилищем. Почему не работает подход с единой СУБД при очень больших объемах данных и как это сделать так, чтобы данные в аналитическом слое не отставали от оперативных и при этом не растерять эти данные по дороге, я расскажу в своем докладе.
Доклад принят в программу конференции
Репликация данных MS SQL Server AlwaysOn. Какова максимальная производительность, как её добиться, что делать если не хватает максимальной производительности, советы по настройке.
Какова максимальная производительность MS SQL Server AlwaysOn.
Что нужно сделать чтобы достичь максимальной производительности.
Какие есть варианты если не хватает максимальной производительности.
С какими проблемами можно столкнуться на высоконагруженных БД. Варианты решения этих проблем.
Советы по настройке.
Про одну существенную неточность в официальной документации Microsoft по AlwaysOn.
Доклад принят в программу конференции
Распределенные графовые СУБД — будущее для аналитики на Больших Данных?
Графовые СУБД в последнее время стали очень популярны для аналитических задач. Традиционно к графовым СУБД относились скептически из-за их производительности и масштабируемости: например, очень популярная СУБД Neo4j пока практически не масштабируется на несколько узлов. Но появились новые системы, изначально разработанные как распределенные графовые СУБД, которые в состоянии уже хранить и обрабатывать десятки терабайт данных, а в скором будущем смогут масштабироваться до петабайт.
В чем существенные отличия графовых СУБД, какие преимущества и новые методы они предлагают для аналитики, и почему будущее аналитики на Больших Данных может оказаться именно за графовыми СУБД?
Доклад принят в программу конференции
DevOps и эксплуатация (4)
Как научить On-Prem Sentry принимать 60 млн событий в сутки
В докладе расскажу про то, как мы в СберМаркете решали проблемы производительности on-prem Sentry — учили обрабатывать 60 миллионов событий в сутки, для чего пришлось провести оптимизацию почти каждого компонента.
Оптимизировали БД Postgres — научили Sentry работать не только с мастером, но и с репликами. Перенесли хранение событий в s3 и сэкономили 12 ТБ на БД (которые лежали в одной таблице!). Оптимизировали обработку событий из kafka — даже если у тебя есть буфер, не значит, что все будет стабильно. Научили работать с шардированным ClickHouse и максимально глубоко погрузились в архитектуру, чтобы достичь производительности, которую не позволяет даже Cloud Sentry.
О боли, муках и страданиях от несовершенства архитектурных решений, что из этого вытекло, над чем пришлось поработать и к чему приложить руку.
Доклад принят в программу конференции
Переход к Platform as a Service в Яндекс Вертикалях: опыт, проблемы, ошибки
Всего пять лет назад в Яндекс Вертикалях разработчики деплоили приложения deb-пакетами. Логи писались в файлы, деплой был долгим и неудобным, мониторинг и алерты лежали на плечах админов - и им же звонили. Мы жили на железе и ручном приводе. Из такой точки А начался наш путь к прекрасному PaaS будущего.
Теперь мы живем в облаке, у админов много автоматики и звонки только по ops-проблемам. Разработчики наших сервисов деплоят по кнопке из телеграм-бота или Web UI, пользуются автосгенерированными дашбордами, просматривают логи сервисов в Grafana и анализируют трейсы. В нашей платформе доступны canary- и branch-деплои и запуск периодических задач. Процесс подготовки сервиса к запуску - это написание карты сервиса и манифеста деплоя, что занимает минимум времени. И все это - без вовлечения в процесс службы эксплуатации.
В нашем докладе расскажем о трудностях, которые мы преодолели при переходе к концепции PaaS:
Как мы переехали с железа в Яндекс Облако: сервера приложений, базы данных, инфраструктурные сервера
Как мы выбирали компоненты инфраструктуры под капотом PaaS
Как мы перешли от статической конфигурации балансеров руками админов к динамической
Как писали Shiva - систему деплоя и инструменты автоматизации для упрощения жизни разработки
Доклад принят в программу конференции
Как мы управляем инфраструктурой на более 1000 серверах при помощи ansible
Мы хотим, чтобы конфигурация в гите всегда соответствовала конфигурации на серверах. Пока серверов было мало - конфигурация применялась быстро, но с ростом количества хостов - стало слишком долго.
Расскажем:
как управляем более 1000 хостов при помощи ansible с постоянным деплоем изменений на все сервера.
как мы написали ansible-agent, который экономит нам ресурсы и время, как он работает и деплоится на сервера.
как мы строим свой проект и как применяем AWX
Доклад принят в программу конференции
Мы охлаждаем воздухом. Дата-центр Яндекса. Какой он?
Всё, что вы хотели узнать про Дата-центр Яндекса, но боялись спросить.
Пора узнать, как Яндекс подходит к процессу проектирования, строительства и эксплуатации своих Дата-центров.
Как собственные разработки Яндекса влияют на применение и повсеместное внедрение новых технологий в своих Дата-центрах и какую роль в этом играют серверы собственной разработки и производства.
Поговорим о том, как охлаждать серверы воздухом с улицы и не тратить при этом дополнительные деньги. А также узнаем, сколько человек нужно, чтобы обслуживать Дата-центр, по мощности равный небольшому городу.
Доклад принят в программу конференции
Узкотематические секции (2)
VK Звонки: оцениваем качество видео объективно
Почему иногда во время звонка зависает видео от кого-то из участников? Почему видео может “пикселить” или напоминать слайд-шоу, и что из этого больше расстраивает пользователей видеоконференций? Как оценить качество видео и выразить эту оценку в виде одного числа?
Постараюсь раскрыть эти вопросы в своем докладе на примере VK Звонков — высоконагруженного сервиса видеоконференций, в которой ежедневно общаются миллионы людей. В докладе я расскажу, с какими вызовами мы сталкиваемся при передаче видео от участников звонка, как справляемся с ними, а так же как измеряем качество видео, чтобы быть уверенным, что действительно предоставляем нашим пользователям сервис высокого уровня.
Доклад принят в программу конференции
Как при помощи бумаги, карандаша и алгоритма raft достичь консенсуса
Есть во вселенной такой алгоритм — raft. Он широко используется для решения задач консенсуса в распределенных системах (для наглядности — сервисы Etcd или Consul, как наиболее известные проекты его использующие).
Мастер-класс предлагает участникам поучаствовать в своеобразной настольной ролевой игре: каждый участник — это отдельный сервер. Вместо жесткого диска — листок бумаги и карандаш, вместо сообщений по сети — записки под партой. Игроки образуют единый кластер и стараются консистентно реплицировать данные, не страшась сбоев сети. Правила игры — это и есть алгоритм Raft, и мастер-класс дает возможность потренироваться исполнять его вручную.
Доклад принят в программу конференции
Безопасность, информационная безопасность (4)
Пять стадий принятия кибербезопасности
Путь каждой компании к тому, чтобы наконец заняться кибербезопасностью - индивидуален. Но он всегда похож на 5 стадий принятия неизбежного “Отрицание”, “Гнев”, “Торг”, “Депрессия”, “Смирение”. Каждая из этих стадий сопровождается одним и тем же набором предубеждений о кибербезе, ошибочных действий и откровенного противодействия различных структур компании, вне зависимости от типа бизнеса. Я расскажу какие аргументы использовать и какие действия предпринимать для того, чтобы максимально быстро и безболезненно эти стадии пройти. А кто подумал, что их придется пройти лишь один раз? Уже существующему подразделению безопасности постоянно приходится доказывать свою необходимость и возвращаться к этим этапам.
Доклад принят в программу конференции
Управляем доступом в распределённой Linux-инфраструктуре
В докладе расскажем, что такое система управления привилегированным доступом (PAM), зачем она нужна и каким критериям она должна соответствовать. Проведём краткое сравнение различных подходов к управлению доступом в высоконагруженных и распределённых Linux-инфраструктурах. Расскажем про свой опыт проектирования и внедрения системы управления доступом на основе open source решений и собственных разработок. Подробно остановимся на том, как внедрение таких систем влияет на изменение процессов эксплуатации, разработки и DevOps, а также разберёмся, влияют ли эти системы на time to market.
Доклад принят в программу конференции
Подсматриваем за Linux инфраструктурой и выявляем атаки
В докладе обсудим основные подходы к построению мониторинга информационной безопасности для высоконагруженной и распределённой Linux-инфраструктуры. Разберёмся, чем средства мониторинга ИБ отличаются от классических средств мониторинга. Проведём анализ и сравнение существующих решений, таких как go-audit, osquery, Wazuh, Elastic Agent и некоторых других. Расскажем, почему мы выбрали osquery в качестве ядра нашей системы. Поделимся проблемами, с которыми мы столкнулись при внедрении osquery, а также расскажем, как мы их решали. На практических примерах покажем, как внедрение системы мониторинга упрощает расследование атак. Обсудим, может ли такая система быть полезна командам эксплуатации и разработки.
Доклад принят в программу конференции
Безопасность CI/CD
Мир стремительно меняется и в настоящее время нужно быть максимально быстро реагировать на стремительно меняющиеся обстоятельства. Поэтому, все сложнее преставить себе высоконагруженное приложение без автоматизированной системы доставки и сборки (CI/CD), ведь использование CI/CD существенно ускоряет разработку и выкатку фич на продакшен. Вместе с ростом использования автоматизированных систем сборки и доставки растет и внимание злоумышленников к этим системам. А ведь действительно, использование этих систем таит в себе новые опасности.
В ходе доклада мы разберемся как защищаться от основных угроз в CI/CD
Доклад принят в программу конференции
BigData и машинное обучение (3)
Orc vs parquet
О форматах
Сравнение orc и parquet
Оптимизация хранения и доступа к данным
Доклад принят в программу конференции
Антифрод наоборот и использование методов ML в нем
1. Что Такое MIR Accept 2.0 и как это работает
2. Сервис Принятия Решений (СПР) - антифрод наоборот
3. Frictionless зона
4. Зачем это банкам
5.Как использование ML улучшает точность рисковой модели СПР
6. Признаковое пространство ML алгоритма
7. Результаты применения ML: примеры оценки качества и финансовые выгоды для владельцев сервиса принятия решений и их потребителей
Доклад принят в программу конференции
MinIO - что изменилось за год
На прошлогоднем HighLoad я рассказывал пр свой опыт разворачивания геораспределённого отказоустойчивого S3-совместимого хранилища на базе MinIO. После этого мне на почту, что приятно, пришло множество вопросов касательно различных ньюансов. В этом году я бы хотел систематизировать ответы на них и представить в виде доклада широкой публике. Кроме того, я планирую рассказать о том, как развивался MinIO в течение прошедшего года, от каких минусов разработчикам удалось избавиться, а что до сих пор остаётся в виде подводных камней, на которые можно легко наступить и порезаться. Так же хочется рассказать об очень интересном опыте масштабирования MinIO - как мы расширили своё присутствие с 3 до 4 дата-центров, какой реальный прирост производительности дал переход от обычных дисков к дисковым массивам. С какими сложностями можно столкнуться при работе с этими массивами. Доклад ориентирован не на мостодонтов, создающих свои облака, таких как ребята и Яндекса или ВК, а на архитектров из компаний, представляющих малый и средний бизнес, у которых, однако, есть серьёзный потенциал роста и потребность в хранении данных в собственном периметре.
Доклад принят в программу конференции
Нейронные сети, искусственный интеллект (1)
Обрабатываем терабайты данных в кредитном скоринге
Кредитный скоринг — очень консервативная область, где традиционно используются самые стабильные и интерпретируемые методы. Сейчас в банке решение о выдаче кредита принимается нейронными сетями на терабайтах данных.
В докладе пойдет речь о том, как интегрировать обработку большого объема данных в онлайн- и офлайн-процессы кредитного конвейера.
Доклад принят в программу конференции
Технологии будущего (1)
Как сделать быстрого голосового ассистента?
Мы стремимся делать так, чтобы Алиса была человечным ассистентом. Один из важных аспектов - умение вести диалог на такой же скорости, как и человек. В своем докладе я расскажу как устроена Алиса и какие ключевые оптимизации скорости сделаны в системе.
Доклад принят в программу конференции
Бэкенд, теория программирования (3)
Как организовать разработку, чтобы prod не лежал
Дано: высокая нагрузка, простои недопустимы. Нужно добавить новую фичу, а мы стажёр/новичок/впервые-видим-проект
Покажу на практике, как нам помогают некоторые подходы избежать множества проблем. Большая часть того, о чём пойдёт речь доступно во фреймворке userver, но должно быть легко применимо и для ваших случаев.
Доклад принят в программу конференции
Ищем товары по фото
Практический опыт интеграции ML в продакшн. Как мы делали "поиск по фото" для интернет магазинов
Блоки
1) Теория - эмбеддинги, векторный поиск
2) Обработка данных - удаление фона, выделение главного объекта на изображении
3) Хранение эмбеддингов, организация поискового индекса
4) Организация работы серверов для работы с векторным поиском.
5) Проблема похожести цветов, восприятие цветов человеческим глазом. Алгоритмы сравнения похожести цветов.
Доклад принят в программу конференции
Собираем распределённые трейсы запросов с 10к бэкендов
Когда мониторинга и статистики становится недостаточно для поиска всех слабых мест и бутылочных горлышек, хочется получать на бэкенде больше информации, что происходит во время обработки запроса: на что тратится время, какие методы выделяют больше памяти, в какие базы упирается сервер, насколько поток выполнения асинхронный и прочее. В целом, хочется иметь подобие вкладки Network в Chrome — но для бэкенда. Это называется трейсинг. Вроде как и материалов много, предлагаемых решений тоже, но — глаза боятся, путаешься, а как грамотно масштабировать на тысячи серверов — не ясно.
Попробуем всё разложить по полочкам на примере того, как мы организовали трейсинг внутри ВКонтакте и сделали интеграцию с Sentry: с учётом микросервисов, распределённых данных и практически zero overhead.
Доклад принят в программу конференции
Цифровая культура / CTO-трек (2)
Делаем СБОЛ надежнее и надежнее: как мы готовимся к сезонам высокой нагрузки
Каждый год мы с друзьями готовимся к HighSeason (период высокой нагрузки) на сервисы Сбербанк Онлайн
1. Вместе с участниками в виде интерактива попробуем подготовить Сбербанк Онлайн к периоду высокой нагрузки
2. Разберем входящие требования к системе
Нефункциональные - 200 тыс.входов в минуту/72 млн.MAU., ограничения в инфраструктуре
3. Окажемся в ситуации "косяка": за время со старта подготовки ИТ ландшафт изменился (Бэковая система не смогла пройти нагрузочное тестирование и нам срочно нужно их спасать).
ЧТо у нас могло пойти не так в этой ситуации: как в октябре бегать с горящими пятками и почему это не всегда так страшно
4. Поговорим о том, а какие паттерны отказоустойчивости мы используем в СБербанк Онлайн + поговорим о самой архитектуре детальнее.
5. Как мы управляем масштабными изменениями.
6. Где-нибудь еще расскажу о том, как мы стараемся управлять надежностью как продуктом и почему у нас это все время не получается.
Доклад принят в программу конференции
Внутреннее облако в Яндексе от прототипа до платформы. Жизненный цикл сервиса от А до Я и вызовы на каждом из этапов.
Яндекс — технологическая компания, в которой работают тысячи разработчиков, которым нужна платформа предоставляющая всё нужное для разработки и эксплуатации написанных внутри Яндекса сервисов.
Вы узнаете основные вехи в эволюции внутреннего облака, в котором разработчики Яндекса запускают свои приложения. Внутреннее облака за 5 лет выросло от прототипа до платформы с десятком тысяч сервисов запущенных на более чем сотне тысяч серверов. В рассказе я буду опираться на свой опыт, ведь трансформация затронула и меня самого. Вместе с внутренним облаком я прошёл путь от разработчика до СТО Platform Engineering в Яндексе, частью которой является внутреннее облако.
Рассказ будет полезен всем, кто хотел бы узнать из каких этапов складывается эволюция подобных продуктов и с какими вызовами придётся на этом пути столкнуться.
Доклад принят в программу конференции
Тестирование, нагрузочное тестирование (1)
От алгоритма до прода: как подойти к верификации распределенных систем
Команда инфраструктуры ВКонтакте разрабатывает распределенные системы, цена ошибки в которых очень велика, потому что это фундамент для бесперебойно работы всего vk.com. В докладе поделюсь опытом, который мы наработали в ходе верификации наших систем. Расскажу, как проверяем, что система будет отвечать заданным требованиям даже в случае различных повреждений в кластере — от сети, до дисков.
Пройдемся по всем этапам от зарождения идеи, до ее реализации и разберём, как на каждом из них понять, что корректность не нарушена. Поговорим про TLA/TLC+, fuzzing и причинах, почему нам пришлось написать "свой" Jepsen.
Доклад принят в программу конференции
Архитектуры и масштабируемость (7)
Эволюция микросервисной архитектуры Aнтиспама Почты Mail.ru
Для того, чтобы защитить пользователей почты mail.ru от вредоносных писем и сообщений Антиспам Почты Mail.ru проверяет более 400 млн писем ежедневно.
На проверку каждого письма у нас есть меньше 350 мс, за это время нужно распарсить письмо, сходить в большое количество баз данных, прогнать несколько ML-моделей, запустить бизнес-логику и выдать заключение - содержится в письме или в сообщении вредоносный контент, спам или фишинг и блокировать доставку до конечного пользователя.
Эта накладывает дополнительные ограничения на скорость и стабильность работы архитектуры антиспама.
Антиспам сегодня это 500 серверов, 40+ сервисов, работающих в k8s (более 7000 подов), размер hadoop-кластера 5+ PB.
В своем докладе на основе нескольких примерах рассказываю как на основе анализа произошедших инцидентов и ошибок эволюционировала архитектура антиспама, какие архитектурные решения оказались наиболее эффективными, а какие не сработали и почему.
Доклад принят в программу конференции
Feature store: как мы совместили высокую производительность и безграничные потребности data scientist’ов
Поиск одна из самых высоконагруженных и одновременно прибыльных систем в Озоне. Какие товары показать пользователю, чтобы он вероятнее что-то купил? Эту задачу решает команда ранжирования поиска, а мы создаем для них и их экспериментов инфраструктуру. ML-модели ранжирования становятся сложнее, товаров на маркетплейсе становится больше, а поиск должен работать так же быстро.
В данном докладе я расскажу:
- какой путь проходит товар, чтобы оказаться в выдаче поиска,
- зачем нам понадобилось создавать целую систему хранения ML-фичей с нуля,
- какие хаки мы применили для уменьшения latency всего поиска,
- что мы сделали, чтобы справляться с миллионами запросов в секунду на терабайтные базы данных,
- как data scientist’ы получили возможность ставить AB-эксперименты не только с разными моделями, но и с по-разному посчитанными фичами,
- как мы минимизировали временные затраты разработчиков на добавление новых видов фичей.
Доклад принят в программу конференции
Ах как хочется вернуться, ворваться, в монолит!
Микросервисы это все еще новый черный. Любой продукт станет лучше если в нем есть блютус, блокчейн и микросервисы. Даже моя бабушка спросила - можно ли сделать микросервисную швейную машинку.
Но как оно на самом деле? Ждет ли вас “град на холме”?
В докладе я расскажу: о том как Авито шло к микросервисам. Это будет таймлайн история, где покажу разные этапы микросервисной архитектуры Авито. И на какие компромиссы шли в процессе
И расскажу что же в итоге получилось, и почему старички все еще грустят по старому доброму монолиту.
Доклад принят в программу конференции
Warden - зачем нам свой service mesh?
Проблема дискаверинга и балансировки нагрузки в межсервисном взаимодействии не новы. Существует ряд готовых решений, реализующий все 3 вида дискаверинга и балансировки (прокси, service mesh и look-a-side load balancing). Из популярных: nginx, isito и ряд других решений. Но около 3 лет назад мы в Ozon решили пойти своим путём, реализовав свой service mesh.
В этом докладе я расскажу про то:
1. Чего нам не хватило и что нас не устроило в готовых решениях
2. Какие собственные решения мы добавили в service mesh и к чему это привело
3. Почему мы переводим Ozon на grpc и как затюнить его в домашних условиях (и как это вам поможет)
4. Как мы объединили client side и look-a-side балансировку и зачем это нам было нужно
Доклад принят в программу конференции
Как мы переживаем сплит-брейн и продолжаем писать данные по S3 протоколу
Наше объектное хранилище умеет жить сразу на большом количестве географически распределенных площадок и соблюдать сложные правила хранения, даже когда сеть между площадками пропала полностью или, что хуже, непонятно как. Расскажем как нам удалось поверх иммутабельного хранилища предоставлять изменяемый S3, #зачемздесьблокчейн и как жить в не астрономическом времени.
Доклад принят в программу конференции
5GB трейсов в секунду или как устроена система трассировки в Ozon
В этом докладе я пролью свет на трейсинг внутри Ozon и на то, как у него получается обрабатывать 5Gb/s трейсов. Речь пойдёт об архитектуре системы трассировки запросов, пайплайне обработки трейсов, методах хранения такого большого количества данных и, конечно же, о проблемах, с которыми мы сталкивались во время разработки и поддержки системы трейсинга.
Помимо этого расскажу и покажу, как мы строим граф взаимодействия (dependency graph) более 2 тысяч сервисов внутри Ozon, а также, как благодаря трейсингу, мы умеем выявлять наиболее ресурсоемкие запросы (critical path), например при загрузке какой-либо тяжелой страницы. Дополнительно затрону тему взаимодействия системы трассировки запросов с другими системами Observability внутри Ozon.
Доклад принят в программу конференции
CБОЛ. Архитектура слоя хранения
Путь пройденный командой развития Сбербанка Онлайн при построении надежной и отказоустойчивой архитектуры слоя хранения является уникальным и опыт полученный в процессе становления может стать подспорьем для развивающихся проектов идущих прямиком в «клуб HL+». Доклад призван в доступной форме рассказать об архитектуре сервиса Сбербанк Онлайн в части хранения данных и поделиться планами по импортозамещению СУБД.
Содержание:
- СБОЛ это платформа для реализации продуктов экосистемы Сбера;
- Архитектура строится вокруг 2 клиентов: Клиент Сбера и команды развития бизнес продукта;
- Данные СБОЛа делятся на 5 типов;
- End 2 End целостный клиентский блок - основа надежного и масштабируемого сервиса;
- Client Backup Layer, который развязал нам руки;
- Микросервисная архитектура платформы помогает нам мигрировать на PostgreSQL;
- Какие данные блока не прижились в Oracle и куда их отселяем. С какими проблемами столкнулись;
- СБОЛ 2025 Целевая картина хранения данных Сбербанк Онлайн;
Доклад принят в программу конференции
Импортозамещение (2)
Протокол MirAccept 2.0: что нас ждёт дальше
Сервис MirAccept - что это
Какие задачи решает протокол MirAccept 2.0
Что нового по сравнению с устаревшим протоколом MirAccept 1.0
Верхнеуровневый обзор технологии
Применение систем рискового анализа
Как в будущем изменится клиентский опыт
Доклад принят в программу конференции
Замещение Thales - аппаратных модулей шифрования
1. Для чего нужны аппаратные модули безопасности и их применение в финтехе.
2. Чем мы пользуемся сейчас. И почему именно Thales.
3. Аппаратное устаревание модулей - как долго они работают и как часто их нужно менять.
4. Наша история импортозамещения - что случилось и как строился процесс.
5. Организация тестирования оборудования. Тестирование криптоядра и тесты операционной применимости.
6. Что мы ожидаем от новых модулей и как мигрировать на новое оборудование.
7. Вопросы сертификации и международной дистрибуции.
Доклад принят в программу конференции
Хардкор (2)
Как профилировать, когда perf видит не всё?
Платформы, опирающиеся на встроенный интерпретатор, сложно профилировать. Чаще всего, возможен только отдельный анализ производительности внутри VM, с помощью специфичного для нее профилировщика, и снаружи VM, с помощью, например, perf. Тем не менее, в некоторых сценариях необходимо видеть полную картину.
Доклад описывает несколько возможных подходов к профилированию таких систем -- от способов интеграции с perf, до написания своего инструментария.
Доклад принят в программу конференции
Эндогенные угрозы физической целостности СУБД
От некоторых кодов ошибок в мониторинге начинают шевелится волосы. Их бодрящий эффект понятен. Системы отказоустойчивости и резервного копирования спроектированы со всем вниманием к деталям, ошибкам прошлого и учётом прогнозирования будущего. Но внутренняя ошибка СУБД может иметь драматичный эффект.
В этом докладе я попробую систематизировать то, что видел при разрушении данных в следствие багов в разных СУБД, преимущественно из семейства Постгреса.
Доклад принят в программу конференции