- AviaSales - метапоисковик авиабилетов. Для обработки одного поискового запроса наш сервис опрашивает от одного до четырех десятков внешних сервисов и обрабатывает их ответы. Ответ одного сервиса - это от 200 до 2000 килобайт XML/JSON. От скорости обработки этих данных напрямую зависит прибыль компании.
- Для эффективной работы с API удалённых сервисов и быстрой параллельной обработки данных был разработан движок "Ясень".
Среди требований, предъявляемых к системе:
- высокая отказоустойчивость;
- лёгкая масштабируемость;
- "горячее" развертывание (deploy);
- простота конфигурирования;
- низкий порог вхождения для программистов

В рамках обработки одного поискового запроса необходимо отослать запросы и обработать результаты от большого набора внешних API, эти запросы необходимо выполнять параллельно. Кроме параллельного исполнения модулей, требуется последовательное исполнение. Часть обработки данных также можно осуществлять уже после отдачи данных пользователю - это отложенное исполнение. Из трёх названных конструкций (parallel/sequential/delayed) состоит DSL, используемый в "Ясене". Из независимых и изолированных модулей (юнитов) с помощью DSL строится workflow. Типичный workflow состоит из 10-100 юнитов, объединённых в последовательные, параллельные и отложенные цепочки.

Необходимость быстро реагировать на отзывы пользователей и показатели работы внешних сервисов влияет на требования к простоте конфигурирования системы. Такие вещи,как изменения наценки на билеты для разных поставщиков, регулирование набора агентств для поиска в зависимости от локали пользователя, источника траффика, географического положения пользователя и многих других факторов, необходимо делать в runtime и без помощи технических специалистов. Для решения этой проблемы workflow в "Ясене" строится из юнитов, каждый из которых имеет URL для получения текущей конфигурации юнита и её обновления. Для упрощения разработки юнитов и их тестирования кроме URL-конфигурирования каждый юнит может быть вызван через HTTP. В взаимодействие с юнитами происходит по HTTP, данные кодируем в json.

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

Для разных типов данных были разработаны разные техники обеспечения отказоустойчивости.

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

Когда в базе 1.3 млн. контактов компаний по всей России, неудивительно, что её периодически кто-то пытается распарсить. Здесь возникает проблема: как отличить добропорядочных пользователей от ботов?

В своем докладе мы расскажем, как эволюционировала наша система защиты от парсинга. Мы рассмотрим следующие этапы и подходы:
— особая локация в Nginx;
— PHP + Redis (счетчик по ключу);
— Nginx + Redis (конфигурационный файл);
— Nginx + Lua + Redis : усложнение логики защиты без снижения скорости ответа.

Также мы собираемся рассказать про язык Lua в связке с Nginx не только в случае защиты от парсинга, но и в других частых кейсах, когда не хочется «поднимать» тяжёлое основное приложение.

Справочный API 2ГИС — крупнейший REST API в Рунете.

Более 300 партнёров, среди которых 2ГИС-Онлайн, Mail.ru, НГС, Е1.ru. Месячная аудитория — 14 млн.
Сервис предоставляет информацию об 1.3 млн. фирм и 1.8 млн. POI в 200 городах России, Падуе (Италия), нескольких городах в Украине и Казахстане.

- Описание основных требований к системе и high-level архитектура.
- Причины миграции с In-Memory Data Grid на Cassandra.
- Описание шагов, которые помогли улучшить производительность (TPS и/или latency).
- Описание того, что не привело к существенному улучшению, и объяснение, почему так вышло.

Серверы и СХД-системы с RAID как пережиток прошлого (сложность поддержки инфраструктур, большие инженерные команды, высокие требования к техническим специалистам).

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

Практически все используют процессоры X86, однотипную память, жесткие диски, внешние СХД.
Множество стандартных "узких мест" и ограничителей.

С ростом объемов данных (говоря о сотнях терабайт на логическую группу) потеря данных на RAID6-массиве гарантирована менее чем за год.

Подходы таких компаний как Google, Facebook и Amazon уникальны и лишены практически всех упомянутых проблем.

Нет RAID и СХД, но используется "dispersed data"; нет "серверов" в традиционном понимании, но есть унифицированные модули, коммутация Ethernet вместо построения FC SAN-сетей, вся логика в ПО, но не специализированных чипсетах.

Результат: уникальная производительность и надежность.

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

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

Максимальное использование существующих решений и технологий (Linux, Cassandra, Apache ZooKeeper, python, множество других), ориентация на flash-память, "заточенность" под частные облака (KVM, VMware, HyperV).

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

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

Сейчас мы живем в мире, который решительно движется в сторону «облаков». Даже используя физическое оборудование, мы концентрируемся на более быстром развертывании и использовании образов для этих машин. Но установка программного обеспечения и управление серверами во множестве сред (разработки, тестирования, отладки (staging), продакшн) – это устаревшая практика, которую начали применять еще 10 лет назад. Такие инструменты, как Vagrant и Packer, предлагают новый подход к этим проблемам.

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

Сколько времени вам нужно, чтобы «поднять» новый веб-сервер? 2 минуты? 5 минут? Что если я скажу вам, что это можно сделать за 15 секунд без каких-либо побочных эффектов? Packer позволяет легко сделать это. Насколько похожи ваши среда разработки и продакшн-среда? Используете ли вы одни и те же скрипты операций для установки обеих сред? Работает ли это на Mac, Windows и Linux? С Vagrant это легко.

В ходе своего доклада я продемонстрирую, как можно использовать Vagrant и Packer для создания стабильных портируемых сред для разработки, тестирования, отладки и продакшна. Эти образы будут работать в нескольких «облаках» (таких, как VirtualBox, VMware, AWS) и даже на физическом оборудовании.

Компания Ivinco, которую я представляю, плотно сотрудничает со Sphinx team, и по нашему заказу они разработали несколько функционалов, в том числе Sphinx HA, о котором будет идти речь в презентации.

Краткие тезисы
1. Предыстория.

2. Архитектура.
- Обычный Sphinx кластер.
- Sphinx HA кластер, варианты реализации, их преимущества и недостатки.
- Масштабирование кластера, перебалансировка.

3. Обработка данных:
- заливка индексируемых данных в MySQL DB;
- индексация и синхронизация индексов;
- апдейт индексов;

