HighLoad++ Junior 2016

31 мая - 1 июня 2016
Сколково, Россия
Обучающая конференция разработчиков высоконагруженных систем
Купить видео
В избранное

Николай Сивко

Сооснователь в okmeter.io

Даниил Подольский

Архитектор и разработчик в Arilot

Михаил Кириллов

Инженер и директор в CINEMOOD

Антон Баранов

Системный администратор Linux в ITSumma

Игорь Мызгин

Специалист по взаимодействию с ключевыми партнерами и клиентами в Servers.ru

О мероприятии

Доклады конференции рассчитаны на небольшие команды, работающие в реальных условиях с реальными проектами. Те случаи, когда нет ресурсов на rocket science, но нагрузку держать необходимо, когда у тебя не сто, а один или два сервера. HighLoad++ для дизайн-студий, Простые решения сложных задач для малых команд в условиях ограниченных ресурсов. Девиз конференции: "Главное — работает!"

Для кого

  • Техническим директорам
  • Тимлидам
  • Архитекторам данных
  • Разработчикам
  • Системным аналитикам
Поделиться

Расписание

Развернуть все
31 мая (вторник)
День 1
Показать
цену в
$
Получить доступ ко всем докладам
Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Николай Сивко

Сооснователь в okmeter.io

Жизнь проекта на production: советы по эксплуатации

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

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

Расскажу на примерах о том, что всё всегда ломается, но с этим можно жить.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Даниил Подольский

Архитектор и разработчик в Arilot

NoSQL — неспроста ли это "ЖЖЖ"?

NoSQL — это слово громко "жужжит".

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

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

Попробуем еще раз.

NoSQL — это именно декларация отказа от некоторых паттернов.

- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?

На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Михаил Кириллов

Инженер и директор в CINEMOOD

Веб-разработка без наркотиков с помощью PostgreSQL, Nginx и c2h5oh

Разговор в докладе пойдёт о веб-программировании. 

При изготовлении веб-проектов то и дело пользуются широко распространёнными фреймворками на базе языков программирования — PHP, Python, Perl, Ruby, Go, Rust, Java и т.п.

Я предлагаю отказаться от употребления оных и использовать для разработки веб-приложений только c2h5oh — расширение для высокопроизводительного сервера nginx. Данное расширение позволяет эффективно использовать PostgreSQL в качестве сервера веб-приложений.

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

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Антон Баранов

Системный администратор Linux в ITSumma

Организация надежного резервного копирования веб-проекта. Практика и подводные камни

1. Общая информация
- Что именно нужно бэкапить?
- Типы бэкапов. Плюсы и минусы.
- Периодичность создания.
- Выбор хранилища.

2. Бэкапы БД и файлов
- Обзор инструментов.
- Источники данных для бэкапов.
- Неочевидные особенности создания/восстановления.

3. Проблемы организации резервного копирования
- Актуальность данных.
- Скорость восстановления.
- Надежность создания резервных копий.

4. Верификация бэкапов
- Тестовый стенд.
- Мониторинг процесса.
- Ручные проверки.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Игорь Мызгин

Специалист по взаимодействию с ключевыми партнерами и клиентами в Servers.ru

Как сравнить и выбрать хостинг-провайдера, или О чем умалчивают маркетологи

Под словосочетанием "услуги хостинга" в настоящее время подразумевается очень много различных услуг: VPS/VDS/аренда оборудования/облака/IaaS/PaaS/SaaS/колокейшн и каждая из этих услуг имеет очень много вариаций и реализаций у каждого провайдера. Любой проект имеет две условные стадии: 1) разработка, 2) production, и если среду разработки можно почти безболезненно переносить от провайдера к провайдеру, то перенос production зачастую сопряжен с трудностями.

В данном докладе будут рассмотрены следующие классы услуг:
1) "виртуальные сервера"/ VDS/ VPS/ облачные услуги/ "клауд".
2) аренда физических серверов и сопутствующие сервисы.

