HighLoad++ Junior 2017

June 5-6 2017
Сколково, Россия
View
To favorites

Иван Круглов

Разработчик at Booking.com

Илья Космодемьянский

CEO at Data Egret

Светлана Смирнова

Инженер технической поддержки at Percona

Анастасия Распопина

Marketing Specialist at Percona

Дмитрий Хмаладзе

CEO at Agnicore

About event

Topic: IT

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

Audience

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

Schedule

Show all
Monday, June 5
Day 1
Get access to all talks
Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Прочие темы

Иван Круглов

Разработчик at Booking.com

SOA: послать запрос на сервер? Что может быть проще?!

Микросервисы - это круто, модно и интересно. Переход на их использование принесет команде заметные преимущества. Но сервис-ориентированная архитектура (SOA) не лишена недостатков. Один их них - это то, что, заменяя простой вызов функции на RPC, мы в неявном виде вводим в уравнение, отвечающее за стабильность системы, целую плеяду новых неизвестных. Например, простейший HTTP-запрос за время своей жизни проходит через множество всевозможных буферов, очередей и алгоритмов на своем пути от клиента к серверу и обратно. Совокупное поведение этих составляющих трудно предсказать, понять и правильно интерпретировать. И особенно трудно это сделать в нестандартных ситуациях.

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

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Оптимизация баз данных

Анастасия Распопина

Marketing Specialist at Percona
and 1 more
speaker

MySQL: чек-лист для новичка в highload

В рамках данного доклада в диалоговом формате будут рассмотрены наиболее распространённые вопросы по MySQL - от краткого обзора возможностей основных вариантов этой СУБД (актуальное состояние Oracle MySQL, Percona Server и MariaDB) до выбора наиболее оптимальных значений для конкретных параметров, чтобы справиться с ростом вашего проекта. 

Подтемы доклада:
- обзор форков MySQL (для каких специфических задач подойдут форки вместо оригинального MySQL); 
- что такое highload в современном мире (где ещё не highload, а где уже highload); 
- что храним в памяти, что на диске; 
- кэширование; 
- кластеризация; 
- репликация/шардинг базы данных; 
- умеет ли СУБД кросс-датацентр репликацию; 
- MySQL-индексы; 
- настройка MySQL под нагрузку; 
- лог медленных запросов в MySQL + анализ запросов; 
- как понять, что "тупит" не MySQL. 

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Принципы масштабирования

BigMemory - работа с сотнями миллионов бизнес-объектов в управляемых средах

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

Описываемый нами способ BigMemory Pile обкатан и применим для большинства современных приложений, связанных с социальными графами, обработкой потоков, IoT, stateful-алгоритмов/анализ, системами кэширования и отслеживания причинно-следственных связей. 

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

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

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Профилирование

Константин Новаковский

Старший системный администратор проекта Vscale at Selectel

Погружение в виртуальную память и большие страницы

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

* Как ядро работает с этими страницами?
* Как аппаратная часть помогает ядру ОС работать с виртуальной памятью?
* Какова цена виртуальной памяти?
* Для чего нужны большие страницы и почему их "прозрачное" использование может сделать хуже?
* Сколько памяти на самом деле потребляет приложение? 

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

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Антипаттерны, ошибки проектирования

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

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

Database First! О распространённых ошибках использования РСУБД

Любой Full Stack Developer сегодня обязан иметь в своём арсенале опыт и умение работы хотя бы с одной популярной РСУБД. Но без понимания основ — того, какие задачи решают СУБД, как происходит работа с данными, какие есть базовые возможности для этой работы, — такие умения превращаются в воздушный замок, быстро разрушающийся при росте проекта.

 

Этот доклад — попытка разбудить интерес слушателей к тщательному изучению основ теории и практики реляционных баз данных и к применению всей мощи РСУБД по прямому назначению.

Мы обсудим несколько фундаментальных ситуаций использования РСУБД (каждая из которых неоднократно встречалась автору), попутно разбирая возможные ошибки:
- элементарная модификация данных;
- работа с датой, временем и временными зонами;

- проверка ограничений целостности;
- очередь заданий;
- пакетная работа с данными (например, удаление пачки записей в таблице);
- полнотекстовый поиск;
- относительно новые задачи (создание API, machine learning).

Для каждого кейса мы сравним плюсы и минусы реализаций «на стороне СУБД» и «снаружи / на стороне приложения», прежде всего с точки зрения производительности. Постараемся понять, почему современные разработчики часто боятся использовать мощь РСУБД. Откуда пошёл миф «хранимки — зло». 

Ну и, наконец, представим чеклист знаний (с перечнем полезных ссылок!), которые, по мнению автора, необходимо иметь, чтобы чувствовать себя увереннее при работе с РСУБД.

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Антипаттерны, ошибки проектирования

Андрей Половов

Руководитель проектов и соучредитель at Флант
and 1 more
speaker

