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

  • Статья

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

Характеристики Рекомендации
Производительность Сколько вычислительных ресурсов требуется?
Задержка Какое влияние будет влиять на расстояние между пользователем и хранилищем данных при задержке? Какой требуемый уровень согласованности с компромиссом по задержке?
Адаптивность Требуется ли хранилище данных всегда доступно?
Масштабируемость Что такое схема секционирования?
Устойчивость Ожидается ли долгое время данные? Что такое политика хранения?
Устойчивость В случае сбоя хранилище данных может выполнять отработку отказа автоматически? Какие меры применяются для уменьшения времени отработки отказа?
Безопасность Шифруются ли данные? Можно ли достичь хранилища данных через общедоступную сеть?

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

  • База данных

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

    Настоятельно рекомендуется реплика tion в конфигурации 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 поддерживает оперативное резервное копирование и восстановление данных по запросу.

Примечание.

Большинство рабочих нагрузок не являются чисто OLTP. Существует растущий спрос на отчеты в режиме реального времени, например запуск отчетов в операционной системе. Также это называют HTAP (гибридная транзакционно-аналитическая обработка). Azure Cosmos DB поддерживает эту возможность с помощью Azure Synapse Link для Azure Cosmos DB.

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

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

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

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

Настройка

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

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

    Примечание.

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

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

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

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

indexing_policy {

  excluded_path {
    path = "/description/?"
  }

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

  included_path {
    path = "/*"
  }

}

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

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

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

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

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

Обработка загрузки

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

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

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

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

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

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

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

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

Обработка сообщений idempotent

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

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

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

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

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

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

Примечание.

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

Наблюдение

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

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

Проверка работоспособности

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

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

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

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

Реализация: критически важный интернет