По каждому классу услуг будут:
1) описаны типовые нюансы, которые позволяют маркетологам провайдеров приукрасить свои предложения, при этом не допуская откровенной лжи в рекламе;
2) даны рекомендации — как в цифрах сравнить двух провайдеров одного класса услуг; также будут даны основные метрики, по которым стоит проводить сравнение;
3) указано, на что обратить внимание, а что является маркетинговой "фичей", которой гордится провайдер, но которая не нужна пользователям;
4) даны рекомендации, как оценить TCO для вас и вашего проекта, чтобы избежать при эксплуатации "откуда такие суммы в счете?!?! на сайте же обещали все за копейки!!!".

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

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Александр Демидов

Руководитель направления арендных решений в 1С-Битрикс

Мониторинг веб-проектов: real-time мониторинг и аналитика, поиск ошибок и "боевая" отладка

Многие веб-студии не имеют в своем штате системных администраторов. И зачастую узнают о проблемах с запущенными проектами уже после того, как они случились.

В докладе рассмотрим:
- Явные и не очень потери на медленном / недоступном сайте.
- Общие принципы внедрения систем real-time мониторинга.
- Мониторинг нетипичных характеристик (наличие бэкапов, делегирование домена и т.п.).
- Автоматизацию типовых реакций на алерты.
- Зачем нужна аналитика в мониторинге (пробуем предугадать проблемы до того, как они случатся).
- Инструменты и общие подходы быстрого поиска "узких" мест.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Очереди и блокировки. Теория и практик

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

Описано применение синхронных и асинхронных очередей, как построить очереди с приоритетами.

Будет сравнение разных серверов очередей: Redis, Tarantool, RabbitMQ, ZMQ, Kafka, Zookeeper, MemcacheQ и др., их преимущества и недостатки, где и какой брокер лучше использовать.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Андрей Тихонов

Разработчик в Avito

Кластеры баз данных: делаем сложные вещи просто

Порой в процессе развития высоконагруженного проекта наступает момент, когда необходимо масштабирование. Возможно, ваш проект впервые упёрся в производительность железа (и таким образом перешёл в разряд высоконагруженных); возможно, это уже не первое масштабирование — не важно. Какие же проблемы могут возникнуть?

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

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

План доклада:
- Введение. Методы масштабирования БД: репликация, шардирование.
- Создаём шардированные кластеры in-memory БД прозрачно для приложений: Twemproxy, Redis-proxy, Mcrouter.
- Уменьшаем накладные расходы от большого количества одновременных подключений на PostgreSQL с помощью PgBouncer.
- Создаём шардированный кластер PostgreSQL с помощью PL/Proxy.
- Добавляем прозрачную для приложения отказоустойчивость с помощью внутренних механизмов репликации БД и HAProxy.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Юрий Колесов

Специалист по безопасности клиентских веб-сервисов в security-gu.ru

Что делать, если пришел DDoS или Antiflood для бедных

