Рейтинг@Mail.ru

Заявки на доклады

Поиск по тегам:

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

Как мы подготовились к BlackFriday

Михаил Косыхин

BlackFriday - момент не только потребительского азарта, но и момент невероятных нагрузок на eCommerce. Мы неплохо подготовились к BlackFriday 2016 и выявили много узких мест, как в приложениях, так и в инфраструктуре. Все выявленные узкие места мы исправили. Мы даже добились ожидаемых показателей продаж, но проблемы недоступности возникли и это отразилось на пользовательском опыте и, возможно, объёмах продаж. Мы поняли, что всё что мы проделали было не зря, но этого оказалось мало.
Поэтому мы пункт за пунктом стали выверять наши шаги в подготовке и перепроверять что можно сделать лучше. От чтения логов, до деталей сценариев и подходов к коммуникациям.
В 2017 году наш результат был отличным. В этом докладе я хочу рассказать как именно у нас это получилось и какие неожиданные проблемы мы находили.
Я думаю, что доклад может быть полезен всем eCommerce у которых бывают резкие, кратные сезонные всплески активности клиентов.

Логирование и мониторинг
,
Devops / другое
,
Нагрузочное тестирование
Программный комитет ещё не принял решения по этому докладу

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

Платформа 4К стриминга на миллион онлайнов

Александр Тоболь

Сервис Видео в Одноклассниках – вторая площадка в Рунете по просмотрам видео. Ежедневно мы фиксируем свыше 590 миллионов просмотров видео. Платформа стриминга ОК сейчас позволяет вести профессиональные трансляции в 4К, стримить с телефона в FullHD и отдавать пользователям более 1 Тб/сек трафика.

В докладе я расскажу про платформу стриминга:
* стриминг с телефона и WEB-браузера;
* протоколы стриминга и просмотра live видео: hls, dash, rtmp, webrtc;
* архитектура системы доставки контента и тюнинг congestion control;
* настройка кодеков на клиенте и нарезка видео на GPU;
* о проблемах гарантии задержки на TCP и о том, как мы пришли к собственному протоколу стриминга поверх UDP с гарантированной задержкой доставки видео зрителям;
* свой UDP-протокол: измерение MTU, pacer, шифрование с потерей пакетов, fast retransmite;
* простые способы FEC не работают и google в QUIC его отключили.

Технический прогресс позволил пользователям вести трансляции со своих смартфонов и интерактивно общаться с пользователями в прямом эфире – появились такие мобильные приложения, как Periscope, Insta Live и стриминговое приложение Одноклассников OK Live.

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

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

Результатом нашей работы стал запуск первого в мире приложение на Android, способного стримить в FullHD (1080p) в мобильных сетях.

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

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

Опыт изменения подхода внедрения: от релизов до фасттрека.

Евгений Фоменко/Евгений Беляков

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

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

Unveiling Linux Kernel Load Balancing Performance

Laura Garcia Liebana

nftlb is a new load balancer core that uses the nftables infrastructure (iptables successor) to build highly scalable services from the Linux kernel side improving the performance of current load balancers.

The aim of this talk is to explain why nftlb is needed, how it works and show some performance figures comparing to other solutions.

We will explain how the nftlb small footprint design allows to be easily integrated in commodity servers, virtual machines and containers.

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

How we deliver 1Tbps of video with our WebRTC peer-to-peer network

Nikolay Rodionov

At Streamroot, we have built a peer-accelerated delivery network for video that now delivers more than 1Tbps of data through our Distributed Network Architecture (DNA) based on WebRTC.
We will talk about how we built our P2P solution and how it works, and how we scaled our backend to handle tens of thousands of requests per second, and millions of simultaneous users, and how we make sure to handle even more during the FIFA worldcup.

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

Событийная архитектура распределенных систем на базе NServiceBus

Борис Тверитнев

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

В теории распределенных систем есть несколько типичных ошибок, приводящих в лучшем случае к потере данных, а в худшем - к потере заказов и денег и, как следствие, работы. Чтобы такого не случалось, разработчикам нужно руководство и инструменты, которые уберегут от этих ошибок. К счастью разработчиков на платформе .NET, такой инструмент существует: NServiceBus - “The most developer-friendly service bus for .NET”.

В докладе пойдет речь о таких архитектурных решениях, как очереди, событийный обмен данными на базе асинхронного обмена сообщениями (publish/subscribe), устойчивые к сбоям долгоиграющие процессы (saga). Это неполный список фич, которых требует любая распределенная система, и которых мы рассмотрим на живых примерах, разработанных на базе NServiceBus.

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

