Рекомендации по надежности для устойчивых рабочих нагрузок на Azure

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

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

В этой статье устойчивость рассматривается через призму компонента «Надежность» и даются ответы на следующие вопросы по проектированию:

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

Предотвращение амплификации сбоев

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

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

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

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

Намеренное проектирование устойчивости

Распространённый антипаттерн — проектировать систему на максимальную отказоустойчивость, не приводя архитектуру в соответствие с реальными бизнес-требованиями.

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

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

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

Стабилизация спроса на сокращение отходов

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

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

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

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

Фактор устойчивости в выборе платформы

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

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

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

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

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

Выполнение тестов, которые обеспечивают значимую проверку устойчивости

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

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

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