HighLoad++ Junior 2016

May 31 - June 1 2016
Сколково, Россия
Обучающая конференция разработчиков высоконагруженных систем
Watch
Add to favorites

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

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

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

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

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

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

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

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

Игорь Мызгин

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

About event

Topic: IT

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

Audience

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

Schedule

See all
Tuesday, May 31
Day 1
Get access to all talks
Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

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

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

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

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

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

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

Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

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

Архитектор и разработчик at 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?

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

Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

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

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

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

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

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

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

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

Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

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

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

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

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

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

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

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

Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

Игорь Мызгин

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

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

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

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

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

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

Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

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

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

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

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

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

Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

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

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

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

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

Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

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

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

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

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

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

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

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

Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

Юрий Колесов

Специалист по безопасности клиентских веб-сервисов at 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 тоже. 
В каком объеме рассказывать про него — буду смотреть по времени. Скорее всего, совсем обзорно.

Available
In cart
Free
Free
Free
Free
Free
Free
Wednesday, June 1
Day 2
Основная программа

Антон Регеда

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

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

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

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

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

Available
In cart
Free
Free
Free
Free
Free
Free
Get access to all talks
Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

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

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

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

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

Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

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

Программист at 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 и нескольких проектах по всему миру.

Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

Роман Ивлиев

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

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

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

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

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

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

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

Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

Игорь Цупко

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

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

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

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

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

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

Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

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

Основатель и системный архитектор at 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, и в чем его отличие от других акселераторов.

Available
In cart
Free
Free
Free
Free
Free
Free
Основная программа

Иван Михеев

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

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

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

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

Available
In cart
Free
Free
Free
Free
Free
Free

Tickets

Video
Access to all videos
Available
In cart
Free
Free
Free
Free
Free
Free

Organizer

Ontico
http://ontico.ru

Event host: Олег Бунин, support@ontico.ru, 74956460764

Similar events

June 5-7 2019
Talks 53
Views 2.27 K
ai, big data, developer, front-end, javascript, programming, react, testing, ui
December 6 2019
Talks 9
Views 792
javascript, machine learning, nextjs, react js, software , testing, ui/ux
December 5-6 2019
Talks 22
Views 35.73 K
algorithmic performance, crdts, data science, dotjs, javascript, modeling, svelte, web framework, webassembly
more