Фреймворки
,
Микросервисы, SOA
,
Архитектурные паттерны
,
Распределенные системы
,
Архитектуры / другое
Программный комитет ещё не принял решения по этому докладу

Программный маршрутизатор DRA в распределенном пакетном ядре​

Игорь Муратов

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

Подобные узлы в некотором смысле аналог роутеров IP-трафика, но с особенностями:
* оперирование трафиком на прикладном уровне;
     * сигнальные протоколы используют разный транспорт TCP/IP, SСTP;
     * реализация некоторых интерфейсов (Gx, Gy, Sy и т.п.) требует stateful обработки.

Будут рассмотрены следующие аспекты:
* Маршрутизация — атрибуты таблиц маршрутизации и основные типы применения;
* Контексты сессий — необходимость  stateful-обработки трафика и типы применения;
* Резервирование — резервирование сетевой функции на примере Gx, Sy.
* Связывание сессий –  multiple PCEF, VoLTE;
* Масштабирование — применение  DRA  для масштабировании по горизонтали сетевой функции;
* Балансировка — применение  DRA  для балансировки трафика на несколько элементов сетевой функци​и;
* Отказоустойчивость — алгоритмы восстановления при сбоях.

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

Применение микросервисов в высоконагруженном биллинге.

Евгений Фоменко/Евгений Беляков

1) Архитектура высоконагруженного биллинга


2) Новые вызовы и двухскоростное ИТ

3) Платформа микросервисов (CI&CD)

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

BigData и машинное обучение

Обмани меня… Разрушаем мифы о Spark-аккумуляторах

Сергей Жемжицкий

На сегодняшний день техники оптимизации обработки данных весьма хорошо известны и понятны.
Вот некоторые из них:

1) Вертикальное или горизонтальное масштабирование инфраструктуры путем добавления большего количества серверов, RAM, CPU, GPU, увеличение пропускной способности сети – другими словами, оптимизация методом грубой силы

2) Чтение только тех данных, которые необходимо прочитать, минимизируя дисковый IO, например,
- путем организации данных в соотвествии с паттерном доступа к ним, например, используя шардинг, партиционирование, бакетирование и т.д. или
- путем использования колоночных форматов хранения данных, таких как Parquet и ORC

3) Минимизация сетевого IO
- путем партиционирования нескольких наборов данных заранее и одинаковым образом (co-partitioning)

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

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

Мы с вами попробуем разобраться можно ли использовать Spark-аккумуляторы для подсчета и сбора метрик гарантированно единожды, в качестве side-effect-а основного процесса обработки данных (немного заглянув во внутренности Spark-а), тем самым сократив объемы обрабатываемых данных и время выполнения задач в некоторых случаях более чем в 2-а раза, а также с тем, действительно ли верны утверждения документации Spark и, если нет, то в каких случаях.

Scala
,
Big Data и Highload в Enterprise
,
Hadoop
,
ETL
Программный комитет ещё не принял решения по этому докладу

CatBoost - градиентный бустинг для больших данных

Анна Вероника Дорогуш

CatBoost - библиотека градиентного бустинга, выложенная в открытый доступ компанией Яндекс.
Главные особенности этой библиотеки - она позволяет эффективно работать с категориальными данными, дает повышенную точность за счет методов борьбы с переобучением, реализует возможность быстро считать значения модели для time-critical сервисов, а также дает возможность обучать модели на больших объемах данных. В докладе мы кратко расскажем про то, что такое градиентный бустинг и зачем он нужен, осветим главные особенности библиотеки и подробно остановимся на обучении бустинга на больших данных.

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

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

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

Александр Рубин

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

Типичный пример - запрос с join, group by, order by. Типичное решение - создать индексы. Однако не все так просто - в некоторых случаях MySQL не использует индекс или использует не тот индекс, который нам бы хотелось. Чтобы разобраться с такими случаями и понять, что происходит, мы будем использовать новые возможности MySQL 5.7 и 8.0 - optimizer trace, performance_schema (новые таблицы) и другие возможности.

В результате мы сможем лучше понять, что происходит внутри MySQL optimizer, и сможем оптимизировать медленные запросы.

MongoDB
,
MySQL (MariaDB, Percona Server)
Программный комитет ещё не принял решения по этому докладу

Концепция логического хранилища данных

Николай Голов

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