ТОП ошибок в инфраструктуре, мешающих высоким нагрузкам

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

Решив, что большинство проблем имеют общие корни, мы решили систематизировать их и поделиться с коллегами. В данном докладе представляем собственный рейтинг типовых highload-проблем и даём практические советы по их решению.

Доклад затронет следующие области:
* базы данных,
* код,
* архитектура,
* сеть,
* деплой,
* и самое неизбежное — человеческий фактор.

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Прочие темы

Как устроены базы данных

Хранить и обрабатывать данные нужно везде, неслучайно, как минимум последние полвека, интенсивно развивались специализированные для этой задачи фреймворки - сервера управления базами данных (СУБД). Как они выглядят сейчас и почему, несмотря на разницу в реализации, одни СУБД принципиально похожи на другие?

В этом докладе мы начнем с основ: транзакции, алгоритмы сериализации, контроля конкурентного доступа и восстановления. Как они реализованы в современных СУБД? Что нужно знать о них разработчику или администратору высоконагруженных систем? Как устроен WAL, и как это помогает обеспечивать резервное копирование и отказоустойчивость? Как СУБД работает с памятью и диском? Почему SQL до сих пор жив как технология, и как работает оптимизатор?

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

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Антипаттерны, ошибки проектирования

Максим Ехлаков

Тимлид бэкенд-разработки at OneTwoRent

Ошибки проектирования высоконагруженных проектов

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

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

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

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Прочие темы

Игорь Мызгин

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

Как заранее соломки подстелить или путь к 99,99% uptime проекта

Каждый проект проходит несколько жизненных стадий, на каждой из которых есть развилка: умереть, замереть на данной стадии или перейти на качественно новый уровень. Первой стадией является чуть ли не виртуалка / мокап / скетч на ноутбуке фаундера/кофаундера. Вторая стадия - это одна/две/три виртуалки на каком-нибудь хостинге. И третий этап - активный рост, развитие инфраструктуры, публикации на ТехКранче и прочие символы успеха.

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

В своем докладе я буду говорить о том, о чем надо не забывать пока маленьким проектам, чтобы смочь вырасти большими и при этом не потратить все ресурсы на создание инфраструктуры проекта. Я детально проговорю то, о чем 99% клиентов хостинга задумываются по факту:
- о разграничении ответственности между клиентом и хостером,
- о том, что написано в SLA и как этот / эти документы читать,
- что должен сделать проект сам, и почему за проект это не будет делать хостер,
- как спланировать свой рост и не стать заложником изначальной инфраструктуры при активном росте,
- о чем надо спросить "на берегу" провайдера/провайдеров.

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

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Прочие темы

Рамиль Хантимиров

Со-основатель и CEO at StormWall

После подключения DDoS-защиты: как "положат" Ваши ресурсы

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

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Get access to all talks
Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Информационная безопасность

Артём Гавриченков

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

DDoS-атаки: тектонические изменения в 2016-2017 году

Осенью 2016 года DDoS-атаки, уже, казалось бы, ставшие досадной обыденностью, вновь выплыли на первые полосы журналов и онлайн-изданий. Атаки с использованием ботнета Mirai и подключенных к Интернету камер сумели создать серьёзные проблемы с доступностью целого ряда сайтов, включая Twitter, Spotify и Reddit.

Для обывателей и СМИ это стало сенсацией, но в IT-мире многие предполагали такое развитие событий. Мы сами предсказывали эту опасность за год до Mirai. Однако у людей, не занимающихся защитой информации непрерывно, возникают закономерные вопросы: какова на самом деле структура проблемы? В чём корень всех бед, и какого развития событий можно ожидать?

Обсудим нынешнее состояние Интернета, те угрозы, которых можно ожидать для функционирования Интернет-ресурсов, а также методы защиты от них.

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Tuesday, June 6
Day 2
Прочие темы

Николай Лавлинский

Технический директор at Метод Лаб

Чеклист по клиентской оптимизации

Когда проект растёт, возникает множество проблем с масштабируемостью сервиса: БД, сервера приложений, хранилище. Однако, не менее важной становится клиентская часть веб-приложения.

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

Во-вторых, применение методик клиентской оптимизации даёт экономию серверных ресурсов: трафик, каналы, место на диске, иногда даже CPU. Для растущих проектов это становится важным.

В докладе разберём пример ускорения реального сайта, по шагам замеряя эффект.

