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

  • Статья

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

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

Важно!

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

Четыре против больших данных

"Четыре и большие данные" предоставляют платформу для лучшего понимания необходимых характеристик платформы данных с высоким уровнем доступности и способов использования данных для повышения эффективности бизнеса. Таким образом, в этом разделе рассматривается, как характеристики Volume, Velocity, Variety и Veracity можно применять на концептуальном уровне, чтобы помочь спроектировать платформу данных с использованием соответствующих технологий обработки данных.

  • Volume: объем поступающих данных для информирования о требованиях к емкости хранилища и распределения по уровням. Это размер набора данных.
  • Velocity: скорость обработки данных в виде пакетов или непрерывных потоков, то есть скорость потока.
  • Variety: организация и формат данных, запись структурированных, частично структурированных и неструктурированных форматов, то есть данных в нескольких хранилищах или типах.
  • Veracity: включает происхождение и курирование рассматриваемых наборов данных для управления и контроля качества данных, то есть точности данных.

Вопросы проектирования

Объем

  • Существующие (если таковые есть) и ожидаемые будущие объемы данных на основе прогнозируемых темпов роста данных в соответствии с бизнес-целями и планами.

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

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

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

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

    • Приведет ли это к простою? и если да, то как долго?
    • Какие существуют процедуры устранения рисков? и потребует ли устранение рисков изменения приложения?
    • Будет ли риск потери данных?

  • Такие функции, как срок жизни (TTL), можно использовать для управления ростом данных путем автоматического удаления записей по истечении времени с помощью создания или изменения записей.

    • Например, Azure Cosmos DB предоставляет встроенную возможность срока жизни .

Скорость

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Для оптимизации последней версии данных необходимо учитывать время истечения срока действия кэша и политики.

Разнообразие (Variety)

  • Модель данных, типы данных, связи данных и предполагаемая модель запросов сильно влияют на решения платформы данных.

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

  • Характер наборов данных, рассматриваемых приложением, может быть разным: от неструктурированного содержимого, такого как изображения и видео, или более структурированных файлов, таких как CSV и Parquet.

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

  • В дополнение к реляционным или нереляционным платформам данных для определенных рабочих нагрузок данных могут также подходить графы или платформы данных "ключ—значение".

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

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

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

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

  • Возможности оптимизации соответствия модели данных и охватываемых типов данных будут сильно влиять на решения платформы данных.

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

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

    • Среды аналитической среды выполнения, такие как Apache Spark, могут иметь ограничения интеграции для анализа структур полиглотовых данных.

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

Достоверности

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

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

  • В любом распределенном приложении с несколькими репликами данных существует компромисс между согласованностью и задержкой, как указано в теоремах CAP и PACELC .

    • При четком распределении средств чтения и записи приложение должно выбрать либо самую быструю доступную версию элемента данных, даже если она устарела по сравнению с только что завершенной записью (обновлением) этого элемента данных в другом реплика, либо самой актуальной версией элемента данных, что может привести к дополнительной задержке при определении и получении последнего состояния.
    • Согласованность и доступность можно настроить на уровне платформы или на уровне отдельных запросов данных.
    • Что такое взаимодействие с пользователем, если данные должны были обслуживаться из реплика ближайшего к пользователю, который не отражает последнее состояние другого реплика? Т. е. может ли приложение поддерживать обслуживание устаревших данных?

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

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

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

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

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

    • Шифрование на стороне клиента обеспечивает управление ключами в Key Vault или другом безопасном расположении.

  • Шифрование канала передачи данных MACsec (IEEE 802.1AE MAC) используется для защиты всего трафика, перемещаемого между центрами обработки данных Azure в магистральной сети Майкрософт.

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

  • Проверка подлинности и авторизация в плоскости данных и уровне управления.

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

  • Наблюдаемость за счет мониторинга работоспособности платформы и доступа к данным.

    • Как будут применяться оповещения для условий за пределами допустимых операционных границ?

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

Объем

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

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

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

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

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

    • Рассмотрите возможность классификации наборов данных по уровням "горячий", "теплый" и "холодный" (архивный).
      • Например, базовые эталонные реализации используют Azure Cosmos DB для хранения "горячих" данных, которые активно используются приложением, а служба хранилища Azure используется для данных "холодных" операций в аналитических целях.

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

    • Настройте срок жизни (TTL) для данных, которые больше не требуются и не имеют долгосрочного аналитического значения.
      • Убедитесь, что старые данные можно безопасно перенастраивать в дополнительное хранилище или удалять без негативного влияния на приложение.
    • Выгрузите некритичные данные в дополнительное холодное хранилище, но сохраните их для аналитической ценности и соответствия требованиям аудита.
    • Сбор данных телеметрии и статистики использования платформы данных, чтобы команды DevOps могли постоянно оценивать требования к обслуживанию и хранилища данных правильного размера.

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

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

