Шаблон дросселирования

Контролируйте потребление ресурсов, используемых экземпляром приложения, отдельным клиентом или всей службой. Это может позволить системе продолжать функционировать и соответствовать целям уровня обслуживания (SLOS), даже если увеличение спроса приводит к крайней нагрузке на ресурсы.

Контекст и проблема

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

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

Решение

Альтернативная стратегия автоматического масштабирования заключается в том, чтобы позволить приложениям использовать определенное ограниченное количество ресурсов, а затем регулировать приложения по достижении этого ограничения. Система должна отслеживать использование ресурсов, чтобы при превышении порогового значения она могла регулировать запросы от одного или нескольких пользователей. Это позволяет системе продолжать работу и соответствовать любым целям уровня обслуживания (SLO), которые установлены. Дополнительные сведения о мониторинге использования ресурсов см. в руководстве по инструментированию и телеметрии.

В системе могут быть реализованы несколько стратегий регулирования, в том числе:

• Отклонение запросов от отдельного пользователя, который уже получал доступ к 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 для поддержки клиента при выборе стратегии повторных попыток.

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

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

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

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

Когда следует использовать этот шаблон

Используйте этот шаблон в следующих случаях:

• Чтобы система продолжала соответствовать целям уровня обслуживания (SLOS).

• чтобы предотвратить монополизацию ресурсов приложения одним клиентом;

• чтобы справляться со всплесками активности;

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

• Сокращение низкоприоритетных вычислительных процессов в периоды высокой углеродоемкости в энергетической сети.

Проектирование рабочей нагрузки

Архитектор должен оценить, как шаблон регулирования можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в столпах Azure Well-Architected Framework. Например:

Как и любое решение по проектированию, рассмотрите любые компромиссы в отношении целей других основ, которые могут быть представлены в этом шаблоне.

Пример

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

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

Следующие шаги

При реализации этого шаблона следует принять во внимание следующие рекомендации:

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

Связанные ресурсы

При реализации этого шаблона могут быть также важны следующие шаблоны:

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