Речь в докладе пойдет о том, что к системе больших данных предьявляются достаточно жесткие, часто конкурирующие требования. Удовлетворить их все на существующем техническом уровне сложно, и получается монолит - медленно развивающийся, сложный в поддержке. Логическое хранилище данных предполагает три части - поддерживающее SQL основное хранилище (ядро монолита) + допускающие микросервисный подход озера данных (на document store базах) и agile ODS (быстро разрабатываемые и работающие витрины на in-memory/виртуализируемых базах). В таком виде это будет быстро развиваться и покрывать самые разнообразные хотелки продуктовых команд, что бы они не захотели - 50ms отставание, real time- аналитику по живым данным, сложные Machine Learning алгоритмы, огромные объемы и/или недопустимость потери ни единой копейки. Даже, если эти хотелки противоречат друг-другу.

MongoDB
,
Базы данных / другое
,
Аналитика / другое
,
Big Data и Highload в Enterprise
,
ETL
Программный комитет ещё не принял решения по этому докладу

Make Your Database Dream of Electric Sheep: Designing for Autonomous Operation

Andy Pavlo

In the last 20 years, researchers and vendors have built advisory tools to assist DBAs in tuning and physical design. Most of this previous work is incomplete because they require humans to make the final decisions about any database changes and are reactionary measures that fix problems after they occur. What is needed for a "self-driving" DBMS are components that are designed for autonomous operation. This will enable new optimizations that are not possible today because the complexity of managing these systems has surpassed the abilities of humans.

In this talk, I present the core principles of an autonomous DBMS based on reinforcement learning. These are necessary to support ample data

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

Место row level security в высоконагруженном проекте

Александр Токарев

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

Далее будет приведён пример практического кейса выбора способа реализации row level security в высоконагруженном enterprise-проекте (4000 пользователей, 10000 запросов одновременно, транзакционная и olap-нагрузка одновременно).

Будет рассмотрен анализ 3-х технологий реализации row level security в СУБД Oracle, и почему же была выбрана именно security в базе, а не на сервере приложений:
1. самодельный;
2. virtual private database;
3. real application security.



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

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

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

Terraform best practices with examples and arguments

Anton Babenko

This talk is for the developers who want to learn best practices in using Terraform at companies and projects of various size (from small to very large), get pros&cons on code structuring, composition. Also, attendees will be able to learn Terraform (and Terragrunt) tricks and gotchas.

It is easy to get started with Terraform to manage infrastructure as code. Just read the documentation on terraform.io, and you are done. Almost.

The harder part begins when infrastructure grows in all directions (several AWS/GCP accounts, regions, teams, projects, environments, external integrations). One of the most frequent questions is "how to structure code".

In this talk, I will explain many of challenges related to that, what works, what does not work, why so, and most importantly I will show all the code which works from small projects to very-large infrastructures (featuring multi-cloud and multi-region setup).

This talk is best suitable for people who have been using Terraform at least for some time and already have practical questions.

All the code and solutions presented at the workshop will be open-sourced.

Архитектурные паттерны
,
Распределенные системы
,
Работа с Amazon
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Деплой в VM, Nomad и Kubernetes: опыт Ламоды

Павел Агалецкий

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

Технологии виртуализации и контейнеризации
,
Непрерывное развертывание и деплой
Программный комитет ещё не принял решения по этому докладу

Terraform modules inside out

Anton Babenko

Terraform module is the smallest reusable component of an infrastructure. Getting started to use modules is easy, but keep them in a good shape and make them really powerful is harder.

Your infrastructure almost always starts simply: few resources managed by few developers. As time goes it grows in all possible directions. You found your ways around grouping resources into Terraform modules, so what can possibly go wrong? (famous last words)

During the talk, I will explain several unknown, hard to find and rather green-field solutions related to Terraform modules. More specifically:
- Types of modules (resource and infrastructure modules, compositions)
- How to specify dependencies between modules
- Workflow for various types of modules

More advanced topics like:
- Refactoring, upgrades, rollbacks (without recreation of the resources)
- Poor-man modules manager
- What are the limitations of the current implementation of Terraform modules and workarounds (eg, jsonnet, cookiecutter, terrapin)

I will demonstrate and run the code which handles advanced problems based terraform-aws-modules from the Terraform Registry and explain why hundreds of developers are using those modules already (btw, they were downloaded 1 million of times already).