Скорость

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

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

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

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

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

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

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

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

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

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

  • Реализуйте кэширование для сценариев "горячих" данных, чтобы свести к минимуму время отклика.

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

Разнообразие (Variety)

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

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

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

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

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

Достоверности

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

    • Распределите реплики данных между Зоны доступности (AZ) в пределах региона (или используйте уровни служб, избыточные между зонами), чтобы обеспечить максимальную доступность внутри региона.

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

    • Рассмотрите бизнес-требования к разрешению конфликтов, когда один и тот же элемент данных изменяется в двух отдельных репликах записи, прежде чем любое изменение можно будет реплицировать, что приводит к конфликту.
      • Используйте стандартизованные политики разрешения конфликтов, такие как "Последняя победа", где это возможно
        • Если требуется пользовательская стратегия с пользовательской логикой, убедитесь, что для управления пользовательской логикой применяются методики CI/CD DevOps.

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

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

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

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

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

Примечание

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

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

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

Дополнительная справка

Дополнительные рекомендации по платформе данных доступны в руководстве по архитектуре приложение Azure.

Глобально распределенное хранилище данных записи в нескольких регионах

Для полного удовлетворения глобально распределенных устремлений "активный — активный" проект приложения настоятельно рекомендуется рассмотреть распределенную платформу данных записи в нескольких регионах, где изменения в отдельных записываемых репликах синхронизируются и объединяются между всеми репликами с разрешением конфликтов при необходимости.

Важно!

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

Azure Cosmos DB предоставляет глобально распределенное и высокодоступное хранилище данных NoSQL, предлагающее операции записи в нескольких регионах и настраиваемую согласованность в готовых условиях. Поэтому рекомендации и рекомендации по проектированию в этом разделе будут посвящены оптимальному использованию Azure Cosmos DB.

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

Azure Cosmos DB

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

  • Azure Cosmos DB поддерживает несколько разных API с разными наборами функций, такими как SQL, Cassandra и MongoDB.

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

  • Azure Cosmos DB поддерживает режимы подключения шлюза и прямого подключения, где Direct упрощает подключение по протоколу TCP к внутренним узлам Azure Cosmos DB реплика для повышения производительности с меньшим количеством сетевых прыжков, а шлюз обеспечивает подключение по протоколу HTTPS к узлам интерфейсного шлюза.

    • Прямой режим доступен только при использовании Azure Cosmos DB для NoSQL и в настоящее время поддерживается только на платформах SDK для .NET и Java.

  • В регионах с поддержкой зоны доступности Azure Cosmos DB предлагает поддержку избыточности зоны доступности (AZ) для обеспечения высокой доступности и устойчивости к зональным сбоям в регионе.

  • Azure Cosmos DB поддерживает четыре реплики данных в одном регионе, и если включена избыточность зоны доступности (AZ), Azure Cosmos DB обеспечивает размещение реплик данных в нескольких зонах доступности для защиты от зональных сбоев.

    • Протокол консенсуса Paxos применяется для достижения кворума между репликами в регионе.

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

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

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

  • Azure Cosmos DB предоставляет две политики разрешения конфликтов, которые можно применять для автоматического устранения конфликтов.

    • Последняя запись Wins (LWW) применяет протокол синхронизации времени, используя системное свойство метки _ts времени в качестве пути разрешения конфликтов. В случае конфликта элемент с наибольшим значением для пути разрешения конфликта становится победителем и если несколько элементов имеют одинаковое числовое значение, система выбирает победителя, чтобы все регионы могли сходиться к одной и той же версии зафиксированного элемента.
      • При конфликтах удаления удаленная версия всегда имеет приоритет над конфликтами вставки или замены, независимо от значения пути разрешения конфликтов.
      • Приоритет последней записи — это политика разрешения конфликтов по умолчанию.
      • При использовании Azure Cosmos DB для NoSQL для разрешения конфликтов можно использовать настраиваемое числовое свойство, например настраиваемое определение метки времени.
    • Пользовательские политики разрешения позволяют использовать определяемую приложением семантику для согласования конфликтов с помощью зарегистрированной хранимой процедуры слияния, которая автоматически вызывается при обнаружении конфликтов.
      • Система гарантирует только однократное выполнение слияния в рамках протокола обязательств.
      • Настраиваемая политика разрешения конфликтов доступна только в Azure Cosmos DB для NoSQL и может быть задана только во время создания контейнера.

  • В конфигурации записи в нескольких регионах существует зависимость от одного центрального региона Azure Cosmos DB для выполнения всех решений конфликтов, при этом для достижения кворума в репликах в регионе концентратора применяется протокол консенсуса Paxos.

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

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

  • Основной регион концентратора определяется первым регионом, в который настроена База данных Azure Cosmos DB.

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

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

  • При развертывании с одним регионом записи в Azure Cosmos DB можно настроить автоматическую отработку отказа на основе определенного приоритета отработки отказа, учитывая все реплики региона чтения.

  • RTO, предоставляемое платформой Azure Cosmos DB, составляет около 10–15 минут, что позволяет захватить затраченное время на выполнение региональной отработки отказа службы Azure Cosmos DB в случае катастрофической аварии, влияющей на регион концентратора.

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

