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

"Что там писать клиентское приложение - вот сервер, который выдерживает 10 тысяч запросов в секунду!"... "Да они там только API делают, вот бы хоть одно приложение под iOS написали!"

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

Мы в Mail.Ru Group используем:

• - таск-трекер JIRA,
• - базу знаний Confluence,
• - инструмент планирования и контроля работы Greenhopper,
• - модуль тестирования Zephyr,
• - инструменты слежения за изменениями и просмотра кода Fisheye и Crucible,
• - средство построения графиков и диаграмм Gliffy,
• - систему непрерывной интеграции Bamboo.

• * Архитектура сервера (потоки, процессы, очереди, ввод-вывод).
• * Concurrency (работа с потоками, синхронизация, переключения контекста).
• * Выделение памяти.
• * Zero-copy ввод-вывод.
• * Профилирование и системная статистика.
• * Когда этого мало и стоит переходить на Kernel Programming.

• * Выравнивание данных и оптимизация работы кэшей процессора, оптимизация для NUMA.
• * CPU-binding (привязка потоков/процессов и прерываний к процессорам).
• * Lock-free структуры данных (атомарные операции, барьеры памяти).
• * Векторные операции.
• * Cache-concious и cache-oblivious структуры данных.
• * Транзакционная память (Intel TSX).

Как построить примитивный самописный поиск за 1 час, как - за 1 вечер, что можно сделать за 1 неделю и когда это оправдано? Что еще, по идее, должен бы уметь Идеальный Поиск и когда лучше взять уже готовое, чем продолжать "пилить" свое? Чем внутри похожи, а чем-таки фундаментально отличаются Sphinx, Lucene и, как следствие, построенные поверх второго Solr, Elastic? Чем Sphinx и Lucene не менее фундаментально отличаются от движков, встроенных в СУБД? Как просто, быстро и абсолютно неправильно "забенчмаркать" разные решения при сравнении? Концепция marketing-driven defaults. Прочие большие (но нефундаментальные) текущие отличия движков, возможна спонтанная пятиминутка ненависти к Java-стеку в целом и саморекламы Sphinx. На сладкое - многогранный ответ на заглавный вопрос: так по каким же критериям выбирать поисковую технологию (очевидно, не техническим)?

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

MySQL - популярная СУБД, используемая во многих проектах. Разработчик Percona Server и инженер Mail.Ru Target расскажет про неудачные решения в репликации MySQL, объяснит её устройство, рассмотрит архитектурные проблемы, многопоточную репликацию в версии 5.7. После этого доклада слушатели поймут, почему это провал, как репликацию нужно было сделать правильно, и почему проект PostgreSQL избежал этих проблем.

Какая вообще в природе бывает репликация (sync vs. async vs. semisync, master-master vs. master-slave), как оно устроено конкретно в MySQL, в каких версиях что добавили. Про binary/relay log, про SBR/RBR/mixed форматы, про глупости с позициями и про GTID, про то, как из-за всяких бед возникают дополнительные продукты типа Tungsten и Galera. Несколько занятных фактов и парочка фокусов, которые можно учинять конкретно с MySQL-репликацией.

Доклад вчистую про внутреннее устройство, по результатам должно появляться общее понимание того, как оно работает внутри и почему именно так. Конкретные SQL-операторы подробно рассматривать НЕ будем, эти скучные мелочи необходимо будет затем самостоятельно смотреть в документации (или не смотреть).

Данный доклад в формате мастер-класса охватывает следующие темы:

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

• a) Основные понятия и принципы работы брокера сообщений RabbitMQ.
• b) Описание работы обменников с типами Direct / Fanout / Topic.
• с) Практическое использование брокера RabbitMQ для отложенной обработки трудоемких операций.

• a) Основные принципы работы с Memcached и Redis, их различия.
• b) Преимущества и недостатки.
• c) Практическое применение:
• * использование Memcached и Redis на высоконагруженном проекте - кэширование карточек объектов в связке Nginx / Memcached / Redis
• * использование SETS, SORTED SETS (типы данных Redis) для постоянного хранения заранее обсчитанных ID обьектов для параметрической фильтрации каталога.

Чем на самом деле занят backend (application server)? Чем обусловлены пределы нагрузки? Как увеличить производительность?

Многозадачность: "нити" (threads), процессы, асинхронный ввод-вывод, event loop. Модели программирования: многопоточная, многопроцессная, корутины, явная асинхронность. Драйвер базы данных: управление соединениями, pipelining, шардирование и отказоустойчивость. Вычислительно сложные задачи: очереди, RPC, workers. Сервисно-ориентированная архитектура (SOA).

• * Как создавать конфигурацию, которую легко сопровождать в течение многих лет.
• * Правильные и неправильные способы конфигурации, типичные ошибки.
• * Где следует использовать регулярные выражения.
• * Почему подход "copy-paste" лучше, чем DRY (Don't Repeat Yourself).

Обзорный (информационный) доклад для тех, кто только начинает работать с высокими нагрузками :)

Разберемся в вопросе о том, что же такое highload. Начнем с того, что попытаемся определить его "в попугаях".

Рассмотрим простой веб-проект, скажем, на PHP, определим границы его нагрузочной способности для одного сферического сервера. Далее разберем, что нужно сделать, чтобы выйти за эти границы.

Потом перейдем к проблемам планировщиков OS и способам их преодоления, затронем событийные системы и поговорим о разных языках программирования. Коснемся немного in-memory БД Tarantool.

Ну и в качестве примера применения всего вышеописанного приведу свой проект распределения заказов такси (один из крупных бэкендов Яндекс.Такси).

• * Минимальные аппаратные требования.
• * Схема L2 для соединения компонентов кластера.
• * Схема L3 для обеспечения внешней доступности сервисов (HSRP, corosync).
• * Локальное дисковое хранилище высокой доступности (на основе проверенного drbd в режиме dual primary).
• * Кластерная файловая система OCFS2 (поверх DRBD).
• * Виртуальные машины в микрокластере.
• * Базовые операции по обслуживанию виртуальных машин.
• * Ограничения предлагаемого решения.
• * Типовые проблемы и их решения.

Мы расскажем о том, как научились хранить данные о трафике на наших сайтах (около 400 млн. хитов в месяц) в распределенной колоночной СУБД, выгружать из API социальных сетей и AppAnnie данные о подписках на наши потоки и установках мобильных приложений, а также импортировать из базы данных сайта информацию об активности зарегистрированных пользователей. Для работы с накопленными терабайтами данных мы научились делать удобные панели мониторинга (dashboards), которыми могут пользоваться не только аналитики, но и журналисты, маркетологи и продакт-менеджеры.

Доклад про:

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

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

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

В своем докладе я поделюсь опытом разработки и внедрения модуля для прозрачного SSD-кэширования в nginx. Такой модуль через добавление одного или нескольких SSD позволяет поднять производительность I/O операций на перегруженном веб-сервере, не внося изменений в application layer.