Стачка.Backend

Максимально широкое и подробное описание текущей (на начало 2020) программной и немного аппаратной архитектуры ВКонтакте, а также компромиссов, проблем и связанных с ними планов на будущее:

* Типы серверов и зачем нам их столько;

* Наши доморощенные БД;

* Немного про frontend часть;

* KPHP сегодня;

* PHP и Go в нашем продакшене;

* Деплой, мониторинг и откаты (куда без них);

* Подходы к отказоустойчивости в реалиях большого проекта.

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

В рамках доклада будут рассмотрены основные методики работы с базами данных для разработчиков, с особым акцентом на наиболее популярных открытых СУБД — MySQL, PostgreSQL и MongoDB.

Один из самых простых и популярных способов «устроить highload на ровном месте» — это написать пару необдуманных строк, изменяющих схему БД, и выложить это в «прод» без обстоятельного тестирования.

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

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

И наконец, основываясь на многолетнем опыте работы с быстрорастущими командами, обсудим организационные вопросы — как выстроить процессы разработки так, чтобы риски простоя и деградации производительности были сведены к минимуму, а команды разработчиков развивались и постоянно наращивали экспертизу работы с БД.

Я хотел бы предложить авторам OSS библиотек и разработчикам приложений взглянуть на написание кода с другой стороны — со стороны тех, кому придётся работать с ним в будущем. Несмотря на то, что чисто технически мы пишем код для машин, его основными пользователями являются люди. Что же такое «код, удобный в использовании»?

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

В докладе я рассмотрю этот «чек-лист» подробнее, а также приведу примеры из мира Руби и не только.

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

Как вступление, сделаю обзор: эволюции архитектуры и инфраструктуры PostgreSQL в Avito; успешно решенных вызовов.

В основной части расскажу о статусе PostgreSQL в Авито 2020: микросервисная архитектура; шардирование; проблемы коммуналок; DBaaS( Database discovery, управление доступом, failover, backup, archive, вопросы разделения ресурсов итд.); вопросы интеграции; эволюция команды.

В заключение поделюсь нашим wishlist/нерешенными вопросами.

В крупных компаниях мы живем в мире плюс-минус качественного кода, актуальных технологий и забываем, что где-то еще крутятся морально устаревшие проекты, написанные до появления в PHP внятного ООП. Но в один день вам могут предложить поддерживать такой проект. За слишком хорошие деньги. У меня был такой опыт - я пришел в очень древний, но “боевой” сервис, смог добиться его переписывания, а затем вернулся к актуальной разработке в продуктовой компании. Выиграв в деньгах и почти не потеряв в знаниях за это время. Хочу поделиться этим опытом и выводами из него.

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

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

В докладе я поделюсь полным описанием процесса перевода проекта: интеграция с Jira, Git-хуки, автоматические скриншоты из тестового окружения. Рассмотрим, как устроено ядро системы, как поддерживать А/B-тестирование и проводить тестирование, имея множество версий. Поговорим, как обеспечить единство стиля с помощью глоссария и памяти переводов, а также как успевать переводить новый функционал за 48 часов и не нагружать разработчиков рутиной.

Стандартно разработчик при поиске проблем в RDBMs подозревает медленные запросы. А что если дело не в медленных запросах? И на самом деле виноваты другие запросы. Расскажу о том какого типа запросы, какую нагрузку дают на базу данных и не дают вашему приложению работать так как вы хотите. Так же поделюсь инструментами для поиска таких запросов.

Kafka имеет развитую экосистему и богатый инструментарий. Иногда это может вызывать растерянность при выборе подходящего инструмента.

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

* Из чего возникла потребность в кэшах. Какие особенности есть в Enterprise. Vendor lock и кэши.

* Какие есть способы получения данных из закрытых подсистем.

* Варианты репликации данных из Oracle: CQN, GG. Какой вариант мы выбрали и почему.

* PIM - кэш продуктов абонента. Как прочитать 10 млрд записей из Oracle и не уронить систему.

* Подробно про схему репликации, холодную загрузку и штатную работу репликации ORACLE-Tarantool

Основы кода классических баз (Oracle, PostgreSQL, MS SQL, ...) написаны в 80-х и унаследовали оттуда много ограничений.

В 21 -веке был кратковременный взрыв NoSQL баз (MongoDB, Redis, Hadoop, ...), устранивших часть старых ограничений, но породивших множество новых.

Сейчас, в 20-х годах в Production Ready состояние входят первые базы, разработанные сразу под инфраструктуру 21 века - облака и контейнеры виртуализации, которые можно назвать "первыми бессерверными".

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

Тезисы доклада уточняются

Тезисы доклада уточняются

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

Ошибки с которыми столкнулись разработчики (Ruby, Golang, Python) при масштабировании финтех стартапа в странах Азии.

Как обновить значение атрибута для всех записей таблицы? Как добавить первичный или уникальный ключ в таблицу? Как разбить таблицу на две? Как …

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

А что делать, если миграции нужно проводить "на горячую" - не останавливая БД и не мешая другим с ней работать? А если при этом таблицы большие (сотни гигабайт), баз данных несколько и серверов приложений тоже несколько?

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

Иногда бывает нужен key-value. Обычно мы берем для этого Redis. Но что если в инфруструктуре уже есть Postgres?

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

Когда задумываться о секционировании.

Как применять разные типы секционирования в Postgresql.

Как не убить производительность.

При создании системы на микросервисах можно легко создать распределенный монолит. Event Storming не уберегает от этого на 100%, но позволяет существенно снизить риск. О том, как именно, с примерами из практики, — в докладе.

В своем докладе я расскажу вам о том как можно быстро и просто сделать веб сервер на языке Golang и документацию к нему. И о том какие есть подходы и инструменты для их реализации.

Что такое grpc-gateway, и как из protobuf сделать api сервер, gRPC сервер и готовую OpenAPI спецификацию.

Так же как из swagger документации построить готовый веб сервер и наоборот.

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

- архитектуре и принципах работы GPU

- алгоритмах обработки данных на GPU и сравнении производительности с CPU

- машинном обучении и нейронных сетях

- научных и финансовых расчетах

- обработке данных и базах данных

- распределенной обработке данных

- облаке и виртуализации

- критериях выбора решений на GPU

- где и как попробовать

MySQL всегда использовали под высокой нагрузкой. Недаром эта база была и остаётся самым популярным бэкэндом для web. Однако наши представления о хайлоде с каждым годом расширяются. Большая скорость передачи данных -> больше устройств с подключением к интернет -> больше пользователей -> больше данных.

Задачи, стоящие перед разработчиками MySQL, с каждым годом усложняются.

В этом докладе я расскажу как менялись сценарии использования MySQL за [почти] 25 лет её истории и что делали инженеры, чтобы MySQL оставалась актуальной. Мы затронем такие темы, как работа с большим количеством активных соединений и высокими объёмами данных. Я покажу насколько современные версии лучше справляются с возросшими нагрузками.

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

MySQL прочно удерживает второе по популярности место после Oracle в рейтинге DB-engines: https://db-engines.com/en/ranking_trend Репликация, табличные движки и поддержка NoSQL не дают MySQL сдавать позиции с 2012 года: года основания рейтинга. Что особенного в этих фичах? Что нужно знать, чтобы использовать их на полную мощность?

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

Доклад рассчитан для начинающих пользователей MySQL. Однако поможет освежить свои знания и более опытным.