Стратегическим направлением платформы Azure Cosmos DB является сокращение RTO до ~5 минут за счет отработки отказа на уровне секций.

  • Целевые точки восстановления (RPO) и цели времени восстановления (RTO) настраиваются с помощью уровней согласованности с компромиссом между устойчивостью данных и пропускной способностью.

    • Azure Cosmos DB предоставляет минимальное значение RTO 0 для нестрого уровня согласованности с записью в нескольких регионах или RPO 0 для строгой согласованности с одним регионом записи.

  • Azure Cosmos DB предлагает соглашение об уровне обслуживания 99,999 % для чтения и записи для учетных записей баз данных, настроенных с несколькими регионами Azure в качестве доступных для записи.

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

  • Azure Cosmos DB предлагает соглашение об уровне обслуживания 99,99 % для пропускной способности, согласованности, доступности и задержки для учетных записей баз данных в пределах одного региона Azure при настройке любого из пяти уровней согласованности.

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

  • Существует два типа пропускной способности, которые можно подготовить в Azure Cosmos DB: стандартная и автомасштабирование, которые измеряются с помощью единиц запросов в секунду (ЕЗ/с).

    • Стандартная пропускная способность выделяет ресурсы, необходимые для обеспечения указанного значения ЕЗ/с.
      • Плата за подготовленную пропускную способность взимается каждый час.
    • Автомасштабирование определяет максимальное значение пропускной способности, и Azure Cosmos DB автоматически масштабируется в зависимости от нагрузки приложения между максимальным значением пропускной способности и минимум 10 % от максимального значения пропускной способности.
      • Автомасштабирование оплачивается каждый час за максимальную потребляемую пропускную способность.

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

    • Автомасштабирование защищает от ошибок регулирования, позволяя Azure Cosmos DB масштабироваться по мере необходимости, сохраняя при этом защиту от затрат, уменьшая при уменьшении нагрузки.

  • При репликации Azure Cosmos DB в нескольких регионах счета выставляются за подготовленные единицы запросов (ЕЗ) для каждого региона.

  • Существует значительная разница в затратах между конфигурацией записи в нескольких регионах и с одним регионом записи, что во многих случаях может сделать несколько master платформы данных Azure Cosmos DB.

Чтение и запись в одном регионе Запись в один регион — чтение с двумя регионами Чтение и запись в двух регионах
1 ЕЗ 2 ЕЗ 4 ЕЗ

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

  • Плата за использование хранилища взимается в виде фиксированной ставки за общий объем хранилища (ГБ), используемого для размещения данных и индексов в течение заданного часа.

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

  • Azure Cosmos DB поддерживает проверку подлинности с помощью удостоверения Microsoft Entra или ключей и маркеров ресурсов Azure Cosmos DB, которые предоставляют перекрывающиеся возможности.