1. Введение
Тема DDoS атак “сетевого” уровня (L4 и ниже) заезжена и раскрыта. Обычно эти атаки такой мощности, что справиться с ними server-side невозможно — они забивают канал на 100%.
Но есть атаки, которые влезают в канал и наносят не меньший урон. Это DDoS атаки на приложение, http flood. В случае атак на приложение сайт/сервер обычно ложится значительно раньше, чем будет забит канал. Такая атака тоже может забить канал, например, с помощью worpress xml rpc amplification (https://blog.sucuri.net/2015/10/brute-force-amplification-attacks-against-wordpress-xmlrpc.html). В этом случае меры борьбы такие же, как с атаками сетевого уровня.
Даже если вы используете сервис, который вас проксированием защищает от DDoS, этот материал будет полезен — сервисы часто пропускают флуд в количествах, достаточных чтобы вы испытывали трудности.

2. КАК ПОНЯТЬ, ЧТО ПРИШЕЛ DDoS
Так как этот доклад я читаю на конференции Highload, предполагаю что у вас есть мониторинг.
Полезные метрики, по которым можно предположить, что вас атакуют:
- Внешний мониторинг: проблемы с доступностью, ошибки, значительное замедление отдачи страниц, потери пакетов.
- “Внутренний” мониторинг: количество запросов в секунду, загрузка CPU, LA, количество запущенных процессов (если бэкенд форкается), загрузка сетевого интерфейса.

3. ЧТО ДЕЛАТЬ, ЕСЛИ ОНО СЛУЧИЛОСЬ
Обычная практика — анализ логов самописными скриптами или, например, fail2ban. Далее iptables/ipset. Недостатки — ресурсоемко, трудоемко, много ложноположительных срабатываний, трудно поддерживать списки.
Я использую возможности nginx. Это geoip, лимиты, модуль test_cookie.

3.1 ЧТО НУЖНО СДЕЛАТЬ ЗАРАНЕЕ
Чем быстрее работает ваш сайт, тем сложнее его заддосить http флудом. Первое действие — ускорение отдачи страниц. Особое внимание уделить скорости генерации 404 ошибки и формам.
Запретите методы, отличные от HEAD, GET. Разрешите POST (PUT и т.д.) только там, где он должен быть.
Настройте geoip. Добавьте в лог запись страны. Предусмотрите в конфиге map для блокирования по странам.
Выделите в конфиге nginx location, которые отдают статику и динамику. Расставьте разумные лимиты на число коннектов с одного ip, на число запросов к статике и динамике. Выделите “тяжелые” страницы в отдельные location. Добавьте отдельный лог на динамику, сэкономите время на grep в случае проблем.
Сделайте настройки для кэширования средствами nginx. Можно и нужно кэшировать POST. Кэширование можно не включать, но настроить. Лимиты, кстати, тоже.

3.2 ЧТО ДЕЛАТЬ, ЕСЛИ ПРИШЕЛ DDoS 
Если сервер нагружен так, что вы ничего не в состоянии делать — отключайте веб. Вы все равно практически лежите, но на еле работающем сервере вы будете разбираться намного дольше. Отключайте бэкенд — апач/php-fpm/unicorn и т. д. — то, что создает нагрузку. 
Далее беглый взгляд на логи. Если вы не ФБ — в логах еще можно разбираться “глазом” и грепом. Вам нужно либо отгрепать запросы на динамику, либо посмотреть в тот самый отдельный лог. Иногда сразу видно флуд, особенно, если вы представляете, как выглядит ваш обычный лог. Иногда не видно, тогда просто смотрите, каких запросов прибавилось. Возможно это не DDoS, а хабраэффект). Далее можно резать по странам, включать (или уменьшать) лимиты, запрещать часть функционала, включать кэширование (на часть функционала). 
Отдельно стоит test_cookie. Это последний рубеж обороны, если вы уверены, что вас атакуют боты, но атаку вы выявить не в состоянии — шаблон постоянно меняется или ботнет слишком велик, лимиты не спасают, geoip тоже. 
В каком объеме рассказывать про него — буду смотреть по времени. Скорее всего, совсем обзорно.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
01 июня (среда)
День 2
Показать
цену в
$
Основная программа

Антон Регеда

Технический эксперт в Juno

Принципы автоматического масштабирования приложения в AWS

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

Как в таком случае правильно вооружиться облачными технологиями? В чём магия AWS Autoscale и как стать магом? 

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

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Получить доступ ко всем докладам
Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

10 способов достижения HighLoad'а и BigData на ровном месте

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

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

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

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Александр Емелин

Программист в Mail.Ru Group

Centrifugo — open-source сервер real-time сообщений

Каждый разработчик может столкнуться с необходимостью внедрить в проект real-time сообщения — возможность с минимальной задержкой уведомлять пользователей о событиях в приложении.

В выступлении будут освещены транспорты и протоколы для трансфера real-time сообщений от сервера клиенту, существующие open-source решения, подводные камни на пути к работающему в боевой среде решению. От HTTP транспортов/протоколов мы перейдем к WebSocket’ам и затронем стандарт HTTP/2 в контексте применения для данной задачи.