4. Обеспечение производительности и отказоустойчивости:
- увеличение пропускной способности за счет HA;
- контроль производительности и критических параметров кластера;

5. Перспективные разработки:
- система дистрибуции индексов;
- контроль потребления ресурсов;
- RLP.

"— Военный, а нам оружие дадут?
— Триста тридцать пять…"
(c) ДМБ


1. Нам нужно реализовать multimaster-репликацию.
2. Зачем нам нужно делать backup, у нас же есть slave?
3. Мы создали индекс - почему он не используется?
4. "Мне говорили, что InnoDB можно настроить так, что она будет быстрее, чем Oracle..."
5. Можно ли использовать join?
6. "Нам нужно выводить 20 очень важных count(*) на главной странице..."
7. “Ну, может, как-нибудь можно?”
8. “Можно ли откатить commit?" "А вот в git можно...”
9. “Давайте сделаем schemaless (или EAV) - это позволит нам уйти от проблемы добавления колонок?”
10. “SQL - это медленно и архаично, давайте будем читать напрямую из таблицы?”

Disqus (http://disqus.com) — это система комментирования страниц. 75% сайтов в мире, работающих с комментариями пользователей, используют эту систему. Чтобы успешно работать с такими огромными объёмами данных, нам приходится использовать много различных систем хранения и обработки данных, среди которых в первую очередь стоит отметить Memcached, Cassandra, Redis, Storm и, конечно, PostgreSQL, занимающий центральное место. Прослушав доклад, вы узнаете, как успешно содержать подобный «зоопарк», познакомитесь с «упаковщиками чужеродных данных» в PostgreSQL и научитесь эффективно работать с ними.

Доклад про паузы при сборке мусора уже был на одной из прошлых конференций HighLoad++.
Паузы stop-the-world являются неотъемлемым атрибутом автоматического управления памятью.
Или всё-таки их можно избежать? – Можно!
Алгоритмы, не требующие пауз для управления памятью, существуют. Существуют и реальные JVM, которые их реализуют.

Содержание доклада
- Принципы автоматического управления памятью (сборки мусора).
- "Метроном" - классический алгоритм сборки мусора без пауз.
- С4 - алгоритм сборки мусора Zing JVM (Azul Systems).
- Особенности эффективной реализации на x86-архитектуре.
- Дополнительные источники проблем: слабые ссылки, фрагментация и прочее.

Появились базы данных, оптимизированные для операций записи, и флэш-память. Переход от использования дисковой памяти к флэш-памяти обычно несложен. Изменение реализации базы данных предполагает гораздо большую неопределенность при переходе от понятного алгоритма «B+ дерево», используемого в InnoDB, к оптимизированному для операций записи алгоритму вроде LSM-дерева, применяемого в WiredTiger, LevelDB и HBase. Я сравнивал их на бумаге и используя работающие реализации. В докладе я расскажу о своих выводах и представлю фреймворк, который я разработал для описания и сравнения этих альтернатив. Акцент делался на производительности хранилищ.

Лемматизация, разбиение составных слов, JSON-атрибуты, вложенные выборки, быстрый поиск фраз, поиск по маскам, куча новых сигналов ранжирования, ALTER TABLE, OPTIMIZE INDEX, расширение GROUP <N> BY,
оптимизации для сверхбольших схем, SHOW PLAN, SHOW PROFILE и еще несколько десятков новых фич (но это уже списком!) поискового сервера Sphinx, которые мы доделали и выкатили в 2013 году.

Обеспечение достойной производительности высокоуровневого языка с динамической типизацией - непростая задача. Just-in-time (JIT) компиляция - динамическая генерация машинного кода с учетом информации, собранной во время выполнения приложения - ключевой элемент производительности виртуальной машины (будь то Java, .NET или даже JavaScript). JIT-компилятор, в свою очередь, должен иметь впечатляющий набор трюков и оптимизаций, что бы компенсировать "динамизм" языка.

В докладе речь пойдет о HotSpot JVM (бесплатной JVM от Oracle) и её архитекте JIT компиляции. В частности, будут освещены такие темы, как:
- принцип много уровневой компиляции;
- подмена выполняемого кода "на лету";
- девиртуализация вызовов;
- "escape analysis" и "scalar replacement";
- взаимодействие системы управления памятью ("сборка мусора") и компилятора.

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

Содержание доклада следующее.

1) Нужно ли вам изменять бизнес-процессы в компании?

2) Человеческий фактор как основная проблема при изменении процесса.

3) Основные схемы разработки программного обеспечения в системе контроля версий. Преимущества и недостатки.

4) Основные этапы перехода к новому рабочему процессу (workflow). Где недопустима ошибка?

5) Интеграция вспомогательных систем и автоматизация процесса. Основные проблемы.

6) Continuous integration и Continuous delivery. Время и бизнес против команды разработки и тестирования.

7) Почему нужно что-то менять, несмотря на все проблемы?

В данном докладе я рассмотрю на примере компании Badoo как основные технические проблемы, так и проблемы мотивации персонала.

Несмотря на то, что DNS является незаметным для многих сервисом, он также является краеугольным камнем практически всего Интернета. В случае возникновения проблем в этой системе у пользователей не будет привычной возможности получить доступ к требуемым сайтам. 2013 год показал, насколько уязвимо это место: имели место DDoS-атаки на DNS hosting-компаний, подмены записей с целью перенаправления клиентов - все это влечет за собой огромные потери.

В связи с этим устойчивость и производительность DNS серверов на данный момент является важной темой для исследования. Сейчас на рынке представлено не менее 20 DNS-серверов на любой вкус - от простых "поделок" до больших систем, которые включают в себя DNS-сервер как одну из компонентов. При этом грамотная и тонкая настройка сервера является острой темой ввиду того, что при не совсем корректных настройках можно не только позволить злоумышленнику внести свои исправления в реальные данные, но и невольно поучаствовать в DDoS-атаке.

В докладе рассматриваются несколько DNS-серверов - с точки зрения производительности при одинаковых исходных данных. Оценка производится не только с учетом наилучшего RPS, но и с учетом возможности снижения нагрузки на сервер за счет подбора соответствующих настроек. Также показаны интересные случаи некорректного поведения серверов при определенных запросах. Рассматриваемые DNS-серверы: Knot-1.2, Knot-1.3, NSD-3, NSD-4, pdnsd, PowerDNS, TinyDNS, Unbound, Yadifa. Данные серверы были выбраны исходя из мнения сообщества, качества исходного кода и количества установок.