Возможности доступа к Azure Cosmos DB Возможности

  • Можно отключить операции управления ресурсами с помощью ключей или маркеров ресурсов, чтобы ограничить ключи и маркеры ресурсов только операциями с данными, что позволяет точно контролировать доступ к ресурсам с помощью Microsoft Entra управления доступом на основе ролей (RBAC).

    • Ограничение доступа к плоскости управления с помощью ключей или маркеров ресурсов приведет к отключению операций уровня управления для клиентов, использующих пакеты SDK для Azure Cosmos DB, и поэтому их следует тщательно оценить и протестировать.
    • Параметр disableKeyBasedMetadataWriteAccess можно настроить с помощью определений IaC шаблона ARM или встроенного Политика Azure.

  • Microsoft Entra поддержка RBAC в Azure Cosmos DB применяется к операциям управления учетной записью и уровнем управления ресурсами.

    • Администраторы приложений могут создавать назначения ролей для пользователей, групп, субъектов-служб или управляемых удостоверений, чтобы предоставлять или запрещать доступ к ресурсам и операциям в ресурсах Azure Cosmos DB.
    • Существует несколько встроенных ролей RBAC , доступных для назначения ролей, и пользовательские роли RBAC также можно использовать для формирования определенных комбинаций привилегий.
      • Читатель учетной записи Cosmos DB обеспечивает доступ только для чтения к ресурсу Azure Cosmos DB.
      • Участник учетной записи DocumentDB позволяет управлять учетными записями Azure Cosmos DB, включая ключи и назначения ролей, но не обеспечивает доступ к плоскости данных.
      • Оператор Cosmos DB, который похож на участника учетной записи DocumentDB, но не предоставляет возможность управлять ключами или назначениями ролей.

  • Ресурсы Azure Cosmos DB (учетные записи, базы данных и контейнеры) можно защитить от неправильного изменения или удаления с помощью блокировки ресурсов.

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

  • Канал изменений Azure Cosmos DB предоставляет упорядоченный по времени канал изменений данных в контейнере Azure Cosmos DB.

    • Канал изменений включает только операции вставки и обновления в исходном контейнере Azure Cosmos DB; он не включает удаления.

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

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

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

    • Можно реализовать шаблон обратимого удаления , чтобы записи данных включались в канал изменений.
      • Вместо явного удаления записей данных записи данных обновляются путем установки флага (например IsDeleted, ) для указания того, что элемент считается удаленным.
      • Для любого целевого хранилища данных, передаваемого каналом изменений, потребуется обнаружить и обработать элементы с флагом удаления, установленным равным True; вместо хранения записей данных с обратимым удалением необходимо удалить существующую версию записи данных в целевом хранилище.
    • Короткий срок жизни (TTL) обычно используется с шаблоном обратимого удаления, чтобы Azure Cosmos DB автоматически удаляет данные с истекшим сроком действия, но только после того, как они будут отражены в канале изменений с флагом удаленного значения True.
      • Выполняет исходное намерение удаления, а также распространяет удаление через канал изменений.

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

  • Azure Cosmos DB автоматически создает резервные копии данных через регулярные интервалы времени, не влияя на производительность или доступность и не потребляя ЕЗ/с.

  • Azure Cosmos DB можно настроить в соответствии с двумя различными режимами резервного копирования.

    • Периодический — это режим резервного копирования по умолчанию для всех учетных записей, в котором резервные копии создаются через периодический интервал, а данные восстанавливаются путем создания запроса к группе поддержки.
      • Период периодического хранения резервных копий по умолчанию составляет восемь часов, а интервал резервного копирования по умолчанию — четыре часа. Это означает, что по умолчанию сохраняются только последние две резервные копии.
      • Интервал резервного копирования и период хранения можно настроить в учетной записи.
        • Максимальный срок хранения составляет месяц с минимальным интервалом резервного копирования в один час.
        • Для настройки избыточности хранилища резервных копий требуется назначение роли azure "Роль читателя учетной записи Cosmos DB".
      • Две резервные копии включаются без дополнительных затрат, но дополнительные резервные копии влечет за собой дополнительные затраты.
      • По умолчанию периодические резервные копии хранятся в отдельном хранилище Geo-Redundant (GRS), недоступном напрямую.
        • Хранилище резервных копий существует в основном регионе концентратора и реплицируется в парный регион с помощью репликации базового хранилища.
        • Конфигурацию избыточности базовой учетной записи хранения резервных копий можно настроить для хранилища, избыточного между зонами, или хранилища Locally-Redundant.
      • Для выполнения операции восстановления требуется запрос в службу поддержки , так как клиенты не могут выполнить восстановление напрямую.
        • Перед открытием запроса в службу поддержки необходимо увеличить срок хранения резервных копий по крайней мере до семи дней в течение восьми часов после события потери данных.
      • Операция восстановления создает учетную запись Azure Cosmos DB, в которой восстанавливаются данные.
        • Существующую учетную запись Azure Cosmos DB нельзя использовать для восстановления
        • По умолчанию будет использоваться новая учетная запись Azure Cosmos DB с именем <Azure_Cosmos_account_original_name>-restored<n> .
          • Это имя можно изменить, например повторно использовать существующее имя, если исходная учетная запись была удалена.
      • Если пропускная способность подготовлена на уровне базы данных, резервное копирование и восстановление будут выполняться на уровне базы данных.
        • Невозможно выбрать подмножество контейнеров для восстановления.
    • Режим непрерывного резервного копирования позволяет выполнить восстановление до любой точки времени за последние 30 дней.
      • Операции восстановления можно выполнять для возврата к определенной точке во времени (PITR) с степенью детализации в одну секунду.
      • Доступное окно для операций восстановления — до 30 дней.
        • Также можно восстановить состояние создания экземпляра ресурса.
      • Непрерывное резервное копирование выполняется в каждом регионе Azure, где существует учетная запись Azure Cosmos DB.
        • Непрерывные резервные копии хранятся в том же регионе Azure, что и все реплика Azure Cosmos DB, используя хранилище Locally-Redundant (LRS) или хранилище, избыточное между зонами (ZRS) в регионах, поддерживающих Зоны доступности.
      • Самостоятельное восстановление можно выполнить с помощью артефактов портал Azure или IaC, таких как шаблоны ARM.
      • Существует несколько ограничений для непрерывного резервного копирования.
        • Режим непрерывного резервного копирования в настоящее время недоступен в конфигурации записи в нескольких регионах.
        • В настоящее время для непрерывного резервного копирования можно настроить только Azure Cosmos DB для NoSQL и Azure Cosmos DB для MongoDB.
        • Если в контейнере настроен срок жизни, восстановленные данные, превышающие его срок жизни, могут быть немедленно удалены.
      • Операция восстановления создает учетную запись Azure Cosmos DB для восстановления на определенный момент времени.
      • Для операций непрерывного резервного копирования и восстановления требуется дополнительная плата.

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

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

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

    • Пользовательский подход приводит к значительным затратам и дополнительным административным издержкам, которые следует понимать и тщательно оценивать.
      • Следует моделировать распространенные сценарии восстановления, такие как повреждение или удаление учетной записи, базы данных, контейнера в элементе данных.
      • Чтобы предотвратить разрастание резервных копий, необходимо реализовать процедуры обслуживания.
    • Можно использовать службу хранилища Azure или альтернативную технологию данных, например альтернативный контейнер Azure Cosmos DB.
      • Служба хранилища Azure и Azure Cosmos DB обеспечивают встроенную интеграцию со службами Azure, такими как Функции Azure и Фабрика данных Azure.

  • В документации по Azure Cosmos DB описаны два возможных варианта реализации пользовательских резервных копий.

    • Канал изменений Azure Cosmos DB для записи данных в отдельное хранилище.
    • С помощью канала изменений можно реализовать как непрерывные, так и периодические (пакетные) пользовательские резервные копии.
    • Канал изменений Azure Cosmos DB пока не отражает удаления, поэтому шаблон обратимого удаления должен применяться с помощью логического свойства и срока жизни.
      • Этот шаблон не требуется, если канал изменений предоставляет полные обновления.
    • Фабрика данных Azure Соединитель для Azure Cosmos DB (Azure Cosmos DB для NoSQL или соединители API MongoDB) для копирования данных.
      • Фабрика данных Azure (ADF) поддерживает ручное выполнение и расписание, переворачивающееся окно и триггеры на основе событий.
        • Обеспечивает поддержку хранилища и сетки событий.
      • ADF в первую очередь подходит для периодических пользовательских реализаций резервного копирования из-за пакетной оркестрации.
        • Он менее подходит для реализации непрерывного резервного копирования с частыми событиями из-за накладных расходов на выполнение оркестрации.
      • ADF поддерживает Приватный канал Azure для сценариев с высоким уровнем безопасности сети.

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

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

