Конференция для разработчиков высоконагруженных сервисов HighLoad++ в этом году получилась просто гигантской. 8 и 9 ноября в СКОЛКОВО приедут 3000 гостей, чтобы вникнуть в тонкости архитектуры, узнать о нововведениях в базах данных, поговорить про микросервисы, облака, большие данные, нейронки и кто знает, в какие еще дебри могут зайти кулуарные разговоры всех этих первоклассных разработчиков.



В расписании 138 докладов основной программы, 14 двухчасовых мастер-классов и несчетное количество митапов (в том смысле, что они будут добавляться по ходу дела, и посчитать мы их сможем только уже по факту). С одной стороны, это все значит, что каждый найдет себе темы по душе и сможет получить ответы на свои вопросы. А с другой — очень сложно выбрать.

Один из вариантов маршрута по конференции — пойти на все самые популярные доклады. Тем более что, работая над расписанием, мы опросили будущих слушателей и составили рейтинг ожиданий. Лидеры голосования выступят в Главном зале (Когресс-холле), который мы по хорошей традиции транслируем бесплатно.

Трансляция первого дня HighLoad++

Трансляция второго дня HighLoad++

Трансляция будет идти на нашем HighLoad Channel в youtube, чтобы не забыть и не пропустить можно подписаться на канал, на блог или на рассылку — а лучше на всё сразу, у нас все полезное :)

Первое, с чем мы сталкиваемся, когда говорим о проактивной оптимизации — не известно, что нужно оптимизировать. «Сделай то, не знаю, что».

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

Основные цели проактивной оптимизации

Основные задачи проактивной оптимизации отличаются от задач реактивной оптимизации и состоят в следующем:

• избавление от узких мест в БД;
• уменьшение потребления ресурсов БД.

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



Если вы работаете с боевыми серверами, то хорошо представляете, что значат инциденты производительности. Нужно всё бросить и быстро решать проблему. ООО РНКО «Платежный центр» работает с многими агентами, и для них очень важно, чтобы таких проблем было как можно меньше. Александр Макаров на HighLoad++ Siberia рассказал, что было сделано, чтобы значительно уменьшить количество инцидентов производительности. На помощь пришла проактивная оптимизация. А почему и как ее производят на боевом сервере, читайте ниже.

С точки зрения пользователя, сервисы звонков выглядят довольно просто: заходишь на страницу к другому пользователю, звонишь, он снимает трубку, вы с ним разговариваете. Снаружи кажется, что все просто, но немногие знают, как сделать такой сервис. А вот Александр Тоболь (alatobol) не только знает, но и охотно делится своим опытом.



Далее текстовая версия доклада на HighLoad++ Siberia, из которой вы узнаете:

• как работают сервисы видеозвонков под капотом;
• как красиво пробить NAT — это будет интересно и специалистам из игровой сферы, которым необходимо peer-to-peer соединение;
• как устроен WebRTC, какие протоколы в него входят;
• как можно тюнить WebRTC через BigData.

О спикере: Александр Тоболь руководит разработкой платформ Видео и Ленты в ok.ru.

Машинное обучение позволяет сделать сервис гораздо удобнее для пользователей. Начать внедрять рекомендации не так сложно, первые результаты можно получить, даже не имея налаженной инфраструктуры, главное начать. А уже потом строить масштабную систему. Именно так все начиналось в Booking.com. А во что это вылилось, какие сейчас используются подходы, как модели внедряются в продакшен, каких их мониторить, рассказал Виктор Билык на HighLoad++ Siberia. Возможные ошибки и проблемы не остались за бортом доклада, кому-то это поможет обойти мели, а кого-то натолкнет на новые идеи.



О спикере: Виктор Билык внедряет продукты машинного обучения в промышленную эксплуатацию в Booking.com.

Спам в социальных сетях и мессенджерах — это боль. Боль и для честных пользователей, и для разработчиков. Как с ней борются в Badoo, рассказал Михаил Овчинников на Highload++, далее текстовая версия этого доклада.


О спикере: Михаил Овчинников работает в Badoo и последние пять лет занимается антиспамом.