Серверы сравниваются с точки зрения возможностей защиты от известных типов атак: DNS Cache Poisoning, DNS Amplification, etc. Основная проблема DNS состоит в работе по протоколу UDP, который практически ничего не гарантирует. При этом мы встаем перед выбором, стоит ли вообще отвечать на пришедший запрос (если стоит, то как и на что) и каким образом сделать это наиболее быстро.

С точки зрения проблематики DDoS, DNS дает злоумышленнику возможность получить плечо атаки в диапазоне 30-60 (и даже больше). На приходящий небольшой пакет DNS-сервер может ответить гораздо бОльшим. А соединив это со spoofed IP жертвы, мы сразу получаем возможность создать атаку на сетевой уровень практически без затрат.

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

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

Является ли выделение памяти «узким местом» вашего приложения? Если это так, известно ли вам об этом? Если вам это известно, знаете ли вы, как это исправить?

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

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

Надеюсь, что к концу моего выступления вы сможете ответить «да» на вопросы, которые были приведены в начале тезисов моего доклада.

Мы (компания "Тамтэк") занимались сравнительным тестированием производительности и отказоустойчивости четырех NoSQL-решений: Aerospike, Couchbase, MongoDB, Cassandra. Особенности исследования: включение в сравнение малоизвестной проприетарной key-value БД Aerospike, тестирование производительности на SSD.

Производительность БД измерялась с использованием YCSB (Yahoo! Cloud Service Benchmark). Нам понадобилось внести изменения в YCSB: добавить поддержку Aerospike, исправить драйверы для MongoDB, написать обертку для параллельного запуска YCSB-тестов на множестве клиентов и визуализации полученных результатов. Поддержка множества клиентов понадобилась, поскольку было обнаружено, что полная загрузка кластера из 4 узлов (по 4 ядра на узле) возможна только с 8 клиентских машин (256 потоков).

Тесты показали, что на данных в оперативной памяти key-value БД показывают производительность до миллиона операций в секунду. Более функциональные document-oriented и column-family БД показывают на порядок меньшую производительность. Задержки (latency) у самых быстрых БД не превышают 1 мс (на 1Gb Ethernet), у самых медленных среднее значение задержки не превышает 10 мс.

Тестирование отказоустойчивости производилось путем принудительного отключения (kill -9) и последующего включения одного из узлов кластера, измерялись время простоя (как при отключении, так и при включении узла) и деградация производительности. Различные базы данных продемонстрировали весьма разнообразное поведение, заложенное в их архитектуру.

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

Многие компании сталкиваются с необходимостью хранить и анализировать большие объемы данных (порядка терабайт и более). Рано или поздно системы хранения перерастают возможности отдельного сервера, и перед разработчиками и архитекторами встает проблема выбора распределенной системы, а также стандартные вопросы вроде производительности, масштабируемости, отказоустойчивости и т. д. Существует несколько подходов к созданию распределенных систем хранения данных, которые по-разному выполняют перечисленные требования. Однако не все из них хорошо подходят для анализа больших объемов данных. Универсальных инструментов не существует.