Azure Cosmos DB

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

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

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

  • Для менее важных сценариев рабочей нагрузки приоритезируете использование конфигурации записи в одном регионе (при использовании Зоны доступности) с глобально распределенными репликами чтения, так как это обеспечивает высокий уровень надежности платформы данных (соглашение об уровне обслуживания 99,999 % для чтения, 99,995 % соглашение об уровне обслуживания для операций записи) по более привлекательной цене.

    • Настройте приложение для использования локального реплика чтения Azure Cosmos DB для оптимизации производительности чтения.

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

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

  • Настройте Azure Cosmos DB с избыточностью зоны доступности (AZ) во всех регионах развертывания с поддержкой AZ, чтобы обеспечить устойчивость к зональным сбоям в регионе.

  • Используйте Azure Cosmos DB для NoSQL, так как она предлагает наиболее полный набор функций, особенно в тех случаях, когда речь идет о настройке производительности.

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

  • Используйте режим прямого подключения для оптимизации производительности сети за счет прямого tcp-подключения к внутренним узлам Azure Cosmos DB с меньшим количеством сетевых "прыжков".

Соглашение об уровне обслуживания Azure Cosmos DB рассчитывается путем усреднения неудачных запросов, которые могут не совпадать напрямую с бюджетом уровня надежности 99,999 %. Поэтому при проектировании с учетом 99,999 % SLO важно спланировать недоступность записи Azure Cosmos DB в регионах и нескольких регионах, гарантируя, что технология резервного хранилища будет размещена в случае сбоя, например сохраняемой очереди сообщений для последующего воспроизведения.

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

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

  • Выберите оптимальный ключ секции.

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

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

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

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

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

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

  • Отключите доступ на запись метаданных на основе ключей Azure Cosmos DB, применив встроенную Политика Azure.

  • Включите Azure Monitor для сбора ключевых метрик и журналов диагностики, таких как подготовленная пропускная способность (ЕЗ/с).

    • Перенаправка рабочих данных Azure Monitor в рабочую область Log Analytics, выделенную для Azure Cosmos DB и других глобальных ресурсов в структуре приложения.
    • Используйте метрики Azure Monitor, чтобы определить, подходят ли шаблоны трафика приложений для автомасштабирования.

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

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

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

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

  • Для развертываний с одним регионом записи настоятельно рекомендуется настроить Azure Cosmos DB для автоматической отработки отказа.

  • Уровень нагрузки за счет использования асинхронного неблокирующего обмена сообщениями в системных потоках, которые записывают обновления в Azure Cosmos DB.

  • Настройте учетную запись Azure Cosmos DB для непрерывного резервного копирования, чтобы получить детальную детализацию точек восстановления за последние 30 дней.

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

  • Настоятельно рекомендуется попрактиковаться в процедурах восстановления непроизводственных ресурсов и данных в рамках стандартной подготовки к непрерывности бизнес-процессов.

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

  • Оцените и примените руководство по управлению базовыми показателями безопасности Azure для Резервного копирования и восстановления Azure Cosmos DB.

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

