Эта статья посвящена конференции, которая проводилась почти 2 года назад. Зачем писать про такие давние события? Во-первых, на мой взгляд, про эту конференцию не многие знают. Во-вторых, мои личные впечатления от нее настолько сильны даже спустя два года, что я просто не могу ими не поделиться. В-третьих, очень хотелось написать, но не очень было понятно как это сделать, так как раньше обзоров я никогда не писала, это моя третья попытка написать об этой конференции. И, конечно, я хочу поблагодарить компанию Distillery, в которой я на тот момент работала, и моего научного руководителя Сергея Мещерякова за возможность посетить эту конференцию.
Международная конференция CMG impact ежегодно проводится американской ассоциацией специалистов в области улучшения производительности IT систем. Ежегодная конференция CMG проводится с 1980 года.
Конференция посвящена Performance engineering and capacity planning (улучшение производительности и планирование пропускной способности). Организаторы, докладчики и участники конференции – это высококвалифицированные специалисты в IT или в области capacity planning, многие из которых начинали работать еще на мейнфреймах, потом ушли в распределенные системы, и в настоящее время продолжают работать в ведущих компаниях отрасли. Квалификация многих из них поражает воображение. На конференции были компании или их представители, которые относятся к мониторингу или тестированию производительности Dynatrace, NewRelic, Soasta, Jmeter, BMC, Moviri, BezNext и многие другие.
На конференции было представлено 120 докладов из более 15 стран мира, в основном США, Канады и Европейских стран. Проводилась она в течение пяти дней с 7 по 11 ноября 2016 года. Режим работы был следующим: доклады на пленарном заседании начинались с 8.00 утра и продолжались секционными докладами в 8 залах до 19.00 вечера с небольшим перерывом на обед в районе полудня. Каждый рабочий день конференции заканчивался общим фуршетом, во время которого можно было лично пообщаться со всеми выступающими и обсудить представленные доклады. Довольно сложно было сделать выбор, какой доклад посетить, так как в параллельных сессиях интересующие доклады шли одновременно в разных залах.
В данной статье я кратко опишу наиболее понравившиеся мне доклады.
Американская ассоциация специалистов в области улучшения производительности IT систем Computer Management Group в 1974 году учредила ежегодную награду Абрахама Михельсона за профессиональный вклад в оценку производительности систем. Данная награда традиционно вручается на конференции CMG impact.
Конференция открылась вручением премии A. A. Михельсона Андре Бонди (Andre Bondi), независимому консультанту, автору книги Foundations of Software and System Performance Engineering: Process, Performance Modeling, Requirements, Testing, Scalability, and Practice.
Первое пленарное заседание началось докладом Андре Бонди. Ключевой мыслью доклада было то, что тюнинг никогда не приведет к улучшению производительности в разы. По мнению автора доклада, наибольший рост производительности можно получить, устраняя архитектурные ошибки в системе. Думаю, многие из вас знают об этом из личного опыта. Я много раз за свою карьеру приходила к такому же выводу. Например, переезд с одной вроде как более производительной системы на более скромную систему opensource может дать прирост производительности, если в процессе переноса команда устранит архитектурные ошибки предыдущей версии системы.
Achieving Scalability and Performance > 1M Concurrent Users at Time
Следующим интересным для меня выступлением был доклад тех. директора Grindr Лукаша Сливки. Grindr – это приложение для онлайн знакомств. Лукаш рассказывал одновременно и о преобразовании компании, и о культуре разработки (они перешли на scrum), и о техническом преобразовании системы. У Grindr более 2,5 миллиона пользователей из которых 1 миллион активных. Основные пользователи до преобразования находились в США и Канаде, по мере удаления от США количество пользователей уменьшалось.
Серверы и хранилища данных также находились в основном в США. Кроме того, приложение уже переехало на самый мощный сервер из возможных на хостинге, и компания столкнулась с острой проблемой оптимизации и масштабирования. Проблема оптимизации и масштабирования была решена радикально — команда переписала полностью весь проект с Ruby on Rails на Scala, это заняло полгода. Scala выбрали по двум причинам: во-первых, можно было писать чистый код с хорошей производительностью; во-вторых, разработчики на Java были более доступны для найма, в отличие от разработчиков на Node.js, которые были дороги и все работали в Facebook.
Интересный опыт компании Grindr доказывает, что для успешного развития иногда нужна новая архитектура. Далее был проведен анализ продолжительности отклика в разрезе по каждой стране, и оказалось, что чем дольше отклик, тем меньше в данной стране пользователей. Команда разработчиков оптимизировала время отклика, значительно уменьшив его, используя CDN, и распределив хранилище данных по облачным серверам с центрами в Европе, Азии и Латинской Америке. После того, как проблемы с производительностью были решены, количество пользователей приложения возросло по всему миру. Данный пример доказывает прямую взаимосвязь между коротким временем отклика и количеством пользователей.
Вторая часть доклада была посвящена управлению командой. Grindr работает по Scrum. Разделение команд сделано по продуктам, то есть каждая команда отвечает полностью за какой-то сервис или продукт для пользователя, и за business value которую пользователь получает. Компания является metric-driven компанией, и у каждой команды есть свои метрики и KPI, которые они должны достигать. Менеджмент среднего звена полностью отсутствует. В компании плоская структура, и команда сама решает, что и как нужно сделать, чтобы достигнуть поставленных задач. Доклады Лукаша есть в записи на youtube. Интервью Лукаша доступно по ссылке.
Is Your Capacity Available?
Интересно, что автор начал свой доклад с информации о том, что банк Capital One принял решение стать открытой в информационном плане компанией. Общеизвестно, что банки обычно не рассказывают о технологиях и процессах. Исползуемых в их работе, считая эту информацию конфиденциальной. Однако в современном мире, чтобы конкурировать за ведущих специалистов и их таланты, которые, как правило, уходят работать в Google и Facebook, банкам необходимо быть более открытыми.
Доклад был посвящен оценке сочетания доступности системы и запаса ее производительности. Так как никому не нужна пропускная способность, которую невозможно использовать.
Игорь описывает конкретную форму, как можно померять свою capacity и ее доступность. У него есть такие метрики как среднее время между падениями, среднее время на восстановление, время простоя за год и другие. Игорь приводит формулу, с помощью которой вы можете посчитать доступность всей вашей инфраструктуры для пользователей. Подробнее можно посмотреть его доклад.
Digital Experience Capacity Planning
Доклад про планирование для IoT Business metrics, IT metrics and Facilities metrics.
Доклад про то, что многие инфраструктуры сейчас работают близко к пределу своей пропускной способности, а что же будет когда будет работать повсеместно IoT. Для меня самым интересным в докладе был его масштаб. То есть есть профессионалы, которые планируют для сайта, для организации, а это целая отрасль. Насколько часто мы поднимаемся до такого масштабного видения?
Enterprise performance assurance based on BigData analytics
Борис рассказывает о BigData и подходах работы с большими данными. Он выделяет следующие стадии работы с данными. Прогностический анализ, так как бизнес должен принимать решения основываясь на данных в текущем моменте. Время — деньги и ничего не изменилось за многие годы, разве что время стало еще дороже сейчас. Информация стоит дорого, если она актуальна.
Работа с кластерами больших данных позволяет дать необходимый анализ вовремя. Далее Борис описывает этапы. Два основных подхода — делать анализ данных в потоке в реальном времени или собрать из в DataLake.
В докладе описан подход использования алгоритмов обработки больших данных и машинного обучения для проведения RCA при сбоях, а также построения прогнозов на основе таких отчетов о дальнейшем поведении системы.
Важным моментом является проверка достоверности результатов, через сравнение фактического поведения с прогнозируемым.
The Top 10 Performance Defects Costing Online Organizations Millions
Крейг описывает топ 10 самых дорогих ошибок которые влияют на производительность сайта. Крейг приводит цифры, что в среднем за 1 секунду ожидания пользователя компания в потенциале теряет 102 миллиона долларов. Интересно, да? Компания сделала анализ около 500 вебсайтов и составила топ 10 основных проблем, которые ведут к низкой производительности. Рекомендации Крейга об использовании кэшей, CDN, настройки правильного разрешения изображений, использования компрессии. А главное тестирования того, что получилось, как оказалось многие думают, что используют кэш, но порядка 70% контента при этом может не кэшироваться из-за неверных настроек. Крейг рекомендует установить бейслайн по производительности и придерживаться его, установить цель по производительности, которую нужно достичь, тестировать и оптимизировать узкие места. Средства для теста webpage test, google analytics, pagespeed, rigor free report. Самой забавным для меня были картинки на сайтах в большом расширении, при этом размер не позволяет оценить этого, так что снижение разрешения не приводит к ухудшению качества.
Мне не удалось найти слайды Крейга, но вот доклад на ту же тему одного из сотрудников компании.
Risky Business
Пару слов о Джефе — он преподаватель в Гарварде, автор 3х книг, первая вышла в 71году, а последняя в 2015 — Rethinking Randomness: A New Foundation for Stochastic Modeling, статья на вики, Интервью с Джеффом.
Доклад о моделировании и прогнозировании производительности. Джеф описывает риски, которые возникают при моделировании системы — риск модели, риск параметров нагрузки системы, риск прогноза, риск приложения, риск возможности использования — в работе. Джефф подробно описывает все возможные риски, которые появляются при моделировании системы и попытки спрогнозировать сколько ресурсов потребуется и какая при этом доступность системы нужна. Варианты как не надо писать SLA – 90% запросов выполняются за 0.5 секунды. Менее рискованно – длинна очереди меньше 33х 90% времени. Его книга об этом. Прогнозирование, которое мы используем из классической математики не всегда дает корректные применимые результаты, хотя формулы могут быть верными. Предсказания очень сильно зависят от допущений модели. Более предпочтительно использовать прогноз основанный на анализе альтернатив (AoA, Analysis of Alternatives).
Я сидела и думала – насколько же это далеко от моего опыта – о, у нас остался запас по производительности всего в 2 раза, что? Как узнали? Ну был пик и в системе уже копились очереди, давайте возьмем сервер побольше. Что говорите? Хорошо что есть очереди? Ну так до того, как мы их стали использовать система просто падала. Вот такой подход с планированием производительности начиная с модели системы — какая-то другая планета.
How to get value out of BigData?
Далее был workshop от компании Moviri. Мовири – компания основанная преподавателем политехнического университета Милана, с офисом в Милане и Бостоне, специализирующаяся на анализе производительности и пропускной способности. О том как важно не только собирать массу данных, но и извлекать из них пользу. Стек Yarn, HDFS, Pig, Hive, Spark, Zookeeper, Cassandra, Cloudera, Kubernetes. В докладе было показано, насколько удобнее стало работать с изменением производительности с системами, работающими в контейнерах.
Компания Moviri приглашала в гости в офис, чем я воспользовалась, так как примерно через месяц ехала в Италию. Было очень здорово встретиться со Стефано Дони и познакомиться с Лука Форни, посмотреть офис и поговорить обо всем, что касается анализа производительности, начиная с анализа производительности и заканчивая проблемами, с которыми сталкиваются консультанты при общении с командой заказчика.
Блог Мовири.
Performance or Capacity? Different approaches for different tasks
Доклад будет полезен тем кто занимается прогнозированием производительности и планированием пропускной способности. Александр приводит примеры и подходы, которые должны использоваться для каждого из случаев. В общем и целом хотя capacity и performance понятия близкие, но для прогнозов должны быть использованы разные методы, с акцентом на конечной цели работы. Для чего мы это делаем? Мы хотим понять сколько оборудования нам нужно и какую пропускную способность мы хотим обеспечить или мы хотим спрогнозировать производительность системы.
Вот тут можно прочитать статью Александра.
Слайды.
How to get started when you don’t know where to start.
О том зачем вообще нужно делать мониторинг производительности. А ведь правда! Живут многие без мониторинга и все вроде бы у них нормально. И правда, многим он не нужен. До тех пор пока они не публикуют статью про свой чудесный сайт на хабре и к ним не заходят люди посмотреть, что там. Или пока что-то другое не приводит к ним много-много пользователей.
В докладе Джастин довольно просто рассказывает, что же можно сделать для того, чтобы начать. Capacity management in 90 days
Шаги
Линкедин Джастина. Слайды можно посмотреть в статье о конференции, которую я опубликую в конце.
Dynamic load Balancing and Continuous Service Delivery in a Big Cloud Infrastructure
Юрий описывает переход RingCentral от монолита, с легаси кодом на микросерсисы. Проблемы с монолитным кодом были в том, что сложно менять конфигурацию, не было возможности делать continuous delivery, трудности в достижении нужных показателей доступности, не было возможности делать A\B тестирование, возможность применить новый функционал только для части пользователей. Был проведен редизайн системы и в новом дизайне использовались контейнеры и микросервисы, появилась возможность делать ресайз системы в онлайн, возможность менять версию сервиса без изменения конфигурации. В микросервисной архитектуре были выделены слой прикладной маршрутизации, слой балансировки, слой обслуживания (не хранит состояние). После внесения изменений Ops команды смогли делать непрерывную доставку на лету, доступность системы возросла с 4 девяток до 99.998. Время, требующееся на увеличение системы и развертывания новых серверов сократилось до 4х часов.
Avoiding costs, delays and failed releases with Lifecycle Virtualization
Доклад Тода посвящен тому как уменьшить проблемы при релизах и ключевая идея в том, чтобы при тестировании программы важно учитывать весь жизненный цикл программы.
4 ключевые его составляющие:
Исходя из моего опыта, большой процент ошибок при деплое происходит как раз из-за того, что мало кто выполняет все 4 условия, и на проде всегда оказывается что-то, чего никто не ожидал увидеть, и это что-то ломает релиз. Очень важно использовать разые use-case с прода по данным и поведению пользователя.
Вот пример из презентации Тода:
Тод — Автор книги про оптимизацию производительности, перф тесты и их интерпретацию.
В книге рассказывается как важна культура тестирования производительности в организации, как ее можно привнести, если сейчас этим никто не занимается. Приведены несколько примеров из практики с описанием задача, которая стоит перед командой, вариантами ее решения, описан какой подход выбрала команда и какие последствия были в реальной системе. На мой взгляд эти истории часто еще и о том, насколько сложно предсказать поведение конечного пользователя, и как важно все таки делать небольшую фокус группу из конечного числа пользователей и смотреть насколько ваш прогноз совпал с поведением фокус группы.
Implementing Metrics-Driven DevOps: Why and How!
Доклад Андреаса Грабнера про практики DevOps в разных команиях и про то, почему важен короткий time2market. Андреас использовал очень интересную метафору про фотографии. Многие помнят пленочные фото – вы делаете фотографию, идете проявляете, печатаете и видите, что она неудачная, но у вас нет возможности переснять фото, так как вы уже не в том моменте.
Сейчас все иначе – вы делаете фото, выкладываете его в инстаграм и тут же получаете обратную связь и можете доснять что-то из того, что просят ваши подписчики. Вы еще в моменте и получаете реакцию в реальном времени.
Теперь, вернемся к программному обеспечению – как было раньше – новые функции ПО планировали, реализовывали, тестировали и делали, например, 1 релиз в год. И понимали, что функциональность, на которую потрачена куча денег и сил нужна двум пользователям из миллионов. У вас такое бывало?
Как сейчас? Agile и возможность делать релизы хоть каждый день как это делает Facebook – возможность сразу же оценить насколько эта функциональность востребована пользователями, нужно ли ее обвешивать рюшечками или лучше выкинуть сразу и не тратить силы и время.
Я очень рекомендую доклад бизнесу, который пытается объяснить своей команде зачем им Scrum и Agile! Сейчас многие махровые enterprise компании с релизами 3 раза в год пытаются стать быстрее, тоньше и звонче
Вообще доклад не об этом, а о том, как построить практики DevOps, делать релизы часто и хорошо. Да, такое бывает. Важно использовать метрики и мониторить ситуацию с приложением, нагрузкой, делать правильный деплой по процессу. Андреас performance advocate и у него довольно много полезных докладов на эту тему с необычными и запоминающимися слайдами.
Вот доклад Андреаса с немного другими слайдами.
Performance Testing in New Contexts
В начале доклада Эрик ретроспективно рассказал как менялась архитектура систем с 2000, как переход в облако изменил или должен был изменить, то как проектируют системы с учетом возможности масштабирования в облаке. Эрик приводит пример из практики, когда одна из TV компаний запустила голосование в мобильном приложении и как раз во время шоу, когда пользователи должны голосовать система не выдержала нагрузки и была недоступна. С культурой стартапов сложно предсказать сколько пользователей будет, может планировалось 20 тысяч, а приложение быстро доберет до 50 тысяч. Есть много приложений для тестирования производительности в облаке BlazeMeter (Jmeter), Selenium, Gatling, Grinder. Они бесплатны, но визуализировать результаты не очень удобно. Поэтому рекомендуется использовать либо еще средство для визуализации (Tableau) либо использовать собственную БД, чтобы потом анализировать то, что получилось. При тестировании веб приложений важно обращать внимание на то, чтобы приходящие тестовые пользователи были геораспределенными. Желательно делать небольшие перф тесты каждую сборку и сравнивать их с базовыми результатами.
Слайды по докладу Эрика можно посмотреть на slideshare.
Эрик автор блога.
Кроме представленных на конференции докладов, было также организовано несколько обсуждений в форме «Круглого стола». Несколько экспертов осуждали заданную тему в формате живого активного диалога с залом. На мой взгляд, это очень интересный формат, так как слушатели конференции могли поделиться своим часто внушительным опытом, и можно было подойти пообщаться с каждым экспертом и участником, обсудив интересующие вопросы.
Особую часть моих впечатлений от конференции составляет неформальное общение с докладчиками и участниками. Благодаря формату проведения дискуссий, обедов, круглых столов и фуршетов, можно познакомиться с людьми со всего мира из разных компаний и обменяться опытом. Довольно много общения внутри конференции. Люди очень открыты и готовы обмениваться опытом.
Отдельно хочу упомянуть Debbie Sheetz. Дебби работала в компании BMC и начинала анализ производительности еще на мейнфреймах. Затем она перешла в распределенные системы. Ее опыт работы в мониторинге огромен и очень интересен.
Также мне посчастливилось пообщаться с Ануш Наджарян из компании MathWorks, чей опыт также заслуживает внимания.
К сожалению, количество докладов не позволяет посетить их все, и записи докладов не ведется, то есть, нет возможности их пересмотреть дома. Организаторы используют статьи для отбора докладчиков, и эти статьи потом передаются участникам конференции, но материалы приглашенных докладчиков в сборнике отсутствуют.
Вот статья Ануш о конференции.
CMG impact очень полезная и интересная конференция с потрясающей атмосферой обмена опытом, которую я рекомендую посетить.
Международная конференция CMG impact ежегодно проводится американской ассоциацией специалистов в области улучшения производительности IT систем. Ежегодная конференция CMG проводится с 1980 года.
Конференция посвящена Performance engineering and capacity planning (улучшение производительности и планирование пропускной способности). Организаторы, докладчики и участники конференции – это высококвалифицированные специалисты в IT или в области capacity planning, многие из которых начинали работать еще на мейнфреймах, потом ушли в распределенные системы, и в настоящее время продолжают работать в ведущих компаниях отрасли. Квалификация многих из них поражает воображение. На конференции были компании или их представители, которые относятся к мониторингу или тестированию производительности Dynatrace, NewRelic, Soasta, Jmeter, BMC, Moviri, BezNext и многие другие.
На конференции было представлено 120 докладов из более 15 стран мира, в основном США, Канады и Европейских стран. Проводилась она в течение пяти дней с 7 по 11 ноября 2016 года. Режим работы был следующим: доклады на пленарном заседании начинались с 8.00 утра и продолжались секционными докладами в 8 залах до 19.00 вечера с небольшим перерывом на обед в районе полудня. Каждый рабочий день конференции заканчивался общим фуршетом, во время которого можно было лично пообщаться со всеми выступающими и обсудить представленные доклады. Довольно сложно было сделать выбор, какой доклад посетить, так как в параллельных сессиях интересующие доклады шли одновременно в разных залах.
В данной статье я кратко опишу наиболее понравившиеся мне доклады.
Американская ассоциация специалистов в области улучшения производительности IT систем Computer Management Group в 1974 году учредила ежегодную награду Абрахама Михельсона за профессиональный вклад в оценку производительности систем. Данная награда традиционно вручается на конференции CMG impact.
Открытие конференции и вручение премии A. A. Михельсона (Michelson Award)
Конференция открылась вручением премии A. A. Михельсона Андре Бонди (Andre Bondi), независимому консультанту, автору книги Foundations of Software and System Performance Engineering: Process, Performance Modeling, Requirements, Testing, Scalability, and Practice.
Первое пленарное заседание началось докладом Андре Бонди. Ключевой мыслью доклада было то, что тюнинг никогда не приведет к улучшению производительности в разы. По мнению автора доклада, наибольший рост производительности можно получить, устраняя архитектурные ошибки в системе. Думаю, многие из вас знают об этом из личного опыта. Я много раз за свою карьеру приходила к такому же выводу. Например, переезд с одной вроде как более производительной системы на более скромную систему opensource может дать прирост производительности, если в процессе переноса команда устранит архитектурные ошибки предыдущей версии системы.
Achieving Scalability and Performance > 1M Concurrent Users at Time
Лукаш Сливка (Lukas Sliwka), Grindr
Следующим интересным для меня выступлением был доклад тех. директора Grindr Лукаша Сливки. Grindr – это приложение для онлайн знакомств. Лукаш рассказывал одновременно и о преобразовании компании, и о культуре разработки (они перешли на scrum), и о техническом преобразовании системы. У Grindr более 2,5 миллиона пользователей из которых 1 миллион активных. Основные пользователи до преобразования находились в США и Канаде, по мере удаления от США количество пользователей уменьшалось.
Серверы и хранилища данных также находились в основном в США. Кроме того, приложение уже переехало на самый мощный сервер из возможных на хостинге, и компания столкнулась с острой проблемой оптимизации и масштабирования. Проблема оптимизации и масштабирования была решена радикально — команда переписала полностью весь проект с Ruby on Rails на Scala, это заняло полгода. Scala выбрали по двум причинам: во-первых, можно было писать чистый код с хорошей производительностью; во-вторых, разработчики на Java были более доступны для найма, в отличие от разработчиков на Node.js, которые были дороги и все работали в Facebook.
Интересный опыт компании Grindr доказывает, что для успешного развития иногда нужна новая архитектура. Далее был проведен анализ продолжительности отклика в разрезе по каждой стране, и оказалось, что чем дольше отклик, тем меньше в данной стране пользователей. Команда разработчиков оптимизировала время отклика, значительно уменьшив его, используя CDN, и распределив хранилище данных по облачным серверам с центрами в Европе, Азии и Латинской Америке. После того, как проблемы с производительностью были решены, количество пользователей приложения возросло по всему миру. Данный пример доказывает прямую взаимосвязь между коротким временем отклика и количеством пользователей.
Вторая часть доклада была посвящена управлению командой. Grindr работает по Scrum. Разделение команд сделано по продуктам, то есть каждая команда отвечает полностью за какой-то сервис или продукт для пользователя, и за business value которую пользователь получает. Компания является metric-driven компанией, и у каждой команды есть свои метрики и KPI, которые они должны достигать. Менеджмент среднего звена полностью отсутствует. В компании плоская структура, и команда сама решает, что и как нужно сделать, чтобы достигнуть поставленных задач. Доклады Лукаша есть в записи на youtube. Интервью Лукаша доступно по ссылке.
Is Your Capacity Available?
Игорь Трубин (Igor Trubin), Банк Capital One
Интересно, что автор начал свой доклад с информации о том, что банк Capital One принял решение стать открытой в информационном плане компанией. Общеизвестно, что банки обычно не рассказывают о технологиях и процессах. Исползуемых в их работе, считая эту информацию конфиденциальной. Однако в современном мире, чтобы конкурировать за ведущих специалистов и их таланты, которые, как правило, уходят работать в Google и Facebook, банкам необходимо быть более открытыми.
Доклад был посвящен оценке сочетания доступности системы и запаса ее производительности. Так как никому не нужна пропускная способность, которую невозможно использовать.
Игорь описывает конкретную форму, как можно померять свою capacity и ее доступность. У него есть такие метрики как среднее время между падениями, среднее время на восстановление, время простоя за год и другие. Игорь приводит формулу, с помощью которой вы можете посчитать доступность всей вашей инфраструктуры для пользователей. Подробнее можно посмотреть его доклад.
Digital Experience Capacity Planning
Эми Спелман и Ричарда Гимарка (Amy Spellmann and Richard Gimark)
Доклад про планирование для IoT Business metrics, IT metrics and Facilities metrics.
Доклад про то, что многие инфраструктуры сейчас работают близко к пределу своей пропускной способности, а что же будет когда будет работать повсеместно IoT. Для меня самым интересным в докладе был его масштаб. То есть есть профессионалы, которые планируют для сайта, для организации, а это целая отрасль. Насколько часто мы поднимаемся до такого масштабного видения?
Enterprise performance assurance based on BigData analytics
Борис Зибицкер (Boris Zibitsker)
Борис рассказывает о BigData и подходах работы с большими данными. Он выделяет следующие стадии работы с данными. Прогностический анализ, так как бизнес должен принимать решения основываясь на данных в текущем моменте. Время — деньги и ничего не изменилось за многие годы, разве что время стало еще дороже сейчас. Информация стоит дорого, если она актуальна.
Работа с кластерами больших данных позволяет дать необходимый анализ вовремя. Далее Борис описывает этапы. Два основных подхода — делать анализ данных в потоке в реальном времени или собрать из в DataLake.
В докладе описан подход использования алгоритмов обработки больших данных и машинного обучения для проведения RCA при сбоях, а также построения прогнозов на основе таких отчетов о дальнейшем поведении системы.
Важным моментом является проверка достоверности результатов, через сравнение фактического поведения с прогнозируемым.
The Top 10 Performance Defects Costing Online Organizations Millions
Крейг Хайд (Craig Hyde), компания Rigor and Rigor
Крейг описывает топ 10 самых дорогих ошибок которые влияют на производительность сайта. Крейг приводит цифры, что в среднем за 1 секунду ожидания пользователя компания в потенциале теряет 102 миллиона долларов. Интересно, да? Компания сделала анализ около 500 вебсайтов и составила топ 10 основных проблем, которые ведут к низкой производительности. Рекомендации Крейга об использовании кэшей, CDN, настройки правильного разрешения изображений, использования компрессии. А главное тестирования того, что получилось, как оказалось многие думают, что используют кэш, но порядка 70% контента при этом может не кэшироваться из-за неверных настроек. Крейг рекомендует установить бейслайн по производительности и придерживаться его, установить цель по производительности, которую нужно достичь, тестировать и оптимизировать узкие места. Средства для теста webpage test, google analytics, pagespeed, rigor free report. Самой забавным для меня были картинки на сайтах в большом расширении, при этом размер не позволяет оценить этого, так что снижение разрешения не приводит к ухудшению качества.
Мне не удалось найти слайды Крейга, но вот доклад на ту же тему одного из сотрудников компании.
Risky Business
Джеф Бьюзен (Jeff Buzen)
Пару слов о Джефе — он преподаватель в Гарварде, автор 3х книг, первая вышла в 71году, а последняя в 2015 — Rethinking Randomness: A New Foundation for Stochastic Modeling, статья на вики, Интервью с Джеффом.
Доклад о моделировании и прогнозировании производительности. Джеф описывает риски, которые возникают при моделировании системы — риск модели, риск параметров нагрузки системы, риск прогноза, риск приложения, риск возможности использования — в работе. Джефф подробно описывает все возможные риски, которые появляются при моделировании системы и попытки спрогнозировать сколько ресурсов потребуется и какая при этом доступность системы нужна. Варианты как не надо писать SLA – 90% запросов выполняются за 0.5 секунды. Менее рискованно – длинна очереди меньше 33х 90% времени. Его книга об этом. Прогнозирование, которое мы используем из классической математики не всегда дает корректные применимые результаты, хотя формулы могут быть верными. Предсказания очень сильно зависят от допущений модели. Более предпочтительно использовать прогноз основанный на анализе альтернатив (AoA, Analysis of Alternatives).
Я сидела и думала – насколько же это далеко от моего опыта – о, у нас остался запас по производительности всего в 2 раза, что? Как узнали? Ну был пик и в системе уже копились очереди, давайте возьмем сервер побольше. Что говорите? Хорошо что есть очереди? Ну так до того, как мы их стали использовать система просто падала. Вот такой подход с планированием производительности начиная с модели системы — какая-то другая планета.
How to get value out of BigData?
Ренато Бономини (Renato Bonomini), Стефано Дони (Stefano Doni), компания Moviri
Далее был workshop от компании Moviri. Мовири – компания основанная преподавателем политехнического университета Милана, с офисом в Милане и Бостоне, специализирующаяся на анализе производительности и пропускной способности. О том как важно не только собирать массу данных, но и извлекать из них пользу. Стек Yarn, HDFS, Pig, Hive, Spark, Zookeeper, Cassandra, Cloudera, Kubernetes. В докладе было показано, насколько удобнее стало работать с изменением производительности с системами, работающими в контейнерах.
Компания Moviri приглашала в гости в офис, чем я воспользовалась, так как примерно через месяц ехала в Италию. Было очень здорово встретиться со Стефано Дони и познакомиться с Лука Форни, посмотреть офис и поговорить обо всем, что касается анализа производительности, начиная с анализа производительности и заканчивая проблемами, с которыми сталкиваются консультанты при общении с командой заказчика.
Блог Мовири.
Performance or Capacity? Different approaches for different tasks
Александр Гильгур (Alex Gilgur), компания Facebook
Доклад будет полезен тем кто занимается прогнозированием производительности и планированием пропускной способности. Александр приводит примеры и подходы, которые должны использоваться для каждого из случаев. В общем и целом хотя capacity и performance понятия близкие, но для прогнозов должны быть использованы разные методы, с акцентом на конечной цели работы. Для чего мы это делаем? Мы хотим понять сколько оборудования нам нужно и какую пропускную способность мы хотим обеспечить или мы хотим спрогнозировать производительность системы.
Вот тут можно прочитать статью Александра.
Слайды.
How to get started when you don’t know where to start.
Джастин Мартин (Justin Martin), компания Cerner
О том зачем вообще нужно делать мониторинг производительности. А ведь правда! Живут многие без мониторинга и все вроде бы у них нормально. И правда, многим он не нужен. До тех пор пока они не публикуют статью про свой чудесный сайт на хабре и к ним не заходят люди посмотреть, что там. Или пока что-то другое не приводит к ним много-много пользователей.
В докладе Джастин довольно просто рассказывает, что же можно сделать для того, чтобы начать. Capacity management in 90 days
Шаги
- Определите часы пиковой нагрузки для вашей системы
- Изучите пределы производительности вашего проекта (момент когда система уже перестает обрабатывать запросы и производительность начинает деградировать)
- Уменьшите потери производительности
- Сбалансируйте потребность – возможно вы можете перенести какие-то нагрузки с часов пиковой нагрузки на менее загруженное время.
Линкедин Джастина. Слайды можно посмотреть в статье о конференции, которую я опубликую в конце.
Dynamic load Balancing and Continuous Service Delivery in a Big Cloud Infrastructure
Юрий Ардулов (Yuri Ardulov), компания RingCentral
Юрий описывает переход RingCentral от монолита, с легаси кодом на микросерсисы. Проблемы с монолитным кодом были в том, что сложно менять конфигурацию, не было возможности делать continuous delivery, трудности в достижении нужных показателей доступности, не было возможности делать A\B тестирование, возможность применить новый функционал только для части пользователей. Был проведен редизайн системы и в новом дизайне использовались контейнеры и микросервисы, появилась возможность делать ресайз системы в онлайн, возможность менять версию сервиса без изменения конфигурации. В микросервисной архитектуре были выделены слой прикладной маршрутизации, слой балансировки, слой обслуживания (не хранит состояние). После внесения изменений Ops команды смогли делать непрерывную доставку на лету, доступность системы возросла с 4 девяток до 99.998. Время, требующееся на увеличение системы и развертывания новых серверов сократилось до 4х часов.
Avoiding costs, delays and failed releases with Lifecycle Virtualization
Тод ДеКапуа (Todd DeCapua), компания CSC digital brand services
Доклад Тода посвящен тому как уменьшить проблемы при релизах и ключевая идея в том, чтобы при тестировании программы важно учитывать весь жизненный цикл программы.
4 ключевые его составляющие:
- Пользователи – виртуализация пользователей имитирующая поведение ваших реальных пользователей системы.
- Сервисы – должна быть виртуализация сервисов, чтобы вы могли проверить работу всего процесса от начала до конца.
- Сеть – эмуляции условий работы сети.
- Данные – виртуализации данных с прода, для того чтобы смоделировать вызовы приложения близкие к тому, что будет происходить в реальности.
Исходя из моего опыта, большой процент ошибок при деплое происходит как раз из-за того, что мало кто выполняет все 4 условия, и на проде всегда оказывается что-то, чего никто не ожидал увидеть, и это что-то ломает релиз. Очень важно использовать разые use-case с прода по данным и поведению пользователя.
Вот пример из презентации Тода:
Тод — Автор книги про оптимизацию производительности, перф тесты и их интерпретацию.
В книге рассказывается как важна культура тестирования производительности в организации, как ее можно привнести, если сейчас этим никто не занимается. Приведены несколько примеров из практики с описанием задача, которая стоит перед командой, вариантами ее решения, описан какой подход выбрала команда и какие последствия были в реальной системе. На мой взгляд эти истории часто еще и о том, насколько сложно предсказать поведение конечного пользователя, и как важно все таки делать небольшую фокус группу из конечного числа пользователей и смотреть насколько ваш прогноз совпал с поведением фокус группы.
Implementing Metrics-Driven DevOps: Why and How!
Андреас Грабнер (Andreas Grabner), компания Dynatrace
Доклад Андреаса Грабнера про практики DevOps в разных команиях и про то, почему важен короткий time2market. Андреас использовал очень интересную метафору про фотографии. Многие помнят пленочные фото – вы делаете фотографию, идете проявляете, печатаете и видите, что она неудачная, но у вас нет возможности переснять фото, так как вы уже не в том моменте.
Сейчас все иначе – вы делаете фото, выкладываете его в инстаграм и тут же получаете обратную связь и можете доснять что-то из того, что просят ваши подписчики. Вы еще в моменте и получаете реакцию в реальном времени.
Теперь, вернемся к программному обеспечению – как было раньше – новые функции ПО планировали, реализовывали, тестировали и делали, например, 1 релиз в год. И понимали, что функциональность, на которую потрачена куча денег и сил нужна двум пользователям из миллионов. У вас такое бывало?
Как сейчас? Agile и возможность делать релизы хоть каждый день как это делает Facebook – возможность сразу же оценить насколько эта функциональность востребована пользователями, нужно ли ее обвешивать рюшечками или лучше выкинуть сразу и не тратить силы и время.
Я очень рекомендую доклад бизнесу, который пытается объяснить своей команде зачем им Scrum и Agile! Сейчас многие махровые enterprise компании с релизами 3 раза в год пытаются стать быстрее, тоньше и звонче
Вообще доклад не об этом, а о том, как построить практики DevOps, делать релизы часто и хорошо. Да, такое бывает. Важно использовать метрики и мониторить ситуацию с приложением, нагрузкой, делать правильный деплой по процессу. Андреас performance advocate и у него довольно много полезных докладов на эту тему с необычными и запоминающимися слайдами.
Вот доклад Андреаса с немного другими слайдами.
Performance Testing in New Contexts
Эрик Проглер (Eric Proegler), компания Soasta
В начале доклада Эрик ретроспективно рассказал как менялась архитектура систем с 2000, как переход в облако изменил или должен был изменить, то как проектируют системы с учетом возможности масштабирования в облаке. Эрик приводит пример из практики, когда одна из TV компаний запустила голосование в мобильном приложении и как раз во время шоу, когда пользователи должны голосовать система не выдержала нагрузки и была недоступна. С культурой стартапов сложно предсказать сколько пользователей будет, может планировалось 20 тысяч, а приложение быстро доберет до 50 тысяч. Есть много приложений для тестирования производительности в облаке BlazeMeter (Jmeter), Selenium, Gatling, Grinder. Они бесплатны, но визуализировать результаты не очень удобно. Поэтому рекомендуется использовать либо еще средство для визуализации (Tableau) либо использовать собственную БД, чтобы потом анализировать то, что получилось. При тестировании веб приложений важно обращать внимание на то, чтобы приходящие тестовые пользователи были геораспределенными. Желательно делать небольшие перф тесты каждую сборку и сравнивать их с базовыми результатами.
Слайды по докладу Эрика можно посмотреть на slideshare.
Эрик автор блога.
Кроме представленных на конференции докладов, было также организовано несколько обсуждений в форме «Круглого стола». Несколько экспертов осуждали заданную тему в формате живого активного диалога с залом. На мой взгляд, это очень интересный формат, так как слушатели конференции могли поделиться своим часто внушительным опытом, и можно было подойти пообщаться с каждым экспертом и участником, обсудив интересующие вопросы.
Оффтоп и разговоры за кулисами
Особую часть моих впечатлений от конференции составляет неформальное общение с докладчиками и участниками. Благодаря формату проведения дискуссий, обедов, круглых столов и фуршетов, можно познакомиться с людьми со всего мира из разных компаний и обменяться опытом. Довольно много общения внутри конференции. Люди очень открыты и готовы обмениваться опытом.
Отдельно хочу упомянуть Debbie Sheetz. Дебби работала в компании BMC и начинала анализ производительности еще на мейнфреймах. Затем она перешла в распределенные системы. Ее опыт работы в мониторинге огромен и очень интересен.
Также мне посчастливилось пообщаться с Ануш Наджарян из компании MathWorks, чей опыт также заслуживает внимания.
К сожалению, количество докладов не позволяет посетить их все, и записи докладов не ведется, то есть, нет возможности их пересмотреть дома. Организаторы используют статьи для отбора докладчиков, и эти статьи потом передаются участникам конференции, но материалы приглашенных докладчиков в сборнике отсутствуют.
Вот статья Ануш о конференции.
CMG impact очень полезная и интересная конференция с потрясающей атмосферой обмена опытом, которую я рекомендую посетить.
