Выбрать страницу

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

 

Autoscaling

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

 

Сценарий простоя Azure Autoscale

Рисунок 1

 

Порог автомасштаба Azure

Рисунок 1.2

 

Рисунок 2

 

Вычислительные решения в Azure

  • Служба приложений. Azure App Service — это полностью управляемая служба веб-хостинга для создания веб-приложений, мобильных задних концов и API RESTful. От небольших веб-сайтов до веб-приложений глобального масштаба Azure имеет варианты ценообразования и производительности, которые соответствуют вашим потребностям.
  • Облачные службы Azure. Облачные службы Azure являются примером платформы как службы (PaaS). Как и Служба приложений Azure, эта технология предназначена для поддержки приложений, которые масштабируемы, надежны и недороги в эксплуатации. Вы можете установить собственное программное обеспечение на VMs, которые используют облачные службы Azure, и вы можете получить к ним удаленный доступ.
  • Azure Service Fabric. Azure Service Fabric — это распределенная системная платформа, которая упрощает упаковку, развертывание и управление масштабируемыми и надежными микрослужбами и контейнерами. Service Fabric представляет собой платформу нового поколения для создания и управления этими приложениями корпоративного класса, уровня-1 и облачных приложений, работающих в контейнерах.
  • Функции Azure. Функции Azure позволяют разработчикам действовать, подключаясь к источникам данных или решениям для обмена сообщениями, что позволяет легко обрабатывать события и реагировать на них. Разработчики могут использовать функции Azure для создания конечных точек API на основе HTTP, доступных широкому кругу приложений, мобильных и IoT-устройств.
  • Виртуальные машины. Виртуальная машина Azure позволит нам создавать и использовать виртуальные машины в облаке как инфраструктуру как сервис. Мы можем использовать изображение, предоставленное Azure, или партнером, или мы можем использовать наши собственные для создания виртуальной машины.

 

Виды автоскальза

 

Вертикальный автоскальза

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

вертикальное масштабирование

Рисунок 3

 

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

Рисунок 3.1 – Приложение становится недоступным при вертикальном масштабировании, так как для перезапуска требуется время.

 

Горизонтальный автоскальзай

Горизонтальное масштабирование означает, что мы изменяем количество работающих ВМ и сохраняем желаемую производительность, разделяя нагрузку между несколькими экземплярами одного и того же VM. Размер виртуальной машины остается прежним. Мы только увеличить их количество путем масштабирования, или мы уменьшаем количество работающих VMs в один момент путем масштабирования дюйма Используя этот подход, мы можем начать с небольшого размера VM и сохранить потребление ресурсов как можно более оптимальным. Кроме того, нет простоя для нашего приложения, так как всегда будет по крайней мере один экземпляр приложения работает. Горизонтальное масштабирование требует балансера нагрузки для равномерного распределения нагрузки между запускаемыми VM. Но, к счастью для нас, Azure делает это из коробки с нулевым действием, необходимым с нашей стороны.

 

горизонтальное масштабирование

Рисунок 5. Масштабируется, когда трафик увеличивается.

 

горизонтальное масштабирование трафика уменьшается

Рисунок 5.1 – Масштабируется при уменьшении трафика.

 

Мониторинг и оповещения

Существует множество способов контроля, если дополнительные ресурсы добавляются в Azure в службу, некоторые из которых довольно сложны, например, лезвие масштабирования службы (Virtual Machine Scale Sets in this case, Рисунок 6). Этот метод предпочитают администраторы, но не владельцы и вкладчики. Чтобы пользователи могли просматривать, мы должны войти в систему на портал Azure, что может быть довольно трудоемким для пользователей.

Наборы виртуальной шкалы машин

Рисунок 6

 

Оповещения

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

 

Предупреждения Azure Autoscale

Рисунок 7

 

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

 

Информация о приложениях

Рисунок 8. Приложение Исследования, показывающие среднее время отклика сервера с запросами службы приложений получает.

 

Это способ настройки автоматического скалки в службе приложений. Во-первых, перейдите на Scale-out > Configure > Add Scale условие Выберите > соответствующую метрику, как процессор, оперативная память, запросы и т.д. > Сохранить, и это сделано.

 

Настройка автомасштаба

Рисунок 9. Настройка условий автоматического масштабирования в плане обслуживания приложений

 

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

Примечание: Автономные VMs нуждаются в дополнительной конфигурации. Тем не менее, наборы виртуальной шкалы машин не требуют административных действий при автоскальзайме. Загрузочных балансаторов создается автоматически.

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

История автоматического запуска

 

На рисунке 10 есть VMSS (Virtual Machine Scale Sets), который масштабировать автоматически, когда условия, которые вы упоминаете, оказываются правдой.

 

Наборы виртуальной машинной шкалы с балансатором нагрузки

Рисунок 10. Виртуальная машина Шкала наборы с нагрузкой балансер.

 

 

Тестирование Автомасштаб Azure

Тестирование является неотъемлемой частью веб-приложения. Без тестирования мы не можем знать наверняка, сможет ли веб-сервер справиться с трафиком, для этого мы проводим тесты. Стресс-тестирование, нагрузочное тестирование — вот несколько примеров тестирования. Чтобы его можно было обрабатывать исключительно в Azure, зарегистрируйтесь в организации DevOps на портале Azure, создайте проект, а затем вы будете перенаправлены на следующую страницу:

 

Панель мониторинга Azure DevOps

Рисунок 11. Панель мониторинга DevOps для тестирования

 

План тестирования Azure DevOps

Рисунок 12. Можно добавлять URL-адреса для целей тестирования и смотреть на метрики службы, которая используется для тестирования.

 

Средний процент процессора по экземпляру

Рисунок 13. График процессора тестового приложения, который находится на VM.

 

Пример результатов GET API

Рисунок 14. Примеры результатов для GET API с такими сведениями, как время отклика, пользовательская нагрузка, запросы в секунду и т. д.

 

Использование LoadView для проверки правильного работы Автомасштаба Azure

Как мы уже знаем, когда количество процессора, оперативной памяти и IO достигнута, происходит автоматическое скалка. Здесь, на рисунке 15, этот график включен в отчет, предоставленный LoadView при запуске теста на определенный URL или конечную точку. Первый график имеет постоянное количество пользователей, посещающих сайт в соответствии с нашей стратегией тестирования нагрузки и поэтому после на точку, среднее время отклика значительно увеличивается.

LoadView Среднее время отклика без автомасштаба

Рисунок 15. Среднее время отклика без автомасштаба

 

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

 

LoadView Среднее время отклика с автомасштабом

Рисунок 16. Среднее время отклика с автомасштабом

 

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

Совокупные сеансы LoadView

Рисунок 17. Количество кумулятивных сессий

 

Тестирование Azure Autoscale: Заключение

При реализации Microsoft Azure Autoscale вам не придется беспокоиться о том, как реализовать балансеры нагрузки, менеджеров трафика и т.д. Azure управляет всем и гарантирует, что для обработки нагрузки на тестирование приложений работает нужное количество ресурсов. Однако использование решения, подобного LoadView, гарантирует, что Autoscale работает правильно и что пользователи не испытывают ухудшения производительности при добавлении ресурсов.

Попробуйте LoadView сами и получите до 5 бесплатных нагрузочных тестов для начала.