Технологии реляционных данных

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

Azure предоставляет множество управляемых платформ реляционных данных, включая базу данных Azure SQL и Базу данных Azure для распространенных реляционных решений OSS, включая MySQL, PostgreSQL и MariaDB. Поэтому рекомендации и рекомендации по проектированию в этом разделе будут посвящены оптимальному использованию вариантов OSS базы данных Azure SQL и Базы данных Azure для обеспечения максимальной надежности и глобальной доступности.

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

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

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

    • Например, сегментирование часто применяется на мультитенантных платформах SaaS для изоляции групп клиентов в разных конструкциях платформы данных.

База данных SQL Azure

  • Azure SQL База данных предоставляет полностью управляемое ядро СУБД, которое всегда работает в последней стабильной версии ядра СУБД SQL Server и базовой операционной системы.

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

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

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

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

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

  • Реплики базы данных уровня "Премиум" или критически важный для бизнеса уровня служб можно распределять между Зоны доступности без дополнительных затрат.

    • Кольцо управления также дублируется в нескольких зонах в виде трех кругов шлюза (ГВ).
      • Маршрутизация на определенный круг шлюза управляется диспетчером трафика Azure.
    • Если используется уровень "Критически важный для бизнеса", конфигурация с избыточностью в пределах зоны доступна только при выборе вычислительного оборудования 5-го поколения.

  • База данных Azure SQL предлагает базовое соглашение об уровне обслуживания на уровне 99,99 % доступности на всех уровнях служб, но обеспечивает более высокий уровень обслуживания на 99,995 % для уровней критически важный для бизнеса или Премиум в регионах, поддерживающих зоны доступности.

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

  • При настройке с георепликацией уровень критически важный для бизнеса базы данных Azure SQL предоставляет целевое время восстановления (RTO) в 30 секунд в течение 100 % развернутых часов.

  • При настройке георепликации уровень критически важный для бизнеса базы данных Azure SQL имеет целевую точку восстановления (RPO) 5 секунд в течение 100 % развернутых часов.

  • Azure SQL уровня "Гипермасштабирование базы данных" при настройке по крайней мере с двумя репликами имеет соглашение об уровне обслуживания доступности 99,99 %.

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

    • Для баз данных на основе единиц DTU невозможно применить зарезервированную емкость.

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

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

База данных Azure для PostgreSQL

  • База данных Azure для PostgreSQL предлагается в трех различных вариантах развертывания:

    • Отдельный сервер, соглашение об уровне обслуживания 99,99 %
    • Гибкий сервер, который обеспечивает избыточность зоны доступности, соглашение об уровне обслуживания 99,99 %
    • Гипермасштабирование (Citus), соглашение об уровне обслуживания 99,95 %, если включен режим высокой доступности.

  • Гипермасштабирование (Citus) обеспечивает динамическую масштабируемость за счет сегментирования без изменений приложения.

    • Распределение строк таблицы между несколькими серверами PostgreSQL является ключевым фактором для обеспечения масштабируемых запросов в гипермасштабировании (Citus).
    • Несколько узлов могут совместно содержать больше данных, чем традиционная база данных, и во многих случаях могут использовать рабочие ЦП параллельно для оптимизации затрат.

  • Автомасштабирование можно настроить с помощью автоматизации runbook, чтобы обеспечить эластичность в ответ на изменение шаблонов трафика.

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

  • Дополнительная плата за хранилище резервных копий до 100 % общего объема подготовленного хранилища сервера не взимается.

    • Плата за дополнительное потребление хранилища резервных копий взимается в соответствии с потребляемыми ГБ в месяц.

  • Затраты на вычислительные ресурсы, связанные с База данных Azure для PostgreSQL, можно сократить с помощью скидки на резервирование на один сервер или с гипермасштабированием (Citus).

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

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

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

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

