Онлайн трансляция учебного трека
Мобильное приложение HighLoad++
Скачать Скачать Скачать
вебинарПОШАГОВЫЙ АЛГОРИТМ
бесплатная книгаПРОДУМАННАЯ ОПТИМИЗАЦИЯ
ЭКСПЕРТНАЯ ЗОНА
материалыЗА ВСЕ СЕМЬ ЛЕТ
онлайнУЧЕБНЫЙ ТРЕК
вебинарВОПРОСЫ И ОТВЕТЫ
конференционнаяГОСТИНИЦА
корпоративныйОБУЧАЮЩИЙ ПАКЕТ

HighLoad++

31 октября
и 1 ноября
Место проведения: Москва,
Краснопресненская наб. 12.
  • Как известно, что не измеряется, то нельзя улучшить. И если замеры на бэкенде (сколько времени выполняются запросы к базе, как быстро генерируются страницы, сколько запросов в секунду может обрабатывать веб-сервер) выполняют почти все разработчики, то ClientSide-производительности незаслуженно уделяется значительно меньше внимания. Быстрый ли DNS, хороший ли канал у хостера, закэширована ли статика, не перегружен ли сайт JavaScript'ом - все это помогает оценить Navigation timing API.

    В докладе мы расскажем о том, как делали систему аналитики, основанную на Navigation timing API, для десятков тысяч сайтов:

    - Как сделать подобную систему за 1 месяц и $1000, используя в Amazon Web Services (AWS) Kinesis и DynamoDB.
    - Как быстро (очень быстро!) принимать миллионы хитов с помощью Nginx+Lua.
    - Как в реальном времени обрабатывать миллионы хитов, постоянно агрегируя данные (потоковая обработка BigData... без хранения BigData).

  • Компьютерное "железо" - это постоянно меняющийся мир, который требует обновления программного обеспечения для эффективного использования оборудования. MySQL не является исключением: хоть разработчики всех веток MySQL и прикладывают усилия для оптимизации производительности, многие из них были реализованы много лет назад, для совсем других архитектур и классов оборудования. В этой презентации мы поговорим о типичных проблемах с производительностью MySQL на современном "железе" и современных нагрузках, вопросах конфигурация MySQL для высоконагруженных систем, а также решения проблем производительности, которые можно ожидать в будущих версиях MySQL и Percona Server.

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

  • Thorny path to the Large-Scale Graph Processing Алексей Зиновьев

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

    Что делать, если объект вашего исследования - это весь веб-граф Рунета, граф Твиттера, дорожная сеть Европейского союза или граф знаний Google? Как корректно и быстро вычислить диаметр графа, найти компоненты связности, кратчайшее расстояние между всеми парами вершин или разрушить минимальное остовное дерево?

    Многие без оглядки "бросаются в омут" Neo4j и других графовых баз данных, кто-то изобретает свои способы компактного хранения графа в оперативной памяти, а некоторые прибегают к мощи парадигмы MapReduce.

    Традиционная MapReduce-парадигма не оправдывает себя при выполнении расчетов на больших графах. Большинство современных фреймворков обработки графов построены по модели "Bulk Synchronous Parallel", в том числе и знаменитые Pregel и Apache Giraph.

    Дивный мир Graph Mining и Large-Scale Graph Processing приковывает к себе взгляды многих исследовательских компаний и увлеченных теорией графов программистов, вовлекая их в процесс создания новых алгоритмов и открытых инструментов. Это увлекательный, но тернистый путь, но дорогу, как известно, осилит идущий.

  • !sync: асинхронное взаимодействие Вячеслав Турчанинов

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

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

    Сопрограммы (coroutines): "Вы все в "монадку", а мы - в "корутинку".

    Странное поведение системы: "Все встало колом? Вам кажется! Оно просто медленно работает".

    Я расскажу...
    - о том, что общего у планировщика ОС, системных вызовов и асинхронного взаимодействия.
    - о том, как принципиально работает асинхронное взаимодействие.
    - о том, в условиях асинхронное взаимодействие приносит пользу.
    - о том, какие условия являются достаточными для комфортной работы с асинхронным взаимодействием и в чем "профит" от сопрограмм (coroutines).
    - о том, как можно "затупить" асинхронный сервер своими дополнениями или встраиваемыми сценариями (nginx, Tarantool).
    - о том, что делать, если "кусочек" кода "не хочет" быть асинхронным.
    - о том, что может пойти не так, как казалось.
    - о том, как я работал с async на Python и как работаю с ним сейчас.

    В итоге должно немного "попустить" или "накрыть", но непременно в удовольствие.

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

    В докладе будет рассказано
    - о том, что кэшируемо, а что нет;
    - о том, какие алгоритмы кэширования применимы для файлов;
    - почему важно кэшировать прозрачно для application layer;
    - о том, как мы реализовали алгоритм кэширования в модуле SSD Cache;
    - о том, что мы дописали в nginx для работы этого модуля;
    - результаты практического использования в production;
    - планы на дальнейшее развитие и возможное открытие кода (если будет достаточно интереса).

  • В Circonus мы занимаемся сбором, хранением и анализом телеметрических данных. Измерения, измерения и ещё раз измерения. В рамках своего доклада я расскажу об эволюции нашей архитектуры данных и уроках, которые мы вынесли из практики масштабирования распределенного сбора и хранения телеметрии. Я буду говорить о переходе с PostgreSQL на собственное колоночное хранилище, а также о миграции с RabbitMQ на Fq. Во время доклада мы обсудим и некоторые неожиданные сценарии отказов.

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

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

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

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

    По окончании данного мастер-класса вы будете в курсе того, какому процессу следовать и какие инструменты вы должны иметь в своём стеке, чтобы эффективно проектировать или перепроектировать ваши приложения с использованием MySQL.

  • Впервые за последние четыре десятка лет в мире баз данных происходит что-то новое. Пять лет назад появилось множество так называемых NoSQL СУБД, которые были призваны справиться с BigData.

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

    MongoDB является ведущей NoSQL СУБД. Сотни тысяч кластеров MongoDB используются в широком диапазоне организаций – от стартапов с JavaScript-архитектурами на стороне сервера до банковских и государственных структур с Java-стеками. В данном докладе будут исследованы 5 возможностей, которые позволяют MongoDB выделяться на фоне других NoSQL СУБД.

  • Все реально существующие сети время от времени могут выходить из строя, тем более при высокой нагрузке. Выход из строя - явление достаточно распространенное, но устойчивость к партиционированию в распределенной системе обеспечивается не так часто. Несмотря на то, что устойчивость к партиционированию является неотъемлемой частью теоремы Брюера (или теоремы САР), распределенные системы, даже спроектированные с учётом реализации 'P' (Partition tolerance – устойчивость к партиционированию) в CAP, не обеспечивают её в достаточной степени и недостаточно детерминированы. К сожалению, это не исключительные случаи, а обычная практика, согласно последним исследованиям [1].

    Galera [2] дополняет MySQL/PXC (подсистему хранения данных Percona XtraDB Cluster)[3] синхронной репликацией благодаря API wsrep репликации. Синхронная репликация требует не только кворума, но и получения согласованного результата. В среде с помехами задержка получения согласованного результата может привести к замедлению фиксации транзакций, следовательно, и к значительной задержке или даже к разделению сети на многочисленные вторичные компоненты и единичный первичный компонент (при условии, что это возможно). Таким образом, обеспечение устойчивости к партиционированию является не просто желательным, а основным требованием.

    Данный доклад касается тестирования устойчивости системы Galera к партиционированию. Docker и Netem/tc (управление трафиком) играет значительную роль в данном случае. Модуль Netem важен для эмуляции случаев выхода из строя – потеря пакетов данных, задержка, повреждение, дублирование пакетов, изменение порядка и др., а также для моделирования таблиц распределения, отражающих задержки канала связи, таких как распределение Парето, paretonormal, uniform (равномерное распределение) и т.д. Docker и контейнеры в целом необходимы для моделирования многочисленных нод, которые могут создаваться в реальном времени (во время работы приложения), легко запускаться и отключаться, иметь сети и потоки, которые просты в настройке при необходимости, обеспечивать горизонтальное масштабирование; если производительность также учитывается в ситуации выбора между контейнерами и полной виртуализацией и др. Утилита Sysbench OLTP используется для эмулирования нагрузки, хотя в данном случае возможно использование RQG (генератора случайных запросов) для расширенного fuzz testing (фаззинга).

    Будут рассмотрены основные результаты исследований.
    * Применение коэффициентов потерь с распознаванием сегментов WAN для виртуальных сетевых интерфейсов.
    * Разные периоды синхронизации после устранения помех в сети.
    * Потеря многих нод с кратковременным всплеском помех против потери одной ноды и более длительных помех.
    * Полнодуплексная связь контейнеров с dnsmasq.
    * Влияние внесетевых факторов – таких, как скорость работы дисков, – на fsync.
    * Распределение запросов по нодам по алгоритму round-robin при наличии/без нод с отказами сети в цепи.
    * Горизонтальное масштабирование тестовых нод и проблемы с Docker/namespace.

    В заключительной части доклада будут обсуждаться все детали тестирования Galera на устойчивость к партиционированию с помощью Docker и Netem. Также будут охвачены схожие инструменты/фреймворки, такие как jespen [4]. Более того, будет приведено сравнение Galera/EVS (расширенная виртуальная синхронизация) с другими протоколами обеспечения согласованного результата – например, Paxos, Raft и др. В конце будут освещены результаты тестирования – дополнение auto_evict к Galera.

    [1] https://queue.acm.org/detail.cfm?id=2655736
    [2] http://galeracluster.com/products/
    [3] http://www.percona.com/software/percona-xtradb-cluster
    [4] https://github.com/aphyr/jepsen

  • 100% HA. Да! Дмитрий Смирнов

    Как правильно обеспечить HA на примере sdn.spb.ru. Полный инструктаж по HA - от электропитания, резервной СКС до приложений. Это совершенно реально. Обсудим всё. Начнём с полов, размещения стоек, кабельной структуры, перейдём к bond, конфигурациям коммутации, потом обсудим балансировку ipvs, KeepAlived, спустимся ниже к Real Servers и плавно уйдём в backend. Обязательно рассмотрим сетевую файловую систему Сeph, аналоги S3 и шифрование LibreS3, синхронизацию данных между дата-центрами. А самое главное - в конце: я объясню, как это всё можно масштабировать географически - ну, на тот случай, если в один из дата-центров влетит бомба. Всё работает.

  • Мы записываем и анализируем около 1 млрд. событий в месяц, и эта цифра растет. Это данные с наших плееров, iOS-приложения и сайта. С таким объемом любой сторонний сервис будет стоить очень дорого и при этом будет сильно ограничен по возможностям. Прошло уже больше года с тех пор, как мы построили и успешно используем своё решение для анализа таких событий.

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

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

  • Я расскажу, как нам удалось более чем в 10 раз ускорить старт просмотра кино и сериалов с использованием технологий адаптивного стриминга MPEG-DASH и HLS. Вы узнаете, какие технологии попали в поле зрения команды, как инфраструктурные особенности, размер аудитории и специфика потребления на разных пользовательских устройствах повлияли на принятие решения о выборе технологии. Естественно, будет дан и подробный отчет о результатах внедрения решения и полученном эффекте.

  • Список подтем доклада:
    - почему важна непрерывная интеграция;
    - проблемы внедрения общих процедур тестирования в унаследованную базу кода;
    - почему инструменты вроде Jenkins не масштабируются в современных командах;
    - проблема непрерывной интеграции в очень быстро растущей компании;
    - современное решение от Dropbox для тестирования (наша Open Source платформа Changes).

    Основная идея: проблема непрерывной интеграции намного серьёзнее, чем вы думаете, особенно если вы не начали решать её сразу.

  • Sharding: patterns and antipatterns Константин Осипов, Алексей Рыбак

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

  • Как обычно, подведем итоги года с аналитикой за 10 прошедших месяцев 2014 года. Расскажем про текущие тренды DDoS-атак и объясним, как это соотносилось с внешнеполитическими событиями и экономикой.

    Проведем разбор типовых ошибок, которые стали причиной самых громких #tangodown этого года.

    Расскажем о том, почему UDP Amplification медленно, но верно подходит к своему логическому завершению. Обсудим самые перспективные вектора угроз 2015 года и представим BCOP (best common practices) для безопасного функционирования ваших приложений с учетом новых угроз.

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

  • Поскольку рост проекта Hailo обеспечил ему глобальное присутствие, нам пришлось пересмотреть наш подход к технологиям. Мы решили уйти от монолитного приложения на PHP и Java и внедрить нативную поддержку «облаков», и проект Hailo перешёл на новую платформу микросервисов, работающую на трех континентах и почти полностью построенную на Go. В данном докладе я расскажу, как мы разработали архитектуру микросервисов и впоследствии перешли на неё, перечислю распространенные ошибки и объясню, как их избежать, и поделюсь уроками, которые мы извлекли из разработки на Go распределенных приложений, рассчитанных на обработку больших объёмов данных с минимальной задержкой.

  • Оптимизация программ для Linux Александр Крижановский

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

  • При построении современных RTB-решений предъявляются особые требования к производительности компонентов, которые обслуживают поступающие запросы на показ рекламы.

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

    Мы расскажем о том, как построили сервис обогащения пользовательских профилей в режиме реального времени, о том, какие технологии мы при этом использовали, и о том, как выбрали Аerospike в качестве NoSQL-хранилища для решения данной задачи. В рамках доклада будут продемонстрированы таблицы со сравнением функциональных возможностей Aerospike, CouchDB, MongoDB, Redis, а также графики производительности Аerospike по сравнению с другими NoSQL-решениями.

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

    Мы выделили входные и выходные метрики, наблюдаем за ними и сравниваем зависимости метрик друг от друга для каждого периода. Таким образом мы не только сравниваем релизы, но и обнаруживаем аномалии. В своём докладе я упомяну полезные инструменты с открытым исходным кодом, которые мы используем в работе: ipython notebook, Graphite, Diamond, pandas и scikit-learn.

  • Построение беспроводных сетей для массовых мероприятий, стадионов, выставок предполагает наличие особых требований к инфраструктуре. Классические enterprise-решения с централизованным контроллером и множеством относительно маломощных точек доступа тяжело масштабируются для большого числа пользователей. В нашем докладе мы расскажем о создании сети беспроводного доступа на выставке Highload++ и о тонкостях реализации подобных решений. Часть доклада будет посвящения трудностям развертывания таких решений для массовых мероприятий - включая миграцию пользователей, переменную плотность, всплески активности в ходе презентаций и выступлений. Расскажем про интересные технологии современных Wi-Fi сетей - формирование лучей, geofencing, подавление Rogue AP, равномерную балансировку пользователей по частотным каналам.

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

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

    Основные подтемы доклада
    - В чем проблема подхода, включающего парсинг логов?
    - Чем хороши, а чем не очень инструменты работы с логами?
    - Что получается, если объем собираемых в день логов составляет около 70 Тб?
    - Плюсы и минусы универсальных решений типа Hadoop для такой задачи.
    - Наш подход к интеграции MapReduce в nginx.
    - Горизонтальная масштабируемость системы агрегации логов.
    - Почему одного сервера достаточно, чтобы считать 50 гигабит трафика в секунду и более 7 миллиардов хитов в день?
    - Результаты работы в production
    - Как бы мы реализовали то же самое сейчас?

  • Я расскажу о том как создать базу данных под задачу не решающуюся средствами SQL и как не влипнуть в велосипедостроение и долгострой :) Решение о котором я расскажу было разработано и вышло в продакшн за пару месяцев и окупилось ещё за пару месяцев.

    Описание проблемы
    1. Нужно отослать пользователю уведомление о том, что появились билеты, соответствующие его параметрам.
    2. У Aviasales очередь с результатами поисков, и каждый совершённый поиск авиабилетов добавляет в эту очередь json-документ размером 200-800 Кб, который содержит тысячи билетов и довольно сложно структурирован.
    3. В базе подписок - миллионы записей, при этом одна подписка состоит из нескольких предикатов.

    В итоге мы имеем поток огромных документов, каждый из которых нужно проверять на соответствие миллионам предикатов. Предикаты бывают как простые (вроде пункт_вылета = Москва), так и сложные (количество_пересадок < 2). Кроме того, некоторые сочетания предикатов проверяют ответ не на полное, а на частичное соответствие (например, цена < 100 && количество_пересадок < 2). В этом случае предикатам будет соответствовать только часть билетов в документе, и именно о них надо уведомить пользователя.

    На github и в остальном Интернете не нашлось решения, позволяющего за допустимо короткий промежуток времени (<50 мс) сопоставлять большой сложноструктурированный документ с миллионами предикатов, поэтому мы в Aviasales создали специфичную базу данных, которая справляется с этой задачей.

    На данный момент это уникальное решение на рынке. У наших конкурентов вы можете подписаться на информирование с чёткими датами и без требований к времени в пути, цене и других, более сложных условий. То есть у конкурентов просто берётся самый дешевый билет на направление, из базы выбираются соответствующие подписки строгим соответствием по 4-м параметрам (что-то вроде "select * from subscription where origin = 'MOW' and destination = 'LED' and depart_date = '2015-01-01' and return_date = '2015-02-01';").

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

  • Тезисы
    · Общая архитектура: история создания, распределение нагрузки, отказоустойчивость.
    · Логи скриптов: сбор, индексация, различные виды просмотра.
    · Влияние Google App Engine — «облачный» разборщик очередей.
    · Проблемы, с которыми мы столкнулись.
    · Планы на будущее: phproxyd на PHP, управляющая логика на Go.
    · Как мы бы реализовали «облако» сейчас: Go, Tarantool, ...

    Описание
    В прошлом году мы рассказывали о новой системе, которую мы назвали «облаком для скриптов» или «облачным cron'ом». Система служит для распределенного запуска скриптов по расписанию с автоматической балансировкой нагрузки и устойчивостью к «падениям» отдельных машин. Изначально система была построена на PHP, MySQL и легковесном самописном демоне — phproxyd, который «умеет» запускать скрипты на машине и отдавать информацию о статусе их исполнения.

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

    Главные демоны нашего «облака» всё ещё работают на немного модифицированном прототипе, который был написан в первые недели разработки, при этом за год суммарный простой составил 3 часа, что дает uptime 99,97%. Тем не менее, у нас есть много идей для улучшения:
    - перевод управляющей логики с PHP на Go;
    - перевод phproxyd с Си на PHP (!), для экономии на запуске интерпретатора;
    - возможный переход на Tarantool для хранения текущего состояния скриптов;
    - длительное хранение логов, индексирование .gz-файлов для просмотра информации даже по очень старым запускам;
    - улучшения в балансировщике (итеративное «уточнение» весов вместо использования «попугаев»).

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

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

    В докладе будет рассказано, чем NFV отличается от существующих программно-аппаратных решений по обработке сетевого трафика, какие преимущества мы получаем, какие новые проблемы и задачи при этом появляются. В рамках доклада мы рассмотрим проблемы производительности таких виртуализированных сетевых сервисов, а также предоставим обзор различных вариантов программного исполнения сетевых сервисов (userspace, kernelspace, VM, Intel DPDK/Netmap и т.п.), и в каждом случае будет показана достигаемая производительность. Кроме того, слушателей ожидает рассказ о будущем NFV, программном стеке и платформах по централизованному управлению и оркестрации.

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

  • Сейчас наша компания занимается разработкой решения, позволяющего анализировать большой социальный граф: такой, в котором >100 млн. вершин и >1 млрд. ребер. На нем могут ставиться различные задачи: от простого обхода всех ближайших соседей вершины до поиска всех подграфов, удовлетворяющих определенным условиям. Кроме того, дополнительная сложность заключается в том, что все время добавляются новые данные, а потому их прогрузка должна идти параллельно с анализом.

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

  • В течение многих лет классическая веб-архитектура включала серверы, рендерившие HTML посредством скриптов или языка приложений на стороне сервера. Однако сейчас веб во многом изменился: браузеры стали быстрее, интернет-соединения стали более стабильными и скоростными, кэширование улучшилось. Эти изменения подводят нас к сдвигу парадигмы - к рендерингу на стороне клиента. Эта новая архитектура позволяет серверам только поставлять данные, а разметка при этом кэшируется на клиенте или близко к нему, в результате чего достигается общее повышение производительности. Реальность Интернета такова, что не все пользователи обладают достаточно мощными компьютерами, устанавливают современные браузеры и используют достаточно быстрое интернет-соединение. Производительность страниц LinkedIn для этих пользователей требовалось как-то повысить.

    Из данного доклада вы узнаете, как мы интегрировали JS-движок в HTTP-прокси, какой опыт получили, добавив исполнение динамического языка на наш ключевой уровень прокси, как боролись с прекращением работы JavaScript и проблемами сборки мусора, и, наконец, как нам удалось ещё больше сократить время задержки.

  • Правильная работа с индексами является ключевой составляющей производительности любой базы данных, и MySQL не исключение. Генеральный директор Percona Пётр Зайцев рассмотрит новые приёмы работы с индексами на базе улучшений оптимизатора MySQL 5.6.

    Вы узнаете:
    • как MySQL использует индексы для выполнения запроса;
    • как выработать оптимальную стратегию работы с индексами;
    • как понять, когда вам нужно добавить индекс;
    • как определить, какие индексы не нужны.

  • Про SQL-инъекции все слышали, и все знают, как с ними бороться. Про NoSQL-инъекции слышали почти все. Данный доклад посвящен совершенно новой теме - инъекциям в key-value хранилище Memcached, про которые точно никто ещё не слышал. Говорить о популярность Memcached не приходится: Twitter, Wikipedia, YouTube, LiveJournal и все highload-проекты сегодня используют его.

    В докладе приводятся реальные уязвимости оберток (wrappers) для хранилища Memcached и практические примеры исправления таких уязвимостей на уровне кода приложения. Обнаружены уязвимости в 1 из 3 существующих оберток ("драйверов Memcached", как их часто называют) для Ruby, 1/2 Python, 1/2 Java, 1/2 PHP, 1/1 Lua, 1/1 .NET, 0/1 Go. Уязвимости позволяют не только компрометировать данные в памяти, но и зачастую вызывать выполнение произвольного кода.

    Отдельная часть доклада затрагивает организацию безопасного хранения данных на основе ключей (namespaces, хеширование и проч.).

  • HighLoad для начинающих Дмитрий Обухов

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

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

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

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

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

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

    Мы обсудим:
    - что такое асинхронная репликация;
    - как устроена асинхронная репликация в MySQL;
    - какие ошибки проектирования были допущены;
    - как эти ошибки проявляются при использовании;
    - чем эти ошибки мешают эксплуатации;
    - почему параллельная репликация MySQL 5.7 не решает проблем, а лишь добавляет новые;
    - как проект PostgreSQL избежал этих ловушек.

  • Большинство проектов с активной email-рассылкой рано или поздно сталкивается с тем, что почтовые сервисы начинают помещать их письма в "Спам" из-за низкого отклика на рассылку. В таких случаях необходимо заметно повысить CTR (кликабельность) рассылки.

    Как это сделать так, чтобы при этом не пострадала общая активность пользователей на сайте? Какие данные и как хранить о пользователях, чтобы это было возможно?

    О чем я расскажу в данном докладе?
    1. О традиционных подходах и попытках их применения в Badoo.
    2. О новом подходе, давшем ошеломительный эффект, - выборе частоты рассылки на основании прошлой активности пользователя.
    3. Техническом устройстве системы, обеспечивающей хранение данных об активности пользователей с email-рассылкой.

  • Гипервизор сегодня превращается в commodity ("ширпотреб"), фактически производитель уже становится неважен. KVM становится одним из лучших выборов - надежный, функциональный, бесплатный, Open Source.

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

    Мы создали гибридное решение типа "все в одном".
    Nutanix - это программная платформа, изначально спроектированная для создания безлимитно масштабируемых "облаков".
    Отсутствуют практически все типичные узкие места.
    Максимальное использование Open Source компонентов с существенной доработкой (Cassandra NoSQL, Apache ZooKeeper, Linux Kernel, EXT4, KVM). Полностью программная реализация.
    Распределенная файловая система NDFS и система управления "облаком" Acropolis.
    Отсутствует RAID или JBOD. Метаданные файловой системы и кластера хранятся в NoSQL DB Cassandra. Конфигурация кластера - Apache Zookeeper. Активное применение SSD как полноценного уровня хранения (не кэширования).

    Поддержка стандартной версии KVM (Centos) через libvirt, но полностью своя реализация управления кластером - aCLI, HTML5 UI, RESTful API.

    Подсистемы

    Arithmos - работа со статистикой гипервизора.
    Cassandra - конфигурация VM и хранение метаданных NDFS.
    Stargate - подготовка и работа с виртуальными дисками, отдача по протоколам iSCSI / NFS / SMB3.
    Apache Zookeeper - конфигурация кластера (одна из наиболее устойчивых к partitioning систем хранения кластерных конфигураций).
    Prism - UI, Prism Central - UI / CLI / API для централизованного управления распределенной инфраструктурой.

    На сегодняшний момент, на Nutanix Acropolis любая компания может запустить “под ключ” ”облачную” инфраструктуру практически любого масштаба за 30 минут.

  • Tempesta FW: FrameWork и FireWall для WAF и DDoS mitigation Александр Крижановский

    Tempesta FW - это Open Source гибрид HTTP-акселератора и файервола, специально разработанный для предотвращения DDoS уровня приложения и построения высокопроизводительных Web Application Firewalls (WAF). Проект работает на Synchronous Sockets - сокетном API, полностью встроенном в TCP/IP стек операционной системы, и использует самую быструю на данный момент реализацию конечного автомата разбора HTTP-сообщений.

    Tempesta позволяет фильтровать трафик от 3-го (IP) до 7-го (HTTP) уровней, а для облегчения реализации кастомных модулей классификации трафика и реализации модулей типа ICAP предоставляет интерфейс Generic FSM, позволяющий переключать контексты разных машин состояний (например машины состояний для ICAP и для HTTP). В пакете уже есть простой фильтр смягчения последствий DDoS (DDoS mitigation filter).

    Проект предназначен прежде всего для построения сетей фильтрации, создания WAF и ускорения веб-приложений, но функциональность принесена в жертву производительности. Так, например, веб-кэш обязан помещаться в RAM.

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

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

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

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

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

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

  • Software Defined Storage (SDS) – сейчас одно из самых модных направлений на рынке. В процессе работы над собственным хранилищем данных мы узнали много интересного (и ценного) об архитектурах SDS, чем и поделимся в докладе. Эти знания необходимы для правильного анализа производительности SDS, чтобы понимать, на каких уровнях работают кеши, почему “sync” – это очень дорогая операция, где могут быть ограничения, и что в действительности влияет на производительность. Подробно поговорим о самой методологии тестирования.
    Стоит еще отметить, что некоторые SDS решения в погоне за производительностью забывают о главном, ради чего они используются. SDS, в первую очередь, должны НАДЕЖНО ХРАНИТЬ данные. Поэтому мы обязательно затронем тему консистентности данных и надежности их хранения.

  • Когда количество пользовательского статического контента на проекте начало превышать возможности используемых нами серверов, мы задумались о будущем и решили масштабироваться не вертикально, а горизонтально. Обычный в современном мире способ горизонтального масштабирования подобного рода хранилища - использование так называемого Object Storage, распределенной системы хранения, строящейся на базе относительно дешевых узлов, имеющей S3 или REST-интерфейс.

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

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

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

  • - Постановка проблемы: в чем сложность работы с большими объемами географических данных.
    - Отображение большого количества меток на клиенте - недостатки стандартных решений.
    - ObjectManager: рисуем много точек на клиенте.
    - Передача большого количества данных с сервера на клиент.
    - Организация хранения данных на сервере - пространственные базы данных и quad-ключи.
    - Организация серверной grid-кластеризации географических объектов.
    - Проблемы кэширования и версионирования данных.

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

  • CREATE INDEX … USING VODKA. VODKA CONNECTING INDEXES! Олег Бартунов, Александр Коротков

    Встроенная поддержка json в PostgreSQL - это уже свершившийся факт, который каждый может осознать, установив версию 9.4. Новый тип данных jsonb имеет эффективное бинарное хранилище, что делает доступ к нему в десятки раз быстрее текстового типа json, а индексная поддержка поисковых операторов jsonb приводит к их тысячекратному ускорению, что делает PostgreSQL серьезным конкурентом MongoDB - признанному лидеру мира NoSQL баз данных. Действительно, несмотря на успех NoSQL (активно распиаренный использованием в некоторых популярных интернет-проектах), многие пользователи не готовы жертвовать целостностью данных в угоду масштабируемости, но хотят иметь гибкость схемы данных в проверенных и надежных реляционных СУБД. Темпы роста компьютерной индустрии (совершенствующиеся процессоры, дисковые подсистемы и сетевые устройства) позволяют большому количеству проектов успешно функционировать на одном сервере и не требовать горизонтальной масштабируемости NoSQL. Более того, при правильном проектировании архитектуры приложения возможно добиться горизонтальной масштабируемости реляционной СУБД, что подтверждает пример Instagram с использованием открытой реляционной СУБД PostgreSQL.

    Однако, чтобы всерьез конкурировать с NoSQL, необходимо иметь богатый язык запросов к json-данным, подкрепленный индексами. Мы расскажем про несколько новых проектов, которые мы ведем для продвижения вперёд в этом направлении. Первый проект - это язык запросов jsquery, который обладает выразительной мощью, достаточной для конструирования сложных запросов, и понятным синтаксисом. Надо сказать, что какого-то принятого стандарта на язык запросов для json нет, а существующий “зоопарк” языков не соответствует нашему представлению о целесообразном и прекрасном, так что мы разработали язык запросов самостоятельно.

    Вот так выглядит запрос на языке запросов MongoDB:

    db.reviews.fnd( { $and :[ {similar_product_ids: { $in ["B000089778"]}}, {product_sales_rank:{$gt:10000, $lt:20000}}] } ).count()

    А вот так этот же запрос можно записать на нашем jsquery:

    SELECT count(*) FROM jr WHERE jr @@ ' similar_product_ids &&
    ["B000089778"] & product_sales_rank( $ > 10000 & $ < 20000)'

    Операторы языка получили индексную поддержку на основе обобщенного обратного индекса (GIN).
    Примечательно, что язык запросов jsquery можно скачать и использовать с PostgreSQL 9.4, то есть уже сейчас!

    Следующий проект носит исследовательский характер, но мы ожидаем от него серьезных результатов. В процессе работы над jsquery и индексами, мы поняли проблемы и ограничения существующих индексных методов доступа и поэтому придумали новый индекс – VODKA! Рассмотрим один мотивирующий пример. Природа json такова, что пути в json-объекте могут быть достаточно длинными, особенно при большой вложенности. Использование B-дерева для их индексации не подходит, так как получится очень большой индекс, сравнимый с размером данных. При индексировании этих путей с помощью GIN в проекте jsquery мы используем хеширование, фильтры Блума для компактного хранения ключей. Этот подход работает, но имеет целый ряд проблем и ограничений, связанный, например, с неточным (lossy) представлением ключей. Для компактного хранения ключей “как есть” можно использовать radix-tree (цифровое дерево), так как пути (ключи) имеют общие индексы. В то же время, GIN-индекс очень компактно хранит дубликаты, поэтому появилась идея использования radix-tree вместо B-дерева для хранения ключей, а если обобщить эту идею на подключение произвольного поискового дерева для хранения ключей, то мы получаем новый тип индекса VODKA. Эти произвольные поисковые деревья могут быть реализованы с помощью других типов индексов, например, radix-tree реализуется с помощью SP-GiST. В случае с индексированием json с помощью VODKA удалось создать компактный индекс, поддерживающий при этом произвольные запросы по ключам json-объекта. VODKA также может быть полезна для индексирования пространственных объектов: один протяжённый объект можно апроксимировать несколькими прямоугольниками. Этим достигается большая точность апроксимации, а в конечном счёте и большая скорость поиска. Помимо этого, с помощью VODKA можно строить специальные структуры данных, ускоряющие смешанные запросы, например, запрос, сочетающий в себе полнотекстовое и пространственное условия. Пример: "найти ближайшие рестораны, в описании которых содержится VODKA". Еще одно ограничение PostgreSQL на композитные индексы может быть снято с помощью VODKA – это невозможность использования разных типов индексов для разных колонок. Более того, с помощью VODKA можно обеспечить построение композитных индексов для тех методов доступа, которые принципиально их не поддерживают, например, SP-GiST, hash.

    Надеемся, что теперь название доклада стало понятным: VODKA CONNECTING INDEXES !

  • Как PostgreSQL работает с диском? Илья Космодемьянский

    Диски, память, цена, процессор - в таком порядке смотрят на характеристики сервера админы, покупающие машину под базу данных. Как эти характеристики взаимосвязаны? Почему именно они?

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

    "Железо", настройки операционной системы, файловой системы и PostgreSQL: как и для чего выбирать хороший setup, что делать, если конфигурация "железа" не оптимальна, и какие ошибки могут сделать бесполезным самый дорогой RAID-контроллер. Увлекательное путешествие в мир батареек, "грязных" и "чистых" страниц, хороших и плохих SSD-дисков, покрасневших графиков мониторинга и ночных кошмаров системных администраторов.

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

    В докладе мы расскажем о современных методах DoS- и DDoS-атак и о способах защиты от них с точки зрения системных администраторов и специалистов по ИБ. Мы продемонстрируем на стенде модель enterprise-сети и в ходе презентации будем осуществлять реальные атаки на инфраструктуру и приложения с помощью продуктов Ixia. Рассмотрим различные виды атак и продемонстрируем, как "отбивают" эти атаки те или иные продукты (межсетевые экраны, системы предотвращения вторжений, средства защиты от DDoS, Web Application Firewall). Также мы затронем способы защиты приложений от Zero-day уязвимостей с помощью этих продуктов.
    В докладе будут рассмотрены и продемонстрированы следующие виды атак:
    HTTP GET Flood и Recursive GET Flood
    Keep-Dead
    Slowloris
    Slow-POST
    HashDoS
    SSL Renegotiation
    XML Bomb (Billion Laughs и Quadratic Blowup)
    NTP, DNS, SSDP, CHARGEN amplification
    Вся демонстрация будет проходить в реальном времени с использованием high-end оборудования, решений в области ИБ, нагрузочного тестирования и опорных сетей.

  • На сегодняшний день наиболее популярным алгоритмом сжатия отправляемых с веб-сервера данных является gzip. Но существует еще несколько новых направлений, на которые стоит обратить внимание при отправке большого количества данных в нагруженных системах.

    Этот доклад будет посвящен новому протоколу сжатия данных SDCH (общий словарь сжатия для HTTP) http://groups.google.com/group/SDCH. Этот протокол мы экспериментально внедрили для статического англоязычного контента (7 тысяч JavaScript-файлов, 2 тысячи CSS-файлов) в компании LinkedIn, и результаты нас приятно удивили.

    Почему это интересно:
    - это абсолютно новый способ сжатия передаваемых данных;
    - практически никто еще не использует этот способ, кроме Google Search;
    - мы хотим уменьшить время загрузки ресурсов веб-приложения;
    - в мире все еще много людей, которые не имеют доступа к сетям с быстрым Интернетом.

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

    Результаты
    - В среднем на 30% уменьшился размер передаваемых данных по сравнению с Gzip.
    - Только файлы маленького размера проигрывают относительно Gzip.
    - Задержка для кодирования файла составила всего 400 микросекунд.
    - Уменьшилось время загрузки страниц, особенно при низкой пропускной способности сети и больших задержках.
    - Чем больше веб-ресурс (чем больше файлов участвует в формировании словаря), тем лучше работает эта технология.

    Какие существуют проблемы и как их решать:
    - генерация словаря может занимать продолжительное время (от нескольких часов до нескольких дней);
    - безопасность: какой контент стоит добавлять в словарь, а какой нет;
    - HTTPS vs. HTTP;
    - вопросы кэширования при использовании CDN;
    - на данный момент есть поддержка только в Chrome, Yandex Browser и в следующих версиях Safari.

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

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

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

    PageSpeed-библиотеки представляют собой набор классов C++ для автоматической оптимизации веб-страниц и ресурсов. Библиотеки являются проектом с открытым исходным кодом.

    PageSpeed ​​ускоряет работу вашего сайта и уменьшает время загрузки страницы. Это модуль веб-сервера, который автоматически применяет передовой опыт для ускорения страниц и связанных с ними ресурсов (CSS, JavaScript, изображения), не требуя изменения существующего контента. В отличие от SDCH, PageSpeed в большинстве случаев не требует каких-то масштабных усилий по внедрению и изменения кода на сервере.

    Результаты
    - Этот подход мы использовали для удаления пробелов и минификации JavaScript на всех наших html страницах, что позволило уменьшить объем HTML-данных в среднем на 20%.
    - Задержка при обработке HTML-страницы составляет в среднем 15-20 миллисекунд.

    Мы успешно используем оба этих подхода на наших серверах и хотим поделится нашим опытом с вами.

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

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

  • Модификации KVM для работы в кластере Андрей Шетухин, Иван Повстен

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

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

    Мы построили Open Source распределенную систему, лишенную единственной точки отказа, позволяющую в автоматическом режиме динамически перераспределять виртуальные машины KVM между физическими серверами.

    Наш алгоритм решает общеизвестную задачу наполнения рюкзака (https://ru.wikipedia.org/wiki/Задача_о_ранце) с учетом набора конфигурируемых критериев. Это значит, что любой системный администратор может самостоятельно задать набор требуемых для виртуальной машины KVM ресурсов, доступных мощностей на каждом физическом сервере, общее количество серверов в кластере, и далее не заботиться о доступности сервиса. В случае аварии или возникновения необходимости миграции виртуальная машина перезапускается автоматически.

    Кроме того, наш алгоритм в автоматическим режиме позволяет запретить запуск виртуальных машин с одной ролью на одном физическом сервере. Это означает, что два фронтэнда nginx или MySQL Master и MySQL Slave никогда не будут запущены на одном физическом сервере. Таким образом мы снижаем вероятность отказа сервиса при внезапном выключении сервера.

  • Монетизация сайтов в Рунете отличается от монетизации сайтов в Европе и США отсутствием возможности апеллировать к капитализации компании через оценку потенциальной стоимости аудитории. Это приводит к проблеме "ценовых ножниц" - стоимость обслуживания каждого посетителя сайта растет, а непрямая монетизация через рекламу не обеспечивает пропорционального роста. Эта проблема заставляет оптимизировать код и инфраструктуру высоконагруженного проекта - постоянно добавлять функциональность с одновременным сокращением потребления ресурсов в пересчете на одного пользователя проекта.

    В рамках доклада будут рассмотрены:
    - кейс проекта ИМХОнет (www.imhonet.ru) с миграцией на гетерогенную инфраструктуру (общедоступное облако + выделенные серверы + облачное хранилище + CDN);
    - кейс проекта 4talk.im;
    - ряд других кейсов.

    Кроме того, будут даны практические рекомендации по выбору - "физика" или "облако", покупка или аренда, использование либо не использование CDN.

  • Openstack - это система, в которой все работает, но ничто не работает хорошо. Объектное хранилище Swift - не исключение в этом вопросе. Установленный у провайдера Swift должен верой и правдой служить высоким нагрузкам. Под вечер с него забирает десятки гигабит контента CDN, а глубокой ночью он принимает резервные копии, которые обычно делаются по cron'у одновременно.

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

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

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

    Однако есть одна вещь, нарушающая идиллию: вам присылают Word/Excel/PowerPoint-файл с просьбой что-то в нем поправить.На примере опыта построения Редактора Mail.Ru я расскажу, как мы решаем эту проблему для пользователей наших сервисов.

    Я планирую рассказать о том, как мы строили этот сервис, с какими проблемами сталкивались и как их решали. Основные аспекты, которые будут затронуты в докладе:
    - чтение документов;
    - механизмы показа и редактирования;
    - построение document thumbnails;
    - методики обеспечения качества.

    Отдельно я разберу вопросы оптимизации, расскажу как найти 7% прироста производительности на пустом месте и как свести уровень ошибок чтения менее чем к 0.5%. Главные вопросы: как читать нечитаемое, как деградировать функционал и когда правильно ломаться и выдавать ошибку. Также я объясню, как контролировать систему и почему дублирование кода в некоторых ситуациях помогает.

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

    Применив мультитенантность (multi-tenancy), можно спроектировать кластер MongoDB, более похожий на кластер Riak с хорошо распределенными операциями записи и некоторыми свойствами схем с несколькими участниками уровня master. Хотя это осуществимо в MongoDB, эту стратегию нельзя считать по-настоящему высокопроизводительной, поскольку экземпляры (instances), находящиеся на одной машине, будут бороться за системные ресурсы, и быстро появится «узкое место».

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

  • Если вы слышали о протоколе SPDY, то вас заинтересует опыт компании LinkedIn по внедрению SPDY на глобальном уровне.

    Протокол SPDY представляет собой улучшенную версию HTTP/1.1 (SPDY 3.1 принят за основу протокола HTTP/2.0). Протокол SPDY был разработан компанией Google и реализован в экспериментальной сборке браузера Chrome в 2011 году. За последние три года протокол был доведён до готовности, и в 2014 году компания LinkedIn начала внедрять SPDY в целях ускорения своих веб-приложений по всему миру. SPDY позволяет доставлять статический веб-контент значительно быстрее, чем протокол HTTP/1.1. Казалось бы, переход на SPDY - это лишь вопрос времени. Однако в реальности веб-контент кэшируется в сетях CDN, и для эффективного использования протоколу SPDY необходимо быть не только эффективнее HTTP/1.1, но и эффективнее сетей CDN. Таким образом, ответ на вопрос об эффективности SPDY оказывается совсем не простым.

    Из нашего доклада вы узнаете об архитектуре SPDY и типичных архитектурах CDN, а также о том, как мы интегрировали SPDY в LinkedIn, как мы оценивали эффективность нашего подхода, и какие сюрпризы нам преподнесла действительность.

  • Тезисы
    1. Эмуляторы на JavaScript - что это такое? Как они работают?
    1.1 Принципы работы.
    1.2. PCE.JS - общая информация.
    1.3. Пути практического применения.

    2. PCE.JS и интеграция с DOM-моделью.
    2.1. Структура PCE.JS и эмуляции.
    2.2. Модифицируем аппаратные прерывания.
    2.3. "Среда разработки".

    3. Возможные пути практического применения.
    3.1. Защита и обфускация front-end-связанной логики - насколько это возможно на самом деле?
    3.2. Benchmarks.
    3.3. Другие пути применения.

  • На основе данных, накапливаемых и хранимых в инфраструктуре рекламной системы MAIL.RU (HDFS, поток данных ~100K записей в секунду), проводится машинное обучение классификаторов, позволяющих разделять различные группы пользователей Интернета.

    Для представления признаков, характеризующих конкретный обучающий прецедент, используется модель bag-of-words, в рамках которой векторы признаков имеют большую размерность и являются разреженными. Уменьшение размерности пространства признаков методом латентного размещения Дирихле (LDA) позволяет в ряде случаев также проводить тематическое моделирование распределения признаков.

    Рассматриваются две практические задачи: (1) разделение пользователей на два класса в соответствии с требованиями таргетированной рекламной кампании; и (2) предсказание месячного дохода пользователя.

    Классификаторы, обучаемые как на разреженных (логистическая регрессия, Lasso, ElasticNet), так и на сжатых векторах признаков (SVM), демонстрируют приемлемое качество (ROC-AUC, Precision/Recall, MSE) на валидационных и тестовых выборках.

  • PostgreSQL играет важнейшую роль в инфраструктуре Zalando: там хранится всё – от информации о клиентах и до данных статей, а также PostgreSQL обеспечивает надёжное резервирование нашим системам управления складами, работающим в реальном времени. Начиная с версии 9.0 мы используем каждый релиз PostgreSQL в продакшне, и с каждым следующим релизом PostgreSQL нравится нам всё больше и больше.

    Я хочу рассказать о том, как мы развёртываем, настраиваем, мониторим и используем базы данных PostgreSQL для обеспечения работы наиболее быстро растущей и самой крупной в Европе платформы электронной коммерции в области моды.

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

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

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

    * Как сделать так, чтобы клиент не "завалил" сервер?
    * Коммуникация ошибок от сервера к клиенту.
    * Синхронизация, разрешение конфликтов.
    * Работа в offline-режиме.
    * Разработка эффективного и корректного API.
    * Асинхронное взаимодействие.
    * Почему клиент и сервер на самом деле очень похожи?

  • Описание основных аспектов доклада:
    - краткая справка: Docker, Puppet;
    - зачем мы начали использовать еще одну технологию;
    - как сделать перезапуск сервиса без downtime;
    - забота об окружающей среде: используй всю мощность сервера;
    - etcd & confd: если уже слышали, поговорим об этом вместе;
    - почему Puppet все еще важен и нужен;
    - чего не хватает для счастья в Docker.

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

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

    При создании нашей аналитической системы мы использовали Amazon Redshift в качестве основного хранилища данных, PostgreSQL для получения информации из БД сайта, MongoDB для кэширования персонализированных рекомендаций и Chart.io для визуализации.

  • MongoDB имеет горизонтально масштабируемую архитектуру. Шардируя свой MongoDB-кластер, вы можете увеличить его вычислительные мощности, будь то дисковое пространство, ОЗУ или ЦП. Шардинг – встроенная функциональность, шардинг и решардинг для данных выполняется автоматически, и возможность подключения к клиенту совершенно прозрачна.

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

  • Компания Intel недавно представила процессоры линейки Intel Xeon E5 v3. Новые процессоры отличаются надежной микроархитектурой, более быстрой памятью, более широкими шинами, большим количеством ядер, более высокой тактовой частотой. Благодаря нововведениям удалось добиться существенно повышения производительности.

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

  • - Автоматическое распределение данных по партициям, а также чтение, обновление и удаление данных без единой правки кода.
    - Автоматическое обновление структур партиций (индексы, ограничения (constraints), триггеры, правила (rules) и т.д.).
    - Удобные и гибкие миграции для больших команд с большим количеством данных, хранимых процедур, представлений, таблиц, типов, миграций, дельт и т.п. Как это всё организовать и поддерживать?
    - Инструменты и утилиты, которые мы используем для вышеперечисленных целей.

  • На основе модели вычислений MapReduce производится обработка логов дарения подарков ОК, хранящихся на Hadoop-кластере для фильтрации и расчета меры схожести подарков. Подготовленные данные кластеризуются на суперкомпьютере с использованием библиотеки MCL.

  • PostgreSQL: Ups, DevOps... Алексей Лесовский

    Когда админы были маленькими, а компьютеры большими, настройка нового сервера была маленьким праздником. Сегодня настройка десятка серверов - рутина. Вручную уже лень, рано или поздно возникает желание написать пару скриптов, которые сделают всю работу сами. Через полдня появляется чудо-скрипт. Однажды начав, сложно остановиться, и через месяц скриптов уже двунадесять, а через год уже никто точно не знает, сколько их и какие правильные. Автоматизация добралась до всех уголков инфраструктуры: настройка ОС, установка пакетов, развертывание app-серверов, развертывание приложений, базы данных... Базы данных? Хм, базы данных... Что-то здесь слишком много ручных операций, да и слишком критичная часть инфраструктуры: один неверный шаг - и 15 лет расстрела.

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

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

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

    Мы представим пример построения подобной системы с использованием RabbitMQ Federation для копирования данных из регионов AWS и реализованной в RabbitMQ поддержки множества протоколов для производства и потребления данных.

    Будет показан интересный способ реализации шардированных очередей с применением RabbitMQ и Consistent Hash Exchange, которые помогут нам с масштабированием.

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

    Справка о RabbitMQ

    RabbitMQ - это совместимый с многими языками и протоколами сервер сообщений с клиентами для многих языков программирования, включая Ruby, node.js, Python, PHP, Erlang и многие другие.

    У брокера RabbitMQ очень активное Open Source сообщество с более чем 1000 связанных проектов на Github. Наименьшее среднемесячное число обращений в сообществе RabbitMQ превышает 700 сообщений в месяц, разработка происходит при непосредственном участии ключевых ​​разработчиков, что делает RabbitMQ брокером, который постоянно совершенствуется на основе обратной связи от пользователей.

    RabbitMQ помогает масштабироваться стартапам (Instagram), обеспечивает стабильную работу медийных компаний (The New York Times) и госучреждений (Национальная служба здравоохранения Великобритании) - и это лишь несколько примеров.

  • Highway to Continuous Integration Денис Трифонов

    В своем докладе я поделюсь опытом внедрения Continuous Integration в наши процессы. Я расскажу, как мы используем Jenkins в качестве CI-сервера, какие задачи мы решаем с его помощью и с помощью других инструментов. Вот основные из них:
    - развертывание и конфигурирование приложений и тестов с помощью Open Stack и Chef;
    - запуск функциональных тестов с помощью PHPUnit и параллельное выполнение с помощью Paratest;
    - обновление окружения и тестирование задачи в ветке с последующим вливанием в master-ветку;
    - ежедневная регрессия на master-ветке и откат до состояния последнего релиза, а также тестирование развертывания с нуля.

    Я затрону интеграцию с JIRA для наших процессов и решения других задач для разработки и тестирования.

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

  • "Авито" является одной из крупнейших интернет-компаний РФ. Наш сайт регистрирует сотни миллионов событий в сутки. Руководству необходима развернутая отчетность об интернет-трафике, в том числе о количестве уникальных посетителей и сессий. Отчетность должна быть очень детализированной, точной, допускать разнообразный ad-hoc анализ. Главная проблема в расчете подобной аналитики - количество уникальных посетителей не аддитивно по иерархическим измерениям (география, продуктовый каталог и т.п.).

    Вертика отлично справляется с поддержкой аддитивных мер на десятках миллиардов строк исходных данных, но когда возникла необходимость поддерживать не аддитивные меры, считающиеся по иерархическим измерениям, нам пришлось реализовать аналог алгоритма MapReduce поверх SQL-движка HP Vertica.

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

  • ЦЕЛЬ
    Реализация узла PCRF согласно спецификации 3GPP для обслуживания 60 миллионов абонентов оператора связи. Упрощенно PCRF – это приложение, которое принимает решение о скорости предоставления услуги абоненту. При принятии решения учитываются такие факторы, как тарифный план абонента с его опциями и турбо-кнопкой, его местоположение в сети, перегруженность сети и другие. К приложению предъявляются следующие требования: поддержка георезервирования, масштабирования, резервирования внутри одного дата-центра, а также работа в режиме 24/7, обеспечение скорости реакции, близкой к real-time, обслуживание не менее 10К запросов в секунду на одном узле.

    РЕШЕНИЕ
    Достижению цели способствовали архитектурные решения, которые обеспечили реализацию требований по масштабируемости и резервируемости, а также решения, связанные с проектированием (design), которые обеспечили реализацию требований к производительности одного узла. Основные принятые архитектурные решения – это избыточность (redundancy) и поддержка ftlb-стратегий (fault tolerance & load balancing). Основные решения, связанные с проектированием (design), это парализация задач без единой точки синхронизации, создание кэша, разбитого на сегменты для отсутствия единой точки синхронизации, разнесение получения данных из сети и их декодирования по разным потокам, использование собственного менеджера памяти.

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

  • Ликбез по Эльбрусу Константин Трушкин

    - Немного истории: как появилась компания МЦСТ - основные вехи.
    - Что сделано на сегодня: линейки процессоров, особенности архитектуры Эльбрус, оценка производительности.
    - Планы на ближайшее будущее, новые модели процессоров.
    - Когда можно ожидать появления массовых и дешёвых машин на основе процессоров Эльбрус.

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

    Более подробно в презентации на английском: http://momjian.us/main/writings/pgsql/central.pdf

  • Webscale backups for MySQL Алексей Копытов

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

    - что выбрать: mysqldump, mydumper, mylvmbackup, XtraBackup или коммерческие решения?
    - оптимизация резервного копирования больших объёмов данных;
    - проблемы блокировок сервера во время создания резервных копий;
    - проблемы, связанные с большим количеством таблиц;
    - эффективное создание инкрементальных резервных копий;
    - эффективное создание частичных резервных копий и частичное восстановление;
    - проверка целостности резервных копий на больших объёмах данных;
    - хранение резервных копий в "облаках".

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

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

  • Большая часть интернет-контента сегодня динамическая, и в основном (более чем на 90% по последним оценкам) это PHP. LiteSpeed Web Server (LSWS) помогает ускорять сайты, обслуживая PHP быстрее других веб-серверов. Он также прост в использовании, поскольку запускается с использованием настроечных файлов Apache.
    LSWS предлагает 3 различных режима работы PHP для разных ситуаций. В своём докладе я расскажу о преимуществах и недостатках различных режимов LSWS для PHP – включая более эффективное использование памяти, более высокую скорость, общее кэширование кодов операций suEXEC и т.д. Я также представлю результаты benchmark-тестов и исследую кейсы со сравнением режимов LSWS и различных реализаций NGINX и Apache. Согласно нашим тестам, LSWS обслуживает небольшие файлы PHP до 2х раз быстрее по сравнению с NGINX и до 40 раз быстрее, чем Apache 2.4 с помощью suPHP. В завершении доклада я расскажу об установке LSWS в Apache-окружении менее чем за 10 минут.

  • Миллиард в секунду – это к нам. Первая большая презентация проекта "волшебного транспорта".

    1Hippeus – инфраструктура обмена сообщениями, ориентированная на предельно эффективное zero-copy & lockfree-взаимодействие через разделяемую память, RDMA, MPI, коммуникации с GPU, сетевыми адаптерами, SDN & NFV, гипервизоры. Это инфраструктурный проект, который станет Open Source уже в первом релизе.

    Грубо говоря, 1Hippeus позволяет вам сформировать и передать сообщение в соседний поток (thread), в ядро или через гипервизор, в другой процесс или на другой сервер в кластере, с накладными расходами как при вызове функции. Это изменит парадигму взаимодействия, не так ли?

    1Hippeus is a AGPL/LGPL library, that act as framework and brings together:
    - zerocopy & lockfree message pump and streaming;
    - operation with shared memory in different address spaces;
    - 0mq, netmap, dpdk.org & Infiniband/MPI as non-local transports;
    - efficient representation for chains of memory blocks with C++ iterators;
    - buffers management and allocation.

    Hippeus или ippeuß – это всадник в войсках Спарты. Название выбрано с минимальным символизмом. Спарта – потому что все жестко, минимум компромиссов. Один – это первый, чемпион и даже «один в поле воин». А еще его саркастически можно называть «гиперконем», «гиппопотамом» или «конем в вакууме» ;)

    Цель 1Hippeus – предоставить предельно эффективную, но минималистичную инфраструктуру для обмена сообщениями в пределах физически единой RAM, а также в кластере посредством DMA/RDMA.

    Обмен в «физически единой RAM» включает варианты взаимодействия процессов в user-mode, модулей ядра, сопроцессоров (Tesla, Xeon-Phi), гостевых ОС в пределах одного гипервизора. А буквы DMA/RDMA подразумевают непосредственную стыковку с кольцом дескрипторов сетевой карты (NIC's DMA-RING) подобно Intel DPDK или Netmap.

    Может показаться, что подобные средства уже есть, но это не так. Картина сильно меняется, если решать задачу действительно эффективно и рационально. Например:
    - MPI является ближайшим промышленным решением, однако даже в случае локального обмена производится копирование данных.
    - DPDK и Netmap просто дадут вам прямой доступ к очередям приема/передачи сетевых карт, но работать придется с сетевыми пакетами на самом низком уровне, включая (де)сериализацию данных.

    Со своей стороны, 1Hippeus ориентирован на предоставление интерфейса и механизма обмена сообщениями, а также инфраструктуры их формирования, причем так, чтобы объем накладных расходов при отправке сообщения был сопоставим с вызовом функции, независимо от объема данных. Это делает 1Hippeus непохожим на другие решения.

    Простой продуманный интерфейс позволяет получить больше. Например, под интерфейсный "фасад" 1Hippeus могут быть подведены другие средства обмена сообщениями - такие, как MPI или 0MQ. Кроме того, реализация транспорта может быть вынесена в отдельный процесс. При этом сохранится тот же минимум накладных расходов.

    Среди планов хотелось бы выделить обеспечение надежных соединений на основе собственных идей, реализованных когда-то в российской версии TDM/IP. Суть в том, что вы задаете максимальную задержку в передаче данных, которую можете себе позволить, исходя из бизнес-логики. Со своей стороны, 1Hippeus либо «поглотит» все проблемы опорной сети без превышения заданного лимита, либо сообщит о проблеме. Другими словами, поведение транспортной подсистемы становится прозрачно-прогнозируемым и детерминированным, а вы можете балансировать между надежностью и скоростью, «подкручивая» только один параметр.

    Остальная масса информации, включая то, как всё это устроено — на конференции.

  • Использование Hadoop в Badoo Валерий Старынин

    Тезисы
    Мы используем Hadoop для сохранения всего click stream с сайта и серверов мобильных приложений - это порядка 1 миллиарда событий в день. А еще мы собираем и анализируем действия пользователей с северной и клиентской стороны - это еще порядка миллиарда событий в день.
    Как все это организовать, запустить и использовать, что можно и что нельзя сделать с помощью Hadoop - об этом будет мой доклад.

    Описание

    В Badoo мы собираем и анализируем большое количество статистической информации. Настолько большое, что сейчас мы просто обязаны думать о масштабировании и параллелизации систем сбора, хранения и отчетов (reporting). Именно для хранения более полной информации, облегчения масштабирования и ускорения получения отчетов мы стали применять Hadoop. Каких результатов мы смогли добиться, какие задачи еще стоят перед нами и какие ограничения мы выявили для себя - обо всем этом я и расскажу в докладе.

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

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

    Вторая часть доклада будет посвещена расширяемости JIRA, рассказу о том, что можно сделать с помощью её системы плагинов. Представлю наш собственный плагин jira-agent - написанная нами система онлайн-оповещения о новых событиях (плагин бесплатно доступен через Atlassian Marketplace). Также я приведу примеры тех плагинов, которые решают наши уникальные задачи и не могут быть использованы кем-то ещё, но которые демонстрируют разнообразие возможностей системы.

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

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

    Для справки: служба поддержки Atlassian считает нашу инсталляцию JIRA самой сложной в мире по количеству плагинов. Количество настроенных проектов в данный момент - более двухсот.

  • Анатомия веб-сервиса Андрей Смирнов

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

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

    Мы обсудим различные варианты архитектуры веб-сервисов, посмотрим на популярные веб-фреймворки на различных языках программирования (Ruby, Python, Go, Java), а также выясним, какие модели они предлагают и как эти модели реализованы.

  • Real-time bidding требует real-time аналитики. RuTarget обрабатывает миллиард запросов на показ баннеров в день. Как определить, например, сколько в этих запросах уникальных пользователей? Доступно расскажем о рандомизированных алгоритмах потоковой обработки данных, вероятностных структурах данных и объясним, как быстро и с вычислительной точки зрения дешево получить нужный результат.

    Основные тезисы
    1) Какие данные у нас есть, и почему их много?
    2) Trade-off: точность vs. нагрузка на инфраструктуру.
    3) Вероятностные структуры данных для data mining - что это такое?
    4) HyperLogLog - метод подсчета числа уникальных элементов в потоке данных.
    5) Large scale, временное окно.
    6) Примеры из реальной жизни.
    7) Count-Min, Summary-Sketch и т.д.

  • После долгого доминирования дисковой структуры данных для СУБД и файловых систем, B-деревья стали медленно вытесняться структурами данных, оптимизированными для операций записи, что позволяет ускорить обработку постоянно растущих объёмов данных. Для достижения этой цели некоторые методы оптимизации для операций записи (например, LSM-деревья) частично жертвуют производительностью запросов B-дерева.
    Фрактальное дерево представляет собой структуру данных, оптимизированную для операций записи, которая сочетает в себе производительность операций вставки при сохранении оптимальной производительности запросов B-дерева. Фрактальное дерево было создано под влиянием многих структур данных (таких, как буферные деревья репозиториев, B^ε деревья и т.д.), но по-настоящему соответствует определению такого дерева наша реализация в Tokutek.
    Я дам вводную информацию о B-деревьях и LSM-деревьях, в общих чертах объясню, как работают фрактальные деревья, чем они отличаются от B-деревьев и LSM-деревьев, и как мы используем их преимущества в плане производительности – как в достаточно очевидных ситуациях, так и в довольно нетривиальных, для поддержки новых возможностей MySQL и MongoDB в TokuDB и TokuMX.

  • Для нас CD — это когда менеджер или релиз-менеджер с помощью одной «кнопки» может выкатить весь продукт «в бой». При высокой связности, распределённости продукта и всех проверках выполнить такую задачу непросто, и делается это небыстро.

    На примере Справочного API 2ГИС я расскажу, как мы сделали для менеджеров эту «кнопку». Расскажу про workflow, о том, как мы используем Jenkins для сборки, Rundeck для администрирования релиза, Яндек.Танк для нагрузок, Chef для конфигурирования серверов.

  • Юлмарт. История создания Дмитрий Завалишин

    Дмитрий Завалишин (экс-начальник отдела разработки портала компании Яндекс, создатель Яндекс.Маркета, в настоящее время - генеральный директор группы компаний DZ Systems) расскажет историю создания веб-платформы крупнейшего в России электронного кибермаркета. Бизнес-задачи, методика управления проектом и взаимодействие с заказчиком, проблемы интеграции, архитектура и другие детали этого проекта федерального масштаба.

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

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

    До недавнего времени браузеры сами по себе были вполне конкретным приложением с поддержкой конечного и определенного производителем списка протоколов уровня приложения. Можно было использовать HTTP(S) и иногда FTP. Помимо этого, были "песочницы" Java, Flash и прочего байткода, а также существовал "зоопарк" браузерных расширений. Казалось бы, чего еще желать, но доставка браузерных расширений до конечного пользователя оказалась настолько колоссальной проблемой, что об нее разбивались целые компании!

    Потом в муках родился WebSocket, за ним на свет пополз WebRTC. Примерно в это же время и замерла в неопределённом состоянии свобода создавать свои протоколы уровня приложения, "дружит"ь с уже существующими или совмещать эти два подхода.

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

    Картинки, цифры и кейсы из нашего опыта идут в комплекте.

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

  • Высоконагруженный проект должен не только предоставлять быстрый и качественный сервис, но и окупать себя. Нам приходится бороться не только за проценты, увеличивающие производительность и надежность, но и за процент проведенных транзакций. При большом объеме платежей разница в 1% может быть внушительной и окупать все затраты.

    Я расскажу о том, как устроен биллинг в таком большом международном проекте, как Badoo, расскажу про возникавшие по мере роста проблемы, продемонстрирую архитектуру, к которой мы в итоге пришли, и объясню, почему она получилась именно такой. Отдельная подтема - то, как мы «готовим» процессинг кредитных карт и как он устроен. Также я расскажу про рекуррентные платежи, процессе разработки и мониторинге

