Масштабирование вычислительных ресурсов
Одним из важных преимуществ облака является возможность масштабирования ресурсов в системе по требованию. Увеличение вертикального (подготовка ресурсов большего размера) или горизонтального (подготовка дополнительных ресурсов) масштаба помогает уменьшить нагрузку на систему за счет снижения использования благодаря увеличению емкости или более широкому распределению рабочей нагрузки.
Масштабирование позволяет повысить скорость реагирования (и производительность с точки зрения пользователя), увеличивая пропускную способность, так как теперь можно обслуживать большее количество запросов. Это также помогает сократить задержки во время пиковых нагрузок, поскольку при пиковых нагрузках в очередь на один ресурс ставится меньше запросов. Кроме того, масштабирование может повысить надежность системы, так как сокращает использование ресурсов и предотвращает приближение к критической точке.
Важно отметить, что, хотя облако позволяет нам легко подготавливать новые или лучшие ресурсы, всегда следует учитывать их стоимость. Таким образом, несмотря на то, что увеличение горизонтального или вертикального масштаба имеет неоспоримые преимущества, важно знать, когда следует уменьшить масштаб для экономии затрат.
Горизонтальное масштабирование
Горизонтальное масштабирование — это стратегия, при которой дополнительные ресурсы добавляются в систему или излишние ресурсы удаляются из системы с течением времени. Такой тип масштабирования полезен для уровня сервера, когда нагрузка меняется непоследовательно или непредсказуемо. Природа изменяющих нагрузок предписывает подготавливать необходимый объем ресурсов для обработки нагрузки в любое время.
Задачу усложняет несколько факторов:
- время запуска экземпляра (например, виртуальной машины);
- модель ценообразования поставщика облачных служб;
- потенциальная потеря дохода от снижения качества обслуживания (QoS) из-за отсутствия своевременного масштабирования.
Рис. 5. Пример шаблона загрузки.
В качестве примера рассмотрим шаблон нагрузки на рисунке 5.
Предположим, мы используем Amazon Web Services, каждая единица времени эквивалентна 1 часу фактического времени, и нам требуется, чтобы один сервер обслуживал 5000 запросов. Спрос достигает пика между единицами времени 6 и 8 и единицами времени 14 и 16. Давайте рассмотрим последний промежуток в качестве примера. Мы можем определить падение спроса в единицу времени 16 и начать уменьшать количество выделенных ресурсов. Так как спрос падает примерно с 90 000 запросов до 10 000 запросов за 3 часа, мы можем сэкономить затраты на десятки или более дополнительных экземпляров, которые можно было бы использовать в единицу времени 15.
На рисунке 6 показан шаблон масштабирования, который изменяет число экземпляров динамически в соответствии с шаблоном нагрузки, при этом количество экземпляров отображается красным цветом. Во время пикового спроса количество экземпляров увеличивается до 20 и 18 соответственно, чтобы предоставить ресурсы, необходимые для обработки трафика. В других случаях число экземпляров уменьшается (свертывается), чтобы поддерживать использование ресурсов на относительно постоянном уровне. Если предположить, что каждый экземпляр стоит 20 центов в час, стоимость хранения 20 экземпляров в течение 24 часов составит 96 долларов. Масштабирование количества экземпляров в этом примере сокращает стоимость до 42 долларов, то есть за год можно сэкономить более 15 000 долларов. Это существенная сумма почти для любого ИТ-бюджета.
Рис. 6. Масштабирование с помощью запросов.
Масштабирование зависит от характеристик трафика и его соответствующей нагрузки, создаваемой в веб-службе. Если трафик соответствует прогнозируемому шаблону (например, основан на поведении человека, таком как вечерний просмотр фильмов в потоковой веб-службе), масштабирование можно спрогнозировать для поддержания качества обслуживания. Однако во многих случаях трафик нельзя предсказать и системы масштабирования должны действовать по ситуации в зависимости от различных критериев.
Следует отметить, что горизонтальное масштабирование можно выполнять с помощью экземпляров контейнеров, а также экземпляров виртуальных машин. Рабочие нагрузки традиционно выполняются в облаке на виртуальных машинах, но все чаще запускаются в контейнерах. Масштабирование достигается с помощью рабочих нагрузок на основе виртуальных машин, когда число виртуальных машин увеличивается или уменьшается. Аналогичным образом можно масштабировать рабочие нагрузки на основе контейнеров, изменяя количество контейнеров. Так как контейнеры обычно запускаются быстрее, чем виртуальные машины, эластичность немного выше, поскольку новые экземпляры контейнеров можно активировать за меньшее время, чем экземпляры виртуальных машин.
Вертикальное масштабирование
Горизонтальное масштабирование — один из способов достижения эластичности, но это не единственный способ. Предположим, что трафик на ваш веб-сайт редко превышает 15 000 запросов на единицу времени, и вы предоставляете один большой экземпляр, который может обрабатывать 20 000 — этого достаточно для обработки обычного трафика, а также для учета небольших пиковых нагрузок. Если нагрузка на веб-сайт растет, вы сможете подстроиться под увеличение трафика, заменив экземпляр сервера на вариант, у которого вдвое больше ядер ЦП и объем ОЗУ. Это называется увеличением вертикального масштаба.
Основная сложность вертикального масштабирования заключается в том, что обычно на смену требуется время, что приводит к простою. Это связано с тем, что для перемещения всех операций с экземпляра меньшего размера в более крупный экземпляр требуется время, даже если это всего несколько минут, но в этот интервал качество обслуживания снижается.
Еще одно ограничение вертикального масштабирования — недостаточная степень детализации. Если у вас 10 экземпляров сервера и необходимо временно увеличить емкость на 10 %, можно увеличить горизонтальный масштаб с 10 до 11 экземпляров и достичь желаемого результата. Однако при вертикальном масштабировании размер следующего крупного экземпляра обычно в два раза больше предыдущего, что будет эквивалентно горизонтальному масштабированию с 10 до 20 экземпляров — для увеличения трафика всего на 10 %. Это менее экономично, чем горизонтальное масштабирование.
Наконец, при выборе вертикального масштабирования следует учитывать доступность. Если у вас есть один большой экземпляр, обслуживающий всех клиентов веб-сайта, и этот экземпляр выходит из строя, веб-узел также выйдет из строя. Но если вы подготавливаете 10 небольших экземпляров для той же нагрузки и один из них выйдет из строя, пользователи могут заметить небольшое снижение производительности, но они по-прежнему смогут получить доступ к сайту. Следовательно, даже если нагрузка предсказуема и стабильно увеличивается по мере роста популярности службы, многие администраторы облака выбирают горизонтальное, а не вертикальное масштабирование.
Масштабирование на уровне сервера
Масштабируемость иногда не ограничивается просто подготовкой дополнительных ресурсов (горизонтальное масштабирование) или больших ресурсов (вертикальное масштаба). На уровне сервера увеличение спроса может повысить конкуренцию для конкретных типов ресурсов, таких как ЦП, память и пропускная способность сети. Поставщики облачных служб обычно предлагают виртуальные машины, оптимизированные для рабочих нагрузок с большим объемом вычислений, рабочих нагрузок с интенсивным использованием памяти и рабочих нагрузок с большой нагрузкой на сеть. Знать особенности рабочей нагрузки и выбирать правильный тип виртуальной машины так же важно, как подключать больше виртуальных машин или виртуальные машины большего размера. Лучше использовать пять виртуальных машин, обрабатывающих рабочие нагрузки с большим объемом вычислений, чем 10, даже если виртуальные машины, оптимизированные для рабочих нагрузок с интенсивным использованием ЦП, стоят на 20 % больше, чем универсальные виртуальные машины.
Увеличение аппаратных ресурсов не всегда является лучшим решением для повышения производительности службы. Увеличение эффективности алгоритмов, используемых службой, может также снизить уровень состязания за ресурсы и оптимизировать использование, устраняя необходимость масштабирования физических ресурсов.
Когда речь идет о масштабировании, важно учитывать отслеживание состояния (или отсутствие отслеживания). Служба без отслеживания состояния предоставляется масштабируемой архитектуре. Служба без отслеживания состояния, по сути, означает, что клиентский запрос содержит все сведения, необходимые для обслуживания запроса сервером. Сервер не хранит сведения о клиенте в экземпляре и сохраняет сведения о сеансе в экземпляре сервера.
Служба без отслеживания состояния помогает переключать ресурсы по требованию, без настройки для поддержания контекста (состояния) клиентского подключения для последующих запросов. Если это служба с отслеживанием состояния, для масштабирования ресурсов требуется стратегия по перемещению контекста из существующей конфигурации в новую. Обратите внимание, что существуют методы для реализации служб с отслеживанием состояния, например для поддержки сетевого кэша, чтобы контекст можно было совместно использовать на серверах.
Масштабирование на уровне данных
В приложениях, ориентированных на данные, при большом числе операций чтения и записи (или и того, и другого) в базе данных или системе хранения время кругового пути для каждого запроса часто ограничивается временем чтения и записи на жестком диске. Более крупные экземпляры позволяют повысить производительность операций ввода-вывода, что может улучшить время поиска на жестком диске и уменьшить задержку службы. Хотя несколько экземпляров данных на уровне данных могут повысить надежность и доступность приложения, обеспечивая избыточность при отработке отказа, репликация данных между несколькими экземплярами имеет дополнительные преимущества при снижении задержки в сети, если клиент обслуживается центром обработки данных, физически расположенном ближе к нему. Сегментирование, или секционирование, данных по нескольким ресурсам — это еще одна стратегия горизонтального масштабирования данных, где вместо простой репликации данных между несколькими экземплярами данные разбиваются на сегменты и хранятся на нескольких серверах данных.
Дополнительная сложность, связанная с масштабированием на уровне данных, заключается в поддержании согласованности (операция чтения для всех реплик одинакова), доступности (чтение и запись всегда успешны) и устойчивости к разделению (гарантированные свойства в системе поддерживаются, когда сбои препятствуют обмену данными между узлами). Это часто называется теоремой CAP, которая гласит, что в распределенной базе данных очень сложно полностью реализовать все три свойства, поэтому в большинстве случаев обеспечивается сочетание только двух свойств1.
Ссылки
- Википедия. Теорема CAP. https://en.wikipedia.org/wiki/CAP_theorem.