База данных SQL Azure

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

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

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

  • Используйте активную георепликацию для развертывания доступных для чтения реплик во всех регионах развертывания (до четырех).

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

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

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

Важно!

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

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

  • Используйте Azure Monitor и Azure SQL Analytics для получения операционной аналитики практически в реальном времени в Azure SQL DB для обнаружения инцидентов надежности.

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

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

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

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

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

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

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

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

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

База данных Azure для PostgreSQL

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

  • При использовании гипермасштабирования (Citus) для критически важных для бизнеса рабочих нагрузок включите режим высокой доступности, чтобы получить гарантию 99,95 % SLA.

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

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

Кэширование данных горячего уровня

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

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

Вопросы проектирования

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

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

Кэш Azure для Redis

  • Кэш Redis — это система хранения открытый код NoSQL "ключ—значение" в памяти.

  • Уровни "Корпоративный" и "Корпоративный" можно развернуть в конфигурации "активный — активный" в Зоны доступности в регионе и в разных регионах Azure с помощью георепликации.

    • При развертывании по крайней мере в трех регионах Azure и трех или более Зоны доступности в каждом регионе с включенной активной георепликацией для всех экземпляров кэша Кэш Azure для Redis обеспечивает соглашение об уровне обслуживания 99,999 % для подключения к одной конечной точке регионального кэша.
    • При развертывании в трех Зоны доступности в одном регионе Azure предоставляется соглашение об уровне обслуживания с подключением 99,99 %.

  • Уровень флэш-памяти "Корпоративный" работает на сочетании ОЗУ и энергонезависимого хранилища флэш-памяти, и хотя это обеспечивает небольшое снижение производительности, он также обеспечивает очень большие размеры кэша до 13 ТБ с кластеризация.

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

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

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

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

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

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

    • Рассмотрите возможность истечения срока действия элементов кэша при изменении резервных данных.

Кэш Azure для Redis

  • Используйте номер SKU "Премиум" или "Корпоративный" для повышения надежности и производительности.

    • Для сценариев с очень большими объемами данных следует рассмотреть уровень "Корпоративная флэш-память".
    • Для сценариев, в которых требуется только пассивная георепликация, также можно рассмотреть уровень "Премиум".

  • Развертывание экземпляров реплика с помощью георепликации в активной конфигурации во всех регионах развертывания.

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

  • Используйте Azure Monitor для оценки Кэш Azure для Redis.

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

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

  • Настройте запланированные обновления , чтобы указать дни и время применения обновлений Redis Server к кэшу.

Аналитические сценарии

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

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

Описание Аналитический отчет Транзакционную
Вариант использования Анализ очень больших объемов данных ("большие данные") Обработка очень больших объемов отдельных транзакций
Оптимизировано для Чтение запросов и агрегатов по множеству записей Запросы на создание, чтение, обновление и удаление (CRUD) практически в реальном времени для нескольких записей
Ключевые характеристики — Консолидация из источников данных записей
— Хранилище на основе столбцов
— Распределенное хранилище
— Параллельная обработка
- Денормализовано
— операции чтения и записи с низким параллелизмом
— Оптимизация для тома хранилища со сжатием		 — Источник данных записи для приложения
— Хранилище на основе строк
— Непрерывное хранилище
— Симметричная обработка
-Нормализованный
— операции чтения и записи с высоким параллелизмом, обновления индекса
— Оптимизация для быстрого доступа к данным с помощью хранилища в памяти

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

Вопросы проектирования

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

