Тезисы уточняются

Масштабирование — способность наращивать систему для обработки большего количества трафика, не теряя при этом пользовательские качества: скорость и отзывчивость.

Масштабирование различают двух типов: вертикальное (больше памяти, диска, лучше процессор) и горизонтальное (больше серверов в кластере).

- Зачем оно нужно, если и так всё работает?
- Когда? Мониторинг, необдуманные решения, оптимизация и жизнь с одним сервером.
- Типичная схема.
- Балансировка нагрузки.
- Какие, вообще, проблемы на стороне приложения?
- Почему PHP так хорош для масштабирования.
- Сессии.
- База данных.
- Файлы.
- Как быть со статистикой?

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

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

Знакомо? Тогда вам будет интересно послушать, как заставить вашу базу данных работать прямо сейчас. А именно:
- какое место в общей производительности базы данных занимает оптимизация запросов?
- когда прекращать “крутить гайки” и заниматься медленными запросами?
- что такое медленный запрос и когда их надо начинать оптимизировать?
- как оптимизировать?
- EXPLAIN, EXPLAIN ANALYZE - как читать и на что обращать внимание?
- как работает оптимизатор запросов PostgreSQL и где могут быть узкие места?
- для чего нужны и для чего не нужны индексы, методики индексирования, и как быть уверенным, что ваш индекс правильно используется?
- какие запросы не будут работать быстро никогда, и как с этим жить?
- ошибается ли оптимизатор и, если да, то почему и как его в таком случае призвать к порядку?

Индексы
- типы индексов;
- типы доступа к таблице;
- составные индексы (когда они работают);
- получение информации об индексе (show index; - описание формата);
- примеры с поиском по нескольким полям и сортировкой: какие индексы будут использоваться, а какие нет;
- что делать в случае нескольких условий по диапазону;
- как сервер выбирает индекс, который будет использован;
- директивы use/force/ignore index.

EXPLAIN
- как работает оптимизатор запросов;
- недостатки explain;
- explain extended;
- получение sql запроса, восстановленного из плана;
- формат выводимой explain информации:
-- что означает каждый столбец;
-- какие значения принимает (для extra только самые часто встречающиеся);
-- на что обратить внимание с точки зрения производительности;
-- как правильно читать план-разбор сложного примера с join-ами, подзапросами (обычными и from) и union-ами;
- новые возможности explain в последних версиях.

Практические примеры (исходный запрос, план, оптимизация, итоговый план) для разных случаев оптимизации:
1. добавление индексов;
2. эквивалентное изменение запроса: or --> union, подзапрос --> join;
3. разбиение запроса на несколько с сохранением промежуточных данных во временной таблице;
4. изменение структуры данных;
5. использование пользовательских переменных.

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

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

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

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

Проблемы:
— Много строк в таблицах.
— «Медленные» запросы.

Варианты масштабирования БД
— Секционирование / партицирование данных.
— Шардинг.
— Репликация.

На какие вопросы будут получены ответы:
— Как создать сегментированную таблицу?
— Использование constraint (ограничений).
— Выборка данных из сегментированных таблиц.
— Как управлять сегментами таблицы: вставка, удаление, изменение данных.
— Индексы и триггеры в сегментированных таблицах.
— Архивация данных.
— Использование представлений и материализованных представлений.
— Шардирование данных.
— Репликация как способ масштабирования БД, архивации и резервного копирования.
— В каких случаях какой из способов масштабирования выбрать?
— Какие плюсы и минусы у каждого из подходов?
— Прирост производительности БД (в 3-4 раза) на том же оборудовании при применении сегментирования.

