HighLoad++ 2017. Архитектуры/масштабируемость, бекенд, enterprise-системы

В первой части конференции вы узнаете:

1. Как мы написали отказоустойчивый, распределенный и консистентный сервис на сто тысяч проводок в секунду. 
2. Почему, согласно CAP-теореме, такой сервис не будет работать. 
3. Как мы сумели разобраться с этим ограничением. 
4. Про Test-Driven Development распределенной системы, или как численными методами строго доказать, что сервис будет работать нужным для нас образом. 
5. Возможности применения используемых технологий при разработке криптовалют.

* Высокая нагрузка с точки зрения сетевого инженера. * Паттерны в архитектуре на примере Facebook/Google. * Многоуровневая балансировка L7, L4, L3. DNS. * Принципы функционирования Anycast и особенности развертывания, методы стабилизации Anycast-сервисов. * Особенности распределения сетевого трафика/подключений.

Обсудим, для реализации каких задач заказчики используют облачные платформы: - Необходимость работать с часто меняющейся конфигурацией железа. - Необходимость часто выделять сервера с разной конфигурацией. - Предоставлять доступ к разнообразным сетевым приложениям. - Разворачивать Telco Cloud (оно же NFV). - Собирать и обрабатывать BigData. От обзора облаков перейдем к рассмотрению практической задачи построения Telco Cloud. В рамках доклада затронем следующие темы: - Проблемы, которые решают SDN и NFV. - Где связь, а в чем разница между SDN и NFV. - Обзор стандарта ETSI NFV. - Существующие решения, реализующие концепцию ETSI NFV. - И на вкусное - разворачиваем NFV своими руками! В последнем разделе поговорим о приложениях, которые должны эффективно работать в облачной среде - о так называемых "Cloud Ready Applications". Какими характеристиками должны обладать приложения? Какие интерфейсы поддерживать? Рассмотрим основные требования: - Независимость от инфраструктуры. - Масштабирование (разделение данных и их обработки, асинхронное взаимодействие). - Безопасность. - Service Discovery. - Configuration Management. - Автоматизированная установка. Выводы, которые можно будет сделать из доклада: С помощью облаков можно решать различные задачи. Мы рассмотрели одну - построение TelcoCloud на основе стандарта NFV. Показали, что технологии SDN и NFV - это совершенно независимые технологии, но вместе они несут определенную синергию. В практической части убедились, что технология NFV достаточно зрелая для промышленного использования. Для эффективной работы в облаках запускаемые приложения должны быть "Cloud Ready".

В докладе мы расскажем: 1. Что такое высоконагруженная фронтальная система банка, чем она отличается от веб-проекта. Место фронтальной системы в IT-ландшафте банка. 2. Как масштабируется СУБД в условиях Enterprise. Технологический стек ограничен и сложно изменяем, решения вендоров по масштабированию ненадежны. Поэтому шардируем экземплярами СУБД. 3. Для отказоустойчивости аналогично делим web-сервера, сервера приложений и т.п. Получаем слабо-связанные, независимо работающие блоки, каждый блок обслуживает часть клиентов. При отказе блока переключаемся на резервный. 4. Для распределения по блокам появляется компонент маршрутизации – как обеспечивается его отказоустойчивость? 5. Где брать данные клиента (история операций, профиль клиента) при переключении в резервный блок? Что можно, а что нельзя деградировать при отказах с точки зрения бизнеса. 6. Какие механизмы обеспечивают непрерывное обслуживание клиентов при отказах бэк-офисных систем. 7. Уголок перспективной архитектуры: омниканальность, наше видение микросервисной архитектуры.

У компании Ingram Micro Cloud стенд на HL. На нем мы организуем браузерную игру TheURBN (urbn.odn.pw) с воксельной графикой, в которой каждый может захватывать территорию общего мира и строить небоскребы при помощи кубиков, а за процессом можно наблюдать на стенде. На экранах мы будем в режиме реального времени показывать виртуальный 3D-мир, в котором участники будут строить небоскребы. Большего погружения можно получить в шлеме VR Oculus Rift на нашем стенде. А в докладе я расскажу, откуда взялась идея сделать такое, и что из этого получилось, как технически устроена игра: от картинки в браузере до архитектуры, базы данных и хостинга всего проекта. Вы узнаете, как это - сделать браузерную 3D-игру в 2017 году, какие трудности вас будут подстерегать, и при чем тут VR. Доклад раскроет технические детали того, как устроена игра, что используется из веб-технологий, как хранятся данные, какую нагрузку пользователей выдерживает, где размещается.