Перед стартом HighLoad++ 2014

Мы завершаем последние приготовления к восьмой конференции разработчиков высоконагруженных систем HighLoad++ 2014. Вот статистика роста количества участников HL++ за последние три года.

рост количества участников HighLoad++

В этом году мы ставим планку в ДВЕ ТЫСЯЧИ участников! Попробуем сделать самую крупную не только в России, но и в Европе профессиональную IT-конференцию. Вы с нами? :)

Конференция пройдет в Москве, точные даты — 31 октября и 1 ноября. Количество потоков — 5 (включая учебный трек), общее количество докладов, традиционно отобранных нашим самым жёстким Программным комитетом — 85!

Тематика конференции остаётся той же — всё, что так или иначе входит в сферу интересов элиты программистов - разработчиков высоконагруженных, масштабных и сложных проектов: базы данных и системы хранения, масштабируемые архитектуры, видео, системное администрирование, поиск, тестирование, cмежные технологии.

Варианты участия

главный зал

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

Конференция не доступна в онлайн-трансляции, но вы можете приобрести онлайн-трансляцию Учебного трека.

В личном кабинете можно заказать билеты. Текущая цена — 24 000 рублей.

Удачи и до встречи на Конференции!

Для участников

Использование скидочных кодов
Важная информация относительно ввода партнёрских скидочных кодов на участие в HighLoad++ 2014. Картинка-скриншот с инструкцией по вводу доступна при переходе по ссылке.
Рекомендации по размещению иногородних участников
Иногородние участники конференции разработчиков высоконагруженных систем HighLoad++ 2014 могут получить скидки на размещение в отеле Crowne Plaza Moscow WTC при переходе по данной ссылке.
Тематика конференции
Темы выступлений — все аспекты разработки и поддержки высоконагруженных систем: проектирование, алгоритмы, разработка, тестирование, архитектура, базы данных, системы хранения, поддержка, системное администрирование, железо, хостинг, управление. Все через призму больших проектов, высоких нагрузок: сотни тысяч пользователей, десятки миллионов хитов, десятки гигабайт данных, терабайты трафика.
Стоимость участия
Цена участия в конференции зависит от даты оплаты — она будет меняться от 13 000 до 24 000 рублей. В стоимость входит питание, раздаточный материал и право посещения двух дней конференции.
Место проведения конференции
В 2014 году конференция пройдет в Москве в "Центре Международной Торговли" на Красной Пресне 31 октября и 1 ноября. Продолжительность — два полных дня. Первый доклад начинается ежедневно в 10:00, а последний заканчивается в районе 18:00. Регистрация открывается в 9:00 утра.

