Платформа данных для критически важных рабочих нагрузок в Azure

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

В этой архитектуре есть два хранилища данных:

• База данных

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

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

• Брокер сообщений

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

Для других соображений по данным см. Руководство по хорошо спроектированной архитектуре: Соображения по платформе данных.

База данных

Эта архитектура использует Azure Cosmos DB для NoSQL. Этот параметр выбран, так как он предоставляет наиболее необходимые функции в этой структуре:

• Мульти-региональная запись

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

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

  Дополнительные сведения о записях в нескольких регионах см. в статье "Настройка операций записи в нескольких регионах" в приложениях, использующих Azure Cosmos DB.

• Управление конфликтами

  Благодаря возможности выполнять запись в нескольких регионах возникает необходимость внедрения модели разрешения конфликтов, так как одновременные записи могут привести к конфликтам данных. Last Writer Wins — это модель по умолчанию и используется для проектирования критически важных задач. Последний записывающий, как определено связанными метками времени записей, выигрывает конфликт. Azure Cosmos DB для NoSQL также позволяет определить пользовательское свойство.

• Оптимизация запросов

  Общая рекомендация по эффективности запросов для контейнеров с большим количеством секций заключается в добавлении фильтра равенства с указанным идентификатором itemID. Подробный обзор рекомендаций по оптимизации запросов можно найти в статье "Устранение неполадок с запросами при использовании Azure Cosmos DB".

• Функция резервного копирования

  Рекомендуется использовать встроенную функцию резервного копирования Azure Cosmos DB для защиты данных. Функция резервного копирования Azure Cosmos DB поддерживает оперативное резервное копирование и восстановление данных по запросу.

Модель данных для рабочей нагрузки

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

Рабочая нагрузка имеет следующие характеристики доступа к данным:

• Шаблон чтения:
  • Точка данных — извлечение одной записи. Идентификатор элемента и ключ раздела используются напрямую для максимальной оптимизации (1 RU за запрос).
  • Чтение списка— получение элементов каталога для отображения в списке. FeedIterator с ограничением на количество результатов используется.
• Записать шаблон:
  • Небольшие записи. Запросы обычно вставляют один или небольшое количество записей в транзакцию.
• Предназначен для обработки большого трафика от конечных пользователей с возможностью масштабирования для удовлетворения спроса на трафик на миллионы пользователей.
• Небольшая полезная нагрузка или размер набора данных — обычно в диапазоне килобайт.
• Низкое время отклика (в порядке миллисекунд).
• Низкая задержка (в порядке миллисекунд).

Настройка

Azure Cosmos DB настроен следующим образом:

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

  Примечание.

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

• Ключ раздела установлен на /id для всех коллекций. Это решение основано на шаблоне использования, который в основном включает "написание новых документов с GUID в качестве идентификатора" и "чтение широкого спектра документов по идентификаторам". Если код приложения поддерживает уникальность идентификатора, новые данные равномерно распределяются по секциям Azure Cosmos DB, что обеспечивает бесконечное масштабирование.

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

Ниже приведен пример реализации, в который показаны параметры политики индексирования с помощью Terraform:

indexing_policy {

  excluded_path {
    path = "/description/?"
  }

  excluded_path {
    path = "/comments/text/?"
  }

  included_path {
    path = "/*"
  }

}

Сведения о подключении приложения к Azure Cosmos DB в этой архитектуре см. в разделе Расмотрение платформы приложений для критически важных рабочих нагрузок.

службы обмена сообщениями;

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

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

Ниже приведены рекомендации по проектированию для премиум-версии службы шины сообщений Azure и Центров событий Azure в контексте критически важной архитектуры.

Управление нагрузкой

Система обмена сообщениями должна иметь возможность обрабатывать необходимую пропускную способность (как в МБ в секунду). Рассмотрим следующий пример.

• Для нефункциональных требований (NFR) системы необходимо указать средний размер сообщения и пиковое количество сообщений в секунду, которые должна поддерживать каждая метка. Эти сведения можно использовать для вычисления требуемой пиковой мб/секунды на метку.
• Влияние переключения на резерв необходимо учитывать при вычислении требуемой пиковой пропускной способности в МБ/секунду на одну метку.
• Для Службы шины Azure NFR должны указать любые расширенные функции службы шины, такие как сеансы и удаление дубликатов сообщений. Эти функции будут влиять на пропускную способность Service Bus.
• Пропускная способность Service Bus с необходимыми функциями должна вычисляться путем тестирования как МБ/секунда на единицу сообщений (MU). Дополнительные сведения по этой теме см. в разделе Service Bus уровней обмена сообщениями "Премиум" и "Стандартный".
• Пропускная способность Центра событий Azure должна вычисляться путем тестирования как МБ/секунды на единицу пропускной способности (TP) для стандартного уровня или единицу обработки (PU) для премиум-уровня. Дополнительные сведения об этом разделе см. в статье Масштабирование с помощью Центров событий.
• Приведенные выше вычисления можно использовать для проверки того, что служба обмена сообщениями может обрабатывать требуемую нагрузку на метку, а также требуемое количество единиц масштабирования, необходимых для выполнения этой нагрузки.
• В разделе операций рассматривается автоматическое масштабирование.

Каждое сообщение должно обрабатываться

Служебная шина Azure категории "Премиум" — это рекомендуемое решение для сообщений с высоким уровнем ценности, для которых должна быть гарантирована обработка. Ниже приведены сведения об этом требовании при использовании Premium уровня службы Azure Service Bus:

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

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

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

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

Обработка идемпотентных сообщений

