Стачка.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

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