HighLoad++

  • Как известно, что не измеряется, то нельзя улучшить. И если замеры на бэкенде (сколько времени выполняются запросы к базе, как быстро генерируются страницы, сколько запросов в секунду может обрабатывать веб-сервер) выполняют почти все разработчики, то 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).

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

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

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

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

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

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

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

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

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

    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 Константин Осипов (mail.ru, tarantool), Алексей Рыбак (badoo)

    Совместный доклад с Костей Осиповым. В черновом варианте: на примере опыта badoo и tarantool'а представим наиболее часто встречающиеся паттерны и анти-паттерны горизонтального масштабирования баз данных.

  • Как обычно, подведем итоги года с аналитикой за прошедших 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

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

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

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

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

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

  • Беспроводной доступ для участников Highload. Павлов Александр Владимирович

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

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

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

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

    На github и остальном интернете не нашлось решения позволяющего за допустимо короткий промежуток времени (<50ms) сопоставлять большой сложноструктурированный документ с миллионами предикатов, поэтому мы в 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 запросов, под такое решение для обработки нашего потока данных действительно требовался мозный кластер, при этом как вы понимаете ни о каком частичном соответствии речи не идёт.

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

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

  • Тезисы:
    · Общая архитектура: история создания, распределение нагрузки, отказоустойчивость
    · Логи скриптов: сбор, индексация, различные виды просмотра
    · Влияние 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, программном стеке и платформах по централизованному управлению и оркестрации.

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

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

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

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

    Есть ли у вас необходимые данные, чтобы решить, стоит ли идти на такой компромисс? Достаточно ли будет тех пользователей, которые будут согласны ждать дольше при загрузке страницы, чтобы получить новую функциональность? Насколько терпеливы ваши пользователи сейчас, и сделают ли их новые возможности системы более или менее терпеливыми?

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

  • Про 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, хеширование и проч.).

  • Гипервизор сегодня превращается в 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 минут.

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

    Чисто обзорный/информационный доклад для начинающих HighLoader'ов :)

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Монетизация сайтов в Рунете отличается от монетизации сайтов в Европе/США отсутствием возможности апеллировать к капитализации компании через оценку потенциальной стоимости аудитории, это приводит к проблеме "ценовых ножниц" - стоимость обслуживания каждого посетителя сайта растет, а непрямая монетизация через рекламу не обеспечивает пропорционального роста. Эта проблема заставляет оптимизировать код и инфраструктуру высоконагруженного проекта - постоянно добавлять функциональность с одновременным уменьшением используемых ресурсов в пересчете на одного пользователя проекта.
    В рамках доклада будут рассмотрены:
    - кейс проекта ИМХОнет (www.imhonet.ru) с миграцией на гетерогенную инфраструктуру (public cloud + dedicated servers + cloud storage + CDN)
    - кейс проекта 4talk.im
    и ряд других кейсов, будут даны практические рекомендации по выбору - физика или облако, покупка или аренда, использование/не использование CDN.

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

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

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

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

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

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

  • Тезисы
    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. Другие пути применения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • - Автоматическое распределение данных по партициям, а также чтение, обновление и удаление данных без единой правки кода.
    - Автоматическое обновление структур партиций (индексы, ограничения (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-ветке и откат до состояния последнего релиза, а также тестирование развертывания с нуля;
    - нагрузочное тестирование с помощью Яндекс.Танк и Graphite, подготовка логов с продакшна из ElasticSearch и построение отчетов с текущими и предыдущими результатами нагрузки.

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

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

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

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

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

  • Как обслужить 60 миллионов абонентов? Руфанов Артем Владимирович

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

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

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

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

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

  • Какая вообще в природе бывает репликация (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 минут.

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

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

    Описание:

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

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

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

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

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

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

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

  • 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, и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 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.

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

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

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

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

  • 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 !

  • На сегодняшний день наиболее популярным алгоритмом сжатия отправляемых с веб-сервера данных является 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 миллисекунд.

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

  • На сегодняшний день DoS-атаки являются популярным инструментом, успешно используемым целым рядом злоумышленников - преступными группировками, недобросовестными конкурентами, политическими организациями и даже правительствами. Это способствует постоянному развитию и совершенствованию методов их проведения. Многие атаки сетевого и сессионного уровней сегодня успешно блокируются на уровне операторов связи и с помощью облачных сервисов, однако вопросам защиты от атак уровня приложений зачастую не уделяется достаточно внимания.
    В докладе мы расскажем о современных методах DoS- и DDoS-атак и о способах защиты от них с точки зрения системных администраторов и специалистов по ИБ. Мы продемонстрируем на стенде модель enterprise-сети и в ходе презентации будем осуществлять реальные атаки на инфраструктуру и приложения с помощью продуктов Ixia. Рассмотрим различные виды атак и продемонстрируем как отбивают эти атаки те или иные продукты (межсетевые экраны, системы предотвращения вторжений, cредства защиты от 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 оборудования, решений в области ИБ, нагрузочного тестирования и опорных сетей.

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

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

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

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

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

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

  • Если вы слышали о протоколе 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, как мы оценивали эффективность нашего подхода, и какие сюрпризы нам преподнесла действительность.

Бесплатный вебинар с рассказом про конференцию

Такое вложение, как покупка дорого билета на двухдневную конференцию, требует обдумывания и ответов на множество вопросов. Мы готовы эти ответы предоставить!

В ближайшую среду, 22 октября, в 19:00 по Московскому времени состоится бесплатный вебинар, где все темы HighLoad++ будут полностью раскрыты.

  1. Мы подробно рассмотрим программу конференции, Программный комитет опишет ключевые доклады и расскажет о программе в целом;
  2. Мы расскажем об учебном треке, зачем его ввели и что в него войдёт;
  3. Эксперты и консультации у экспертов - как этим пользоваться и почему это самая крутая идея за последние несколько лет;
  4. Мы расскажем, почему в этом году мы изменили схему работы со спонсорами и к чему это привело;
  5. Западные докладчики, влияют ли на нас санкции и кого мы пригласили в этом году;
  6. И ответим на любые организационные вопросы;

И вообще все, что вы хотели спросить, но не спрашивали, потому что такой опции просто не было. Теперь — есть! Мы ответим на все вопросы о том, что вас ждёт в конце октября на крупнейшей IT-конференции Европы.

Доступ

Ссылка на комнату для бесплатного вебинара будет опубликована на этой странице позднее.

Регистрация

Календарь

Внесите это событие в ваш календарь:

Add to Calendar 22-10-2014 19:00:00 22-10-2014 20:00:00 61 Бесплатный вебинар с рассказом про конференцию разработчиков высоконагруженных систем HighLoad++ Рассказ о программе, ключевых докладчиках, формате, работе с экспертами, спонсорах - обо всём, что ждёт вас на конференции. Вебинар Конференции Олега Бунина support@ontico.ru false DD/MM/YYYY

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

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

Новости

Бесплатный вебинар с рассказом про конференцию разработчиков высоконагруженных систем HighLoad++
Мы расскажем обо всём: программе, ключевых докладчиках, изменениях в формате, работе с экспертами, спонсорах, подарках - обо всём, что ждёт вас на мероприятии. Также ответим на все вопросы по докладам, расписанию и организации
Две недели до конференции HighLoad++!
Состав ключевой секции "Архитектуры" поможет Вам принять решение!
Базы данных и системы хранения
Список наиболее ожидаемых докладов секции от ключевых докладчиков HighLoad++ 2014 - не пропустите!
Открыта запись на индивидуальные консультации экспертов HighLoad++ 2014!
Мы запустили сайт записи на консультации экспертов - http://experts.highload.ru/. Они будут БЕСПЛАТНЫМИ для всех участников конференции!
Разработчик Dropbox и автор Sentry на HighLoad++
Дэвид Крамер (David Cramer) предложил нам на выбор два доклада, каждый из которых достоин включения в программу. Какой лучше?
Что быстрее nginx'а? Узнайте на HighLoad++ :)
Майкл Армстронг (Michael Armstrong), представитель компании LiteSpeed Technologies, предлагает сравнить скорость работы PHP с разными веб-серверами и утверждает, что Nginx можно обогнать!
Подробная программа второго вебинара из серии "Пошаговый алгоритм проектирования высоконагруженной системы"
Эксплуатация, мониторинг, быстрая и долгосрочная оптимизации, поиск, статистика и ответы на вопросы - всё это на втором вебинаре Олега Бунина по высоконагруженным системам уже завтра!
Олег Царёв об устройстве репликации в MySQL
Нам удалось уговорить Олега Царёва, отличного эксперта по базам данных, выступить на HighLoad++ с мега-докладом!
Лучшие видео HighLoad++ бесплатно в обмен на обратную связь
Заполняйте наш простой опрос и получайте ссылки на видео прошлых лет!
Международная конференция Lean Kanban Russia наконец в Москве!
Наши партнёры предоставили скидку на участие в этой конференции - 10% по промокоду highload!

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

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

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

  • SQLInfo.ru
  • Интернет Хостинг Центр
  • Sports.ru
  • Rusonyx
  • Adriver
  • SuperJob
  • REG.RU
  • ООО «Юмисофт»
  • Агава
  • PCWeek
  • PС Мagazine
  • Bugtraq.ru
  • 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