Сеть была запущена 1-го января с 10 локациями, в августе локаций было 25, к концу года будет 80. На каждой локации 4-8 игровых машин и локальный сервер (итого: флот в сотню машин), которыми нужно управлять: контролировать, что конфигурация операционной системы соответствует целевой; что игровой контент и сопряженные сервисы скопированы и настроены; мониторить загрузку, статус работы, нетиповые события; собирать бизнес-события и синхронизировать данные, которые должны быть общими во всей сети. И все эти задачи нужно решать в условиях плохой соединенности локаций с интернетом (нормальным бывает пинг в 1.5 секунды и потери пакетов до 80% или полное отсутствие интернета на 10-20 часов). В ходе развития платформы мы выработали решения, которые позволяют предсказуемо контролировать сеть локаций, несмотря на плохой интернет. В этом докладе я расскажу об основных проблемах, которые мы встретили и решили.

Наш проект – это облачный CI-сервис, на котором пользователи запускают тесты разрабатываемых проектов. В этом году система автозакупки нашего проекта приобрела 37218 машин (Amazon Instances). Это позволило обработать 189488 "задач" (прогонов тестов) наших клиентов. Тесты – это всегда ресурсоемкие задачи с максимальным потреблением процессорных мощностей и памяти. Мы не можем прогнозировать, сколько параллельных вычислений и в какой момент времени будет. Перед нами стояла задача построения архитектуры системы, которая умеет очень быстро увеличивать, а также быстро уменьшать мощности кластера Все это осложнялось тем, что ресурсоемкость вычислений не позволяла нам использовать классические инструменты AWS или GoogleComputeEngine. Мы приняли решение написать собственную систему автоматического масштабирования, учитывая требования нашей предметной области. В докладе я расскажу о том, как мы спроектировали и построили архитектуру нашего сервиса, что из себя представляет система автоматической закупки машин, а также расскажу подробнее об основных архитектурных блоках проектов, решающих подобные задачи.

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

Ловко придумать схему сжатия для своих данных умеют не все, а очень зря. Иногда (иногда) при помощи этой магии удается добиться как бы невозможного: одновременно и сэкономить диск или память, и при этом ускорить код. Как работает магия сжатия в целом? Как она работает более конкретно в очень разных продуктах: ""просто базах"" типа MySQL или Mongo; в поисковиках типа Lucene или Sphinx (или даже веб-поисках); в колоночных хранилищах типа Vertica или Clickhouse; в конце концов, внутри апдейтов Chrome? Обсудим это, пробежимся по всем важным ключевым словам от замшелых Huffman до моднейших Snappy - и, важнее, по ещё паре десятков других ключевых слов. Подробно разберем несколько особо интересных методов и трюков про сжатие и прочую перепаковку данных. Посмотрим пример на 100 строк кода со сжатием в 6 раз и одновременным ускорением работы в 5 раз (читерством, конечно), причем успешно написанный не специально обученным монстром, а совершенно обычными разработчиками. Посмотрим на скорость разных готовых кодеков, попытаемся понять, когда какой можно применять, а где нельзя. Бонус-трек в коридоре, если кому интересно, как устроено внутри сжатие картинок, видео и прочего такого. Условно прикинем на пальцах, как написать свой простенький игрушечный JPEG-декодер в сотню-другую строк; можно на JavaScript или Python. Или не JPEG!