Azure Cosmos DB

  • Аналитические запросы, выполняемые на транзакционных данных Azure Cosmos DB, обычно объединяются по секциям по большим объемам данных, потребляя значительную пропускную способность единиц запросов (ЕЗ), что может повлиять на производительность окружающих транзакционных рабочих нагрузок.

  • Аналитическое хранилище Azure Cosmos DB предоставляет схематизированное полностью изолированное хранилище данных, ориентированное на столбцы, которое позволяет выполнять крупномасштабную аналитику данных Azure Cosmos DB из Azure Synapse без влияния на транзакционные рабочие нагрузки Azure Cosmos DB.

    • Если контейнер Azure Cosmos DB включен в качестве аналитического хранилища, на основе операционных данных в контейнере создается новое хранилище столбцов. Это хранилище столбцов сохраняется отдельно от хранилища транзакций, ориентированного на строки для контейнера.
    • Операции создания, обновления и удаления операционных данных автоматически синхронизируются с аналитическим хранилищем, поэтому обработка канала изменений или извлечения, преобразования и загрузки не требуется.
    • Синхронизация данных из операционного хранилища в аналитическое хранилище не использует пропускную способность единиц запросов (ЕЗ), подготовленных в контейнере или базе данных. Это не влияет на производительность транзакционных рабочих нагрузок. Аналитическое хранилище не требует выделения дополнительных ЕЗ в базе данных или контейнере Azure Cosmos DB.
    • Автоматическая синхронизация — это процесс, в котором изменения операционных данных автоматически синхронизируются с аналитическим хранилищем. Задержка автоматической синхронизации обычно составляет менее двух (2) минут.
      • Задержка автоматической синхронизации может составлять до пяти (5) минут для базы данных с общей пропускной способностью и большим количеством контейнеров.
      • После завершения автоматической синхронизации можно запросить последние данные из Azure Synapse.
    • Хранилище аналитического хранилища использует модель ценообразования на основе потребления, которая взимает плату за объем данных и количество операций чтения и записи. Цены на аналитическое хранилище отделены от цен на транзакционные магазины.

  • Используя Azure Synapse Link, аналитическое хранилище Azure Cosmos DB можно запрашивать непосредственно из Azure Synapse. Это позволяет использовать не ETL, гибридную обработку Transactional-Analytical (HTAP) из Synapse, чтобы данные Azure Cosmos DB можно запрашивать вместе с другими аналитическими рабочими нагрузками из Synapse практически в реальном времени.

  • Аналитическое хранилище Azure Cosmos DB не секционировано по умолчанию.

    • В некоторых сценариях запросов производительность будет повышена за счет секционирования данных аналитического хранилища с помощью ключей, которые часто используются в предикатах запросов.
    • Секционирование активируется заданием в Azure Synapse, которое запускает записную книжку Spark с помощью Synapse Link, которое загружает данные из аналитического хранилища Azure Cosmos DB и записывает их в секционированное хранилище Synapse в основной учетной записи хранения рабочей области Synapse.

  • Azure Synapse Analytics бессерверные пулы SQL могут запрашивать аналитическое хранилище с помощью автоматически обновленных представлений или командSELECT / OPENROWSET.

  • Azure Synapse пулы Spark Analytics могут запрашивать аналитическое хранилище с помощью автоматически обновленных таблиц Spark или spark.read команды .

  • Данные также можно скопировать из аналитического хранилища Azure Cosmos DB в выделенный пул Synapse SQL с помощью Spark, чтобы можно было использовать подготовленные ресурсы Azure Synapse пула SQL.

  • Данные аналитического хранилища Azure Cosmos DB можно запрашивать с помощью Azure Synapse Spark.

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

Хранилище аналитических столбцов Azure Cosmos DB

  • Канал изменений Azure Cosmos DB также можно использовать для обслуживания отдельного дополнительного хранилища данных для аналитических сценариев.

Azure Synapse

  • Azure Synapse объединяет возможности аналитики, включая хранилище данных SQL, большие данные Spark и Data Explorer для аналитики журналов и временных рядов.

    • Azure Synapse использует связанные службы для определения подключений к другим службам, таким как служба хранилища Azure.
    • Данные можно принимать в Synapse Analytics с помощью действие Copy из поддерживаемых источников. Это позволяет выполнять аналитику данных в Synapse, не влияя на исходное хранилище данных, но увеличивает время, затраты и задержки при передаче данных.
    • Данные также можно запрашивать на месте в поддерживаемых внешних хранилищах, избегая дополнительных затрат на прием и перемещение данных. Служба хранилища Azure с Data Lake 2-го поколения — это поддерживаемое хранилище для запросов к экспортируемым данным Synapse и Log Analytics с помощью Synapse Spark.

  • Azure Synapse Studio объединяет задачи приема и запроса.

    • Исходные данные, в том числе данные аналитического хранилища Azure Cosmos DB и данные экспорта Log Analytics, запрашиваются и обрабатываются для поддержки бизнес-аналитики и других агрегированных аналитических вариантов использования.

Azure Synapse Analytics

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

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

Аналитика приложений

AIOps и операционная аналитика

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

  • Создайте выделенную учетную запись хранения Azure и используйте ее в качестве основной учетной записи хранения рабочей области для хранения данных и метаданных каталога рабочей области Synapse. Настройте его с иерархическим пространством имен, чтобы включить Azure Data Lake 2-го поколения.

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

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

Ознакомьтесь с рекомендациями по работе с сетями.

Сеть и подключение