В докладе будут рассмотрены специфические требования к распределенным системам хранения данных, выведенные из примеров анализа, в частности, многомерного анализа данных. Из этих требований следуют определенные технические трудности, которые можно преодолевать по-разному. Я расскажу о способах их преодоления на примерах разных систем, включая специализированную аналитическую RDBMS Vertica, которой будет уделено основное внимание (другие сравниваемые распределенные системы: key-value Dynamo-like, ShardQuery, Hadoop, HadApt, MemSQL, Paraccel). Наша компания с успехом использует Vertica уже три года в качестве основной платформы для анализа эффективности и оптимизации работы рекламной сети, обрабатывая и анализируя до 10 ТБ "сырых" данных или 3.5-4 миллиарда событий в сутки (см. мой прошлогодний доклад: http://www.highload.ru/2012/abstracts/430.html). Мы попробовали разные решения, поэтому очень хорошо понимаем не только преимущества, но и компромиссы, с которыми приходиться мириться. Архитектурные решения Vertica очень хорошо продуманы и подходят именно для решения задач распределенного анализа больших данных. Понимание границ их применимости, преимуществ и недостатков будет полезно не только пользователям Vertica, но и пользователям и разработчикам других распределенных систем.

Мой доклад не представит какую-то особенную технологию или волшебный алгоритм. Речь пойдет о том, как чуть больше, чем за квартал, совсем не большая команда перезапустила работающий в режиме 24/7 совсем не маленький видео-сервис на "Одноклассниках" на написанной с нуля платформе, развернутой на парке из более чем 200 серверов, распределенных между несколькими центрами обработки данных.

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

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

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

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

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

В качестве примера реализации будет рассмотрен Kale stack (skyline, oculus) от Etsy, это OpenSource-инструмент для обнаружения и корреляции аномалий.

Подведем итоги первых трех кварталов 2013 года.
Расскажем о том, по каким показателям этот год оказался поистине выдающимся.
Рассмотрим самые популярные методики проведения DDoS-атак, механику их работы и возможные стратегии противодействия им.
Поговорим о том, как СДЕЛАТЬ МИР ЛУЧШЕ И ДОБРЕЕ.
Заглянем в будущее.

Badoo — крупнейшая в мире социальная сеть для знакомств с новыми людьми. У нас тысячи серверов в двух дата-центрах, и какие-то из них постоянно выходят из строя. Наш кластер машин состоит из различных групп: машины для обслуживания веб-запросов, серверы баз данных, хранилище фотографий, серверы для выполнения cron-заданий, машины для C/C++ сервисов и некоторые другие. Для обработки заданий по расписанию мы используем так называемые «скриптовые» машины, на которых запускаются PHP-скрипты в CLI, которые выполняют нужные действия. До недавнего момента мы использовали обычный cron для запуска скриптов по расписанию, а также самописную утилиту для того, чтобы автоматизировать процесс прописывания нужных строчек в cron. Тем не менее, разработчикам приходилось по каким-то критериям выбирать одну или несколько машин, на которых будут запускаться эти скрипты, и они жестко «привязывались» к конкретным серверам. Если какая-то из машин «падала», мы должны были вручную переносить с неё скрипты на другие машины. Чтобы равномерно распределять нагрузку по серверам, а также обеспечивать автоматическое восстановление в случае отказа (failover), мы решили сделать свое «облако», которое призвано решить эти проблемы. Доклад посвящен процессу создания «облака», а также первым результатам, которые мы получили в связи с его использованием.

Краткий план доклада

- Требования к «облаку».

- Существующие решения.

- Распределение нагрузки по машинам.

- Обработка сбоев оборудования.

- Мониторинг «облака».

Мы взяли типичное веб-приложение на базе PHP/MySQL (движок социальной сети Livestreet) и убрали из него все медленное и плохое:
- постоянный маршаллинг данных PHP - MySQL - Memcached;
- процессы инициализации фреймворка при каждом вызове;
- кэши и механизмы их инвалидации;
- нормализованную структуру данных и множество операций JOIN таблиц;
- обращения к ФС, в том числе со стороны БД;
- кривые, опостылевшие и плохо поддающиеся JIT-компиляции языки программирования.

Получилось такое решение:
- NodeJS, Redis и вся логика на Lua внутри Redis (как хранимые процедуры).
- NodeJS получает JSON из Redis и без преобразований отправляет его на клиента, где он попадает в MVC фреймворк типа Ember.JS.
- Скорость выдачи страниц выросла в 30-100 раз.
- Появилась возможность push-уведомлений клиента через pub/sub в Redis.
Наш опыт
- Мы сделали это для проекта на Livestreet с 3k топиков, 20k регистраций и 10k комментариев.
- Библиотека Lua-скриптов для работы со связанными объектами в Redis будет выложена в свободный доступ на GitHub до начала конференции.

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

Различные back-end сервисы Twitter слаженно работают, обслуживая сотни тысяч запросов в секунду от миллионов пользователей, подключающихся к ним параллельно. Это стало возможным благодаря Finagle – расширяемой RPC-системе с открытым исходным кодом для JVM, построенной на фреймворке Netty.

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

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

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

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


- Автоматическая сборка документации для сторонних разработчиков:

-- web-консоль.

Генерируемая консоль в сервисе apigee.com на основе phpdoc-документации c помощью ApiGen, в которой разработчик может экспериментировать с API:

-- описание структур;

-- описание сервисов с http-роутингом.

- Генерируемый роутинг на основе документации (phpdoc).

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

- Динамическое построение форм с состояниями (FormBuilder).

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


- Функциональное тестирование Behat.

Тестирование API на естественном языке.


- Версионность структур.

Как мягко изменять протокол API, не ломая production-клиенты?

Как многие слышали, nginx - это такой быстрый (некоторые даже говорят, что очень быстрый) http-сервер. Зачастую знания о нем этим и ограничиваются.
Действительно, если нужен быстрый сервер - берём nginx, другие варианты, если они и были, можно смело вычёркивать.

Так ли это? Или, возможно, есть нюансы?

Нюансы есть. Сервер ещё быстрее и ещё эффективнее - всегда к вашим услугам. И это... nginx! Просто сотрите пыль^W^W... возьмите свежую версию!

Что нового появилось в nginx за последнее время, и для чего всё это нужно? В докладе - рассказ про основные новые функции, появившиеся в nginx 1.1.x ... 1.5.x.

1.1.x: улучшения cache loader, поддержка криптографии на эллиптических кривых (привет, NSA!), оптимизация потребления памяти SSL-соединениями, применение нескольких limit_conn и limit_req одновременно, MP4 streaming "в коробке", proxy_cache_lock, disable_symlinks для shared-хостинга, а
также поддержка PCRE JIT для тех, кто любит регулярные выражения.

1.3.x: улучшения в поддержке IPv6, балансировщик upstream-серверов least_conn, поддержка ETag (а значит, докачка в IE9+), gunzip и возможность хранить ресурсы сжатыми, OCSP Stapling, SPDY, поддержка
передачи тела запроса в виде chunks, проксирование WebSockets и возможность писать логи уже сжатыми.

1.5.x (still counting): поддержка EPOLLRDHUP и использование O_PATH для disable_symlinks на Linux'е, несколько директив error_log одновременно, SMTP pipelining, очередные оптимизации SSL,
proxy_ssl_protocols и proxy_ssl_ciphers, модуль auth request, небуферизированная работа с FastCGI-бэкендами (fastcgi_buffering) для тех, кому нужен streaming ответов.

Всё, что вы хотели знать о новой функциональности в nginx, но боялись спросить!

Мобильные уведомления крайне важны для создания персонализованных мобильных приложений, которыми хочется пользоваться постоянно. Приглашаем вас посмотреть, как высоконагруженные мобильные решения типа Bing News решают задачу одновременной доставки мобильных уведомлений миллионам пользователей смартфонов iOS, Android, и Windows Phone, используя Windows Azure Notification Hubs. Мы рассмотрим архитектуру этих решений, а также архитектуру самих Notification Hubs, в том числе выполнение параллельной доставки с маленькой задержкой, "богатым" pub-sub-роутингом, сегментированием аудитории и персонализацией уведомлений с поддержкой нескольких платформ.

1. Введение.
1.1. Про AdRiver.
1.2. Определение события как информационной единицы системы.
1.3. Условное разделение системы на две части: realtime-часть отвечает за выборку баннеров и порождает события, а статистическая подсистема отвечает за их хранение и обработку.
1.4. Обоснование необходимости хранения событий и несколько примеров аналитической информации, которая предоставляется клиентам.
1.5. Обоснование необходимости обеспечения консистентности данных - это основное бизнес-требование к подсистеме хранения. Рассказ про далекие времена, когда события хранились в текстовых логах и регулярно приходилось объяснять клиентам природу расхождений цифр в различных отчетах.

2. Постановка задачи и требования.
2.1. Описание рабочих объемов данных: 4 млрд событий в сутки или ~500 Гб сериализованных данных в сутки. Минимальный период хранения - 1 год.
2.2. Обеспечение консистентности данных.
2.3. Обеспечение произвольного доступа к данным.
2.4. Обеспечение надежности, отказоустойчивости и масштабируемости.

3. Реализация и ключевые решения.
3.1. Сравнительный анализ предметной области. Эксперименты с map/reduce фреймворками и СУБД. Обоснование разработки собственной системы хранения.
3.2. Общее описание разработанной системы History.
3.3. Обоснование важности алгоритмической оптимизации и отказа от "лишней" логики в высоконагруженных серверах.
3.3.1. Наша аксиома проектирования: каждый компонент должен ХОРОШО выполнять одну функцию, вместо того, чтобы ПЛОХО предоставлять множество.
3.3.2. Сервер, предоставляющий произвольный доступ к данным, абстрагирован от самих данных и не производит никакой их обработки. Это позволяет уменьшить нагрузку на процессор при обслуживании множественных запросов к данным.
3.4. Краткое описание используемых механизмов сериализации. Аналогия c Google Protobuf.
3.5. Описание используемого механизма индексации данных, который позволяет идентифицировать любое событие системы. Это решение является ключевым к обеспечению консистентности.
3.6. Потоковое хранение данных и страничная организация - панацея в решении проблем с оперативной памятью. Предпочтительнее "упереться" в производительность дисковой подсистемы или процессора, чем в "Out of Memory", потому что в первом случае произойдет лишь снижение производительности системы, а во втором - отказ в обслуживании.
3.7. Сжатие данных, страничная организация хранения и абстрагирование сервера от самих данных позволяют любой нашей ноде отдавать гигабит информации в секунду, обслуживая 200 клиентов и обрабатывая 1000 файлов. Загрузка процессора, диска и памяти в этот момент не больше минимальной. Сервер отдает клиенту пожатые страницы данных, которые клиент должен распаковать и обработать перед тем как запросить следующую порцию. За это время сервер успевает подготовить следующую порцию данных и обслужить остальных клиентов.

4. Ремарки к реализации.
4.1. Однажды мы нарушили собственную аксиому проектирования и нагрузили сервер оптимизацией чтения данных (группировка по ключам). В результате "открылся ящик Пандоры" - теперь при ошибках в конфигурации система может "закопаться" в io wait.
4.2. Работа с диском производится асинхронно посредством POSIX AIO. В планах осуществить переход на kernel AIO и сравнить эксплуатационные характеристики.

5. Выводы и перспективы.
5.1. Задача решена, все довольны.
5.2. Подведение итога для эксплуатационных характеристик системы: год данных - 200Тб, параллельное обслуживание 1000 клиентов, суммарный исходящий трафик подсистемы - 20Гбит/сек. Оценка стоимости.
5.3. Краткий обзор инструментов аналитики, построенных на базе History. Размышления на тему того, что вся "лишняя" логика, от которой отказались в п.3.3., ушла на более высокие уровни.
5.4. Требуется существенное увеличение скорости получения данных. Описание способов реализации этого требования.
5.5. Требуется уменьшение задержки в работе (latency) системы без потери консистентности данных.

В докладе будет представлен обзор архитектуры многоцелевой DPI-платформы, на основе которой могут строиться как "шпионские" приложения класса СОРМ/PRISM, так и коммерческие системы PCEF/TDF (Traffic Shaping), безопасного Интернета (интеллектуальная фильтрация содержимого), таргетирования рекламы и т. д. К особенностям рассматриваемого решения можно отнести мультитерабитное масштабирование, способ балансировки, обработку "роем" (Swarm Intelligence) и аварийного восстановления (failover) посредством репликации конечных автоматов.

Roadmap:
- offtopic: кому и зачем нужен DPI?
- offtopic: законность и морально-этические вопросы.
- на какую "луну" нужно сесть, что мы хотим сделать?
- распределение трафика за счет использования коммутаторов и MAC rewrite.
- роевой интеллект (Swarm Intellegence) для управления балансировкой и обработкой данных.
- репликация конечных автоматов (виртуальных микромашин).
- распределенное "Табло" как оперативное хранилище с элементами key-value и eventual consistency, lockfree в shared memory.
- транспортный фасад, унифицирующий DPDK, netmap, Infiniband (RDMA), 0mq и zerocopy и lockfree обмен через shared memory.
- latency и throughput, асинхронное принятие решений.

Better the devil you know than the devil you don't - будьте готовы к знакомству ;-)

1. Зачем: обратная совместимость как конкурентное преимущество.
2. Как проектировать архитектуру так, чтобы минимизировать риски нарушения обратной совместимости.
3. Полтора приёма безопасного рефакторинга.

База данных должна работать быстро. Она непременно должна работать быстро - всегда. В реальной жизни это, к сожалению, достижимо далеко не всегда.

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

- Как узнать, действительно ли MySQL ограничивает производительность нашего приложения?
- Какие факторы влияют на производительность?
- Как правильно тестировать производительность MySQL и на какие метрики смотреть?
- Как определить, какие запросы создают проблемы?
- Как увеличить производительность MySQL?
- Как можно предсказать и спланировать производительность MySQL?

В своем докладе мы рассмотрим архитектуру сервиса и основные инфраструктурные процессы.
Архитектура: Yii-фреймворк и компоненты, PgSQL, Sphinx, С++-демоны для многокритериального поиска.
Развертывание: серверы (Новосибирск, Москва, Амстердам), Phing, Chef.
Мониторинг: Zabbix API, Pinba + утилита профилирования методов API, Graylog.
Кеширование: Nginx + Lua, Redis, APC, шардинг кеша и инвалидация.

Также мы расскажем, как нам удаётся стабильно делать релизы каждый вторник и обновлять данные по всем городам каждый день. И многое другое…

Справочный API 2ГИС — крупнейший REST API в Рунете.

Более 300 партнёров, среди которых 2ГИС-Онлайн, Mail.ru, НГС, Е1.ru. Месячная аудитория — 14 млн.
Сервис предоставляет информацию об 1.3 млн. фирм и 1.8 млн. POI в 200 городах России, Падуе (Италия), нескольких городах в Украине и Казахстане.

Сравнение распределенных файловых систем
В рамках этого выступления я продемонстрирую различия в производительности следующих файловых систем:
GlusterFS
XtremeFS
FhgFS
Ceph

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

Всем известно, что для оптимизации запросов в MariaDB/MySQL надо использовать индексы. Индексы обеспечивают быстрый доступ к данным, индексы предоставляют статистику. Конечно, порой поддержание индексов в рабочем состоянии заметно замедляет работу, но что делать?

Оптимизатор запросов в MariaDB 10.0 поддерживает статистику, независимую от движков хранения данных. Это, во-первых, означает, что он может собирать и использовать статистику по всем таблицам во всех движках - одинаково и независимо от возможностей конкретных движков. Но самое главное - он может собирать данные по неиндексированным колонкам! И не только одно число - кардинальность - как для индексов, но и гистограммы, точно описывающие распределение значений в колонке!

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

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

На производительность СУБД, помимо очевидных «железячных» факторов, влияют и такие факторы, как структуры, в которых хранятся данные, количество данных, виды запросов, их количество и степень конкурентности. Индексы в базах данных часто рассматриваются как палочка-выручалочка, которая помогает вырваться вперед в непрерывной гонке за производительностью.

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

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

В "Одноклассниках" более 1 млн. активных групп, в которых происходит более 700 млн. действий в день. Мы высчитываем разные уникальные комбинации для администраторов групп по разным периодам и с разной частотой. Например, такие: группа, пол, возраст, активность по периодам – за час, за текущие 24 часа, за последние 365 дней. В случае подсчета уникальных комбинаций за 365 дней нам приходится обрабатывать более 200 млрд. записей каждый день.

Эти подсчеты происходят на паре серверов MS SQL 2012 AlwaysOnAvailabilityGroup и одном MS Windows 2008 R2 сервере c .Net 4.0. В этом докладе речь пойдет о том, как мы построили эту систему и как решали проблемы, с которыми пришлось столкнуться.

Многие производители систем хранения данных предлагают простые wizard-подобные системы для перевода вашего приложения на свою технологию. Однако, когда клиенты спрашивают нас о миграции с одной базы данных на другую, мы всегда начинаем объяснять, насколько этот процесс непрост и уникален в каждом конкретном случае. Прочитав хорошую книжку, можно получить представление об эксплуатации той или иной базы данных или базовые знания об устройстве веб-сервера. Но по книжкам нельзя научиться планировать миграцию одного из ключевых компонентов системы - слоя работы с данными - с одной технологии на другую. Да и нет таких книжек.

В этом докладе мы хотим рассказать об уникальном опыте одного из наших клиентов - 404 Group. В их случае миграция была фактически поставлена на поток: за последние несколько лет целый ряд независимых проектов был успешно перенесен на PostgreSQL c различных технологий хранения данных. На людей, предлагающих заменить систему хранения данных, часто смотрят как на профессиональных революционеров. Они проявляют и определенный фанатизм, и стремление разрушить “весь мир насилья до основанья, а затем...”, и (часто) нежелание работать в команде, и (иногда) неумение эволюционно развивать систему. Как избежать подобных крайностей? Как правильно оценить необходимость миграции, возможный выигрыш и возможные затраты? Как провести миграцию с минимальным ущербом для бизнеса? Мы ответим на эти вопросы и постараемся представить несколько точек зрения на них.

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

Например, вы разработчик и точно знаете, что для оптимального хранения данных нужно выполнить миграцию с MySQL или PostgreSQL, или Oracle, или HBase на HandlerSocket или DB2 z/OS, или MongoDB, или вообще написать “свое простое хранилище“ (tm). О чем вам нужно подумать, прежде чем идти к руководству, и как нужно аргументировать свое предложение?

Другая ситуация: вы - технический руководитель. К вам ежедневно приходят разработчики и, сверкая глазами, предлагают сделать "как у Facebook" или "как у Вконтакте", или “как нам рассказывали в универе”. Какими соображениями руководствоваться, принимая решение? С чего начинать, если предлагают настолько новую технологию, что сами вы с ней еще не знакомы?

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

Требования, предъявляемые к поиску по почте, отличаются от тех, которые обычно предъявляют к "большим" поисковым системам. Это становится причиной применения совершенно других, нестандартных технологических решений. В докладе я расскажу про устройство полнотекстового поиска в Почте Mail.Ru.

Основные темы, которых мы коснемся:
– Чем поиск по почте отличается от «большого» веб-поиска? Данные не хранятся в одном большом индексе, для каждого почтового ящика индекс свой: пополнять «большой» индекс – это фактически постоянно держать его в памяти, а это – дорого. Также стоит отметить, что почта – вещь интимная, и допустить «смешивание» данных (например, из-за ошибки разработчика) нельзя. Кроме того, для поиска по почте характерны более серьезные требования к полноте поисковой выдачи. Недопустимо, чтобы пропало даже одно письмо (баг с потерей письма всегда ставится в блокирующем приоритете).
– Нерентабельность кеширования индексов. Обычно по почте пользователи ищут не более, чем по 2 запроса подряд. Держать их индекс в памяти долгое время – дорого. Поэтому индекс устроен таким образом, что необходимую информацию из него можно прочитать с диска в минимальное время (2-3 обращения к диску, целиком индекс никогда не читается, лишь его малая часть).
– Токенизация – разбиение текстов на отдельные слова. Рассмотрим алгоритм и причины его выбора.
– Процесс пополнения индекса с минимальными затратами и основания для перестройки индексов. Индекс должен обновляться сразу, как только произошли изменения. Столь частые изменения индекса вызывают повышенную нагрузку на диск (приходится переписывать файл с индексом целиком, т.к. данные в нем – сортированные). Чтобы этого избежать, свежие данные храним в несортированном виде (в виде лога транзакций), по которому осуществляем последовательный поиск. Добавление информации в этот лог – одна операция записи в конец файла. Перестраивается индекс тогда, когда скорость поиска становится ниже заданного порога.
– Рассмотрим сам процесс поиска по индексу и последующие операции над полученной выборкой: применение фильтров, ранжирование (в отличие от «большого» web-поиска, в поиске по почте ранжирование тривиально – это всего лишь сортировка по дате), «подсветка» найденных слов в результате.
– Строение индекса саджестов (поисковых подсказок), обоснование его оптимальности (максимальная скорость получения результата при разумном размере индекса), а также сам алгоритм получения выборки саджестов.
– Поговорим об отказоустойчивости и об измерении качества поиска.

select(2) и poll(2) - медленные, epoll(7) - быстрый. Чтобы решить задачу c 10k запросов, мы используем потоки, мультиплексирование и многоядерные серверы. Но что будет, если эти 10 тыс. запросов придут одновременно (например, случится DDoS)? Как быстро сервер установит все эти соединения и обработает запросы? Сколько пакетов в секунду держат обычные сокеты на одном процессорном ядре?

В докладе будет рассказано

* о том, как пакет в Linux попадает с сетевого адаптера в TCP-сокет процесса;

* о том, как работает установление новых соединений, мультиплексирование и чтение из сокетов;

* о том, как ускорить прикладной сервер (оптимизация accept(), MSI-X и RPS/RFS, GRO);

* о том, что этого недостаточно - можно быстрее: как работает Oracle Reliable Datagram Sockets?

* О том, что можно делать все еще быстрее: переход к полностью синхронным сокетам (не путать с блокируемым вводом-выводом).

История создания и причины успеха MySQL, рассказ о росте этой СУБД до момента продажи компании Sun, которую впоследствии купила Oracle.

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

В данном выступлении также будет сказано о вызовах, с которыми нам пришлось столкнуться, чтобы сделать свое ответвление (fork), - в частности, о слиянии с MySQL 5.5 и различными системами (типа BuildBot), которые мы использовали для сборки «бинарников». Кроме того, я расскажу о том, как мы работаем с сообществом MariaDB/MySQL.

В этом докладе я расскажу о том, как мы делаем Web в Skype, о практиках, технологиях и процессах, которые позволяют нам динамически масштабировать наши веб-приложения. Я расскажу о нашем "облачном" PHP-фреймворке, SOA, о подходе к разработке, тестированию и развертыванию на сотни машин.
Основные моменты доклада
- Общая архитектура, её преимущества перед предыдущими нашими решениями, основные принципы. SOA и REST.
- PHP сегодня в плане красоты кода практически не уступает Java. Краткий обзор интересных техник, которые мы используем.
- CI: цикл разработки, пакетирование, тестирование, (авто)развертывание (deployment).
- Несколько слов об особенностях работы с базой данных: подход к релизам, версионирование.
- Интеграционные тесты.
- Chef - то, как мы его используем, нестандартные решения для gradual rollout.

RabbitMQ – сервер сообщений и очередей, реализованный на Erlang. В этом выступлении рассмотрено, как RabbitMQ использует Erlang и Open Telecom Platform (OTP) для построения высоконадежного брокера сообщений.
Мы представим обзор следующих областей.

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

Если вам интересно, что находится внутри устойчивого Erlang-приложения, вам стоит посетить это выступление.

Современные задачи, стоящие перед потоковой передачей видео (streaming), требуют новых решений. Люди хотят смотреть мультибитрейтное SD/HD видео с возможностью выбора языков и субтитров - старые решения дают сбой.

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

Во второй части доклада будет рассказано, какие аппаратные проблемы, проблемы уровня ОС и алгоритмические проблемы возникают при достижении трафика в 10 Гбит/с с одного сервера.

А именно:

почему приходится отказываться от аппаратных рейдов в пользу примитивных JBOD-решений и как ими управлять?

как так получилось, что для быстрой сети существует событийный API epoll, а для медленных дисков - только блокирующий API, и что с этим делать?

как эффективно использовать дорогие SSD в связке с дешевыми HDD? Различные профили нагрузки у сайтов с разным контентом: где-то весь трафик можно раздать с зеркалированного SSD, а где-то размер "горячей" зоны переваливает за 5 терабайт.

Подходы к решению проблемы выбора: какой контент класть на SSD, а какой продолжать раздавать с HDD?

Как строить программу так, что бы она никогда не сообщала об истекшем времени ожидания и внятно диагностировала собственную перегрузку?

Мир не будет прежним. Существует много вычислителей - "умных" и не очень, быстрых и не очень, дорогих и дешевых. Как ими управлять и остаться в здравом рассудке? Пожалуй, есть механизмы для этого. В докладе будет рассказано о том, почему монолитная архитектура больше не годится, и что с этим делать.

Основные тезисы доклада:
- проблема сложных вычислительных задач (на примере кодирования видео);
- интеграция Erlang и "Си" (проблема zero-copy и безопасности VM при данной интеграции);
- архитектура кластера, взаимодействия DSP-процессоров и хоста (транспортный уровень: DMA, PCI-e уровень; ОС: linux driver; application level: свой framework);
- framework для работы с shared memory.

Новый мир, новые абстракции, новые инструменты.

Тема отказоустойчивости веб-приложений чаще всего рассматривается в контексте распределенных атак DDoS. В последнее время наблюдается тенденция к уменьшению численности ботнетов и увеличению КПД атак, приведенному к одному запросу. Целью настоящей работы является демонстрация примеров логических и иных ошибок в коде и настройке веб-приложений, приводящих к отказу в обслуживании посредством отправки всего лишь одного или нескольких запросов. В докладе приводятся примеры реальных уязвимостей из практики проведения аудитов информационной безопасности в период с 2009 до 2013 год. Все рассмотренные уязвимости имеют отношение к доступности веб-приложения и/или его компонент, частей инфраструктуры и могут быть классифицированы по четырем группам: уязвимости логики работы приложений, уязвимости архитектуры/администрирования,уязвимости обработки форматов данных, классические уязвимости. Будут рассмотрены причины появления уязвимостей и методы борьбы с ними, рекомендации по устранению и результаты работы с клиентами в этом процессе из практики.

Когда мы слышим слово «масштабирование», мы обычно думаем о сервисах back-end, базах данных и даже о центрах обработки данных. Но что происходит, когда вам приходится масштабировать скомпилированное приложение в гетерогенной среде с тысячами узлов, которые невозможно контролировать? Как отладить приложение, запущенное на машине, к которой у вас нет доступа, и использующее различные версии библиотек с кастомными патчами, которых у вас нет?

Возможно, вы будете удивлены, узнав, что ошибки в libpcap мешают вам эффективно перехватывать пакеты из сетевого интерфейса, но это еще не все. В драйверах NIC тоже полно ошибок, которые исчезают и вновь появляются в различных версиях ядра в рамках одного и того же релиза крупной операционной системы. Объединение Ethernet-каналов (Ethernet bonding) также имеет собственный «набор» багов при использовании NIC с поддержкой аппаратного VLAN-тегирования.

Я сталкивался с интересными проблемами везде: начиная от компиляторов, ядер, компоновщиков и загрузчиков и заканчивая багами в автоматизированных инструментах, системах автоматизации и даже «острыми углами» в самих упаковочных системах.

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

Badoo — это большая социальная сеть с более чем 190 млн. пользователей. В нашей компании мы предварительно оцениваем большую часть нового функционала посредством A/B тестирования. Вот уже примерно год как мы используем собственный высоконагруженный фреймворк тестирования, при этом, по моему мнению, он очень прост, понятен и не требует огромных ресурсов на разработку и поддержку. В докладе я расскажу вам о том, почему мы пришли к собственному решению, объясню его архитектуру и принципы работы. Я уверен, что каждый из вас может сделать что-то подобное для своего проекта и начать принимать более обоснованные решения.

Тезисы
- Как мы раньше тестировали?
- Почему мы сделали свой инструмент?
- Архитектура: API, граф. интерфейсы, транспорт, скрипты, БД.
- Структура теста.
- Основные правила А/Б тестирования.
- Оценка результатов, примеры отчетов.
- И заключительная часть - о том, что от человека с головой полностью не избавиться.

Сложность

Несмотря на то, что конференция называется Highload++, я уверяю, что представленную здесь архитектуру может потянуть и проект с посещаемостью в 1000 чел в день и тремя программистами в штате. Реализовать все, о чем здесь рассказано, на PHP можно меньше чем за неделю с учетом работы только одного человека. А результат, между прочим, вполне измерим, и выражается он в реальной прибыли.

1) Проблемы сервисов все те же - "тормоза" в неизвестном месте, отказы, время восстановления.
2) Как технологии SmartOS/Solaris могут помочь в решении этих задач?
3) ZFS - файловая система будущего. Краткий обзор ключевых возможностей - автоматический контроль целостности, дедупликация, snapshots, пересылка.
4) ZFS snapshot: как организовать быстрые снимки на базе copy-on-write?
5) ZFS send/recv: как быстро поднять dataset, возможно, в частном или даже общедоступном облаке.
6) Пара недокументированных фактов про ZFS из личного опыта.
7) DTrace - средства отладки приложения, драйверов, ядра - находим, где собака порылась!
8) DTrace - пример 1. Почему тормозила БД? Отладка функции в драйвере диска.
9) DTrace -пример 2. Неясно, какой код ошибки возвратила функция ядра - в чем дело? Разбираемся.
10) Кратко о Solaris Zones - технологии виртуализации в SmartOS.
11) Наш опыт решения проблем. Эффективность внедрений.
12) Несколько примеров размещения быстрорастущих американских стартапов на SmartOS в Joyent - LinkedIn, Voxer, Digital Chocolate, GoldFire.

