Банки.ру — проект с 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждый разработчик может столкнуться с необходимостью внедрить в проект 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 и нескольких проектах по всему миру.

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

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

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

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

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

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

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

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

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

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

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?

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