В RFC 7231 гипертекстовый протокол передачи утверждает: "A ... метод считается идемпотентным , если предполагаемое влияние на сервер нескольких идентичных запросов с этим методом совпадает с эффектом для одного такого запроса".

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

• Может возникнуть ситуация, когда обработка сообщения включает операции базы данных, в частности вставку новых записей с идентификаторами, созданными базой данных. Новые сообщения можно отправлять брокеру, который содержит эти идентификаторы. Из-за отсутствия распределенных транзакций, охватывающих как базу данных, так и брокер сообщений, могут возникнуть различные осложнения в случае сбоя процесса выполнения кода. См. следующие примеры ситуаций:
  • Код, создающий сообщения, может выполняться до фиксации транзакции базы данных, как это принято у многих разработчиков, работающих с помощью шаблона Unit of Work. Эти сообщения могут утечь, если происходит сбой между вызовом брокера и запросом фиксации транзакции базы данных. По мере возврата транзакции эти идентификаторы, созданные базой данных, также отменяются, и они становятся доступными для другого кода, который может выполняться одновременно. Это может привести к тому, что получатели экранированных сообщений обрабатывают неправильные записи базы данных, что повреждает общую согласованность и правильность системы.
  • Если разработчики помещают код, который выдает сообщение после завершения транзакции базы данных, процесс по-прежнему может завершиться ошибкой между этими операциями (транзакция зафиксирована — отправлено сообщение). Когда это произойдет, сообщение снова пройдет обработку, но на этот раз защитная конструкция идемпотентности определит, что оно уже обработано (на основе данных, хранящихся в базе данных). Предложение пропустит сообщение, создающее код, полагая, что все было сделано успешно в последний раз. Подчиненные системы, которые ожидали получать уведомления о завершенном процессе, не получают ничего. Эта ситуация снова приводит к общему состоянию несоответствия.
• Решение указанных выше проблем включает использование шаблона транзакционной исходящей очереди, где исходящие сообщения хранятся отдельно, в том же транзакционном хранилище, что и бизнес-данные. Затем сообщения передаются брокеру сообщений, когда первоначальное сообщение успешно обработано.
• Так как многие разработчики не знакомы с этими проблемами или их решениями, чтобы гарантировать, что эти методы применяются последовательно в критически важной системе, мы рекомендуем иметь функциональные возможности исходящих ящиков и взаимодействие с брокером сообщений, упакованным в какую-то библиотеку. Весь процесс обработки кода и отправки транзакционно значимых сообщений должен использовать эту библиотеку, а не взаимодействовать напрямую с брокером сообщений.
  • Библиотеки, реализующие эту функцию в .NET, включают NServiceBus и MassTransit.

Высокий уровень доступности и аварийное восстановление

Брокер сообщений должен быть доступен для производителей для отправки сообщений и потребителей для их получения. Ниже приведены сведения об этом требовании:

• Чтобы обеспечить максимальную доступность с помощью Служебной Шины, используйте «Премиум-уровень», который поддерживает зоны доступности в поддерживаемых регионах. С зонами доступности сообщения и метаданные реплицируются в трех разных центрах обработки данных в одном регионе.
• Используйте поддерживаемые пакеты SDK для Service Bus или Event Hubs для автоматического повтора операций чтения или записи.
• Рассмотрите active-active репликацию или active-passive репликацию в качестве моделей для защиты от региональных бедствий.

Наблюдение

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

• Дросселирование указывает, что у системы нет необходимых ресурсов для обработки запроса. Как служебная шина, так и Центры событий поддерживают мониторинг регулируемых запросов. Вы должны оповестить об этом индикаторе.
• Глубина очереди . Глубина очереди, которая растет, может указывать на то, что процессоры сообщений не работают или недостаточно процессоров для обработки текущей нагрузки. Глубину очереди можно использовать для информирования логики автоматического масштабирования обработчиков.
  • Для Service Bus глубина очереди предоставляется в виде количества сообщений.
  • Для центров событий потребители должны вычислить глубину очереди на секцию и отправить метрику в программное обеспечение мониторинга. Для каждого чтения потребитель получает порядковый номер текущего события и свойства последнего события в очереди. Потребитель может вычислить смещение.
• Очередь недоставленных писем — сообщения в очереди недоставленных писем представляют сообщения, которые не удалось обработать. Обычно эти сообщения требуют вмешательства вручную. Оповещения должны быть заданы в очереди недоставленных писем.
  • Служебная шина имеет очередь недоставленных сообщений и метрику DeadLetteredMessages.
  • Для Event Hubs эта функция должна быть кастомной логикой, интегрированной в потребителя.
• Использование ЦП и памяти — ЦП и память должны отслеживаться, чтобы система обмена сообщениями была достаточно ресурсов для обработки текущей нагрузки. Как Шина обслуживания уровня "Премиум", так и Центры событий уровня "Премиум" отображают использование ЦП и памяти.
  • Единицы обмена сообщениями (MU) используются в Service Bus для изоляции ресурсов, таких как ЦП и память для пространства имен. ЦП и память, увеличивающиеся выше порогового значения, могут указывать на то, что настроено недостаточно единиц MUs, а снижение ниже других пороговых значений может указывать на то, что настроено слишком много единиц MUs. Эти индикаторы можно использовать для автоматического масштабирования MUS.
  • Уровень "Премиум" центров событий использует единицы обработки (PUS) для изоляции ресурсов, а стандартный уровень использует единицы пропускной способности (TUS). Для этих уровней не требуется взаимодействие с ЦП или памятью для автоматического раздувания PUS или TUS.

Проверка здоровья

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

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

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

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