В Badoo зарегистрировано 390 миллионов пользователей (данные на октябрь 2017). Если сравнивать размер аудитории сервиса с населением России, то можно сказать, что в нашей стране по статистике каждых 100 млн человек охраняет 500 тысяч полицейских, а в Badoo каждые 100 млн пользователей защищает от спама всего один сотрудник Антиспама. Но даже такое небольшое количество программистов способно защитить пользователей от разных неприятностей в интернете.

Проверить один сервер — не проблема. Берешь чек-лист и по порядку проверяешь: процессор, память, диски. Но с сотней серверов такой способ вряд ли хорошо сработает. Чтобы исключить человеческий фактор, сделать проверки более надежными и быстрыми, надо автоматизировать процесс. Кому знать, как это лучше сделать, как не хостинг-провайдеру. Артём Артемьев на HighLoad++ Siberia рассказал, какие методы можно использовать, что лучше запускать руками, а что отлично получается автоматизировать. Далее текстовая версия доклада с советами, которые сможет повторить каждый, кто работает с железом и нуждается в регулярной проверке его работоспособности.



О спикере: Артём Артемьев (artemirk) технический директор в большом хостинг-провайдере FirstVDS, сам работает с железом.

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



Маленький минутрый пик в 84 RPS «пятисоток» — это пять тысяч ошибок, которые получили реальные пользователи. Это много и это очень важно. Необходимо искать причины, проводить работу над ошибками и стараться впредь не допускать подобных ситуаций.

Николай Сивко (NikolaySivko) в своем докладе на RootConf 2018 рассказал о тонких и пока не очень популярных аспектах балансировки нагрузки:

• когда повторять запрос (retries);
• как выбрать значения для таймаутов;
• как не убить нижележащие серверы в момент аварии/перегрузки;
• нужны ли health checks;
• как обрабатывать «мерцающие» проблемы.

Под катом расшифровка этого доклада.

njs — это JavaScript-интерпретатор в легковесном веб-сервере, с помощью которого можно создавать новые nginx-переменные и обработчики стадий запроса. Чем njs хорош? Чего не умеет? И зачем вообще его сделали? На эти и другие вопросы ответит Дмитрий Волынцев (xeioex), разработчик nginx и основной разработчик интерпретатора njs.

— Дмитрий, зачем понадобился скриптинг в конфигах nginx?

— Первая причина — директива if. Люди, которые первый раз ее увидели, думают, что можно использовать ее императивно. На самом деле это не так — конфигурация nginx является декларативной. В примере ниже можно подумать, что в ответе будут два header: X-First и X-Second. Но в ответ попадет только второй header, потому что так устроен nginx: если мы напишем две if-директивы, то выберется самая последняя.

location /only-one-if {
    set $true 1;

    if ($true) {
        add_header X-First 1;
    }

    if ($true) {
        add_header X-Second 2;
    }

В продолжение "разбора полетов" с HighLoad++ 2017 мы подготовили небольшой обзор пяти лучших (по мнению участников конференции) англоязычных докладов.

Наивысших оценок удостоились темы, касающиеся использования ProxySQL (в ТОП-5 попало целых два доклада об этом инструменте), тестирования приложений в публичном облаке Amazon, а также принципы логгирования в масштабах, когда это становится проблемой, и мониторинг Apache Kafka.

Видеозаписи всех докладов HighLoad++ 2017 мы только что выложили в свободный доступ. Полный список из 150 докладов на нашем YouTube-канале в этом плей-листе.

Кроме этого плейлиста в канале несколько сотен видео по базам данных, архитектурам, масштабированию, очередям, машинному обучению и другим highload-премудростям :)

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

Мы попросили поделиться своим кейсом разработки и доставки микросервисов Алексея Баитова, ведущего инженера 2ГИС. Поговорим на тему архитектурных решений, деплоя и возможности масштабирования. Расспросим про трендовые и просто удобные инструменты для работы.

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

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


В докладе на Highload++ 2017 Андрей Смирнов (smira) решил, что о хорошем говорить неинтересно, зато подробно рассказал, про каждую проблему, с которой пришлось столкнуться: про потерю и порчу данных, про зомби и потерю производительности. Эти истории и вправду напоминают катание на горках, но на все проблемы находится решение, за которым добро пожаловать под кат.

О спикере: Андрей Смирнов работает в компании Virtustream, реализующей облачное хранилище для enterprise. Идея состоит в том, что условно Amazon делает облако для всех, а Virtustream делает специфические вещи, которые необходимы большой компании.

