HighLoad.org – блог о высоких нагрузках
HighLoad.org > Как MySpace протестировала сайт с добавлением миллиона виртуальных пользователей

Как MySpace протестировала сайт с добавлением миллиона виртуальных пользователей
2010-03-08 23:12 my_fess 
В декабре 2009 MySpace начала предоставлять потоковое музыкальное видео в Новой Зеландии, основываясь на предыдущих успехах MySpace в музыкальном направление. Новые фичи включали в себя возможность просматривать музыкальное видео, находить видео по артисту, создавать списки любимых роликов и многое другое. Из-за добавления такой фичи на популярном сайте, таком как MySpace ,нагрузка конечно очень сильно вырастет, и они хотели протестировать новый функционал до выкладывания его в продакшн.
Если вы управляете инфраструктурой, стоящей за высоко-нагруженным приложением, то вы не хотите никаких сюрпризов. Вы хотите понять ваши слабые места, определить запас прочности и знать, что делать, когда нагрузка преодолеет этот допустимый порог. Единственный способ понять, что будет происходить во вреям максимального трафика - тестирование инфраструктуры с ожидаемым уровнем нагрузки. Для MySpace целью было протестировать дополнительно 1 миллион пользователей на их сайте параллельно использующих новые видеофишки. Ключевое слово здесь — параллельно. Не в течение часа или дня... 1 миллион пользователей параллельно проявляющих активность на сайте. Следует заметить, что 1 миллион виртуальных пользователей — это только часть от того, что MySpace обычно принимает на сайте во время пиков нагрузки. Они хотели добавить к живому трафику тестовый трафик, чтобы определить воздействие от добавления новых фич на производительность всей инфраструктуры. Это требует возможности генерировать большую нагрузку — это как раз то место, где облачные вычисления начинают рулить. Для проведения теста MySpace работала вместе с SOASTA, используя облако, как платформу для генерации нагрузки. Здесь приведены детали нагрузки, которая была сгенерирована в ходе тестирования. Все числа относятся только к тестовому трафику от виртуальных пользователей и не включают в себя измерения настоящих живых пользователей:
  • 1 миллион параллельных виртуальных пользователей
  • Несколько разделов тестирования: поиск, просматривание музыкального видео, оценивание видео, добавление видео в список любимых и просматривание страниц канала артиста.
  • Трафик — 16 гигабит в секунду
  • 6 терабайт данных передано в час
  • Более 77 000 кликов в секунду, не включая настоящих пользователей
  • 800 Amazon EC2 крупных инстансов использовалось для генерации нагрузки (3200 облачно вычислительных ядра)

Архитектура тестового окружения

SOASTA CloudTest управляет выбором провайдера облака, в данном случае Amazon, и предоставлением серверов для тестирования. Весь процесс по добычи 800 инстансев EC2 занял меньше 20 минут. Мы сделали 25 вызовов к Amazon EC2 API и запросов серверов. В данном случае команда запросила инстансы EC2 Large для генерации нагрузки и сбора результатов со следующими спецификациями:
  • 7.5 GB оперативной памяти
  • 4 вычислительных юнита EC2 (2 виртуальных CPU по 2 вычислительных юнита EC2 каждый)
  • хранилище 850 GB (2 по 420 GB и плюс 10 GB раздела root)
  • 64-битная платформа
  • Fedora Core 8
В дополнение были заказаны 2 инстанса EC2 Extra-large для создания тест-контроллера и для результирующей базы данных со следующими спецификациями:
  • 15 GB оперативной памяти
  • 8 вычислительных юнита EC2 (4 виртуальных ядра по 2 вычислительных юнита EC2 в каждом)
  • хранилище 1690 GB (4 по 420 GB и плюс 10 GB раздела root)
  • 64-битная платформа
  • Fedora Core 8
  • База данных PostgreSQL
После заказа всех серверов, которые нужны для тестирования ,мы начали проверять их, чтобы удостовериться, что они стабильно работают. Как только мы находили мертвые сервера, мы отказывались от них и запрашивали дополнительные сервера, чтобы заполнить пробелы. Предоставление инфраструктуры было на самом деле простым занятием. На рисунке показано, как тестовое облако на EC2 было настроено для создания большой нагрузки на датацентры MySpace.
Пока шел тест, некоторые из генераторов нагрузки отсылали отчеты о их производительности в один из аналитических центров. Каждый аналитический центр был подсоединен к базе данных PostgreSQL, хранящей данные о производительности в агрегирующем репозитории. Предоставление доступа к базе данных только агрегированным метрикам и плюс горизонтальное масштабирование - это часть метода масштабирования теста такой величины который генерирует и хранит так много данных.

