Возможно ли количественное определение масштабируемости в качестве требования?

Question

G'day,

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

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

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

Оба варианта были необходимы для обеспечения масштабируемости.

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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

Резервирование - это что-то другое, но также должно быть включено и рассмотрено.

Answer 6

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