Контролируйте потребление ресурсов, используемых экземпляром приложения, отдельным клиентом или всей службой. Благодаря контролю потребления ресурсов система продолжает работать и выполняет соглашение об уровне обслуживания, даже если растущие потребности приводят к чрезмерной нагрузке на ресурсы.
Контекст и проблема
Нагрузка на облачное приложение обычно зависит от количества активных пользователей или типов выполняемых действий. Например, скорее всего, больше активных пользователей будет в рабочее время. Или в конце каждого месяца система будет выполнять аналитику, требующую большого количества вычислительных ресурсов. Могут также возникать неожиданные и непредвиденные всплески активности. Если потребности системы в обработке превышают емкость доступных ресурсов, производительность системы будет очень низкой, и она даже может перестать работать. Если система должна соответствовать установленному уровню обслуживания, такой сбой может быть неприемлемым.
Существует множество стратегий для обработки разной нагрузки в облаке в зависимости от бизнес-целей приложения. Одна из стратегий — использовать автомасштабирование для сопоставления подготовленных ресурсов с потребностями пользователя в любое время. Это создает потенциал для постоянного удовлетворения потребностей пользователей и одновременной оптимизации эксплуатационных расходов. Однако при автоматическом масштабировании может активироваться подготовка дополнительных ресурсов, эта подготовка не является немедленной. Если потребности в ресурсах растут быстро, может возникнуть период дефицита ресурсов.
Решение
Альтернативная стратегия автоматического масштабирования заключается в том, чтобы позволить приложениям использовать определенное ограниченное количество ресурсов, а затем регулировать приложения по достижении этого ограничения. Система должна отслеживать использование ресурсов, чтобы при превышении порогового значения она могла регулировать запросы от одного или нескольких пользователей. Это позволяет системе продолжать функционировать и соответствовать любым соглашениям об уровне обслуживания ( соглашения об уровне обслуживания), которые находятся на месте. Дополнительные сведения о мониторинге использования ресурсов см. в руководстве по инструментированию и телеметрии.
В системе могут быть реализованы несколько стратегий регулирования, в том числе:
Отклонение запросов от отдельного пользователя, который уже получал доступ к API системы более n раз в секунду в течение определенного периода. Для этого система должна измерять использование ресурсов для каждого клиента или пользователя, использующих приложение. Дополнительные сведения см. в руководстве по контролю потребления служб.
Отключение или снижение функциональных возможностей выбранных неосновных служб, что позволяет предоставить достаточное количество ресурсов для беспрепятственной работы основных служб. Например, если приложение выполняет потоковую передачу видео, для него можно включить более низкое разрешение.
Выравнивание нагрузки для распределения объема операций. Этот подход подробно описан в статье о шаблоне балансировки нагрузки на основе очередей. В мультитенантной среде этот подход снижает производительность для каждого клиента. Если система должна поддерживать разные клиенты с разными соглашениями об уровне обслуживания, запросы более важных клиентов могут обрабатываться немедленно. Запросы других клиентов могут задерживаться и обрабатываться после выполнения более срочных запросов. Шаблон очереди приоритетов можно использовать для реализации этого подхода, так как может предоставлять различные конечные точки для различных уровней или приоритетов служб.
Отсрочка операций для приложений или клиентов с более низким приоритетом. Эти операции могут быть приостановлены или ограничены. При этом создается исключение,которое сообщает клиенту, что система занята и операцию следует повторить позже.
При интеграции с некоторыми сторонними службами, которые могут стать недоступными или возвращать ошибки, следует тщательно выполнять интеграцию с некоторыми сторонними службами. Уменьшите количество одновременных запросов, обрабатываемых таким образом, чтобы журналы не заполнялись ошибками. Кроме того, вы избегаете затрат, связанных с необязательной повторным попыткой обработки запросов, которые завершаются сбоем из-за этой 3-сторонней службы. Затем, когда запросы обрабатываются успешно, вернитесь к обычной неуправляемой обработке запросов. Одна из библиотек, реализующих эту функцию, — NServiceBus.
На этой диаграмме с областями показано использование ресурсов (сочетание памяти, ЦП, пропускной способности и других факторов) по времени для приложений, которые используют три функции. Функция — это область функциональных возможностей, например компонент, который выполняет определенный набор задач, блок кода, выполняющий сложные вычисления, либо элемент, который реализует какую-то службу, например кэш в памяти. Эти функции обозначены буквами A, B и C.
Область под линией функции показывает ресурсы, которые используются приложениями при вызове этой функции. Например, область под линией функции А отображает ресурсы, потребляемые приложениями, которые используют функцию А. Область между линиями функций A и B обозначает ресурсы, используемые приложениями, которые вызывают функцию B. Объединив области всех функций, можно определить совокупное использование ресурсов системы.
На рисунке выше показаны результаты задержки операций. Непосредственно перед точкой времени T1 общее число ресурсов, выделенных для всех приложений, использующих эти функции, достигает порогового значения (ограничения на использование ресурсов). На этом этапе существует риск, что приложения исчерпают доступные ресурсы. В этой системе функция B менее важна, чем функции A и C, поэтому она временно отключается и используемые ею ресурсы освобождаются. Между точками времени T1 и T2 приложения, использующие функции A и C, продолжают работать в обычном режиме. Со временем использование ресурсов этими двумя функциями снизится до такой степени, что в момент времени T2 высвободится достаточно ресурсов, чтобы снова включить функцию B.
Автоматическое масштабирование и регулирование можно также совмещать, чтобы обеспечить ответ приложений на запросы и выполнение соглашений об уровне обслуживания. Если ожидается, что спрос останется высоким, регулирование предоставляет временное решение во время масштабирования системы. На этом этапе можно восстановить все функциональные возможности системы.
На следующей диаграмме с областями показано общее использование ресурсов всеми приложениями, работающими в системе, по времени. Также здесь показано, как регулирование можно объединить с автоматическим масштабированием.
В момент времени T1 достигнуто пороговое значение, соответствующее мягкому ограничению на использование ресурсов. На этом этапе система может начать масштабироваться. Однако если новые ресурсы не становятся доступными достаточно быстро, существующие ресурсы могут быть исчерпаны и система может завершиться ошибкой. Чтобы предотвратить такое развитие событий, система временно регулируется, как описано выше. Когда автомасштабирование завершено и доступны дополнительные ресурсы, регулирование может быть расслаблено.
Проблемы и рекомендации
При выборе схемы реализации этого шаблона следует учитывать следующие моменты.
Регулирование приложения и стратегия его реализации является архитектурным решением, которое влияет на всю структуру системы. Регулирование следует запланировать на раннем этапе разработки приложения, так как его непросто добавить после реализации системы.
Регулирование должно выполняться быстро. Система должна уметь обнаруживать рост активности и реагировать соответствующим образом. Система также должна уметь быстро восстанавливаться до исходного состояния после уменьшения нагрузки. Для этого необходимо постоянно собирать и отслеживать соответствующие данные производительности.
Если службе нужно временно запретить запрос пользователя, он должен вернуть определенный код ошибки, например 429 ("Слишком много запросов") и 503 ("Сервер слишком занят"), чтобы клиентское приложение понимало, что причина отказа в обслуживании запроса вызвана регулированием.
- HTTP 429 указывает, что вызывающее приложение отправило слишком много запросов в период времени и превысило предопределенное ограничение.
- HTTP 503 указывает, что служба не готова к обработке запроса. Распространенная причина заключается в том, что служба испытывает более временные пики нагрузки, чем ожидалось.
Клиентское приложение может подождать какое-то время перед повторным выполнением запроса. Retry-After Необходимо включить заголовок HTTP для поддержки клиента при выборе стратегии повторных попыток.
Регулирование может использоваться в качестве временной меры, пока система автоматически масштабируется. В некоторых случаях лучше просто сократить, а не масштабировать, если всплеск активности внезапный и, как ожидается, не будет долго работать, так как масштабирование может значительно добавить к выполняемым затратам.
Если регулирование используется в качестве временной меры во время автомасштабирования системы, и если требования к ресурсам очень быстро растут, система может не работать, даже если она работает в режиме регулирования. Если это недопустимая ситуация, попробуйте поддерживать больше резервных ресурсов и настроить интенсивное автоматическое масштабирование.
Нормализуйте затраты на ресурсы для различных операций, так как обычно они не несут равных затрат на выполнение. Например, ограничения регулирования могут быть ниже для операций чтения и выше для операций записи. Не учитывая стоимость операции, может привести к исчерпанию емкости и раскрытию потенциального вектора атаки.
Динамическое изменение конфигурации поведения регулирования во время выполнения желательно. Если система сталкивается с ненормальной нагрузкой, которую примененная конфигурация не может обрабатывать, ограничения регулирования могут потребоваться увеличить или уменьшить, чтобы стабилизировать систему и следить за текущим трафиком. Дорогостоящие, рискованные и медленные развертывания на этом этапе не желательны. Использование конфигурации регулирования внешнего хранилища конфигураций является внешней и может быть изменено и применено без развертываний.
Когда следует использовать этот шаблон
Используйте этот шаблон в следующих случаях:
чтобы гарантировать постоянное соответствие системы соглашению об уровне обслуживания;
чтобы предотвратить монополизацию ресурсов приложения одним клиентом;
чтобы справляться со всплесками активности;
чтобы оптимизировать затраты на систему, ограничивая максимальные уровни ресурсов, необходимые для поддержания работы системы.
Проектирование рабочей нагрузки
Архитектор должен оценить, как шаблон регулирования можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:
| Принцип | Как этот шаблон поддерживает цели основных компонентов |
|---|---|
| Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и обеспечить восстановление до полнофункционального состояния после сбоя. | Вы разрабатываете ограничения, помогающие предотвратить исчерпание ресурсов, которые могут привести к сбоям. Этот шаблон также можно использовать в качестве механизма управления в корректном плане снижения. - RE:07 Самосохранение |
| Решения по проектированию безопасности помогают обеспечить конфиденциальность, целостность и доступность данных и систем рабочей нагрузки. | Вы можете разработать ограничения, чтобы предотвратить исчерпание ресурсов, которые могут привести к автоматическому злоупотреблению системой. - Сетевые элементы управления SE:06 - РЕСУРСЫ SE:08 Для защиты |
| Оптимизация затрат ориентирована на поддержание и улучшение рентабельности инвестиций рабочей нагрузки. | Примененные ограничения могут информировать моделирование затрат и даже быть напрямую привязаны к бизнес-модели вашего приложения. Они также помещают четкие верхние границы на использование, которые можно учитывать в размерах ресурсов. - Модель затрат CO:02 - Затраты на масштабирование CO:12 |
| Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных, кода. | Если система находится под высоким спросом, эта схема помогает снизить перегрузку, которая может привести к узким местам производительности. Вы также можете использовать его для упреждающего предотвращения шумных сценариев соседей. - Планирование емкости PE:02 - Pe:05 Масштабирование и секционирование |
Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.
Пример
На последнем рисунке показано, как регулирование может быть реализовано в мультитенантной системе. Пользователи в каждой клиентской организации получают доступ к размещенному в облаке приложению, в котором они заполняют и отправляют опросы. Инструментирование в приложении контролирует скорость, с которой пользователи отправляют запросы к приложению.
Чтобы пользователи из одного клиента не влияли на скорость реагирования и доступность приложения для других пользователей, ограничивается число запросов в секунду, которые могут отправить пользователи из одного клиента. Приложение блокирует запросы, которые превышают это ограничение.
Следующие шаги
При реализации этого шаблона также может быть важно следующее руководство.
- Руководство по инструментированию и телеметрии. Регулирование зависит от сбора сведений об интенсивности использования службы. Руководство объясняет, как создавать и записывать пользовательские данные мониторинга.
- Руководство по контролю потребления служб. Описывает, как измерять использование служб, чтобы получить представление о том, как они используются. С помощью этих сведений можно определить способ регулирования службы.
- Руководство по автоматическому масштабированию. Регулирование может использоваться в качестве временной меры, пока система автоматически масштабируется. Или его можно использовать, чтобы система вообще не выполняла автоматическое масштабирование. Статья содержит сведения о стратегиях автоматического масштабирования.
Связанные ресурсы
При реализации этого шаблона могут быть также важны следующие шаблоны:
- Шаблон балансировки нагрузки на основе очередей. Балансировка нагрузки на основе очередей часто используется для реализации регулирования. Очередь может служить буфером, который помогает балансировать скорость доставки в службу запросов, отправляемых приложением.
- Шаблон очереди с приоритетом. Система может использовать очереди с приоритетом в рамках стратегии регулирования, чтобы поддерживать производительность критически важных или ценных приложений, снижая производительность менее важных приложений.
- Шаблон внешнего хранилища конфигураций. Централизованная и внешняя политика регулирования предоставляет возможность изменять конфигурацию во время выполнения без необходимости повторного развертывания. Службы могут подписаться на изменения конфигурации, тем самым применяя новую конфигурацию немедленно для стабилизации системы.