Новости

Будет или нет онлайн-трансляция HighLoad++ 2014?
Онлайн-трансляции конференции в этом году не будет, зато будет онлайн-трансляция УЧЕБНОГО ТРЕКА!
Корпоративное обучающее предложение для IT-компаний от команды HighLoad++
Хотите больше зарабатывать и развиваться быстрее?
Программа HighLoad++ 2014 сформирована: сборник тезисов в PDF
85 докладов, 8 секций основной программы + учебный трек: продолжаем рассказ о ключевых докладах!
DDoS-атаки на HighLoad++: вор должен сидеть в тюрьме! (с)
Защита от DDoS-атак на трёх уровнях: программном, инфраструктурном и юридическом!
Бесплатный вебинар с рассказом про конференцию разработчиков высоконагруженных систем HighLoad++
Мы расскажем обо всём: программе, ключевых докладчиках, изменениях в формате, работе с экспертами, спонсорах, подарках - обо всём, что ждёт вас на мероприятии. Также ответим на все вопросы по докладам, расписанию и организации. Ссылка на вебинарную комнату: https://login.webinar.fm/ru/login/highload/.
Две недели до конференции HighLoad++!
Состав ключевой секции "Архитектуры" поможет Вам принять решение!
Базы данных и системы хранения
Список наиболее ожидаемых докладов секции от ключевых докладчиков HighLoad++ 2014 - не пропустите!
Открыта запись на индивидуальные консультации экспертов HighLoad++ 2014!
Мы запустили сайт записи на консультации экспертов - http://experts.highload.ru/. Они будут БЕСПЛАТНЫМИ для всех участников конференции!
Разработчик Dropbox и автор Sentry на HighLoad++
Дэвид Крамер (David Cramer) предложил нам на выбор два доклада, каждый из которых достоин включения в программу. Какой лучше?
Что быстрее nginx'а? Узнайте на HighLoad++ :)
Майкл Армстронг (Michael Armstrong), представитель компании LiteSpeed Technologies, предлагает сравнить скорость работы PHP с разными веб-серверами и утверждает, что Nginx можно обогнать!

Спонсоры конференции

  • Nutanix
  • Webzilla
  • Badoo
  • Parallels
  • Филанко
  • Treatface
  • Selectel

Информационная поддержка

  • SQLInfo.ru
  • Интернет Хостинг Центр
  • Sports.ru
  • Rusonyx
  • Adriver
  • SuperJob
  • REG.RU
  • ООО «Юмисофт»
  • Агава
  • PCWeek
  • PС Мagazine
  • Bugtraq.ru
  • TRINET
  • FL.ru
  • Телеканал «Конференция ТВ»
По любым вопросам обращайтесь:
Бухгалтерия и вопросы оплаты :
Олег Бунин , +7(495) 646-07-68
Организационный комитет :
Олег Бунин , +7 (495) 646-07-68
Программный комитет :
Олег Бунин , +7 (916) 635-95-84
Горячая линия :
+7 (495) 646-07-68, ежедневно с 10 до 22

Почтовый адрес:
119180, Москва, Бродников пер., д. 7 стр. 1, +7 (495) 646-07-68 ООО «Онтико»

Rambler's Top100
Рейтинг@Mail.ru