Расскажем о нашем опыте разработки модуля межсетевого экрана для MySQL с использованием генератора парсеров ANTLR и языка Kotlin. Подробно рассмотрим следующие вопросы: — когда и почему целесообразно использовать ANTLR; — особенности разработки ANTLR-грамматики для MySQL; — сравнение производительности рантаймов для ANTLR в рамках задачи синтаксического анализа MySQL (C#, Java, Kotlin, Go, Python, PyPy, C++); — вспомогательные DSL; — микросервисная архитектура модуля экранирования SQL; — полученные результаты.

Мы предлагаем вам рассказ о разработке сервиса в контексте его эксплуатации, решения инцидентов и их расследования. Представьте, у вас проект с полутора тысячами машин, многомиллионной аудиторией и сложной бизнес-логикой. Как писать логи, чтобы расследование инцидентов не превращалось в поиск иголки в стоге сена? Как локализовать проблему, как её воспроизвести и как не потратить на это целый день? Мы рассмотрим распространенные проблемы и некоторые приёмы, которые мы используем для их решения. Также в нашем докладе будут затронуты темы сбора метрик и мониторинга. Рассказ основан на опыте разработки проекта Облако@Mail.ru и личном опыте докладчиков.

В Badoo на данный момент на общей кодовой базе работают несколько разных проектов на всех основных платформах (iPhone, Android, Web и т.д.), где каждая платформа может иметь больше десятка одновременно работающих версий. В этом докладе я расскажу о том, как мы с этим живем и какими подходами решаем задачи разного кода для разных версий клиентов. А именно: как мы меняем протокол, как мы поддерживаем разный серверный код для разных версий клиентов, что такое минорная фича, почему старый клиент – это не страшно, – и как это все помогает в A/B-тестировании.

В крупных (или микросервисных) архитектурах у Backend'а есть свои Backend'ы. И, если какой-то сервис очень важный, он не всегда очень производительный. Как сделать так, чтобы ваша система продолжала отвечать, даже если важные источники информации перестали отвечать? Рассказываю о нашем опыте в Tinkoff: 1. Как мы выбирали СУБД и на чём остановились. 2. Как поддерживать версионность форматов данных. 3. Как понять, что ваш сервис умер или ожил. 4. Как встроить cache, не переписывая приложения на Scala. 5. Итоги и замеры."

Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров. В данном докладе я хотел бы поделиться моим опытом разработки высокопроизводительных приложений на базе новой платформы Microsoft. Речь пойдет как об общих подходах к разработке приложений (очереди, оптимизация ввода/вывода, кэширование), так и о деталях реализации ASP.NET Core и .NET Core. Мы также рассмотрим основные подводные камни, связанные с производительностью, и методики, чтобы их избежать до того, как приложение пойдет в релиз.

Пару месяцев назад мы выпустили первую бета-версию нашего нового open-source проекта NGINX Unit. Он базируется на уникальной архитектуре нового поколения и на данный момент способен выполнять функции гибкого и эффективного сервера приложений. Из доклада вы узнаете, для чего создавался новый сервер, его основные приемущества, какими возможностями уже обладает и какие задачи способен решать. А также познакомитесь с его архитектурой и удобным JSON RESTful интерфейсом управления, позволяющим быстро манипулировать вашими веб-приложениями без потери соединений и прерываний в обслуживании.

Пишем свой протокол стриминга с гарантированной задержкой поверх UDP. Архитектура отказоустойчивого стриминг-сервиса, способного выдержать потерю дата-центра и миллион онлайнов. Проблемы мобильного стриминга и TCP-протокола, QUIC как замена TCP, UDP и fast retransmit, forward error correction (FEC), задержка или потеря пакетов, приоритезация потоков, шифрование и многое другое. Сервис Видео в Одноклассниках – вторая площадка в Рунете по просмотрам видео, ежедневно мы фиксируем свыше 400 миллионов просмотров видео. Технический прогресс позволил пользователям вести трансляции со своих смартфонов и интерактивно общаться с пользователями в прямом эфире – появились такие мобильные приложения, как Periscope, Insta Live и стриминговое приложение Одноклассников OK Live. Новый способ генерации контента предложил нам новые технологические вызовы: * гарантировать задержку между стримером и зрителями на динамично меняющемся мобильном Интернет-канале; * обеспечить непрерывный стриминг даже при потере части оборудования; * сбалансировать нагрузку на раздающие сервера во время популярных, например, спортивных трансляций. Мы поделимся опытом построения масштабируемого отказоустойчивого сервиса видеостриминга, расскажем про его архитектуру, которая выдерживает тысячи стримов online и миллионы зрителей. В ходе доклада: * отвечу на вопрос, как оптимизировать задержку трансляции до времени, сравнимого с p2p-видеоконференцией; * расскажу про протоколы hls, dash, rtmp, webrtc; * настройка кодеков на клиенте и транскодере для минимизации задержки; * расскажу о проблемах гарантии задержки на TCP и тем, как мы пришли к собственному протоколу стриминга поверх UDP с гарантированной задержкой доставки видео зрителям; * свой UDP-протокол: измерение MTU, pacer, шифрование с потерей пакетов, fast retransmite; * простые способы FEC не работают и google в QUIC его отключили. Результатом нашей работы стал запуск первого в мире приложение на Android, способного стримить в FullHD (1080p) в мобильных сетях.

...и что сделать, чтобы уже находилось? И снова про качество поиска. Поменьше скучной теории (ну, чтобы не более 60%); больше практических примеров. Как оценить типа-качество ""на пальцах""; почему это плохая идея. Как построить оценивалку; насколько это просто; где взять готовую (нигде); зачем человечеству Толока или Mechanical Turk. Что именно и как именно крутить в формуле ранжирования. Почему только лишь Магического Мега Ранжирования - любого, из любого поисковика - вам, скорее всего, не хватит и придётся подкручивать своё. Что значат все эти непонятные ""сигналы"" и прочие формулки, как они себя на самом деле ведут в жизни. Что ещё покрутить вместо (ладно, разрешаю вдобавок) к той формуле, причем, возможно, с куда бОльшим толком. В какой момент наступает машинное обучение, а где его всё ещё отлично заменяет обычный Excel. Отчего вашему конкретному интернет-магазину никакие Сложные Формулы не нужны вообще, а вот над качеством поиска, тем не менее, поработать стоит. Бонус-трек, если (если) позволит NDA: как именно подобные изменения мгновенно и измеримо влияют на счастье (или нет) небольших групп в полмиллиона пользователей.