Масштабирование ресурсов
Одним из важных преимуществ облака является возможность масштабирования ресурсов в системе по требованию. Увеличение вертикального (подготовка ресурсов большего размера) или горизонтального (подготовка дополнительных ресурсов) масштаба помогает уменьшить нагрузку на отдельные ресурсы за счет снижения использования благодаря увеличению емкости или более широкому распределению рабочей нагрузки.
Масштабирование позволяет повысить производительность за счет увеличения пропускной способности, так как теперь можно обслуживать большее количество запросов. Это также помогает сократить задержки во время пиковых нагрузок, поскольку при пиковых нагрузках в очередь на один ресурс ставится меньше запросов. Кроме того, это помогает повысить надежность системы, снижая степень использование ресурсов, что позволяет замедлить их износ.
Важно отметить, что, хотя облако позволяет нам легко подготавливать новые или лучшие ресурсы, всегда следует учитывать их стоимость. Таким образом, несмотря на то, что увеличение горизонтального или вертикального масштаба имеет неоспоримые преимущества, важно знать, когда следует уменьшить масштаб для экономии средств. В n-уровневых приложениях также важно определить, где находятся узкие места и какой уровень следует масштабировать, будь то уровень данных или уровень сервера.
Масштабирование ресурсов облегчается с помощью балансировки нагрузки (мы обсуждали это ранее), которая помогает маскировать процесс масштабирования системы за счет скрытия ее за постоянной конечной точкой.
Стратегии масштабирования
Горизонтальное масштабирование (расширение и сужение)
Горизонтальное масштабирование — это стратегия, при которой в систему либо добавляются дополнительные ресурсы, либо удаляются излишние. Такой тип масштабирования полезен для уровня сервера, когда нагрузка является непредсказуемой и меняется непоследовательно. Природа изменяющих нагрузок предписывает эффективно подготавливать необходимый объем ресурсов для обработки нагрузки в любое время.
Соображения, которые делают эту задачу трудновыполнимой, включают время запуска экземпляра, модель ценообразования поставщика облачных служб и потенциальные потери дохода от ухудшения качества обслуживания (QoS) из-за отсутствия масштабирования во времени. В качестве примера рассмотрим следующий шаблон нагрузки.
Рис. 6. Пример шаблона загрузки запроса
Давайте представим, что мы используем Amazon Web Services. И также представим, что каждая единица времени эквивалентна 3 часам фактического времени, и нам требуется, чтобы один сервер обслуживал 5000 запросов. Если посмотреть на нагрузку в единицах времени от 16 до 22, то в ней возникает огромное колебание. Мы можем обнаружить падение спроса около единицы времени 16 и начать уменьшать количество выделенных ресурсов. Так как мы за 3 часа переходим от приблизительно 50 000 почти к 0 запросов, формально мы можем сэкономить 10 экземпляров, которые были бы в момент времени 16.
Теперь давайте представим, что каждая единица времени равна 20 минутам реального времени. В этом случае сокращение всех ресурсов в единице времени 16 только для того, чтобы через 20 минут добавить новые ресурсы, фактически приведет к увеличению затрат, а не к экономии, так как AWS выставляет счета за каждый вычислительный экземпляр на почасовой основе.
В дополнение к приведенным выше двум соображениям поставщику услуг также потребуется оценить убытки, которые он понесет, снизив качество обслуживания в единицу времени 20, если у него имеется емкость только для 90 000 запросов, а не для 100 000.
Масштабирование зависит от характеристик трафика и его соответствующей нагрузки, создаваемой в веб-службе. Если трафик соответствует прогнозируемому шаблону (например, основан на поведении человека, таком как вечерний просмотр фильмов в потоковой веб-службе), масштабирование можно спрогнозировать для поддержания качества обслуживания. Однако во многих случаях трафик нельзя предсказать, и системы масштабирования должны действовать по ситуации в зависимости от различных критериев, как показано в приведенных выше примерах.
Вертикальное масштабирование (вверх и вниз)
Существуют определенные типы нагрузок для поставщиков услуг, которые более предсказуемы, чем другие. Например, если вы знаете из исторических шаблонов, что число запросов всегда находится в диапазоне10 000–15 000, вы достаточно спокойно можете использовать один сервер, который может обслуживать 20 000 запросов — этого будет достаточно хорошим решением для целей поставщика услуг. Эти нагрузки могут увеличиваться в будущем, но, поскольку они будут увеличиваться согласованно, служба можно будет переместить в более крупный экземпляр, который может обслуживать больше запросов. Это подходит для небольших приложений с небольшим объемом трафика.
Сложность вертикального масштабирования заключается в том, что на смену всегда требуется время, что приводит к простою. Это связано с тем, что для перемещения всех операций с экземпляра меньшего размера в более крупный экземпляр требуется время, даже если это всего несколько минут, в этот интервал качество обслуживания все равно будет снижено.
Кроме того, большинство поставщиков облачных служб предлагают увеличение мощности вычислений путем удвоения мощности вычислительного ресурса. Поэтому степень детализации не такая хорошая, как при горизонтальном масштабировании. Таким образом, даже если нагрузка предсказуема и стабильно увеличивается по мере роста популярности службы, многие поставщики услуг выбирают горизонтальное, а не вертикальное масштабирование.
Рекомендации по масштабированию
Наблюдение
Мониторинг является одним из наиболее важных элементов для эффективного масштабирования ресурсов, так как он позволяет иметь метрики, которые можно использовать для интерпретации того, какие части системы необходимо масштабировать и когда нужно это сделать. Мониторинг позволяет проводить анализ шаблонов трафика или использования ресурсов, чтобы получить обоснованную оценку, когда и сколько ресурсов нужно масштабировать, чтобы максимально повысить QoS наряду с прибылью.
Отслеживается несколько аспектов ресурсов для активации их масштабирования. Наиболее распространенной метрикой является использование ресурсов. Например, служба мониторинга может отслеживать использование ЦП каждым узлом ресурсов и масштабировать ресурсы, если использование слишком высокое или низкое. Если, например, использование каждого ресурса превышает 95 %, то, вероятно, лучше добавить дополнительные ресурсы, так как система сильно загружена. Поставщики услуг обычно выбирают точки срабатывания путем анализа точки останова узлов ресурсов, определяя, когда в них начнут происходить сбои, и сопоставляя их поведение с различными уровнями нагрузки. Но из соображений экономии важно максимально использовать каждый ресурс, поэтому рекомендуется оставить операционной системе пространство для некоторых издержек. Аналогично, если использование значительно ниже, скажем, 50 %, возможно, требуются не все узлы ресурсов и некоторые из них можно отключить.
На практике поставщики услуг обычно отслеживают сочетание нескольких метрик узла ресурса, чтобы оценить, когда следует масштабировать ресурсы. Некоторые из них включают использование ЦП, использование памяти, пропускную способность и задержку. Azure предоставляет Azure Monitor в качестве дополнительной службы, которая может отслеживать любой ресурс Azure и предоставлять такие метрики.
Без отслеживания состояния
Служба без отслеживания состояния предоставляется масштабируемой архитектуре. Служба без отслеживания состояния, по сути, означает, что клиентский запрос содержит все сведения, необходимые для обслуживания запроса сервером. Сервер не хранит сведения о клиенте в экземпляре и сохраняет сведения о сеансе в экземпляре сервера.
Служба без отслеживания состояния помогает переключать ресурсы по требованию, без настройки для поддержания контекста (состояния) клиентского подключения для последующих запросов. Для масштабирования ресурсов службы с отслеживанием состояния требуется стратегия по перемещению контекста из существующей конфигурации узла в новую конфигурацию. Обратите внимание, что существуют методы для реализации служб с отслеживанием состояния, например, поддержание сетевого кэша с помощью Memcached, чтобы контекст можно было совместно использовать на серверах.
Что масштабировать?
В зависимости от характера службы необходимо масштабировать различные ресурсы в соответствии с ее требованиями. На уровне сервера при увеличении рабочих нагрузок в зависимости от типа приложения это может привести к усилению состязания за ресурсы ЦП, памяти, пропускной способности сети или всего сразу. Мониторинг трафика позволяет определить, какой ресурс сталкивается с ограничениями, и соответствующим образом масштабировать этот конкретный ресурс. Поставщики облачных служб не всегда обеспечивают гибкость для масштабирования только вычислительных ресурсов или только памяти. Но они предоставляют различные типы вычислительных экземпляров, которые специально ориентированы на нагрузки с большим потреблением вычислительной мощности или памяти. Например, для приложения с большой нагрузкой на память было бы более целесообразно масштабировать ресурсы до экземпляров, оптимизированных для памяти. Для приложений, которым необходимо обслуживать большое количество запросов, не связанных с интенсивным потреблением вычислительных ресурсов или памяти, масштабирование в виде нескольких стандартных экземпляров может оказаться лучшей стратегией.
Увеличение аппаратных ресурсов не всегда является лучшим решением для повышения производительности службы. Увеличение эффективности алгоритмов, используемых в службе, может также снизить уровень состязания за ресурсы и оптимизировать использование, устраняя необходимость масштабирования физических ресурсов.
Масштабирование на уровне данных
В приложениях, ориентированных на данные, при большом числе операций чтения и записи (или и того, и другого) в базе данных или системе хранения время кругового пути для каждого запроса часто ограничивается временем выполнения операций ввода-вывода жесткого диска при чтении и записи. Более крупные экземпляры позволяют повысить производительность операций ввода-вывода при чтении и записи, что может улучшить время поиска на жестком диске, что, в свою очередь, может привести к значительному снижению задержки службы. Наличие нескольких экземпляров данных на уровне данных может повысить надежность и доступность приложения, предоставляя избыточность при отработке отказа. Репликация данных между несколькими экземплярами имеет дополнительные преимущества в снижении задержки в сети, если клиент обслуживается центром обработки данных, физически расположенном ближе к нему. Сегментирование, или секционирование, данных по нескольким ресурсам — это еще одна стратегия горизонтального масштабирования данных, где вместо простой репликации данных между несколькими экземплярами данные разбиваются на несколько сегментов и хранятся на нескольких серверах данных.
Дополнительная сложность, связанная с масштабированием на уровне данных, заключается в поддержании согласованности (операция чтения для всех реплик одинакова), доступности (чтение и запись всегда успешны) и устойчивости к разделению (гарантированные свойства в системе поддерживаются, когда сбои препятствуют обмену данными между узлами). Это часто называется теоремой CAP, которая гласит, что в распределенной базе данных очень сложно полностью реализовать все три свойства, поэтому в большинстве случаев в системе обеспечивается сочетание только двух из этих свойств. Вы узнаете больше о стратегиях масштабирования баз данных и теореме CAP в последующих модулях.