Во второй части доклада я расскажу об open-source сервере real-time сообщений Centrifugo (https://github.com/centrifugal/centrifugo). Сервер написан на языке Go и обладает уникальными особенностями “из коробки”, выделяющими его из толпы (http://www.leggetter.co.uk/real-time-web-technologies-guide/) подобных решений:

- простота в использовании и интеграции с приложением. Сервер не завязан на язык программирования, предоставляя API для взаимодействия — таким образом, он может быть полезен разработчикам приложений на любом языке/фреймворке;
- возможность балансировки клиентов на несколько инстансов сервера;
- история сообщений в каналах, восстановление потерянных сообщений при кратковременных потерях соединения, информация о пользователях в канале, сообщения о подписке/отписке пользователя на канал;
- готовность к деплою — DEB/RPM-пакеты, docker-контейнер;
- возможность использовать с десктопными и мобильными приложениями.

Центрифуга используется в Mail.Ru и нескольких проектах по всему миру.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Роман Ивлиев

Директор по информационным технологиям в Банки.ру

Всему своё время

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

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

Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload? 
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы. 
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому". 
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?

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

P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Игорь Цупко

Технический директор в Notamedia

Сайт Москвы за 6 месяцев

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

Я расскажу об архитектурных приёмах организации SOA-облака, подходах к созданию API сервисов и подводных камнях, с которыми мы столкнулись, а также о средствах быстрого прототипирования в коде.

Кроме прочего, будет рассказано:
- как мы сделали гибкую архитектуру в mos.ru. Angular и API сервисов, индексация поисковыми машинами и мобильные приложения;
- причём тут Битрикс;
- типовые сервисы на Yii2. Как за 1-3 дня разворачивать микросервисы с админкой на Angular;
- загрузка файлов в сервисном облаке — куда же класть файлы в многосерверной системе;
- поиск по сервисам — какой способ проще, а какой правильнее.

Ну и конечно, мы поведаем о самом главном в гонке со временем: как вычищать за собой технический долг, чтобы через полгода не было мучительно больно за сделанный проект.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Александр Крижановский

Основатель и системный архитектор в Tempesta Technologies

Как Web-акселератор акселерирует ваш сайт

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

Еще я расскажу про еще один Open Source Web-акселератор - Tempesta FW. Уникальность проекта в том, что это гибрид Web-акселератора и файервола, разрабатываемый специально для обработки и фильтрации больших объемов HTTP трафика. Основные сценарии использования системы — это защита от DDoS прикладного уровня и просто доставка больших объемов HTTP трафика малыми затратами на оборудование.

- Что такое Web-акселератор, зачем он был придуман и как понять когда он нужен;
- Типичный функционал reverse proxy, его отличия от Web-сервера;
- Упомянем про SSL акселераторы; 
- Заглянем вглубь HTTP, и как он управляет кэшированием и проксированием, что может быть закэшированно, а что - нет; 
- Мы сравним наиболее популярные акселераторы (Nginx, Varnish, Apache Traffic Server, Apache HTTPD, Squid) по фичам и внутренностям; 
- Зачем нужен еще один Web-акселератор Tempesta FW, и в чем его отличие от других акселераторов.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €
Основная программа

Иван Михеев

Заместитель технического директор в AGIMA

Оптимизация сайта. Диагнозы и курсы лечения

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

Осветим: 
- Самые эффективные приемы по оптимизации производительности сайта.
- Ускорение сайта при помощи перевода сложных live-процессов в планировщик.
- Методы поиска медленных запросов к БД и оптимизация скорости работы БД.
- Профилирование кода с помощью xdebug и xhproof.
- Оптимизация frontend и статики.

Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €

Билеты

Показать
цену в
$
Видеозапись
Доступ к записям всех докладов
Куплено
В корзине
0 ₽
0 ₽
0 $
0 $
0 €
0 €

Организатор

Ontico
http://ontico.ru

Организационный комитет: Олег Бунин, support@ontico.ru, 74956460764

Похожие мероприятия

5-6 июня 2017
Докладов 18
Просмотров 2
Big data, Ddos, Galera, Highload, Javascript, Mongodb, Php, Postgresql, Высоконагрузочная разработка, Данные, Кеширование, Репликация
31 октября - 1 ноября 2014
Докладов 83
Просмотров 60
Big data, Ddos, Galera, Highload, Javascript, Mongodb, Mysql, Nginx, Php, Postgresql, Высоконагрузочная разработка, Данные, Кеширование, Репликация, Репликация бд
7-8 ноября 2016
Докладов 137
Просмотров 18
BigData, Ddos, Galera, Highload, Javascript, Mongodb, Php, Postgresql, Высоконагрузочная разработка, Данные, Кеширование, Репликация
показать еще