Стачка.Backend

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

Рассказ будет основан на реальных событиях роста видео платформы ОК с 720p и 30 млн просмотров в сутки, до 4К и 870 млн, и 2 Тбит/сек.

Сервис Видео в Одноклассниках – первая площадка в Рунете по объемам видео.

В докладе я расскажу:

* pipeline видеохостинга;

* как сделать самую быструю загрузку видео;

* как сделать самое быстрое транскодирование видео;

* архитектура системы доставки контента и CDN;

* тюнинг и проблемы TCP для раздачи 4K;

* как и зачем нужно отказаться от ffmpeg и нарезка видео на GPU;

* обсудим будущее видео хостингов.

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

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

Зачастую "позже" так и не наступает, но бывают исключения.

Что делать если проблемы с производительностью возникли в старом и заросшем функционалом JEE монолите?

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

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

Выбранные для доклада грабли помогут ответить на следующие вопросы:

- Что не так с настройками (по умолчанию)?

- К каким неожиданностям должны быть готовы клиенты?

- Зачем Кафке девопс?

- Много настроек — это хорошо или плохо?

- О чём забыли написать в документации?

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

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

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

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

В докладе особое внимание будет уделено тому, что вас ждёт, если вы решите сделать большой OpenSource-проект.

1. Что такое OpenSource и что в нём такого?

2. Общие лучшие практики. Без чего не полетит любой открытый проект.

3. Важность общего видения и направления. Как решается, что делать а что нет.

4. Работа с сообществом. Общение, организация. Негативный фидбек.

5. Как получить первых последователей и что делать для роста сообщества.

6. Психологические аспекты. Ответственность и выгорание в OpenSource.

7. Финансовый вопрос.

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

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

Kafka как платформа потоковой обработки данных становится всё более популярной. Тем, кто впечатлился обзорными докладами и решит попробовать создать рабочее приложение при помощи Kafka Streams API, предстоит освоить немало новых вещей и соответствующим образом настроить мышление.

С чего начать?

Как работает хранение и репликация локального состояния?

Что такое RocksDB и как её возможности используются в Kafka Streams «под капотом»?

Что за страшные слова: «репартиционирование» и

«копартиционирование»?

Какова семантика джойнов и оконных операций?

Как писать тесты?

Как отлаживать систему «на ходу»?

Что делать с исключениями?

На эти вопросы мы попытаемся ответить, по пути рассмотрев несколько демо-примеров.

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

Мы живём в сложное микросервисное время. Нельзя просто взять и написать код. От современного разработчика требуется понимание и использование инструментов, которые выходят за рамки кода, отвечающего за бизнес функционал. Service discovery, centralized configuration, distributed tracing, circuit breaking, API gateway — все эти штуки из удела высшего общества давно превратились в обыденные механизмы, без которых не построить современное приложение. Одно хорошо — обо всём этом уже позаботились другие люди и приготовили для нас замечательные готовые решения. Казалось бы, добавил новую библиотечку в зависимости, и готово, однако всё не так просто — обрастая функциональностью, мы теряем лёгковесность. Всё это сопровождается постоянным усложнением систем и новыми функциональными хотелками.

В докладе расскажу про способ, как мы в Леруа Мерлен справляемся с ожирением наших микросервисов.

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

Из доклада вы узнаете, как подход API First помогает снизить риски, делает разработку более контролируемой и гибкой. Этот подход не инновация и не rocket science, но остается недооцененным. Я расскажу про его предпосылки, ключевые моменты, преимущества и недостатки.

Мы в компании долго занимались "приготовлением" PHP к серьезным задачам и добились в этом определенного успеха. Но время не стоит на месте, ровно как и запросы клиентов к динамичности их приложений. Масштабность одного проекта потребовала популярный нынче "распил" на микросервисы и тогда мы познали как разные новые технологии (GraphQL, GRPC, Kubernetes и др.), так и новые, для нас, языки в мире backend - JavaScript и Golang.

Впоследствии мы начали писать все больше и больше backend на Go и JS, что познакомило нас с совершенно новым миром возможностей и трудностей:) В своем докладе я планирую рассказать именно об особенностях перехода от PHP к GoLang, а именно:

• Сравнение возможностей асинхронности

• Насколько дорого перевести разработчиков с PHP на Go

• Как сделать переход максимально "дешевым" для компании

• Где и какие повседневные задачи решать проще

В каких ситуациях какой язык больше подходит и почему?

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

В докладе мы поговорим о весьма хорошо зарекомендовавших себя подходах, известных еще со времен Smalltalk и Erlang, - Message-oriented middleware и Event Sourcing. Обсудим пути миграции RPI-based приложения в сторону асинхронности и реактивности. Поговорим о трудностях возникающих на этом пути, посмотрим, как решаются вопросы с ACID и CAP, а также какие подходы можно применить для тестирования подобных систем.

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

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

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

Ключевые вещи, о которых пойдет речь в докладе: Rails, Elastic, Python, Clojure, структуры и алгоритмы обработки данных