Фестиваль РИТ++ 2016 завершён. Изучайте презентации, смотрите фотографии и ждите видео :)
Обучающая конференция разработчиков высоконагруженных систем
Проходит в рамках фестиваля
Российские интернет-технологии
Архив
2015
года
Доклады конференции рассчитаны на небольшие команды, работающие в реальных условиях с реальными проектами. Те случаи, когда нет ресурсов на rocket science, но нагрузку держать необходимо, когда у тебя не сто, а один или два сервера. HighLoad++ для дизайн-студий, Простые решения сложных задач для малых команд в условиях ограниченных ресурсов. Девиз конференции: "Главное — работает!"
  • Что делать, если пришел 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 тоже.
    В каком объеме рассказывать про него — буду смотреть по времени. Скорее всего, совсем обзорно.

    Юрий Колесов
    security-gu.ru
  • Оптимизация сайта. Диагнозы и курсы лечения

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

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

  • Как 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, и в чем его отличие от других акселераторов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Роман Ивлиев
    Банки.ру
  • Кластеры баз данных: делаем сложные вещи просто

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

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

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

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

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

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

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

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

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

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

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

    Илья Космодемьянский
    PostgreSQL-Consulting LLC
  • Организация надежного резервного копирования веб-проекта. Практика и подводные камни

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Новости
31 мая 2016
Вопросы и ответы
Ответы на вопросы участников РИТ++.
26 мая 2016
F.A.Q.
Мы собрали всю информацию, которая может вам пригодиться на конференции, в одну большую новость, начиная от того, как добраться до конференции и где кушать, заканчивая вопросами бухгалтерии и командировочных.
25 мая 2016
Как добраться до фестиваля: расписание автобусов и схемы проезда
Фестиваль пройдет в Кампусе бизнес-школы Сколково. В статье - информация о том, как попасть на фестиваль: нашим автобусом, городской маршруткой или на автомобиле.
16 мая 2016
Жизнь проекта на production: советы по эксплуатации
В рамках обучающей конференции для разработчиков высоконагруженных систем HighLoad++ Junior мы обязательно поговорим об эксплуатации проектов. Разработать мало — важно ещё и грамотно эксплуатировать и развивать.
12 мая 2016
Пользовательские митапы и активности!
Ура! Каждый участник фестиваля РИТ++ или любой входящей в него конференции теперь может предложить сообществу свой собственный митап, доклад или встречу.
В этом году программа получилась замечательной.
Но в 2015 году было очень хорошо!
Отзывы от участников
Спасибо за отличную идею и тем, что делитесь информацией, которую трудно найти в сети.
Полезные доклады, бойкие и веселые докладчики.
Доклады были интересные. Очень понравилось, что все происходило в доброжелательной и приветливой обстановке, организаторы вежливые. Много интересных компаний и людей были на выставке. Удалось пообщаться, узнать много нового и проконсультироваться по нашим насущным рабочим вопросам. Все с интересом общались, делились опытом. Очень доброжелательно и открыто всё говорили. А самое главное, благодаря опыту предвидели некоторые мои вопросы и возможные будущие сложности. Не приходит в голову, что еще написать. Если описывать общее впечатление от конференции, то я восхищен и очень доволен всем, что было! Приходил за знаниями и общением со специалистами компаний, представленных на выставке - составил список вопросов и к кому нужно с ними подойти. Всё успел, всё узнал. Было здорово! Хочется еще! :)
Был впервые на ваших конференциях, вот посещу хайлоад и уже смогу сравнить :)
Да я вообще впервые выбрался на конференцию в Москву. Очень благодарен вам за то, что в одном месте сразу столько интересных людей собрали - для регионалов (мы из Челябинска) это - очень ценно! СПАСИБО!
Информационные спонсоры