Основная задача системы мониторинга и контроля биржевой площадки — обеспечивать упорядоченное и стабильное функционирование рынка и, в частности, поддерживать аналитическую работу отделов, отвечающих за выявление возможных манипуляций.
Система мониторинга должна собирать информацию обо всех входящих заявках, ответах системы, данных, поступающих из внешних источников, а также о релевантных внутренних состояниях трейдинговой платформы. В условиях высокочастотной торговли объемы этой информации достаточно велики, и их обработка требует масштабируемой инфраструктуры.
Операторы биржевых площадок и участники торгов ожидают, что системы мониторинга и контроля рисков будут оказывать минимальное влияние на основную функциональность трейдинговой платформы и время отклика.
Недобросовестные участники рынка пытаются скрыть злоупотребления и манипуляции рынком под видом легитимных финансовых транзакций, а некоторые законные операции обладают многими признаками нарушений. Системам мониторинга и контроля рынков приходится делать аналитические заключения под высокой нагрузкой, на основе нечеткой логики, параметры которой приходится непрерывно адаптировать под новые трейдинговые ситуации и схемы поведения участников торгов.
Наш доклад содержит обзор предметной области и основных требований к системам мониторинга и контроля для биржевых площадок, а также описание разрабатываемой нами системы, ее архитектуры и выбранного технологического стека, включая Akka, LevelDB, Play, ZeroMQ и ExtJS.

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

