вторник, 23 декабря 2014 г. - www.msmirnov.ru

Нагрузочное тестирование с использованием Amazon Web Services

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

На тот момент у нас уже были автоматизированные сценарии тестирования, которые имитировали поведение обычных пользователей при работе с системой. Сценарии были разработаны с использованием Coded UI Tests и Selenium.

Эти сценарии использовались в рамках текущего автоматизированного регрессионного контроля.

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

В рамках такого тестирования мы решали задачи поиска деградации производительности системы, поиска узких мест и роста потребления системных ресурсов (утечки памяти, место на дисках, CPU и т.п.)

В качестве платформы размещения тестовых сценариев была выбрана облачная платформа Amazon Web Services (AWS) в следующем виде - мы создали эталонную виртуальную машину в Amazon Elastic Cloud 2 (EC2), на которую установили скрипты автоматизированного тестирования.

Затем, мы разработали отдельное центральное приложение, которое через AWS API дублировало эталонную машину в Amazon EC2 столько раз, сколько нам требовалось (например, создавало 100 одинаковых машин), затем проводило окончательную настройку тестовых сценариев и запускало эти сценарии на выполнение.

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

По завершении тестового периода центральное приложение уничтожало все тестовые виртуальные машины (кроме эталонной) и генерировало отчет о результатах тестирования, который содержал сводную информацию по всем машинам и по каждой машине отдельно.
Мой сайт - www.msmirnov.ru

четверг, 12 июня 2014 г. - www.msmirnov.ru

ЛАФ-2014

Только что закончился первый день ежегодного (на этот раз уже пятого) Летнего Аналитического Фестиваля-2014 (ЛАФ-2014), где уже в который раз собираются коллеги и друзья, находящиеся на переднем крае российской аналитической мысли.

Являясь постоянным участником фестиваля, я замечаю, как поднялся уровень и изменился характер докладов со времени ЛАФ-2010. Если раньше доклады носили в основном обзорный характер и касались описания процессов управления требованиями в конкретных компаниях, то сейчас авторы, накопив обширный опыт, больше концентрируются на конкретных проблемах и практиках в управлении требованиями, а также пытаются систематизировать текущее состоянии системного и бизнес-анализа в мире вообще и России в частности.

Ну и конечно, как всегда, радует дружеская непринужденная обстановка, веселые конкурсы, постоянно возникающие профессиональные споры и дискусии.

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

ЛАФ - это сообщество друзей. Пусть он будет всегда. Я его люблю и постараюсь не пропускать.

Был впервые в живую пообщаться с Юлей Ериной, повидать Аню Абрамову, послушать как всегда харизматичных Дмитрия Безуглова и Сергея Мартыненко, серьезного и обстоятельного Александра Белина, а также и всех остальных.

И напоследок несколько фотографий:











Мой сайт - www.msmirnov.ru

вторник, 27 мая 2014 г. - www.msmirnov.ru

Архитектура небольшой социальной сети

Некоторое время назад перед моей командой стояла задача построения средней социальной сети музыкантов и их фанатов, рассчитанной на 25 миллионов пользователей.

Инструментарий, выбранный для реализации проекта я описывал в статье TeamCity и другие. В этой статье я бы хотел поделиться архитектурой, которая была создана для реализации этой локальной сети.

На следующей диаграмме отображена выбранная нами архитектура:


 


Архитектура была основана на принципах архитектур высоконагруженных приложений. Она изначально предусматривала балансировку и распределение нагрузки и не имела единой точки отказа.

Архитектура включала в себя несколько слоев – слой пользовательского интерфейса UI, слой бизнес-логики и слой хранения данных.

 

Слои UI и бизнес-логики не хранили в себе никаких состояний (stateless) и могли иметь любое количество независимых инстансов, балансирующих нагрузку.

Слои UI был реализован как Single Page Application (SPA), основанное на технологиях Bootstrap, Angular и jQuery, способное работать на любом виде устройств.

Слой бизнес-логики был реализован в виде ASP.NET Web API-приложения, обменивающегося с UI сообщениями в формате JSON.

 

MySQL хранил информацию о пользователях, денежных транзакциях и т.п., разбитую вертикально (vertical sharding) на несколько инстансов.

Memcached кешировал часто запрашиваемую из MySQL информацию – данные о пользователях, контент сайта и т.п.. Кеш автоматически распределялся между несколькими инстансами Memcached.

MongoDB была выбрана в качестве NoSQL-хранилища взаимосвязей между пользователями и различными объектами – подписки, ленты событий, комментарии, альбомы фотографий и пр.

 

Task processor – сервис для выполнения фоновых задач – отправка писем, СМС. обслуживание баз и пр.

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

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

 

Система не использовала никакие собственные хранилища для размещения информации, которая могла потребовать много дискового пространства и не хранила никакую небезопасную информацию (номера карточек и т.п.)

YouTube использовался в качестве хранилища видео-данных и средства проведения review.

Облачное хранилище Amazon Web Services (AWS) использовалось для хранения фотографий и музыкального контента.

Google, Facebook, Twitter и Instagram использовались для авторизации в социальной сети.

Мой сайт - www.msmirnov.ru

понедельник, 3 февраля 2014 г. - www.msmirnov.ru

TeamCity и другие

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

Прежде всего, мы вернули управление задачами в JIRA, отказавшись от тяжеловесного Rational Team Concert и TFS (хотя про TFS плохо говорить не хочу).

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

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

Кроме того, одновременно с юнит-тестами проводится статистический анализ кода при помощи утилиты FxCop 10, запуск которой мы также настроили в TeamCity. Отчет о найденных недочетах в коде можно увидеть непосредственно в TeamCity.

После удачной сборки и тестирования проекта производится его автоматическое развертывание в тестовое окружение - на тестовый сервер. Выполняется это также средствами TeamCity.

Для развертывания тестовой базы данных мы в TeamCity настроили запуск EMS DB Comparer, который сравнивает схемы девелоперской и тестовой баз, создает change script и выполняет его на тестовой базе. При этом он ведет историю сгенерированных скриптов, которую мы в будущем может анализировать или как-то использовать. К сожалению, в данном проекте мы не смогли использовать утилиту VSDBCMD для развертывания database-проектов, создаваемых в Visual Studio, так как данный проект использует базы данных MySQL.

В качестве средства обмена документами мы начали использовать Google Docs вместо опять же достаточно тяжелого SharePoint. Совместно используемую проектную область через Google Drive можно замапить себе на локальный диск, что очень удобно.

Для разработки тест-кейсов и формирования отчетов о тестировании мы начали использовать TestRail QA. Он нам представляется более удобным, чем TestLink, который мы использовали раньше.

Последнее, на чем хочу остановиться - это Source Control - он остался в TFS и это единственная функция, которая за ним остается на данный момент.


Таким образом, обобщая все, что я сказал выше, получаем следующий список инструментов:
  • Source Control - TFS
  • Управление проектом - JIRA (вместо TFS)
  • Сборка проекта и выполнение юнит-тестов - TeamCity (вместо TFS)
  • Статистический анализ кода - FxCop
  • Синхронизация баз данных - EMS DB Comparer
  • Обмен документами - Google Docs (вместо SharePoint)
  • Тест-кейсы - TestRail QA
В завершение хочу сказать спасибо Леше Раге за бесценные консультации в подборке инструментов.
Мой сайт - www.msmirnov.ru