Трудности

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

Тест был ограничен в использование 800 инстансев EC2

SOASTA - один из крупнейших потребителей ресурсов облачных вычислений, обычно используются сотни серверов от нескольких облачных провайдеров для проведения таких массивных нагрузочных тестирований. Во время тестирования команда запросила максимально возможное число инстансев EC2. Ограничения в доступном железе означало, что каждый сервер должен симулировать поведение относительно большого числа пользователей. Каждый генератор нагрузки симулировал от 1300 до 1500 пользователей. Этот уровень нагрузки почти в 3 раза больше того, который обычно производит генератор нагрузки от CloudTest, это было достижение нового уровня воздействия на продукт, которое потребовало некоторой креативной работы команды инженеров для решения проблемы. Вот некоторые из приемов, использовавшиеся для облегчения нагрузки на генератор нагрузки:
  • Планирование запросов каждого виртуального пользователя так, чтобы клики не запускались все одновременно на генераторе нагрузки
  • Сократить объем собираемых данных - включать только то, что необходимо для анализа производительности

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

CND обычно выдает контент для посетителей сайта из ближайшей для них точки основываясь на их географическом местоположение. Если вы сгенерируете весь тестовый трафик из, например, зоны обслуживания Amazon-ом восточного побережья, тогда вы скорее всего нагрузите только одну точку представительства Akamai. Под нагрузкой тест сгенерировал значительный объем переданных данных в несколько датацентров Akamai. Получилась более большая нагрузка, чем потенциально могла бы быть получена при обычных пиках нагрузки, но это не такое уж нереалистичное тестирование при условии, что это происходит только с трафиком Новой Зеландии. Результатом теста стало то, что некоторые соединения были разорваны или отклонены Akamai при определенном уровне нагрузки и было сгенерировано много ошибок при выполнение теста. Это довольно частый барьер, который необходимо преодолеть когда генерируешь нагрузку на сайты в продакшене. Сильно масштабируемые продакшн тесты должны быть спроектированы так, чтобы они просчитали эту ситуацию и нагружали всю продакшн экосистему. Это означает, что нужно генерировать нагрузку из множества географических точек так, чтобы трафик распределялся по всем датацентрам. В конечном счете понимание возможностей географических точек присутствия не было достигнуто в тесте.

Из-за воздействия дополнительной нагрузки, MySpace была вынуждена заменять некоторые из серверов на лету для поддержания работы тестируемых фич

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

Выученные уроки

  1. Для web сайтов с высоким трафиком тестирование в продакшене — единственный способ получить точную картину запаса прочности и производительности. В инфраструктуре крупных приложений множество невидимых преград, которые проявятся только при тестирование в лабораторных условиях и при дальнейшей попытке экстраполировать результаты.
  2. Гибкое масштабирование все в большей и большей степени становится важной частью архитектуры приложения. Приложения должны быть построены таким образом, чтобы критичные бизнес процессы могли быть независимо мониторены и масштабированы. Возможность добавить производительности относительно быстро становится ключевым моментом архитектуры в ближайшие годы, большие игроки поняли это уже давно. Facebook, Ebay, Intuit и многие другие крупные web имена занимаются продвижением этого принципа проектирования. Хранение вещей слабо связанными несет множество своих преимуществ ,которые провозглашались раньше, но теперь запас прочности и производительности быстрыми темпами двигаются на вершину списка.
  3. Мониторинг в реальном времени критически важен. Для того чтобы реагировать на проблемы производительности вам необходимо иметь возможность мониторинга в реальном времени. Мониторинг должен быть связан с вашими ключевыми бизнес процессами и функциональными областями и должен быть настолько риалтаймовым насколько это возможно.

Автор статьи: Dan Bartow Дата: 4 марта 2010 Оригинал статьи


комментарии [0]  | комментировать

  © 2010-2018 HIGHLOAD