Проектирование приложений критически важных рабочих нагрузок в Azure
При разработке приложения критически важны требования к функциональным и нефункциональным приложениям. В этой области проектирования описываются шаблоны архитектуры и стратегии масштабирования, которые помогают обеспечить устойчивость приложения к сбоям.
Внимание
Эта статья является частью серии критически важных рабочих нагрузок Azure Well-Architected Framework. Если вы не знакомы с этой серией, рекомендуется начать работу с критически важной рабочей нагрузкой?
Архитектура единиц масштабирования
Все функциональные аспекты решения должны быть способны масштабироваться в соответствии с изменениями спроса, в идеале автомасштабирование в ответ на загрузку. Рекомендуется использовать архитектуру единиц масштабирования для оптимизации сквозной масштабируемости с помощью секционализации, а также для стандартизации процесса добавления и удаления емкости. Единица масштабирования — это логическая единица или функция, которую можно масштабировать независимо. Единица может быть состоит из компонентов кода, платформ размещения приложений, меток развертывания, охватывающих связанные компоненты, и даже подписок для поддержки требований к мультитенантным клиентам.
Мы рекомендуем этот подход, так как он отвечает ограничениям масштаба отдельных ресурсов и всего приложения. Это помогает в сложных сценариях развертывания и обновления, так как единица масштабирования может быть развернута как одна единица. Кроме того, можно протестировать и проверить определенные версии компонентов в модуле, прежде чем направлять в него трафик пользователей.
Предположим, что ваше критически важное приложение — это онлайн-каталог продуктов. Он имеет поток пользователя для обработки комментариев и оценок продукта. Поток использует API для получения и публикации комментариев и оценок, а также вспомогательных компонентов, таких как конечная точка OAuth, хранилище данных и очереди сообщений. Конечные точки API без отслеживания состояния представляют детализированные функциональные единицы, которые должны адаптироваться к изменениям по требованию. Базовая платформа приложений также должна иметь возможность масштабироваться соответствующим образом. Чтобы избежать узких мест производительности, подчиненные компоненты и зависимости также должны масштабироваться до соответствующей степени. Они могут масштабироваться независимо, как отдельные единицы масштабирования или вместе в рамках одной логической единицы.
Примеры единиц масштабирования
На следующем рисунке показаны возможные области для единиц масштабирования. Области варьируются от модулей pod микрослужб до узлов кластера и меток регионального развертывания.
Рекомендации по проектированию
Область. Область единицы масштабирования, связь между единицами масштабирования и их компонентами должна быть определена в соответствии с моделью емкости. Учитывайте нефункциональный требования к производительности.
Ограничения масштабирования. Ограничения и квоты масштаба подписки Azure могут иметь отношение к проектированию приложений, выбору технологий и определению единиц масштабирования. Единицы масштабирования помогают обойти ограничения масштабирования службы. Например, если кластер AKS в одном модуле может иметь только 1000 узлов, можно использовать два единицы для увеличения этого ограничения до 2000 узлов.
Ожидаемая загрузка. Используйте количество запросов для каждого потока пользователя, ожидаемой пиковой частоты запросов (запросов в секунду) и шаблонов ежедневного и еженедельного или сезонного трафика для информирования основных требований к масштабированию. Кроме того, следует учитывать ожидаемые шаблоны роста как для трафика, так и для объема данных.
Приемлемое снижение производительности. Определите, допускается ли пониженная служба с высоким временем отклика при загрузке. При моделировании требуемой емкости необходимой производительности решения под нагрузкой является критически важным фактором.
Нефункциональное требование. Технические и бизнес-сценарии имеют различные аспекты устойчивости, доступности, задержки, емкости и наблюдаемости. Анализ этих требований в контексте сквозных потоков пользователей. У вас будет относительная гибкость в проектировании, принятии решений и выборе технологий на уровне пользовательского потока.
Рекомендации по проектированию
Определите область единицы масштабирования и ограничения, которые будут запускать единицу для масштабирования.
Убедитесь, что все компоненты приложения могут масштабироваться независимо или как часть единицы масштабирования, которая включает другие связанные компоненты.
Определите связь между единицами масштабирования на основе модели емкости и нефункциональными требованиями.
Определите метку регионального развертывания, чтобы объединить подготовку, управление и операцию ресурсов регионального приложения в разнородном, но взаимозависимом масштабируемом модуле. По мере увеличения нагрузки можно развертывать дополнительные метки в одном регионе Azure или в разных регионах Azure, чтобы горизонтально масштабировать решение.
Используйте подписку Azure в качестве единицы масштабирования, чтобы ограничения масштабирования в одной подписке не ограничивают масштабируемость. Этот подход применяется к сценариям с высокомасштабируемыми приложениями, имеющими значительный объем трафика.
Модель требуемой емкости вокруг определенных шаблонов трафика, чтобы убедиться, что достаточная емкость подготовлена в пиковые периоды, чтобы предотвратить снижение уровня обслуживания. Кроме того, оптимизируйте емкость в нерабочие часы.
Измеряйте время, необходимое для горизонтального масштабирования и масштабирования операций, чтобы гарантировать, что естественные вариации трафика не создают неприемлемый уровень ухудшения обслуживания. Отслеживание длительности операций масштабирования в виде операционной метрики.
Примечание.
При развертывании в целевой зоне Azure убедитесь, что подписка целевой зоны выделена приложению для предоставления четкой границы управления и предотвращения антипаттерна Noisy Сосед.
Глобальное распределение
Невозможно избежать сбоя в любой высоко распределенной среде. В этом разделе приведены стратегии устранения многих сценариев сбоя. Приложение должно иметь возможность противостоять региональным и зональным сбоям. Его необходимо развернуть в активной или активной модели, чтобы нагрузка распределялась по всем регионам.
Просмотрите это видео, чтобы получить общие сведения о планировании сбоев в критически важных приложениях и максимальной устойчивости:
Рекомендации по проектированию
Избыточность. Приложение должно быть развернуто в нескольких регионах. Кроме того, в регионе настоятельно рекомендуется использовать зоны доступности, чтобы обеспечить отказоустойчивость на уровне центра обработки данных. Зоны доступности имеют периметр задержки менее 2 миллисекунда между зонами доступности. Для рабочих нагрузок, которые являются "чатными" между зонами, эта задержка может привести к штрафу производительности для передачи данных между зонами.
Активная и активная модель. Рекомендуется использовать стратегию активного и активного развертывания, так как она обеспечивает максимальную доступность и обеспечивает более высокое соглашение об уровне обслуживания (SLA). Однако это может привести к проблемам синхронизации данных и согласованности для многих сценариев приложений. Решение проблем на уровне платформы данных при рассмотрении компромиссов с повышенными затратами и инженерными усилиями.
Активное или активное развертывание в нескольких облачных поставщиках — это способ потенциально снизить зависимость от глобальных ресурсов в одном поставщике облачных служб. Однако стратегия многооблачного активного и активного развертывания представляет значительную сложность вокруг CI/CD. Кроме того, учитывая различия в спецификациях ресурсов и возможностях между поставщиками облачных служб, вам потребуется специализированные метки развертывания для каждого облака.
Географическое распределение. Рабочая нагрузка может иметь требования к соответствию географическому расположению данных, защите данных и хранению данных. Рассмотрите, есть ли определенные регионы, в которых должны находиться данные или где должны быть развернуты ресурсы.
Источник запроса. Географическое расположение и плотность пользователей или зависимых систем должно информировать о принятии решений о глобальном распределении.
Возможность подключения. Доступ к рабочей нагрузке пользователями или внешними системами влияет на вашу структуру. Рассмотрите возможность доступности приложения через общедоступный Интернет или частные сети, использующие каналы VPN или Azure ExpressRoute.
Рекомендации по проектированию и выбор конфигурации на уровне платформы см. в разделе "Платформа приложений: глобальное распределение".
Архитектура на основе событий с слабой связью
Подключение обеспечивает взаимодействие между службами через хорошо определенные интерфейсы. Свободное соединение позволяет компоненту приложения работать независимо. Стиль архитектуры микрослужб соответствует критически важным требованиям. Это упрощает высокий уровень доступности, предотвращая каскадные сбои.
Для свободного связывания настоятельно рекомендуется включить дизайн на основе событий. Асинхронная обработка сообщений через посредника может создать устойчивость.
В некоторых сценариях приложения могут объединять свободное и жесткое связывание в зависимости от бизнес-целей.
Рекомендации по проектированию
Зависимости среды выполнения. Свободно связанные службы не должны быть ограничены для использования одной вычислительной платформы, языка программирования, среды выполнения или операционной системы.
Масштабирование. Службы должны быть в состоянии масштабироваться независимо. Оптимизируйте использование ресурсов инфраструктуры и платформы.
Отказоустойчивость. Ошибки должны обрабатываться отдельно и не должны влиять на клиентские транзакции.
Целостность транзакций. Рассмотрим эффект создания и сохраняемости данных, происходящих в отдельных службах.
Распределенная трассировка. Для сквозной трассировки может потребоваться сложная оркестрация.
Рекомендации по проектированию
Выравнивание границ микрослужбы с критически важными потоками пользователей.
Используйте асинхронное взаимодействие на основе событий, где это возможно для поддержки устойчивого масштабирования и оптимальной производительности.
Используйте такие шаблоны, как исходящий и транзакционный сеанс, чтобы гарантировать согласованность, чтобы каждое сообщение было обработано правильно.
Пример: подход на основе событий
Эталонная реализация "Критически важный в Сети" использует микрослужбы для обработки одной бизнес-транзакции. Она применяет операции записи асинхронно с брокером сообщений и рабочей ролью. Операции чтения синхронны, с результатом, возвращенным вызывающей функции напрямую.
Шаблоны устойчивости и обработка ошибок в коде приложения
Критически важное приложение должно быть разработано для обеспечения устойчивости, чтобы оно направлено на максимальное количество сценариев сбоя. Эта устойчивость обеспечивает максимальную доступность и надежность служб. Приложение должно иметь возможности самостоятельного восстановления, которые можно реализовать с помощью шаблонов конструктора, таких как повторные попытки с обратным отключением и выключением цепи.
Для не временных сбоев, которые невозможно полностью устранить в логике приложения, модель работоспособности и операционные оболочки должны предпринять корректирующие действия. Код приложения должен включать надлежащее инструментирование и ведение журнала для информирования модели работоспособности и упрощения последующего устранения неполадок или анализа первопричин по мере необходимости. Необходимо реализовать распределенную трассировку для предоставления вызывающей стороны комплексного сообщения об ошибке, включающего идентификатор корреляции при возникновении сбоя.
Такие средства, как Application Insights , помогают запрашивать, сопоставлять и визуализировать трассировки приложений.
Рекомендации по проектированию
Правильные конфигурации. Это не редкость для временных проблем, чтобы вызвать каскадные сбои. Например, повторные попытки без соответствующего резервного копирования усугубят проблему при регулировании службы. Вы можете выполнять задержки повторных попыток линейно или увеличивать их экспоненциально, чтобы отступить через растущие задержки.
Конечные точки работоспособности. Функциональные проверки в коде приложения можно предоставлять с помощью конечных точек работоспособности, которые внешние решения могут опрашивать для получения состояния работоспособности компонента приложения.
Рекомендации по проектированию
Ниже приведены некоторые распространенные шаблоны проектирования программного обеспечения для устойчивых приложений:
| Расписание | Итоги |
|---|---|
| Выравнивание нагрузки на основе очередей | Представляет буфер между потребителями и запрошенными ресурсами, чтобы обеспечить согласованные уровни нагрузки. По мере того как запросы потребителей помещаются в очередь, рабочий процесс обрабатывает их в соответствии с запрошенным ресурсом в темпе, заданном рабочей ролью и возможностью запрашиваемого ресурса обрабатывать запросы. Если потребители ожидают ответов на их запросы, необходимо реализовать отдельный механизм реагирования. Примените приоритетный порядок, чтобы наиболее важные действия выполнялись сначала. |
| Автоматическое выключение | Обеспечивает стабильность, ожидая восстановления или быстро отклоняя запросы, а не блокируя при ожидании недоступной удаленной службы или ресурса. Этот шаблон также обрабатывает ошибки, которые могут занять переменное время для восстановления после подключения к удаленной службе или ресурсу. |
| Распределительный блок | Пытается секционировать экземпляры служб на группы на основе требований к нагрузке и доступности, изолируя сбои для поддержания функциональности службы. |
| Сага | Управляет согласованностью данных между микрослужбами, имеющими независимые хранилища данных, обеспечивая обновление служб с помощью определенных каналов событий или сообщений. Каждая служба выполняет локальные транзакции для обновления собственного состояния и публикует событие для активации следующей локальной транзакции в сага. Если обновление службы завершается сбоем, сага выполняет компенсирующие транзакции для противодействия предыдущим шагам обновления службы. Отдельные действия по обновлению службы могут реализовать шаблоны устойчивости, такие как повторная попытка. |
| Мониторинг конечных точек работоспособности | Реализует функциональные проверки в приложении, к которому внешние средства могут обращаться через предоставляемые конечные точки через регулярные интервалы. Вы можете интерпретировать ответы от конечных точек с помощью ключевых операционных метрик для информирования о работоспособности приложения и активации операционных ответов, таких как повышение оповещения или выполнение компенсирующего развертывания отката. |
| Повторить | Обрабатывает временные сбои элегантно и прозрачно. — Отмена, если ошибка вряд ли будет временной и вряд ли будет выполнена успешно, если операция предпринята повторно. — Повторите попытку, если ошибка является необычной или редкой, и операция, скорее всего, будет выполнена успешно при попытке немедленно. — повторите попытку после задержки, если ошибка вызвана условием, которое может потребовать короткого времени для восстановления, таких как сетевое подключение или сбои высокой нагрузки. Примените подходящую стратегию обратного отключения, так как увеличение задержек повторных попыток. |
| Регулирование | Управляет потреблением ресурсов, используемых компонентами приложений, что защищает их от чрезмерного использования. Когда ресурс достигает порогового значения нагрузки, он откладывает операции с более низким приоритетом и ухудшает неуклюжную функциональность, чтобы основные функции могли продолжаться до тех пор, пока не будут доступны достаточные ресурсы для возврата к нормальной работе. |
Ниже приведены некоторые дополнительные рекомендации.
Используйте предоставленные поставщиком пакеты 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 обычно предоставляют дополнительные возможности и часто обновляются.
Следующий шаг
Ознакомьтесь с рекомендациями по платформе приложений.