Partition Magic — наша собственная утилита для автоматического управления партицированными таблицами в PostgreSQL (https://github.com/2gis/partition_magic):
— Автоматическое создание партиций.
— Управление триггерами, проверками, ограничениями и индексами.
— Выборка данных.
— Добавление данных.
— Удаление данных.
— Изменение данных.

Покажу на примерах PostgreSQL и расскажу про готовые к использованию утилиты и инструменты.

В последнее время сайты и веб-приложения растут всё быстрее, а задачи, стоящие перед БД, эволюционируют. Поэтому для (успешных) проектов традиционная реляционная СУБД часто не может удовлетворить все нужды. В ответ на эту проблему возникло большое количество разнообразных решений, очень различающихся по функциональности и характеристикам. При этом они все заносятся под один большой зонтик "NoSQL", что не способствует пониманию вещей. Запутанные веб-разработчики пытаются взять текущую модную и обсуждаемую NoSQL БД и приспособить её под свои нужды, не всегда понимая, нужную ли технологию они выбрали (референс к MongoDB is Web Scale http://www.youtube.com/watch?v=b2F-DItXtZs).

Целью доклада является упорядочение хаоса в головах разработчиков.

- Обзор популярных БД и их классификация (KV store, document store, columnar, etc).
- CAP-теорема и её применение к выбору БД (где-то параметры можно настроить, где-то подпереть сбоку костылем, где-то - увы).
- Типичные примеры применения.
- Антипаттерны применения (из личного опыта и тысяч прочитанных вопросов на stackoverflow :) ).

Насколько повысится среднее время обработки одного запроса если увеличить нагрузку вдвое? Почему производительность базы данных может снизиться при росте числа клиентов? Как добиться эффективного распределения большого числа задач на весь кластер? О практике и о теории обработки очередей на которой основана практика в моём докладе.

Tarantool - отечественная Opensource NoSQL база данных.

В докладе мы обсудим:
- Какое место занимают NoSQL базы данных в highload проектах?
Почему и для чего вам стоит NoSQL решения?
Какие NoSQL решения вы можете использовать?
- Рассмотрим, что из себя представляет Tarantool 1.6 - база данных и сервер приложений в одном лице.
Какие основные особенности Tarantool как NoSQL базы данных?
Lua как встроенный язык сервера приложений.
- Посмотрим, как можно начать использовать Tarantool в своих проектах, и сделаем первые шаги.
Как установить Tarantool.
Первый запуск и основы конфигурирования.
Модель данных.
Как создавать и работать с хранилищем данных.
Как использовать пакеты tarantool.
- Узнаем об интересных модулях и фичах Tarantool
Чем полезен application server
Tarantool http
Tarantool queue
- Познакомимся с сообществом Tarantool opensource
Почему сообщество - это важно?
Чем полезны opensource проекты начинающему разработчику?

Вступление

Каждый разработчик web приложений рано или поздно сталкивается с довольно типичной проблемой: перед ним стоит задача построить фабрику по производству омнониевых торсиометров.
Фабрика производит омнониевые торсиометры очень быстро, но для калибровки прибора (как известно) необходим омноний, за которым приходится летать на Андромеду.
Пока корабль летит до Андромеды, фабрика простаивает.
Самый очевидный выход из ситуации - построить склад омнониума прямо рядом с фабрикой.

Терминология кэширования

В связи решением построить склад возникает ряд проблем:
Вырастает сложность предприятия. Нужно организовать доставку на склад и со склада, вести складской учет, и т.д.
- Cклад ограничен по объему (cache size). Слишком много омнониума привезти нельзя
- Для калибровки необходимо быстро найти образец омнониума нужной формы и породы (cache hit / miss)
- Омнониум быстро портится (freshness), а испорченным омнониумом торсиометры калибровать нельзя (stale data). Сначала нужно проверить (validation) пригодность, и выбросить просроченный омнониум со склада (invalidation)
- Иногда случается обидная ситуация - корабль прилетает раньше, чем фабрика успеет израсходовать весь омнониум. Склад переполняется, и приходится выбрасывать ещё годный омнониум, чтобы освободить место для новоприбывшего (eviction).

Выбор места для кэширования в WEB

Браузер <-> Кэш браузера <-> Сервер
Браузер <-> Кэш браузера <-> Proxy / CDN <-> Сервер
Браузер <-> Кэш браузера <-> Proxy / CDN <-> Сервер <-> Кэш(и) сервера

Выбор данных для кэширования

Кэширование эффективно только при "хороших" данных.

Бесполезно кэшировать часто изменяющиеся данные.
- Объем кэша всегда ограничен. Кэшировать нужно 20% данных, которые используются 80% времени.
- Нужно учитывать размер данных. Иногда доставка данных из кэша делает кэширование бессмысленным. Например: хранить в памяти 3Gb данных, которые вычитываются по сети, со скоростью 1Mb/s

Хорошие кандидаты для кэширования:
- Небольшие картинки: лого, аватары, пр.
- Java script / CSS / иногда HTML страницы целиком.
- Внутренние объекты бизнес-логики
- Временные данные: сессии, статистику

Кэширование на стороне бэкенда

Опять-таки, кэш можно разместить в разных местах, или сразу в нескольких

HTTP Server cache

Релевантные HTTP Headers
- Expires:
- Cache-Control:
- Etag:
- Last-Modified:
- Content-Length:
- Vary:

Прямо в коде бэкенда
- Хранить во внутренней структуре используемного ЯП (dict / map / HashTable / unordered_map / etc.)
- Использовать библиотеки (cachelot)

Отдельный кэширующий сервис

Основное преимущество - доступен сразу для нескольких приложений backend.

Пара слов о memcached

Key value storage. Expiration. Flags.

set / get / add / replace / delete

Пара слов о Redis

Структуры: String / List / Set / Hash / Sorted Sets

Почему noSQL подобные кэши - это удобно

За счет K-V структуры очень высокая скорость get / set операций.

С помощью K-V можно представить любые данные (чаще даже проще, чем в реляционных СУБД).

account:311:some.key = "Some value"

Для кэша это важно, т.к. данные, как правило, плохо структурированные, или очень разнородные.

Упрощается внутренняя структура кэша - понижается шанс ошибок, порчи данных и пр.



Использование Memcached в архитектуре бэкенда
Настройка и общие паттерны использования

Много одновременных сессий
Batch запросов
Настройка потоков memcached (-t)
Memcached как in-memory хранилище временных данных (режим консистентного хранилища -M)

Статистика

Чтение и расшифровка статистики. Как реагировать на различные показатели.


Кластеризация memcached серверов

Варианты архитектур

routing на стороне клиента (например libketama)
Brocker (например mcrouter) упрощает общую архитектуру , дает пространство для maintenance
Что такое constent hashing и для чего он нужен.

Пара слов про DHT.


Проблема консистентности данных

Chain replication

Share nothing

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

+ Обзор внутреннего устройства Hadoop и продуктов вокруг;
+ Как можно использовать для решения (спектр);
+ Как подходить к обоснованности использования даже в небольших проектах;
+ Hadoop в Badoo - история успеха;
+ Hadoop в Badoo - история проблем.

1. Вводная часть: базовые понятия и определения
1.1. Что такое “файл”
1.2. Роль файлов в современном мире, миф о ненужности файлов
1.3. Файловое хранилище АКА файловая система
1.3.1. внутреннее устройство
1.3.1.1. винтажные и журналируемые. зачем нужен журнал
1.3.1.2. плоские и иерархические
1.3.1.3. контроль доступа
1.3.2. POSIX
1.3.2.1. произвольное чтение
1.3.2.2. произвольная запись
1.3.2.3. атомарные операции
1.3.3. bells and whistles
1.3.3.1. сжатие, шифрование, дедупликация
1.3.3.2. snapshots
1.4. кеширование чтения и записи
2. HighLoad - это сеть
2.1. что вообще такое “HighLoad”, или “ведет ли кроилово к попадалову”
2.2. протоколы доступа: stateless и stateful
2.3. отказоустойчивость и ее двуличие
2.3.1. целостность данных
2.3.2. бесперебойные запись и чтение
2.4. Теорема CAP
3. Так в чем проблема?
3.1. Берем большую-пребольшую СХД и…
3.1.1. локальный кеш?!
3.1.2. конкурентная запись?!!
3.1.3. Берем OCFS2 и…
3.1.3.1. Как “падают виртуалки”?!
3.1.3.2. И почему так медленно?
3.1.4. А еще большую-пребольшую СХД довольно трудно получить в свое распоряжение
3.2. Берем CEPH/Lustre/LeoFS и…
3.2.1. Почему так медленно?!
3.2.2. Что значит “ребалансинг”?!
3.3. И немного о резервном копировании
3.3.1. Резервное копирование - это не отказоустойчивость
3.4. И снова про атомарные операции
3.5. Так почему все-таки нельзя просто сложить файлы в базу?
4. Что же делать?
4.1. В первую очередь это зависит от того, какова наша задача
4.1.1. А надо ли экономить?
4.1.2. POSIX - нужен ли он?
4.1.3. Большие файлы - нужны ли они?
4.1.4. Атомарные операции - нужны ли они?
4.1.5. Версионирование - нужно ли версионирование?
4.1.6. Насколько большим должно быть наше хранилище?
4.1.7. И собираемся ли мы удалять файлы?
4.1.8. И каков будет профиль нагрузки?
4.2. I’m feeling lucky - для некоторых сочетаний требований решение есть!
4.3. А для остальных - решения нет.
5. Так что же все-таки делать? (заключение)
5.1. искать бюджет
5.2. все-таки сложить все файлы в базу - личное мнение докладчика
5.3. написать свое
5.3.1. не так это и сложно!
5.3.2. но все же довольно сложно

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

В самом начале, когда наш проект маленький и простой, на эту задачу никто может и не обращать внимания, так как все происходит быстро и просто. Процесс деплоя состоит из 2-3 общеизвестных шагов — git pull, yii migrate, etc..., которые легко запомнить и в них сложно ошибиться.

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

В докладе:
— рассмотрим подробно вышеуказанные проблемы, с которыми неизбежно сталкиваются проекты;
— обсудим, какие решения существуют в индустрии (chef, ansible, etc), чем они отличаются, какой выбрать и в чем их задача;
— поговорим про административные вопросы, которые с этим связаны.

Мы проговорим про связь приложения и ОС, какие компоненты есть в современной ОС на примере Linux, как настройки этих компонент могут повлиять на приложение.

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

Запускаем сервер (БД, Web-сервер или что-то свое собственное) и не получаем желаемый RPS. Запускаем top и видим, что 100% выедается CPU. Что дальше, на что расходуется процессорное время? Можно ли подкрутить какие-то ручки, чтобы улучшить производительность? А если параметр CPU не высокий, то куда смотреть дальше?

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

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

Выбор "правильного" провайдера услуг дата-центров очень важен, но есть две проблемы:
1) "Все лгут" - маркетинг провайдера и реальность далеко не всегда совпадают, все провайдеры рассказывают о своих сильных сторонах и умалчивают о слабых;
2) "когда у вас в руках молоток - все вокруг превращается в гвозди" - все провайдеры услуг имеют свою специализацию и любую задачу клиента они стремятся решить так, как умеют, а не так как надо клиенту.