1. Подготовка видео: загрузка, конвертация и последующая раздача.
1.1. Как мы проверяем целостность загруженного видео?
1.2. Загрузка на серверы раздачи: как мы пробовали раздачу через торренты.
1.3. Рациональность подключения "облаков" для конвертации видео.

2. Раздача: доставка видео до пользователя.
2.1. Дешевые хостинги для минимизации расходов.
2.2. Несколько хостингов как способ повысить отказоустойчивость.
2.3. Балансировка: почему мы остановились на DNS Round Robin. Преимущества и проблемы.

3. Аварийное восстановление (failover) и маштабирование.
3.1. Мониторинг объемов трафика и предсказание роста объемов раздачи. Автоматическое выключение "съевших" трафик серверов.
3.2. Раздача в пиковые часы - гибрид: "железо" и "облака".
3.3. Мониторинг последней мили: "как убедиться, что у юзеров не лагает видео"?

В своем докладе я расскажу, почему мы выбрали графовую базу данных Neo4j для проверки дорожного графа городов России (все населенные пункты с населением больше 300 000 жителей). Основные задачи, которые мы решаем средствами Neo4j — это проверки на связность и доступность проезда.

Опорные пункты доклада:
— SQL против графовых баз данных;
— обзор графовой базы данных neo4j;
— архитектура решения, в котором используется графовая БД;
— выполнение алгоритмов на графе в условиях его частых изменений.

В основе доклада лежат результаты работы над проектом «Fiji». Это внутрикорпоративная система, которая позволяет штатным картографам 2ГИС создавать, хранить и экспортировать карту во внешние продукты: онлайн-, десктоп- и мобильную версии 2ГИС.

Сайт Сочи 2014 - крупнейшее событие в современной российской истории, причём не только офлайн, но и онлайн!

Мы поговорим о том, какие требования выдвигал Организационный комитет (ОКОИ) к порталу Сочи 2014. Высокие нагрузки - это далеко не всё, и высокие нагрузки - это не только посещаемость.

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

А еще мы развенчаем популярные ныне мифы о грандиозной онлайн-стройке!