Вот примерный чеклист по клиентской оптимизации, покрывающий большинство проблем среднего веб-проекта:
1. Базовая конфигурация Nginx для эффективной раздачи статики.
2. Клиентское кэширование: заголовки, сброс кэша, особенности браузеров.
3. Сжатие текстового контента: gzip, zopfli, brotli, статическое сжатие, поддержка Nginx и браузеров.
4. Быстрый TLS: конфигурация Nginx, нагрузка на сервер и клиент, наиболее оптимизированные шифры, типы сертификатов, stapling, кэширование сессий, HTTP/2.
5. Настройка TCP/IP-стека в Linux для веб-приложений.
6. Оптимизация картинок: для JPEG, PNG, SVG, применение WebP.
7. Веб-шрифты: форматы, подходы к оптимизации.
8. Общий подход к ускорению рендеринга страниц (синхронная/асинхронная загрузка CSS, JS, объединение ресурсов), клиентские SPOF.
9. Использование CDN: когда нужно, зачем. Влияние задержек сети на скорость.
10. Средства синтетического тестирования клиентской скорости.

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Прочие темы

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

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

Проксирование HTTP-запросов web-акселератором

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

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

- Как работает HTTP-проксирование без кэша;
- Что такое персистентные соединения и чем они отличаются от HTTP keep alive;
- Как, когда и сколько соединений может устанавливать HTTP-акселератор с апстримом;
- Что становится с запросами, которые ждут очереди на отправку в соединение с апстримом, но апстрим "из коробки" и сбрасывает соединения каждые 100 запросов;
- Что такое HTTP pipelining, и как им пользуются современные HTTP-акселераторы;
- Что такое неидемпотентные запросы, и почему нужно о них беспокоиться.

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Выбор технологий

Сергей Спорышев

Руководитель отдела разработки высоконагруженных проектов at ITSumma

Как сделать сложное простым. История создания Проект1917

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

Каждый web-программист мечтает написать свой фреймворк, CMS или соцсеть, и современный стек технологий дает настолько широкий выбор инструментов, что очень легко построить переусложненное архитектурное решение.

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

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

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Прочие темы

Юрий Колесов

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

Рост с нуля до 15000 сообщений в секунду. Мучительный и поучительный

Компания TIMCONNECT процессит банковские смс-сообщения, по возможности отправляя их как push.

Расскажем, как мы за 2 месяца небольшой командой масштабировались в 15 раз, минимально переписывая код, применяя паттерны из хайлоада методом проб и ошибок. На примерах проиллюстрируем, что хайлоад может быть достижим просто и быстро. Если повезет. 

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

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Прочие темы

Андрей Минкин

Тимлид at Mad Devs

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

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

Со временем проект становится популярнее и популярнее, нагрузка начинает расти и мы поговорим о том, что такое:
0. Нагрузка? Как ее анализировать? Как понять, где нагрузка? Как оптимизировать код? Когда внедрять кэширование и начинать масштабирование. Какие подводные камни вас ожидают?
1. Кэширование. Как внедрить, и какие есть подводные камни. Как оценить, что кэширование работает? Какие проблемы возникают, если кэширование работает плохо.
2. Путь масштабирования и борьба за ресурсы. Как жить, если все сервисы дерутся? Когда масштабировать, и какие есть варианты масштабирования
3. Проблемы балансировки.
4. Подводные камни в распределенных системах. Состояния гонки и проблемы конкурентного доступа. Целостность данных. Событийная целостность.

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Балансировка нагрузки

Антон Резников

Руководитель группы разработки Облака@Mail.Ru at Mail.Ru Group

Балансировка HTTP-трафика

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

Мы рассмотрим три самые распространённые задачи: распределения запросов
динамического контента (HTML, API), раздачу статического контента и загрузку
данных от пользователя. На примере этих задач мы будем добиваться масштабируемости, высокой доступности, затронем проблемы эксплуатации и гео-балансировку.

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0
Общая программа

Артём Кузвесов

Frontend developer at Ideco

Документация REST API

Часто возникает ситуация, когда нужна документация для API. Например, если вы работаете в команде, где роли backend- и frontend-разработчиков исполняют разные люди. Или нужно дать доступ к API сторонним разработчикам.

Такая документация должна быть всегда актуальной и легко читаемой. Как показывает практика, хранение её в google docs/Markdown/reStructuredText/etc. неудобно, и программисты часто забывают её вовремя актуализировать. Лучше всего, если документация API будет храниться максимально близко к коду.

Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0

Tickets

Video
Access to all videos
Purchased
In cart
0 ₽
0 ₽
$0
$0
€ 0
€ 0

Organizer

Ontico
http://ontico.ru

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

Similar events

May 31 - June 1 2016
Talks 16
Views 15.99 K
big data, ddos, galera, highload, javascript, mongodb, php, postgresql, высоконагрузочная разработка, данные, кеширование, репликация
October 31 - November 1 2014
Talks 83
Views 156
big data, ddos, galera, highload, javascript, mongodb, mysql, nginx, php, postgresql, высоконагрузочная разработка, данные, кеширование, репликация, репликация бд
November 7 2017
Talks 157
Views 252.26 K
big data, ddos, galera, highload, mongodb, php, postgresql, высоконагрузочная разработка, данные, кеширование, репликация
more