Highload++ — знаковое событие в мире IT и своеобразный ежегодный чекпойнт для любого разработчика высоконагруженных систем. Это самая большая и крутая профессиональная конференция для разработчиков в России. На ней много всего: участников, событий, докладов, партнеров и экспертов. В 2017 году Highload++ собрал 2600 человек и, конечно, это не предел. Это мегасобытие, на котором просто нужно быть, в 2018 году пройдет в Москве 8 и 9 ноября.



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

Когда только Dropbox запустился, один пользователь на Hacker News прокомментировал, что реализовать его можно несколькими bash-скриптами с помощью FTP и Git. Сейчас такого сказать никак нельзя, это крупное облачное файловое хранилище с миллиардами новых файлов каждый день, которые не просто как-то хранятся в базе данных, а так, что любую базу можно восстановить на любую точку в течение последних шесть дней.

Под катом расшифровка доклада Славы Бахмутова (m0sth8) на Highload++ 2017, о том, как развивались базы данных в Dropbox и как они устроены сейчас.


О спикере: Слава Бахмутов — site reliability engineer в команде Dropbox, очень любит Go и иногда появляется в подкасте golangshow.com.

Содержание

• Кратко об архитектуре Dropbox
• История развития баз данных и как устроена текущая архитектура Dropbox
• Простейшие операции над базами данных (фейловеры, бэкапы, клоны, промоушены)
• Автоматизация — что управляет всеми базами данных и запускает операции
• Мониторинг
• Тестирование, стейджинг и DRT

В преддверии cибирской HighLoad++ мы побеседовали с одним из наших спикеров — Юрием Насретдиновым, расспросив его о том, хорошо ли работается во ВКонтакте, одновременно приоткрывая завесу тайны над внутренней кухней социальной сети.



В рамках же самой конференции Юрий будет рассказывать о том, как социальная сеть вставляет данные в ClickHouse с десятков тысяч серверов, чего в текущей беседе мы коснулись лишь вскользь.

Интервью с Александром Титовым, одним из членов программного комитета нашей июньской конференции HighLoad++, отдельная секция которой будет посвящена DevOps.
Под катом про то, в каком направлении дует «ветер» DevOps, и какие именно аспекты этой концепции будут обсуждаться на форуме.

Сегодня мы поговорим с Николаем, «борцом» за продвижение новых технологий в мире БД, членом нашего программного коммитета и активным участником всевозможных конференций. Главные темы — самоуправляемые СУБД, DBA AI, облака, NoSQL, встроенные механизмы контроля БД, доклады на РИТ++ и HighLoad++ Siberia, а также масса дельных советов и примеров, которые могут пригодится в реальной работе как разработчику, так и DBA.

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

Frontend — довольно конкурентная среда. Здесь легко начинать карьеру, но сложно перейти в разряд middle. Вдобавок возникает вопрос, в каком направлении развиваться, если каждый день появляются новые фреймворки и темы для холиваров?

О том, как выглядит и куда движется современный frontend, я расспросил Сергея Попова, члена программного комитета нашей FrontendConf, которая пройдет в конце мая в Москве в рамках РИТ++. Попутно мы поговорили про то, как происходит отбор докладов, и какие тут возникают трудности.

Сегодня РИТ++ — масштабное российское IT-мероприятие. Но таким он был не всегда. Мы начинали с небольшой тусовки на несколько сотен человек, а к концепции фестиваля пришли только через восемь лет.

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

То, о чем я хочу рассказать, началось 30 декабря 2010 года, когда компания Etsy выложила на GitHub первый коммит своей системы StatsD. Эта, сейчас уже, суперпопулярная система, написанная на JavaScript (хипстеры ликуют), в которую можно отправлять метрики, замеры исполнения кусков вашего кода, а она их агрегирует и отправляет уже агрегированными в систему хранения time-series.



На фоне популярности StatsD и других time-series систем появилась идея «Monitor Everything»: чем больше различных вещей в системе измеряется, тем лучше, потому что в случае неожиданной ситуации будет возможно найти нужную, уже собранную метрику, которая позволит во всем разобраться.

Давайте вообще все, что можно, мониторить — и будет классно!

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

И так получилось, что есть много проблем со всем этим, про которые, собственно, нам и расскажет Павел Труханов ( tru_pablo ).