Проектирование приложений критически важных рабочих нагрузок в Azure

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

Важно!

Эта статья является частью серии критически важных рабочих нагрузок Azure Well-Architected Framework . Если вы не знакомы с этой серией, рекомендуется начать с что такое критически важная рабочая нагрузка?.

Архитектура единиц масштабирования

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

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

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

Примеры единиц масштабирования

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

Рекомендации по проектированию

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

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

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

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

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

Рекомендации по проектированию

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

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

• Определите связь между единицами масштабирования на основе модели емкости и нефункционирующих требований.

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

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

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

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

Примечание

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

Глобальное распределение

Невозможно избежать сбоя в любой высокораспределённой среде. В этом разделе приведены стратегии устранения многих сценариев сбоя. Приложение должно выдерживать региональные и зональные сбои. Он должен быть развернут в модели "активный—активный", чтобы нагрузка распределялась между всеми регионами.

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

Рекомендации по проектированию

• Избыточность. Приложение должно быть развернуто в нескольких регионах. Кроме того, в пределах региона настоятельно рекомендуется использовать зоны доступности , чтобы обеспечить отказоустойчивость на уровне центра обработки данных. Зоны доступности имеют периметр задержки менее 2 миллисекундами между зонами доступности. Для рабочих нагрузок, которые являются "болтливыми" между зонами, эта задержка может привести к снижения производительности и повлечь за собой плату за пропускную способность для передачи данных между зонами.

• Модель "активный—активный". Рекомендуется использовать стратегию активного и активного развертывания, так как она обеспечивает максимальную доступность и обеспечивает более высокое соглашение об уровне обслуживания (SLA). Однако это может привести к проблемам синхронизации и согласованности данных во многих сценариях приложений. Решение проблем на уровне платформы данных, учитывая компромиссы, связанные с увеличением затрат и инженерными усилиями.

  Активное и активное развертывание в нескольких поставщиках облачных служб — это способ снизить зависимость от глобальных ресурсов в рамках одного поставщика облачных служб. Однако стратегия многооблачного активного развертывания значительно усложняет процесс ci/CD. Кроме того, учитывая различия в спецификациях ресурсов и возможностях поставщиков облачных служб, вам потребуются специализированные метки развертывания для каждого облака.

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

• Источник запроса. Географическая близость и плотность пользователей или зависимых систем должны информировать проектные решения о глобальном распределении.

• Возможность подключения. То, как пользователи или внешние системы получают доступ к рабочей нагрузке, повлияет на вашу структуру. Определите, доступно ли приложение через общедоступный Интернет или частные сети, использующие каналы VPN или Azure ExpressRoute.

Рекомендации по проектированию и выбор конфигурации на уровне платформы см. в разделе Платформа приложений: глобальное распространение.

Слабосвязанная архитектура на основе событий

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

Для слабой взаимозависимости настоятельно рекомендуется включить разработку на основе событий. Асинхронная обработка сообщений через посредника может повысить устойчивость.

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

Рекомендации по проектированию

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

• Масштабирование. Службы должны иметь возможность масштабироваться независимо. Оптимизируйте использование инфраструктуры и ресурсов платформы.

• Отказоустойчивость. Сбои должны обрабатываться отдельно и не должны влиять на клиентские транзакции.

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

• Распределенная трассировка. Для комплексной трассировки может потребоваться сложная оркестрация.

Рекомендации по проектированию

• Выравнивайте границы микрослужб с критически важными потоками пользователей.

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

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

Пример. Подход на основе событий

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

Шаблоны устойчивости и обработка ошибок в коде приложения

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

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

Такие средства, как Application Insights , помогают выполнять запросы, сопоставлять и визуализировать трассировки приложений.

Рекомендации по проектированию

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

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

Рекомендации по проектированию

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

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

Ниже приведены некоторые дополнительные рекомендации.

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

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

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

• Реализуйте шаблоны устойчивости, используя проверенные стандартизированные пакеты, такие как Polly для C# или Sentinel для Java.

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

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

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

Выбор языка программирования

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

Рекомендации по проектированию

• Возможности пакета средств разработки. Существуют различия в возможностях, предоставляемых пакетами SDK для служб Azure на разных языках. Эти различия могут повлиять на выбор службы Или языка программирования Azure. Например, если Azure Cosmos DB является возможным вариантом, go может быть не подходящим языком разработки, так как в нем нет пакета SDK для сторонних разработчиков.

• Обновления компонентов. Подумайте, как часто пакет SDK обновляется с новыми функциями для выбранного языка. Часто используемые пакеты SDK, такие как библиотеки .NET и Java, обновляются часто. Другие пакеты SDK или пакеты SDK для других языков могут обновляться реже.

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

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

Рекомендации по проектированию

• Оцените все соответствующие пакеты SDK Azure для необходимых возможностей и выбранных языков программирования. Проверьте соответствие нефункциональным требованиям.

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

• Приоритизация пакета SDK для .NET для оптимизации надежности и производительности. Пакеты SDK для .NET Azure обычно предоставляют больше возможностей и часто обновляются.

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

Ознакомьтесь с рекомендациями для платформы приложений.

Платформа приложений