Архитектурные паттерны
,
Разделение представления и бизнес-логики, шаблонизация
,
Методы и техника разработки ПО
,
Разработка библиотек, включая open source библиотеки
,
Работа с Amazon
,
Архитектуры / другое
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Devops / другое
Программный комитет ещё не принял решения по этому докладу

Сервисы-сироты: обратная сторона (микро)сервисной архитектуры

Андрей Никольский

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

Микросервисы, SOA
,
Архитектурные паттерны
,
Критерии выбора технологий для проекта
,
Управление конфигурацией
,
Devops / другое
,
Продуктовая разработка
Программный комитет ещё не принял решения по этому докладу

Особенности реализации доступа по протоколу iSCSI к СХД Ceph

Алексей Костин

В случае, если у вас имеется СХД ceph, и ваши клиенты не поддерживают rbd (например, клиент - это windows или vmware), вам приходится искать решения, какими еще способами можно отдать устройство клиенту и обеспечить отказоустойчивость этого решения.

Я расскажу, какие варианты решения проблемы есть, и какие существуют ограничения, расскажу, что такое tcmu-runner и почему его стоит использовать. Рассмотрю решение ceph-iscsi и сравню его с решением компании SUSE. Объясню, почему может потребоваться передавать Persistent Reservation через rbd-устройство, где это может понадобиться, в каком случае лучше подождать с внедрением этих технологий.

Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
Программный комитет ещё не принял решения по этому докладу

TeamCity на высоких оборотах. Опыт Tinkoff.ru.

Артем Шепелев

Как справляться с повышенной нагрузкой на сервер? Как организовать релизный цикл билд-агентов? Как сделать provisioning билд-агентов без потери кэшей билд-тулов?
Отвечая на эти вопросы, мы попробуем разобраться с основными проблемами высоконагруженных CI/CD платформ. Кроме того, поговорим о обслуживании агентов, утилизации пулов и лицензий. Покажем на примерах решения нетривиальных задач от разработки.

Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
Программный комитет ещё не принял решения по этому докладу

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

Аппаратное обеспечение в эпоху Artificial Intelligence (AI)

Владимир Алексеев

Вопросы, которые обсудим в рамках доклада:
* Ликбез: какое "железо" нужно для создания AI?
* Чем "железо для AI" отличается от "обычного": с какими проблемами сталкиваются производители?
* Достаточно ли вставить GPU в рабочую станцию, чтобы стать data scientist 80-го уровня?
* PCI Gen 4: что дальше? Нам нужен новый интерконнект!
* FPGA для исполнения моделей: "все новое - это хорошо забытое старое".

Бэкенд / другое
,
Оптимизация производительности
,
Распределенные системы
,
Архитектуры / другое
,
Сравнение enterprise и web
,
Другое
,
Enterprise-системы
Программный комитет ещё не принял решения по этому докладу

Dbrain: автоматизация ретуши фотографий для KUPIVIP

Артур Кузин

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

В докладе будет рассказано о процессе сбора датасета для решения этой задачи. Затем будет краткий обзор лучших решений на примере соревнования Kaggle - Carvana Image Masking Challenge по сегменации изображений. Будет рассказано об адаптации лучших приемов. Также будет рассказано про цветокоррекцию и удаление дефектов.

Алгоритмы и их сравнение
,
Machine Learning
Программный комитет ещё не принял решения по этому докладу

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

Golang: специфические вопросы производительности

Даниил Подольский
Кирилл Даншин

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

Например, о проблемах производительности.

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

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

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

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

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

Serverless Functions на примере Lambda от Amazon

Алексей Колесников

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

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

API
,
Java
,
Архитектурные паттерны
,
Отказоустойчивость
,
Работа с Amazon
,
Архитектуры / другое
Программный комитет ещё не принял решения по этому докладу

Олимпиадникам тут не место, или как разрабатывать поддерживаемые приложения

Артем Кудряшов

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

Прочие языки
,
Бэкенд / другое
,
Микросервисы, SOA
Программный комитет ещё не принял решения по этому докладу

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

Отказоустойчивость сети. M-LAG

Максим Раевский

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

Я собираюсь рассказать о разных технических (и не очень) вариантах защиты от отказов сети на примере опыта ivi.ru. Расскажу о нашем состоянии в 2017 году, почему мы захотели перемен и что мы в итоге сделали.

Расскажу, почему мы выбрали не "холодильники" и не стеки для нашего ядра. Расскажу о преимуществах и недостатках MLAG в оборудовании Huawei CloudEngine и ExtremeNetworks. А напоследок покажу тизер о наших планах развития сети в этом году.

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