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

Доброго времени суток,

Я читал пункт Quantify в книге "97 вещей, которые должен знать каждый архитектор программного обеспечения". Знай" (ссылка на Амазон санирована), и она получила мне интересно, как количественно оценить масштабируемость.

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

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

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

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

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

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


scalability requirements quantify
person Rob Wells    schedule 06.07.2009    source источник

Ответы (6)


arrow_upward
2
arrow_downward

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

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

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

person frankodwyer    schedule 06.07.2009

arrow_upward
3
arrow_downward

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

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

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

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

person RSolberg    schedule 06.07.2009
comment
Ах, это должно быть требование на будущее! (-: - person Rob Wells; 06.07.2009
comment
@Rob - по крайней мере, это было идентифицировано ... Мой любимый - это когда что-то делается, а потом кто-то приходит и говорит, но это не работает .... - person RSolberg; 06.07.2009

arrow_upward
1
arrow_downward

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

person Alex Martelli    schedule 06.07.2009

arrow_upward
1
arrow_downward

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

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

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

person meade    schedule 07.07.2009

arrow_upward
1
arrow_downward

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

person jldupont    schedule 13.10.2009

arrow_upward
0
arrow_downward

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

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

Из http://www.information-management.com/issues/19971101/972-1.html

person mcandre    schedule 06.07.2009
comment
-1: Ссылка на внешнюю страницу, которая недоступна. - person Matthieu Rouget; 28.07.2014