Можно ли количественно оценить масштабируемость как требование?

Question

Добрый день,

Я читал статью Количественная оценка в книге «97 вещей, которые должен знать каждый архитектор программного обеспечения» (очищенная ссылка на Amazon), и это заставило меня задуматься о том, как количественно оценить масштабируемость.

Я разработал две системы для крупной британской телерадиокорпорации, которые используются для:

1. определить страну происхождения входящих HTTP-запросов или
2. определить подходящие форматы видео для геометрии экрана мобильного телефона и текущего типа подключения.

Обе конструкции должны были обеспечивать масштабируемость.

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

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

Итак, можно ли количественно оценить масштабируемость?Будет ли это примерное количество дополнительных серверов, которые вы могли бы добавить для горизонтального масштабирования решения?

Answer 1

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

Вы также можете часто указывать числа внутри домена приложения — скажем, система поддерживает комментирование, вы можете количественно определить порядок количества комментариев, которые она должна иметь возможность хранить.

Однако стоит помнить, что не все, что имеет значение, можно измерить, и не все, что можно измерить, имеет значение.:-)

Answer 2

Я думаю, что это сводится к тому, что означает масштабируемость в данном контексте, и поэтому ответ будет таким: это зависит.

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

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

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

Answer 3

Надлежащей мерой масштабируемости (не самой простой;-) является набор кривых, определяющих требуемые ресурсы (ЦП, память, хранилище, локальная пропускная способность и т. д.) и производительность (например,задержка) доставляется по мере роста нагрузки (например.с точки зрения количества запросов в секунду, но для некоторых приложений могут также подходить и другие показатели, такие как общая требуемая пропускная способность данных).Лица, принимающие решения, обычно требуют, чтобы такие точные, но сложные измерения сводились к нескольким ключевым цифрам (конкретным точкам на некоторых из нескольких кривых), но я всегда стараюсь вести переговоры о более точных, а не о более простых для понимания измерениях таких показателей. Ключевые метрики!-)

Answer 4

Когда я думаю о масштабируемости, я имею в виду:

• производительность — насколько отзывчивым должно быть приложение для данной нагрузки.
• насколько велика нагрузка, которую может вырасти приложение, и какая стоимость единицы (если в расчет каждого сервера входит программное обеспечение, поддержка и т. д.)
• как быстро вы можете масштабировать приложение и какой объем буфера вы хотите использовать в период пиковой нагрузки (мы можем добавить на 50% больше пропускной способности за 2–3 часа и потребовать 30% буфера сверх запланированного пикового использования)

Избыточность – это нечто другое, но ее также следует учитывать и учитывать.

Answer 5

«Система должна масштабироваться таким образом, чтобы поддерживать линейную зависимость X для стоимости/пользователя».

Answer 6

Вот один из способов:

«Предположим, что один процессор может обрабатывать 100 единиц работы в секунду...»

От http://www.information-management.com/issues/19971101/972-1.html