В своем докладе я постараюсь рассмотреть все аспекты вопроса выбора провайдера/провайдеров услуг хостинга/дата-центров.

Данный доклад ориентирован на широкую аудиторию и будет полезен всем, кому надо выбирать провайдера услуг хостинга/дата-центров для внутренних и/или внешних проектов.

В рамках доклада будут рассмотрены следующие вопросы:
1) формализация ТЗ на оказание услуг провайдерами или "а что нам надо";
2) классификация провайдеров дата-центров по спектру оказываемых услуг;
3) SLA - что это? какие SLA бывают? что подразумевают провайдеры и чего ожидаете вы в документе под названием Service Level Agreement;
4) магическое слово compliance, или что хочет государство;
5) чем отличаются одни провайдеры от других;
6) как проверить провайдера - uptime/связанность/рейтинги/спектр услуг;
7) пишем RFP - как сформулировать потребности так, чтобы потом результат не разочаровал.

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

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

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

Тезисы доклада:
1. Что такое балансировка и зачем она вообще нужна? Когда хорошо бы об этом задуматься?
2. Реализация балансировки: виды, способы, практики.
3. Методы локальной балансировки
3.1. Балансировка на канальном уровне (L2-метод)
• Используем отдельным балансировщик
• Сократим расходы, избавимся от выделенного балансировщика
• Плюсы и минусы
3.2. Балансировка на сетевом уровне (L3-метод)
• Преимущества и недостатки
4. Методы глобальной балансировки
4.1. DNS балансировка.
• DNS Round Robin
• Сильные и слабые стороны подхода
4.2. HTTP Redirect
• Механизм балансировки на основе Redirect запросов
• Плюсы и минусы метода
4.3. Балансировка на базе Anycast
• Когда Anycast – это хорошо, а когда - не очень?
5. Некоторые не менее распространенные алгоритмы балансировки
• Weighted Round Robin
• Least Connections
• Destination Hash Scheduling и Source Hash Scheduling
• Sticky Sessions
6. Балансировка должна быть типовой. Очень кратко о решениях интеграторов.
7. Как можно совмещать несколько методов балансировки с перенаправлением запросов. Наш пример.
8. Подведение итогов, выводы.

1. Мониторинг высоконагруженного проекта.
1.1. Специфика мониторинга высоконагруженного проекта: гранулярность мониторинга, надежность системы мониторинга, система оповещений.
1.2. Мониторинг и контроль распределенных систем.
1.3. Специфика организации оповещений в высоконагруженном проекте. Превентивный мониторинг.

2. Резервирование и резервное копирование в высоконагруженном проекте.
2.1. Резервирование и резервное копирование - разные вещи.
2.2. Резервирование: на уровне сервера, дата-центра, географически распределенных площадок.
2.1. Организация резервного копирования. Сохранность часто обновляемых данных.

3. Обслуживание высоконагруженного проекта.
3.1. Организация поддержки высоконагруженного проекта: опыт, специфика работы.
3.2. Организация дежурств, эскалация оповещений.
3.3. Аварии в высоконагруженных проектах: примеры из жизни.