20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков (ведущий разработчик Cezurity)
Аннотация
Когда команда разработчиков собирается написать новый сервис, у нее, как правило, отсутствует свободное время, но есть необходимый энтузиазм. Из-за нехватки времени многие архитектурные решения приходится принимать, руководствуясь общими соображениями, так как провести всесторонние тесты имеющихся на рынке средств в краткие сроки невозможно. Мы, специалисты компании Cezurity, начали свой проект не вчера, и уже накопили некоторый опыт использования технологий, появившихся сравнительно недавно - таких как Skytools, Node.JS, RabbitMQ и Redis. О том, какие возникли проблемы при внедрении этих средств, и какие их ограничения пришлось преодолевать и учитывать - мой доклад. Кроме того, я расскажу о новом направлении в нашей деятельности - внедрении HBase для хранения большого объема данных.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие.
Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload?
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы.
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому".
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?
В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)
Что нового в MySQL 8.0? / Дмитрий Ленев (Oracle)Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 16:00
Тезисы:
http://backendconf.ru/2017/abstracts/2801.html
8.0 - это следующая крупная версия СУБД MySQL Server, которая на данный момент находится в активной разработке. Цель данного доклада - познакомить слушателей с новыми возможностями и улучшениями производительности,которые реализованы в этой версии.
В частности, мы поговорим о:
- новом словаре данных, связанных с ним изменениях в INFORMATION_SCHEMA, а также поддержке атомарного DDL;
- новых возможностях в выполнении запросов - поддержке Common Table Expressions и Window функций, "невидимых" и descending индексах;
- улучшениях в поддержке Unicode;
- возможностях более гибкой работы с блокировками в запросах (SKIP LOCKED/NOWAIT);
- ролях и других изменениях в системе привилегий;
- улучшениях в репликации.
MySQL: чек-лист для новичка в highload (Cвета Cмирнова, Aнастасия Распопина ...Anastasia Rostova
Подтемы доклада:
- обзор форков MySQL (для каких специфических задач подойдут форки вместо оригинального MySQL);
- что такое highload в современном мире (где ещё не highload, а где уже highload);
- что храним в памяти, что на диске;
- кэширование;
- кластеризация;
- репликация/шардинг базы данных;
- умеет ли СУБД кросс-датацентр репликацию;
- MySQL-индексы;
- настройка MySQL под нагрузку;
- лог медленных запросов в MySQL + анализ запросов;
- как понять, что "тупит" не MySQL.
Как сделать сложное простым. История создания Проект1917 / Сергей Спорышев (I...Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 6 июня, 13:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2732.html
В докладе я поделюсь нашим опытом разработки Project1917 - исторического проекта в реальном времени в формате социальной сети. Каждый web-программист мечтает написать свой фреймворк, CMS или соцсеть, и современный стек технологий дает настолько широкий выбор инструментов, что очень легко построить переусложненное архитектурное решение. ...
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?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
Ошибки проектирования высоконагруженных проектов / Максим Ехлаков (OneTwoRent)Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 15:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2632.html
Наиболее типичные ошибки, которые совершаются при создании высоконагруженных продуктов: выбор используемых языков, фреймворков, СУБД и других инструментов. Каковы причины совершения этих ошибок, и как их избежать.
Во время проектирования и разработки высоконагруженных программных продуктов существует большой соблазн применить классические подходы. Однако не все они будут полезны, а какие-то даже вредны. При этом цена каждой такой ошибки всегда будет очень большой.
На примере нескольких реальных проектов мы поговорим об ошибках проектирования, разработки и управления, о том, почему они возникли, и о решениях, которые позволили (или не позволили) преодолеть их.
RTB DSP на языке Go укрощение buzzwords / Даниил Подольский (Qmobi.Com)Ontico
RTB и его проблематика должны быть знакомы участникам конференции — мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие — нет, будет рассказано в докладе.
Банки.ру — проект с 10-летней историей. В разные времена мы испытывали разные нагрузки. Портал перестраивался под новые требования как логически, так и технологически, что-то мы меняли в авральном режиме, что-то — эволюционным путём. Сейчас в среднем в день у нас примерно 2КК просмотра страниц, т.е. мы уже не маленькие, но ещё и не совсем большие.
Я хочу поговорить об оптимизации, её своевременности, и о субоптимизации, о том, что далеко не всегда лучшие практики разработки нагруженных систем идут на пользу бизнесу.
Посмотрим примеры и поищем ответы на вопросы:
1) Настолько ли ваш highload — highload?
2) Считать ли хабрэффект поводом для внедрения высоких технологий?
3) "Костыль" или "высокотехнологичное решение" — что выбрать? Плюсы и минусы.
4) Как выбрать момент для начала новой эры? Есть ли критерии, когда имеет смысл начинать оптимизировать ваше приложение и внедрять крутые штуки "по-взрослому".
5) Как можно использовать "список Бунина" для достижения очень неплохих показателей, и все ли пункты реально нужны вам?
6) Как работать с тех. долгом, чтобы он не зарастал мхом?
В заключение я расскажу про несколько примеров из жизни banki.ru в части замены технологических решений в области высоких нагрузок, и что из этого вышло.
P.S. Мнение докладчика может не совпадать с вашим, но это его опыт:)
Что нового в MySQL 8.0? / Дмитрий Ленев (Oracle)Ontico
РИТ++ 2017, Backend Conf
Зал Сан-Паулу, 6 июня, 16:00
Тезисы:
http://backendconf.ru/2017/abstracts/2801.html
8.0 - это следующая крупная версия СУБД MySQL Server, которая на данный момент находится в активной разработке. Цель данного доклада - познакомить слушателей с новыми возможностями и улучшениями производительности,которые реализованы в этой версии.
В частности, мы поговорим о:
- новом словаре данных, связанных с ним изменениях в INFORMATION_SCHEMA, а также поддержке атомарного DDL;
- новых возможностях в выполнении запросов - поддержке Common Table Expressions и Window функций, "невидимых" и descending индексах;
- улучшениях в поддержке Unicode;
- возможностях более гибкой работы с блокировками в запросах (SKIP LOCKED/NOWAIT);
- ролях и других изменениях в системе привилегий;
- улучшениях в репликации.
MySQL: чек-лист для новичка в highload (Cвета Cмирнова, Aнастасия Распопина ...Anastasia Rostova
Подтемы доклада:
- обзор форков MySQL (для каких специфических задач подойдут форки вместо оригинального MySQL);
- что такое highload в современном мире (где ещё не highload, а где уже highload);
- что храним в памяти, что на диске;
- кэширование;
- кластеризация;
- репликация/шардинг базы данных;
- умеет ли СУБД кросс-датацентр репликацию;
- MySQL-индексы;
- настройка MySQL под нагрузку;
- лог медленных запросов в MySQL + анализ запросов;
- как понять, что "тупит" не MySQL.
Как сделать сложное простым. История создания Проект1917 / Сергей Спорышев (I...Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 6 июня, 13:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2732.html
В докладе я поделюсь нашим опытом разработки Project1917 - исторического проекта в реальном времени в формате социальной сети. Каждый web-программист мечтает написать свой фреймворк, CMS или соцсеть, и современный стек технологий дает настолько широкий выбор инструментов, что очень легко построить переусложненное архитектурное решение. ...
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?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
Ошибки проектирования высоконагруженных проектов / Максим Ехлаков (OneTwoRent)Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 15:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2632.html
Наиболее типичные ошибки, которые совершаются при создании высоконагруженных продуктов: выбор используемых языков, фреймворков, СУБД и других инструментов. Каковы причины совершения этих ошибок, и как их избежать.
Во время проектирования и разработки высоконагруженных программных продуктов существует большой соблазн применить классические подходы. Однако не все они будут полезны, а какие-то даже вредны. При этом цена каждой такой ошибки всегда будет очень большой.
На примере нескольких реальных проектов мы поговорим об ошибках проектирования, разработки и управления, о том, почему они возникли, и о решениях, которые позволили (или не позволили) преодолеть их.
RTB DSP на языке Go укрощение buzzwords / Даниил Подольский (Qmobi.Com)Ontico
RTB и его проблематика должны быть знакомы участникам конференции — мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие — нет, будет рассказано в докладе.
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)Ontico
NodeJS — достаточно молодой фреймворк, и пока не каждый решается использовать его в продакшене, а тем более в highload.
В течение последнего года мы разрабатывали проект DMP (Data Management Platform), используя NodeJS для прототипирования. На данный момент проект в большей степени все еще остался на JS и без труда справляется с текущими нагрузками в 10 000 запросов в секунду.
В докладе я расскажу, почему остановились именно на NodeJS и совсем не жалеем об этом.
К сожалению, никакое дело не обходится без граблей и костылей. Я расскажу обо всех встретившихся проблемах и уделю особое внимание проблемам со спагетти-кодом, утечками и нехваткой памяти. Как мы убили немало времени, тщетно ища источник проблем, и какие правила мы составили для себя на будущее, чтобы не повторить своих ошибок.
Расскажу немного о применении микросервисов для решения проблемы спагетти-кода.
И, как итог, опишу ряд рекомендаций, которые помогут избежать большой траты времени при использовании NodeJS.
Миф об очень сложном Highload / Александр Горный (Mail.Ru Group)Ontico
Highload, высокие нагрузки — популярный и дорогой buzzword, ради него проводятся огромные конференции, разработчики указывают его в резюме, претендуя на большие деньги, а работодатели в вакансиях, обещая более интересную работу.
В докладе я показываю, что современная производительность серверов позволяет не думать о нагрузке для 95% "highload" проектов, знания из конференций не нужны в реальной жизни. Для разработки почти любого, даже очень крупного сайта достаточно PHP+MySQL, здравого смысла и совсем-совсем базовых правил, не обсуждающихся даже на Highload Junior.
План выступления.
1. Ликбез о производительности. RPS, latency — что это значит, как считается, к каким числам надо стремиться? Из чего складывается время отклика? База данных, фронтенд, верстка или мобильное приложение.
2. Замеры достижимой производительности теплого LAMP-ового сервера. Бенчмарк без индексов в базе.
Бенчмарк с индексами в базе. Сравнение с требуемыми цифрами.
3. Перечисление возможных детских ошибок, которые могут испортить эти результаты в жизни. Все эти ошибки объясняются не в академии Highload или институте Highload Junior, а в школе.
Примеры ошибок:
- выгрузка всей базы, а не нужных 20 элементов;
- паразитный вызов тяжелой страницы;
- плохой хостинг;
- чужие тормозные элементы;
- неадекватный объём html/js-кода.
4. Отсутствие детских ошибок позволяет эффективно программировать 90% крупных сайтов, 3-4 приема превратят 90% в 95%.
- nginx;
- репликация;
- кэширование и предрасчет.
Этому, кстати, тоже почти не учат на highload junior, но этому я вас уже научил.
5. Примеры продуктов, в которых на самом деле нужен highload?
- Очень-очень-очень много хитов, дешевле highload, чем новое железо.
- Очень много очен�
Приключения проекта от компьютера разработчика до серьезных нагрузок / Андрей...Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 6 июня, 15:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2466.html
В этом докладе я хочу рассказать историю, с которой, скорее всего, сталкивался каждый.
История - путь проекта от стадии разработки до выкатывания его в продакшн, начала эксплуатации.
...
Организация надежного резервного копирования веб-проекта. Практика и подводны...Anton Baranov
1. Общая информация
- Что именно нужно бэкапить?
- Типы бэкапов. Плюсы и минусы.
- Периодичность создания.
- Выбор хранилища.
2. Бэкапы БД и файлов
- Обзор инструментов.
- Источники данных для бэкапов.
- Неочевидные особенности создания/восстановления.
3. Проблемы организации резервного копирования
- Актуальность данных.
- Скорость восстановления.
- Надежность создания резервных копий.
4. Верификация бэкапов
- Тестовый стенд.
- Мониторинг процесса.
- Ручные проверки.
smart balancing with nginx+lua / Андрей Кононов (IPONWEB)Ontico
В этом докладе я планирую осветить следующие проблемы:
- Почему стандартных механизмов балансировки бывает недостаточно.
- Как выбирать фундамент для решения, и какие принципы проектирования использовались.
- Как формировались требования для решения, которое работает сейчас в продакшне и пропускает через себя ощутимое количество.
Расскажу, как без помощи сторонних сессионных хранилищ и довольно за дёшево организовать "sticky balancing", и как это работает с точки зрения науки. Покажу пример отказоустойчивой геораспределённой системы, расскажу, что мониторить и как правильно это делать при помощи специального расширения для nginx и не только. Расскажу о том, как было организовано нагрузочное и функциональное тестирование конечного продукта. Также расскажу про полный жизненный цикл этого весьма критичного для инфраструктуры приложения.
Поскольку мы живём в публичных облаках, я по ходу доклада расскажу, как мы тестировали и сравнивали AWS и GCP, а также про некоторые сугубо практические особенности организации in-house балансировки внутри публичного облака.
Ангелы и демоны многопоточного программирования / Алексей Федоров (Одноклассн...Ontico
Современные процессоры имеют на борту по нескольку вычислительных ядер, позволяющих запускать задачи на них параллельно. И, казалось бы, вот оно — счастье: бей большие задачи на куски, запускай эти куски параллельно на разных ядрах и радуйся.
Но не все так просто. Для того чтобы одновременный доступ к общим данным выполнялся корректно, современные системы используют разные примитивы синхронизации. В основе одних лежат блокировки (locks), в основе других — операции типа сравнение-с-обменом (compare-and-swap). Однако и у тех и у других есть свои слабые места. О них мы и поговорим.
Из доклада вы узнаете, чем блокирующие алгоритмы отличаются от неблокирующих, и какими достоинствами и недостатками обладает каждый из этих классов. Кроме того, будут показаны различные подводные камни тех и других решений: Deadlock, Livelock, Starvation, Mutable vs Immutable hype.
LuaJIT как основа для сервера приложений - проблемы и решения / Игорь Эрлих (...Ontico
С того момента, как было принято решение использовать язык Lua в качестве языка описания бизнес-логики в нашей платформе, прошло уже больше восьми лет. Проекты росли, данных становилось больше, возрастала нагрузка на сервера приложений. Со временем у нас накопился солидный багаж знаний о том, как устроен LuaJIT, с какими проблемами можно столкнуться при его использовании и как эти проблемы можно решать.
Я расскажу про то...
* Почему при миграции с x86 на x64 доступной памяти в LuaJIT становится меньше, и как мы с этим боролись.
* Как загрузить в LuaJIT несколько миллионов объектов и не умереть в тормозах от сборщика мусора.
* Насколько ужасна встроенная функция хеширования строк и почему иногда надо жертвовать производительностью в пользу качества.
Cоциальный граф "Одноклассников" в myTargetOleg Tsarev
Задача выглядит обманчиво простой — рядом с баннером игры из Одноклассников показывать текстовый тизер «эту игру играет Кот Матроскин и ещё 5 твоих друзей» (имя и количество берутся из друзей пользователя на Одноклассниках).
Как обрабатывать граф друзей проекта Одноклассники для этой задачи?
На этот простой вопрос дают разные ответы:
- взять графовую базу данных
- использовать матрицу инцидентности
- использовать список смежных вершин.
Если уточнить, что сырые данные занимают полтора терабайта, в графе 200 миллионов вершин и 13 миллиардов связей, то ручные решения сразу отметаются.
«Графовая база данных!» Стоит озвучить нагрузку в десятки тысяч запросов секунду и требования отвечать за миллисекунды (тысячные доли секунды!) как графовые базы сразу оказываются за бортом — типичное время ответа на простые запросы — единицы секунд.
Экс-разработчик MySQL и SciDB, ныне ведущий разработчик myTarget Олег Царёв расскажет, как решалась эта непростая задача в рамках проекта.
ТОП ошибок в инфраструктуре, мешающих высоким нагрузкам / Андрей Половов (Флант)Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 14:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2706.html
Наша специализация — запуск и обслуживание высоконагруженных сервисов. За все время у нас не было ни одного проекта, в котором бы при запуске или эксплуатации сервиса не проявились нагрузочные проблемы, заложенные программистами или архитекторами. Цель доклада — структурировать типовые проблемы нагруженных проектов и дать практические советы по их урегулированию.
...
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
РИТ-2013: Доклад о решениях по асинхронной обработке данных, внедреннных в Мамбе. 1) собственный Comet-сервер, 2) Неудачное внедрение Gearman, 3) RabbitMQ: основы работы, тонкости и особенности внедрения.
NodeJS в HighLoad проекте / Акрицкий Владимир (iAge Engineering)Ontico
NodeJS — достаточно молодой фреймворк, и пока не каждый решается использовать его в продакшене, а тем более в highload.
В течение последнего года мы разрабатывали проект DMP (Data Management Platform), используя NodeJS для прототипирования. На данный момент проект в большей степени все еще остался на JS и без труда справляется с текущими нагрузками в 10 000 запросов в секунду.
В докладе я расскажу, почему остановились именно на NodeJS и совсем не жалеем об этом.
К сожалению, никакое дело не обходится без граблей и костылей. Я расскажу обо всех встретившихся проблемах и уделю особое внимание проблемам со спагетти-кодом, утечками и нехваткой памяти. Как мы убили немало времени, тщетно ища источник проблем, и какие правила мы составили для себя на будущее, чтобы не повторить своих ошибок.
Расскажу немного о применении микросервисов для решения проблемы спагетти-кода.
И, как итог, опишу ряд рекомендаций, которые помогут избежать большой траты времени при использовании NodeJS.
Миф об очень сложном Highload / Александр Горный (Mail.Ru Group)Ontico
Highload, высокие нагрузки — популярный и дорогой buzzword, ради него проводятся огромные конференции, разработчики указывают его в резюме, претендуя на большие деньги, а работодатели в вакансиях, обещая более интересную работу.
В докладе я показываю, что современная производительность серверов позволяет не думать о нагрузке для 95% "highload" проектов, знания из конференций не нужны в реальной жизни. Для разработки почти любого, даже очень крупного сайта достаточно PHP+MySQL, здравого смысла и совсем-совсем базовых правил, не обсуждающихся даже на Highload Junior.
План выступления.
1. Ликбез о производительности. RPS, latency — что это значит, как считается, к каким числам надо стремиться? Из чего складывается время отклика? База данных, фронтенд, верстка или мобильное приложение.
2. Замеры достижимой производительности теплого LAMP-ового сервера. Бенчмарк без индексов в базе.
Бенчмарк с индексами в базе. Сравнение с требуемыми цифрами.
3. Перечисление возможных детских ошибок, которые могут испортить эти результаты в жизни. Все эти ошибки объясняются не в академии Highload или институте Highload Junior, а в школе.
Примеры ошибок:
- выгрузка всей базы, а не нужных 20 элементов;
- паразитный вызов тяжелой страницы;
- плохой хостинг;
- чужие тормозные элементы;
- неадекватный объём html/js-кода.
4. Отсутствие детских ошибок позволяет эффективно программировать 90% крупных сайтов, 3-4 приема превратят 90% в 95%.
- nginx;
- репликация;
- кэширование и предрасчет.
Этому, кстати, тоже почти не учат на highload junior, но этому я вас уже научил.
5. Примеры продуктов, в которых на самом деле нужен highload?
- Очень-очень-очень много хитов, дешевле highload, чем новое железо.
- Очень много очен�
Приключения проекта от компьютера разработчика до серьезных нагрузок / Андрей...Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 6 июня, 15:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2466.html
В этом докладе я хочу рассказать историю, с которой, скорее всего, сталкивался каждый.
История - путь проекта от стадии разработки до выкатывания его в продакшн, начала эксплуатации.
...
Организация надежного резервного копирования веб-проекта. Практика и подводны...Anton Baranov
1. Общая информация
- Что именно нужно бэкапить?
- Типы бэкапов. Плюсы и минусы.
- Периодичность создания.
- Выбор хранилища.
2. Бэкапы БД и файлов
- Обзор инструментов.
- Источники данных для бэкапов.
- Неочевидные особенности создания/восстановления.
3. Проблемы организации резервного копирования
- Актуальность данных.
- Скорость восстановления.
- Надежность создания резервных копий.
4. Верификация бэкапов
- Тестовый стенд.
- Мониторинг процесса.
- Ручные проверки.
smart balancing with nginx+lua / Андрей Кононов (IPONWEB)Ontico
В этом докладе я планирую осветить следующие проблемы:
- Почему стандартных механизмов балансировки бывает недостаточно.
- Как выбирать фундамент для решения, и какие принципы проектирования использовались.
- Как формировались требования для решения, которое работает сейчас в продакшне и пропускает через себя ощутимое количество.
Расскажу, как без помощи сторонних сессионных хранилищ и довольно за дёшево организовать "sticky balancing", и как это работает с точки зрения науки. Покажу пример отказоустойчивой геораспределённой системы, расскажу, что мониторить и как правильно это делать при помощи специального расширения для nginx и не только. Расскажу о том, как было организовано нагрузочное и функциональное тестирование конечного продукта. Также расскажу про полный жизненный цикл этого весьма критичного для инфраструктуры приложения.
Поскольку мы живём в публичных облаках, я по ходу доклада расскажу, как мы тестировали и сравнивали AWS и GCP, а также про некоторые сугубо практические особенности организации in-house балансировки внутри публичного облака.
Ангелы и демоны многопоточного программирования / Алексей Федоров (Одноклассн...Ontico
Современные процессоры имеют на борту по нескольку вычислительных ядер, позволяющих запускать задачи на них параллельно. И, казалось бы, вот оно — счастье: бей большие задачи на куски, запускай эти куски параллельно на разных ядрах и радуйся.
Но не все так просто. Для того чтобы одновременный доступ к общим данным выполнялся корректно, современные системы используют разные примитивы синхронизации. В основе одних лежат блокировки (locks), в основе других — операции типа сравнение-с-обменом (compare-and-swap). Однако и у тех и у других есть свои слабые места. О них мы и поговорим.
Из доклада вы узнаете, чем блокирующие алгоритмы отличаются от неблокирующих, и какими достоинствами и недостатками обладает каждый из этих классов. Кроме того, будут показаны различные подводные камни тех и других решений: Deadlock, Livelock, Starvation, Mutable vs Immutable hype.
LuaJIT как основа для сервера приложений - проблемы и решения / Игорь Эрлих (...Ontico
С того момента, как было принято решение использовать язык Lua в качестве языка описания бизнес-логики в нашей платформе, прошло уже больше восьми лет. Проекты росли, данных становилось больше, возрастала нагрузка на сервера приложений. Со временем у нас накопился солидный багаж знаний о том, как устроен LuaJIT, с какими проблемами можно столкнуться при его использовании и как эти проблемы можно решать.
Я расскажу про то...
* Почему при миграции с x86 на x64 доступной памяти в LuaJIT становится меньше, и как мы с этим боролись.
* Как загрузить в LuaJIT несколько миллионов объектов и не умереть в тормозах от сборщика мусора.
* Насколько ужасна встроенная функция хеширования строк и почему иногда надо жертвовать производительностью в пользу качества.
Cоциальный граф "Одноклассников" в myTargetOleg Tsarev
Задача выглядит обманчиво простой — рядом с баннером игры из Одноклассников показывать текстовый тизер «эту игру играет Кот Матроскин и ещё 5 твоих друзей» (имя и количество берутся из друзей пользователя на Одноклассниках).
Как обрабатывать граф друзей проекта Одноклассники для этой задачи?
На этот простой вопрос дают разные ответы:
- взять графовую базу данных
- использовать матрицу инцидентности
- использовать список смежных вершин.
Если уточнить, что сырые данные занимают полтора терабайта, в графе 200 миллионов вершин и 13 миллиардов связей, то ручные решения сразу отметаются.
«Графовая база данных!» Стоит озвучить нагрузку в десятки тысяч запросов секунду и требования отвечать за миллисекунды (тысячные доли секунды!) как графовые базы сразу оказываются за бортом — типичное время ответа на простые запросы — единицы секунд.
Экс-разработчик MySQL и SciDB, ныне ведущий разработчик myTarget Олег Царёв расскажет, как решалась эта непростая задача в рамках проекта.
ТОП ошибок в инфраструктуре, мешающих высоким нагрузкам / Андрей Половов (Флант)Ontico
РИТ++ 2017, HighLoad Junior
Зал Сингапур, 5 июня, 14:00
Тезисы:
http://junior.highload.ru/2017/abstracts/2706.html
Наша специализация — запуск и обслуживание высоконагруженных сервисов. За все время у нас не было ни одного проекта, в котором бы при запуске или эксплуатации сервиса не проявились нагрузочные проблемы, заложенные программистами или архитекторами. Цель доклада — структурировать типовые проблемы нагруженных проектов и дать практические советы по их урегулированию.
...
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
РИТ-2013: Доклад о решениях по асинхронной обработке данных, внедреннных в Мамбе. 1) собственный Comet-сервер, 2) Неудачное внедрение Gearman, 3) RabbitMQ: основы работы, тонкости и особенности внедрения.
Антон Довгоброд: Highload и очереди задач на примере PHP + Gearman + Yii2Oleg Poludnenko
Доклад с PUG#4 https://www.facebook.com/events/350783888446030/
Презентует:
- Асинхронность в веб-приложениях.
- Систему очередей Gearman.
- Пример Реализации c использование Yii2 + Gearman.
101 способ приготовления RabbitMQ и немного о pipeline архитектуре / Филонов ...Ontico
Архитектурный шаблон проектирования конвейер (pipeline) хорошо зарекомендовал себя при проектировании высоконагруженных (highload) систем. Использование шины сообщений (message bus) при реализации каналов взаимодействия позволяет достигать хороших показателей масштабируемости (scalability), но при этом появляются дополнительные накладные расходы, которые сказываются на показателях производительности (performance).
В докладе обсуждаются варианты использования системы обмена сообщениями RabbitMQ в качестве связующего программного обеспечения (middleware) для построения конвейерной архитектуры. Рассматриваются вопросы производительности и масштабирования как stateless так и statefull фильтров.
В качестве примера рассматривается реализация системы обработки сложных событий (complex event processing) применительно к управлению журналированием (log management).
Очереди и блокировки. Теория и практика / Александр Календарев (ad1.ru)Ontico
В докладе будут описаны паттерны использования очередей и блокировок, рассказано, зачем нужны очереди и блокировки, показано на примерах использования в разных архитектурах.
Описано применение синхронных и асинхронных очередей, как построить очереди с приоритетами.
Будет сравнение разных серверов очередей: Redis, Tarantool, RabbitMQ, ZMQ, Kafka, Zookeeper, MemcacheQ и др., их преимущества и недостатки, где и какой брокер лучше использовать.
Очереди и блокировки. Теория и практика / Александр Календарев (ad1.ru)
Similar to 20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков
Обзор перспективных баз данных для highload / Юрий НасретдиновOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 10:00
Тезисы:
http://backendconf.ru/2017/abstracts/2773.html
В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.
...
Доклад от Parallels:
Методики тестировния производительности database-centric приложений
Описание: При работе над сложными продуктами в database-centric приложениях изменения в коде и тем более в SQL запросах к базе данных могут приводить к неожиданным падениям производительности или же деградации производительности приложения с ростом размера базы данных. Поэтому важно уметь как можно быстрее отлавливать и исправлять причины таких деградаций.
Доклад о том, как устроен процесс мониторинга производительности продукта автоматизации хостинга и облачных сервисов Parallels Automation, для которого определяющим фактором является производительность базы данных.
Компания покажет, как анализирует планы исполнения SQL запросов внутри PostgreSQL, как проверяет насколько быстро и эффективно в целом работают SQL запросы, как определяет стратегию дальнейшей оптимизации.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Управление ок...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Управление окружениями в сложном проекте: Chef и другие", Александр Чистяков (ведущий разработчик Cezurity).
Аннотация
Облачный антивирус, который мы делаем в партнерстве с vk.com, отличается от типичного веб-проекта наличием большого числа специализированных и не очень специализированных подсистем. Это ставит перед отделом эксплуатации принципиально новые вызовы: нужно не только уметь реагировать на случайные сбои и предсказывать неслучайные, но и просто помнить где что лежит и какую задачу выполняет. О том, как мы отвечаем на эти вызовы в компании Cezurity - мой доклад.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
ORM технологии в .NET (Nhibernate, Linq To SQL, Entity Framework)Pavel Tsukanov
Расскажу зачем они вообще нужны. Пройдемся по технологиям и промоем им косточки. Рассмотрим достоинства и недостатки, а также где и когда лучше всего применять ту или иную ORM.
Top-10 популярных вопросов администраторам баз данных или почему я против св...Ilya Kosmodemiansky
Similar to 20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков (20)
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Highload...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Highload и стартап на Java - как совместить?", Александр Константинов (основатель FriendRent, разрабочик в JetBrains)
Аннотация
Если долгое время создавал высоконагруженные и распределенные системы, а затем начал делать стартап, то в голове сразу же прорисовывается архитектура, которая должна быть у такого сервиса. Однако понятно, что создать за месяц большую и сложную систему - крайне затруднительно. Работая в Яндексе и JetBrains, мы накопили большой опыт разработки таких сервисов. В своём докладе я расскажу, как создать в стартапе архитектуру так, чтобы это заняло минимум времени, но при этом система могла бы легко выдержать миллион просмотров в месяц. От чего стоит отказаться, а на что наоборот следует обратить внимание, как упрощать систему, но при этом оставлять возможность расширения. Ключевые слова: Java, Spring, MySQL, JSP, Nginx.
Биография
Совладелец проекта FriendRent повященного аренде недвижимости через социальные сети. Senior Developer в компании JetBrains. В студенческие годы разрабатывал приложения для Вконтакте.
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуат...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Эксплуатация HBase на паре жизненных примеров", Александр Чистяков (ведущий разработчик Git in Sky)
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Строим N...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Когда надо изобретать свой велосипед? Строим NoSQL хранилище в приемлемые сроки", Александр Календарёв (разработчик РБК-Медиа Холдинг / Love Planet)
Аннотация
- Что из себя представляет Современная служба знакомств (крупная соцсеть в миниатюре).
- Какие задачи мы решаем и немного про общую архитектуру проекта.
- Обзор про существующие key/value решения
- Почему не нас не устроили memcachedb, redis, tarantool или MongoDВ...
- Какие велосипеды пришлось изобретать и что взяли готовое.
- Протокол обмена, почему выбрали memcached
- Как и зачем расширять существующие протоколы
- Как устроено хранилище изнутри (на базе key/value Hash & Tree), немного скучной теории про структуры данных, полезно тем, кто все же рискнет написать что-то своё.
- какие key/value АПИ можно еще использовать.
- Проблемы здоровья хранилища или зачем и как делать Мониторинг.
- возможность масштабирования, проблемы и пути решения.
Биография
Опыт в IT индустрии 15 лет, кандидат наук. Докладчик на Hi++ 2011, ADDConf-2, DevConf 2012, PHPConf 2009 и других. Автор блога highloadblog.ru. Круг интересов: хранение и обработка данных.
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Оптимиза...IT-Portfolio
16 декабря, DEV {highload} - конференция о Highload веб-разработке, "Оптимизация архитектуры для работы 24/7", Олег Краснов (системный архитектор SEMrush)
Аннотация
Со времени предыдущего доклада прошло полгода и мы сделали огромный рывок вперёд. В 2008 году система хранения SEMrush была построена на базе сочетания SQL с файловым хранилищем и позволяла выдерживать нагрузку примерно в 3 миллиона запросов в день. К моменту прошлого выступления нагрузка возросла на порядок, а сейчас на подобной нагрузке было успешно введено обновление данных онлайн без потери производительности.
В докладе, через призму краткой ретроспективы, будут освещены изменения технологий обработки данных проекта SEMrush. В ходе выступления будет проведен обзор изменившихся требований к системе, как в плане надёжности, так и скорости реакции на запросы пользователей. Выступление будет дополнено реальными проблемами, программного обеспечения и оборудования, а также способами их решения. Кроме этого будет произведён обзор планов на ближайшее будущее.
О компании
Компания SEMrush является разработчиком программного обеспечения для анализа конкурентов и определения ключевых слов для SEO оптимизации, входит в тройку мировых лидеров разработчиков аналитических инструментов для изучения трафика. Существует на рынке с 2007 года. Сервис SEMrush предоставляет пользователям информацию, необходимую для анализа конкурентной среды и оптимизации поисковой выдачи. SEMrush незаменим для углубленного анализа ключевых слов, позиций конкурентов, AdWords кампаний.
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Несколько...IT-Portfolio
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Несколько кейсов из жизни "больших" проектов", Виталий Гаврилов (технический директор "Ленвендо")
Аннотация
Команда разработчиков «Ленвендо» реализовала сотни проектов, среди которых были сайты и интернет-магазины для компаний: Эльдорадо, Газпромбанк, Связной, SUP media, Эхо Москвы в Петербурге, Банк БФА и другие. Специалисты компании в совершенстве владеют языками программирования от низкоуровневого C++ до высокоуровневых PHP, Perl, Bash и умею разрабатывать проекты с многомиллионной посещаемостью.
В рамках презентации будет рассмотрено несколько интересных кейсов из практики «Ленвендо». Мы поговорим об особенностях построения высоконагруженных проектов с использованием БД PostgreSQL, о резервном копировании и особенностях его организации в высоконагруженных проектах с большими объемами данных. Также остановимся на специфике проектов, размещенных в 2-х и более датацентрах, и тех инструментах, которые мы используем для построения таких проектов (csync2, MySQL Multi-Master Replication и т.д.).
Особое внимание будет уделено теме управляемого статического кеширования, позволяющего существенно (от 30% до нескольких раз) снизить нагрузку на backend-сервера с сохранением актуальности отображаемой на сайте информации (с помощью RabbitMQ, RedisDB, Nginx embedded Perl).
И напоследок - короткое «лирическое» отступление о том, когда и для чего имеет смысл использовать СУБД Oracle.
О компании
Компания «Ленвендо» - профессионал в области разработки, внедрения и технической поддержки высоконагруженных Интернет-решений. Компания была признана одной из лидеров по разработке Highload-систем (рейтинг Best in Digital 2013).
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Когда сто...IT-Portfolio
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Когда стоит написать свою БД", Олег Краснов (cистемный Архитектор SEMrush)
Аннотация
В 2008 году система хранения SEMrush была построена на базе сочетания SQL и файлового хранилища. Это позволило выдерживать нагрузку примерно до 3 миллионов запросов в день. Но уже в 2009 году было видно, что интерес к сервису растет стремительно и очень скоро старая система хранения будет основным сдерживающим фактором. Мы провели ряд экспериментов и в результате исследования остановились на собственной структуре хранения данных. Новая система была создана в предельно короткие сроки и уже через 3 месяца была введена в строй. Эта система используется и по сей день, хотя нагрузка выросла на порядок.
В докладе будет освещены история и методы построения хранилища данных проекта SEMrush. В ходе выступления будет проведена ретроспектива требований. Также докладчик расскажет об особенностях применяемого хранилища данных и отличиях от стандартных методов и средств. В том числе, будут освещены перспективы данной технологии применительно к реалиям и новым потребностям проекта.
О компании
Сегодня SEMrush – ведуший сервис для анализа конкурентов. Он позволяет узнать кейворды, по которым любой домен или сайт попадает в AdWords, выдачу Google и Bing. В отличие от других инструментов, которые позволяют анализировать только ваши собственные данные, SEMrush дает возможность изучить рекламные тексты конкурентов и собирает сведения об их бюджетах на продвижение в поисковиках.
20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Инженерны...IT-Portfolio
20 апреля DEV {highload} - конференция о Highload веб-разработке, "Инженерный дзен. DevOps на практике", Александр Титов (DevOps-эксперт "Экспресс 42")
Аннотация
Разработать программное обеспечение в веб-индустрии - это еще не все, надо его еще выкатить в производственное окружение и при этом не разочаровать пользователей. Обычно этот процесс происходит раз в месяц или две недели и сопровождается стрессом для всех участников, а часто заканчивается очень неприятной процедурой отката изменений, далеко не всегда безболезненной.
Проведем параллель с эволюцией в природе, разве там происходит так? Что-то меняется слишком резко и происходит откат? Нет, природа плавно меняет себя, делая небольшие изменения и пропуская их через проверку временем.
Инженерам, работающим в сфере программного обеспечения, дан уникальный шанс, они могут вносить изменения в работающий продукт каждый день, но для этого надо выполнить несколько условий:
- наладить в команде доверительные отношения;
- постоянно интегрировать продукт в тестовой среде;
- поддерживать непрерывный контекст при интеграции;
- использовать подходящие инструменты для управления конфигурацией и деплоя.
Доклад будет про то, как подобрать подходящие инструменты и процессы для работы и начать регулярно выкатывать ваш продукт. В мире принято такие практики называть DevOps.
Биография
Совладелец компании по внедрению DevOps-инструментов и процессов "Экспресс 42". Александр был техническим директором первого облака в России "Оверсан-Скалакси", потом руководил отделом системного администрирования в компании Скайп, подготовил инфраструктуру для запуска проекта видеосообщений.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Грабли при ма...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. «Грабли при масштабировании веб-приложения, на которые очень легко наступить», Евгений Коковихин (системный архитектор WapStart)
Аннотация
Что происходит при росте приложения с 1М до 50М хитов в сутки. С какими проблемами можно столкнуться, когда серверов становится больше одного. О чем важно помнить при проектировании приложения, способного масштабироваться.
Подробно
Когда мы сделали первую публичную версию plus1.wapstart.ru, она помещалась на один сервер и была соответствующим образом спроектирована. Потом нагрузка начала расти, а мы начинали наступать на грабли. В докладе будет рассказано о наиболее типичных "граблях", что возможно позволит избежать их другими разработчиками при проектировании приложения.
О чем пойдет речь (кратко):
* балансировка нагрузки;
* кеширование данных и прогрев кешей;
* работа с сетью;
* сессии;
* файлы, загружаемые пользователями;
* работа с СУБД.
Мы пишем на PHP, используем фреймворк OnPHP, СУБД Postgres.
Биография
Родился в несуществующем городе несуществующей страны. Первый мобильный телефон увидел в 1997 году. С детства любил программировать, последние 4 года посвятил развитию рекламы в мобильном веб. Своими глазами видел эволюцию мобильных устройств и предпочтений рекламодателей.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Особенности р...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Особенности работы с разработчиками", Алексей Капитанский (teamlead развлекательных сервисов Фотостраны).
13 октября, DEV {web} - конференция о Highload веб-разработке. "Java под нагр...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Java под нагрузкой, в поисках проблем...", Филипп Дельгядо (CTO Goodwix, ex-teamlead Яндекс.Деньги)
Аннотация
Не так давно с некоторым изумлением узнал, что Java для нагруженных систем представляется совершенной terra incognita. Хотя и совершенно не хочется бороться с мифами, по крайней мере, с удовольствием расскажу, как просто и без хлопот использовать Java в вебе. Про "суровый" highload рассказывать не буду, а вот про простые решения - с удовольствием. Ну и на закуску расскажу, за что я нежно люблю блобы.
О себе
Teamlead сколько себя помню, успел поработать и в "Яндекс.Деньгах" и в "БК Марафон". Люблю простые решения, сложные задачи и хорошую коммуникацию.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура п...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура проекта на 30 млн. пользователей", Дмитрий Смирнов (ведущий разработчик Фотостраны).
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура п...
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков
1. Демоны в большом проекте –
проблемы и их решения
Александр Чистяков
Младший системный администратор Cezurity
admin@cezurity.com
2013 dev.it-portfolio.net
2. Кто я?
• Топ-менеджер РАО ЕЭС
• Муж певицы Глюк’оZa
• Подрабатываю в компании Cezurity
системным администратором
dev.it-portfolio.net 2
3. Кто вы?
• 91.89% - Windows users
• 6.94% - OS X users
• 1.17% - Linux users
• Вы слышали про компьютерные вирусы?
• Если не слышали, вирус – это такая
программа для устаревших операционных
систем, несанкционированно
модифицирующая их работу
dev.it-portfolio.net 3
4. Отказ от ответственности
• Верите презентациям на слово?
картинка №1 (очень важная)
dev.it-portfolio.net 4
5. Чем занимается Cezurity?
• Создание облачного антивируса
• Целевая аудитория – те самые 91.89%
• Как мы уже выяснили, Windows в зале ни у
кого нет, поэтому речь пойдет не об
антивирусе, а о
• ВЫСОКИХ НАГРУЗКАХ
dev.it-portfolio.net 5
6. Что такое высокие нагрузки?
• Как установили ученые (британские), еще
викинги занимались созданием
высоконагруженных сайтов, они просто не
знали, что это – высоконагруженные сайты
• Высокие нагрузки – это когда вам
позвонили среди ночи, сообщить о том, что
все упало
• Где нагрузка выше: VK или Одоклассники?
dev.it-portfolio.net 6
7. Как викинги делали сайты?
• Методология “Фигак-фигак и в продакшн”
• У веб проекта должна быть архитектура!
• Со времен викингов проще жить не стало
dev.it-portfolio.net 7
8. А что такое архитектура?
• Веб-проект состоит из квадратиков
• Квадратики можно найти в сети и скачать!
• Если скачивать все найденные в сети
квадратики, к окончанию проекта успеете
• Многообразие квадратиков порождает
комбинаторный взрыв, следовательно
• Нужно знать, какие квадратики скачать!
dev.it-portfolio.net 8
9. Откуда мы знаем, что скачивать?
• “Берите тот дистрибутив Linux, который
стоит у вашего районного Linux-гуру”
• “Никто не был уволен за покупку Cisco”
• “Вся бытовая техника в доме должна быть
одного производителя”
• …и тому подобная чушь
dev.it-portfolio.net 9
10. Откуда мы знаем, что скачивать?
• А мы не знаем
• Некоторые квадратики попадают в проект,
потому что у команды есть предыдущий
опыт с ними (или языком/платформой)
• Некоторые квадратики попадают в проект
после сравнения свойств нескольких
кандидатов и выбора наиболее
подходящего
dev.it-portfolio.net 10
11. Архитектура типичного веб-проекта
• Сервер приложений (неинтересно)
• Reverse-proxy (тривиально)
• СУБД (товарищеский матч MySQL vs
PostgreSQL на стульях и швабрах в
перерыве)
• ORM (расшифровывается как “я не знаю
SQL”)
• Кэш
dev.it-portfolio.net 11
13. Итого, что нам было нужно
• СУБД?! (SQL or NoSQL? SQL and NoSQL? SQL
xor NoSQL?)
• Очереди
• Шардинг
• Кэш
• BigData
dev.it-portfolio.net 13
14. Техническая археология
• Проекту больше года, ключевые сервисы
уже на своих местах
• Попытка осмыслить пути выбора
составляющих архитектуры и оценить
достоинства и недостатки
dev.it-portfolio.net 14
15. SQL and NoSQL
• Необходимость не только писать данные в
базу, но еще и гарантированно читать их
обратно => старый добрый SQL
• Необходимость не просто читать данные,
но делать это быстро => рассмотрение
современных NoSQL решений
• Необходимость хранить данных больше,
чем влезает на один сервер (и на 2, и на 3)
dev.it-portfolio.net 15
16. Очереди
• Варианты:
– ActiveMQ (мир делится на Java-программистов
и не Java-программистов, среднего нет)
– RabbitMQ (5 баллов за маркетинг)
– ZeroMQ (не сервис, а библиотека)
– Kestrel (слова “a port of Starling from Ruby to
Scala” звучат как приговор)
– Beanstalkd (кто-нибудь в зале слышал?)
• Выбор пал на RabbitMQ
dev.it-portfolio.net 16
17. Впечатления Java-программиста
• Попытка прочесть и понять спецификацию
AMQP вызывает судороги
• Ни одна клиентская библиотека толком не
реализует поддержку AMQP keepalive
• Большая часть клиентских библиотек
похожа на студенческие курсовые
• Erlang – очень простой язык
• RabbitMQ чаще работает, чем не работает
dev.it-portfolio.net 17
18. Проблемы
• Написан на Erlang – надо знать Erlang
• Можно попробовать не знать Erlang, но
тогда конфигурация и эксплуатация
RabbitMQ будет вызывать неприятие
• Не можете понять Erlang – картинка №1!
• Очереди в памяти – при падении данные
теряются
• Памяти не хватает – все встает
dev.it-portfolio.net 18
19. Кто сказал «персистирование»?
• У нас уже есть PgQ (SkyTools)
• PgQ – это очереди поверх PostgreSQL
• Они работают хорошо
• Но дисковая подсистема на машинах, где
они развернуты, начинает работать плохо
• В RabbitMQ - диск лучше? Картинка №1!
• Большая часть наших сообщений живут
миллисекунды – зачем их персистировать?
dev.it-portfolio.net 19
20. Шардинг
• PL/Proxy – проект, позволяющий
организовать шардинг с использованием
хранимых процедур на PL
• (Как вы уже, наверное, догадались, мы
используем PostgreSQL)
dev.it-portfolio.net 20
21. Впечатления Java-программиста
• Хранимые процедуры это древнее зло
– Их сложно читать и понимать
– Их сложно отлаживать
– Сложно анализировать slow query log, так как
там не запросы, а вызовы хранимок
• К счастью, шардинг с помощью PL/Proxy
(пока) работает как часы
• (Кстати, PL/Proxy используется в Skype)
dev.it-portfolio.net 21
22. Кэш
• Варианты:
– memcached (в названии есть слово “cache”)
– Redis (в названии нет слова “cache”)
– MongoDB (“MongoDB is web scale!”)
– Membase/Couchbase (в названии все время
разные слова, И ЭТО НЕСПРОСТА, все мои
попытки внедрить Membase заканчивались
срочной эвакуацией с него)
dev.it-portfolio.net 22
23. Memcached
• Очевидный выбор
• С точки зрения топ-менеджера РАО ЕЭС
представляет собой slab allocator с lock-free
структурами данных, MVCC и evented I/O
• Просто работает, причем, у многих
• Не поддерживает объединение ключей в
множества (тегирование ключей, списки)
dev.it-portfolio.net 23
24. Redis
• Второй очевидный выбор
• Поддерживает списки
• Может работать как кэш, а может – как БД
• По умолчанию сохраняет данные на диск
dev.it-portfolio.net 24
25. MongoDB
• Судя по деталям реализации, была
написана викингами
• У нас отсутствует достаточный запас боевых
мухоморов, чтобы пытаться внедрить
продукт, технические решения в котором
долгое время противоречили здравому
смыслу (no WAL, global lock, random crashes
и другие атрибуты web2.0-ready решения)
dev.it-portfolio.net 25
26. Неочевидный вариант
• MySQL + HandlerSocket
• Не рассматривался никем, кроме меня –
все-таки, у антивирусной компании потоки
данных совсем не такие, как у типичного
веб-проекта
• Поэтому писать на диск данные из кэша
нам не надо – «горячие» данные все время
разные
dev.it-portfolio.net 26
27. Итак, Redis
• Сначала мы пытались использовать его еще
и как базу (без вытеснения)
• Два типа данных – с установленным
expiration date и персистентные
• Когда место в памяти заканчивается, Redis
перестает записывать данные
• Почему заканчивается место в памяти?
• Redis ведет slow log (у нас до 400-600 Mb)
dev.it-portfolio.net 27
28. Redis – итоговые настройки
• Вытеснять все без разбора:
– maxmemory-policy allkeys-lru
• Ничего не сохранять на диск: #save
• (Кстати, Redis долго читает состояние с
диска при рестартах, если оно есть)
• Если сохранение на диск было отключено
не сразу, надо стереть дамп
• slowlog-log-slower-than -10000
dev.it-portfolio.net 28
29. Redis – после внедрения
• Мы не используем репликацию (нет смысла
в силу особенности бизнеса)
• Мы храним данные в разных базах одного
инстанса и в нескольких разных инстансах
• Активно используем списки
• Мы не сразу нашли, куда расходуется
память, и даже хотели ее профайлить
• В целом, мы довольны
dev.it-portfolio.net 29
30. BigData
• Антивирусная компания – это очень много
данных, даже когда клиентов мало
• Данные нужно не только записать, но и
прочитать
• И не только прочитать, но и обработать
• Например, если в файле обнаружен новый
вирус, нужно сообщить всем клиентам, у
которых был такой файл
dev.it-portfolio.net 30
31. BigData
• Нельзя просто взять, и сложить все на одну
машину
• Варианты:
– RIAK, Cassandra, MongoDB, ТЫСЯЧИ ИХ
(eventually consistent == eventually inconsistent)
– HBase (strongly consistent)
– Vertica (стоит денег)
– Greenplum (стоит денег)
dev.it-portfolio.net 31
32. HBase - развертывание
• Раньше я ничего не говорил про это, так как
развертывание Redis, RabbitMQ,
memcached, etc - тривиально
• HBase развернуть тоже несложно – сначала
нужен ZooKeeper cluster
• Стойте, как я сказал, «несложно»?
• 5 сервисов на мастер-ноде, по 3 на слейвах
• 8 кукбуков в Chef
dev.it-portfolio.net 32
33. Стоп, а что это все-таки, HBase?
• Это такое key-value хранилище
• В котором ключи сохраняют отношение
порядка
• Потому что используется LSM tree
• Позволяет извлекать данные не только по
конкретным ключам, но и делать range
scans
• На уровне отдельной строки - атомарность
dev.it-portfolio.net 33
34. HBase – эксплуатация
• Ручки у HBase везде, и крутить их можно в
разные стороны
• Мы пока начинаем, и настраивали только
region size и max KeyValue size в сторону
увеличения
• Клиенты у нас на Python, работают через
Thrift
• Thrift-сервер требует больше памяти, чем
мог бы (Java-программист во мне смеется)
dev.it-portfolio.net 34
35. Из чего состоит HBase?
• ZooKeeper – координатор
• HDFS – распределенная файловая система
• Сервисы самого HBase поверх HDFS
• Сломаться может везде:
– ZooKeeper может потерять кворум из-за
задержек ответа нод
– Файловая система может потребовать
проверки
– master node может умереть
dev.it-portfolio.net 35
36. Как обеспечивать устойчивость?
• Подстроить сетевые таймауты
• Поставить рядом второй кластер и делать
репликацию данных на него
• Либо быть готовым к проверке файловой
системы в ручном автоматическом режиме
• Дублировать master node
dev.it-portfolio.net 36
37. Так в ручном или не в ручном?
• А что может сломаться на файловой
системе, когда вышестоящие сервисы
обеспечивают strong consistency?
• Write-ahead logs
• Что-то потеряли в WALs?
– Картинка №1!
• Автоматическая проверка – хорошо, но
может быть долго
dev.it-portfolio.net 37
38. Перспективный план
• Научиться ломать HBase
• Научиться чинить HBase
• Научиться редко ломать HBase
• Научиться быстро чинить HBase
• ????????
• В октябре прочитать про это большой
доклад
dev.it-portfolio.net 38
39. В анонсе было про Node.JS
• Каково назначение Node.JS в
инфраструктуре?
• Генерировать непонятные эксепшны вида
[2013-04-19 22:21:41.987] [FATAL] daemon - !! Unhandled exception !! TypeError: Object [object Object] has no method 'destroy'
at onclose (stream.js:74:10)
at EventEmitter.emit (events.js:115:20)
at RequestStream.destroy (/opt/node-server/lib/http_server.js:220:7)
at IncomingMessage.onclose (stream.js:74:10)
at IncomingMessage.EventEmitter.emit (events.js:115:20)
at abortIncoming (http.js:1649:11)
at CleartextStream.serverSocketCloseListener (http.js:1659:5)
at CleartextStream.EventEmitter.emit (events.js:115:20)
at SecurePair.destroy (tls.js:907:22)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
dev.it-portfolio.net 39
40. Лист ненависти
• Прочь с моего облака! (с) The Rolling Stones
• Node.JS есть? А если найду?
• Крокфорда читали?
• Node.JS был выбран, «потому что он
быстрый»
• Анекдот про скорость печати в 400
символов в минуту
• Use statically typed languages, Luke!
dev.it-portfolio.net 40
41. Выводы
• Абсолютное большинство проблем – не в
софте, а в голове
• Надо только вовремя понять, в чьей (в
своей, или в голове разработчика сервиса)
• Если вы берете в проект сервис, вам
придется на нем жениться быть готовым
поддерживать его код
• Очень важно помнить про картинку №1
dev.it-portfolio.net 41
42. Пора закругляться
• Если погода хорошая – поблагодарить
• Если погода плохая – извиниться за то, что
пришлось ее испортить
• Вопросы?
• Голосуйте за меня на http://devconf.ru/offers
• http://twitter.com/noatbaksap
• http://github.com/alexclear
dev.it-portfolio.net 42