Почему важно учитывать масштабируемость систем

автор Дарья Казовская

19 Июл 2016

Исторически так сложилось, что владельцы бизнеса считают излишним вдаваться в подробности разработки программных решений для своих IT-проектов. Этот процесс ассоциируется у бизнеса c многоступенчатыми объяснениями разработчиков по поводу меняющихся технологий и системных требований. Поэтому, когда речь заходит о масштабируемости систем, представители компаний предпочитают переводить диалог с разработчиками на более общий уровень, параллельно отсекая все важные технические детали.

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

Что поможет бизнесу пойти на контакт с IT-специалистами и вникнуть в особенности масштабирования систем?

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

5 ключевых вопросов о масштабировании

По нашему опыту разработчики затрагивают 5 главных вопросов, когда говорят о масштабируемости:

1. Есть ли понимание планируемых возможностей системы?

2. Какие типовые действия будут осуществлять пользователи системы?

3. Какие узкие места могут быть в системе? На какую часть системы ложится наибольшая нагрузка?

4. Что более принципиально для системы – отказоустойчивость или высокая производительность?

5. Откуда может возникнуть потребность в масштабируемости системы?

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

Есть ли понимание планируемых возможностей системы?

Что за этим стоит:

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

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

Пример:

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

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

График планируемой посещаемости сайта

Взять на вооружение:

Чётко формулируйте цели IT-проекта и составляйте план или график прогнозируемой посещаемости сайта. Желательно с указанием временных интервалов.

Разработчики задают вопрос о возможностях системы не из праздного интереса. Им необходимо заранее предусмотреть лазейки для дальнейшего роста возможностей системы. Если бизнес планирует завоевывать мир, необходимо предельно ясно обозначать свои цели. Скажем, когда на сайт с ежедневной аудиторией не более 300 пользователей придёт 10000 уникальных посетителей за раз, система не должна падать.

Какие типовые действия будут осуществлять пользователи системы?

Что за этим стоит:

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

Типовые действия пользователи системы

Пример:

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

Взять на вооружение:

Чтобы предотвратить негативное развитие событий, подробно описывайте предполагаемый сценарий действий пользователя. В том числе, продумывайте два направления:

  • Как вы хотели бы, чтобы пользователь взаимодействовал с системой
  • Как это может происходить на самом деле

Какие узкие места могут быть в системе? На какую часть системы ложится наибольшая нагрузка?

Что за этим стоит:

Любая сложная информационная система может включать в себя от одного до нескольких узких мест. Узкое место – это такая проблемная точка в системе, которая в определённый момент времени принимает на себя наибольшую нагрузку. Зная вероятные узкие места в системе, разработчик может скорректировать её работу в случае деградации сервера. Это помогает избежать потерю потенциальных пользователей системы при пиковых нагрузках.

Проблема поиска узких мест не связана с масштабируемостью системы напрямую, однако её нельзя упускать из виду. Вовремя не предусмотренное узкое место может свести на нет все усилия по масштабированию. Даже если разработчик успешно проведёт масштабирование системы, ему необходимо проанализировать её архитектуру, чтобы избежать узких мест.

Пример:

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

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

Узкие места информационных систем

Взять на вооружение:

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

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

Что более принципиально для системы – отказоустойчивость или высокая производительность?

Что за этим стоит:

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

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

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

Пример:

Представим, что операционист в банке выполняет запрос клиента на получение кредита и вносит его данные в систему. В это время сессия обрывается и система перестаёт откликаться на действия операциониста. Данные потеряны и у операциониста нет другого доступа в систему. Операционист просит клиента подождать, пока система будет восстановлена, или обратиться в банк на следующий день. Клиент потратил время и не доволен сложившейся ситуацией. По сути, в системе произошёл сбой, и от того, насколько она устойчива к подобным отказам, зависит лояльность конкретного клиента.

Отказоустойчивость систем

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

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

Взять на вооружение:

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

Откуда может возникнуть потребность в масштабируемости системы?

Что за этим стоит:

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

Пример:

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

Взять на вооружение:

Ответьте себе на вопрос, что вы понимаете под масштабируемостью системы в текущем IT-проекте. Разделите понятия:

  • У вас в базе данных 10000 пользователей и вам нужно наращивать возможности сервера для хранения информации
  • На ваш веб-сайт единовременно приходят 10000 пользователей и сервер нуждается в подкреплении своих вычислительных мощностей

Потребность в масштабируемости системы

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

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

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

  • 0 Репосты

Комментарии

Фильтр

Закрыть

Технологии

Индустрии