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

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

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

Внимание

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

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

Функция "Четыре vs of Big Data" предоставляет платформу для лучшего понимания необходимых характеристик платформы данных с высоким уровнем доступности и способов использования данных для максимальной эффективности бизнеса. Поэтому в этом разделе рассматривается, как характеристики тома, скорости, разнообразия и достоверности могут применяться на концептуальном уровне для разработки платформы данных с помощью соответствующих технологий данных.

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

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

Объем

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

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

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

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

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

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

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

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

Скорость

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разнообразие

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

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

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

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

• Помимо реляционных или нереляционных платформ данных, платформ данных graph или key-value также может быть подходит для определенных рабочих нагрузок данных.

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

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

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

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

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

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

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

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

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

Правдивость

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

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

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

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

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

  • Стандартизированные политики разрешения конфликтов, такие как "Last Write Wins", или настраиваемая стратегия с пользовательской логикой может быть применена.

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

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

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

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

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

  • Пакеты шифруются и расшифровываются на устройствах перед отправкой, предотвращая физические атаки "man-in-the-middle" или snooping/wiretapping.

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

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

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

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

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

Объем

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

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

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

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

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

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

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

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

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

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

Скорость

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

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

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

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

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

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

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

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

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

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

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

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

Разнообразие

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

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

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

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

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

Правдивость

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

• Дерево принятия решений хранилища данных Azure
• Критерии выбора хранилища данных
• Нереляционные хранилища данных
• Реляционные хранилища данных OLTP

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

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

Внимание

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

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 гарантирует, что реплики данных помещаются в несколько AZ для защиты от зональных сбоев.

  • Протокол консенсуса 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 заключается в удалении этой зависимости одного региона для разрешения конфликтов в конфигурации записи в нескольких регионах, используя 2-этапный подход 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 в нескольких регионах счета выставляются за подготовленные единицы запросов (ЕЗ) в каждом регионе.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Реализуйте логику повторных попыток в пакете SDK на клиентах.

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

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

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

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

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

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

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

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

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

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

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

  • Рассмотрим такие шаблоны, как разделение команд и ответственности за запросы и выбор событий.

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

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

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

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

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

  • BR-1. Обеспечение регулярного автоматического резервного копирования
  • BR-3. Проверка всех резервных копий, включая ключи, управляемые клиентом
  • BR-4, устранение риска потери ключей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кэш Azure для Redis

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

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

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

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

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

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

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

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

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

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

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

Кэш Azure для Redis

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

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

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

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

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

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

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

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

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

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

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

Description	Аналитический отчет	Деловое
Вариант использования	Анализ очень больших объемов данных ("большие данные")	Обработка очень больших объемов отдельных транзакций
Оптимизировано для	Чтение запросов и агрегатов во многих записях	Почти в реальном времени запросы create/Read/Update/Delete (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 включен в качестве аналитического хранилища, новое хранилище столбцов создается внутренне из операционных данных в контейнере. Это хранилище столбцов сохраняется отдельно от хранилища транзакций, ориентированного на строку для контейнера.
  • Операции создания, обновления и удаления операционных данных автоматически синхронизируются с аналитическим хранилищем, поэтому для обработки изменений или обработки ETL не требуется.
  • Синхронизация данных из операционного хранилища в аналитическое хранилище не использует единицы запросов пропускной способности (ЕЗ), подготовленные в контейнере или базе данных. Производительность транзакционных рабочих нагрузок не влияет. Аналитическое хранилище не требует выделения дополнительных единиц запросов в базе данных Или контейнере Azure Cosmos DB.
  • Автоматическая синхронизация — это процесс, в котором изменения операционных данных автоматически синхронизируются с аналитическим хранилищем. Задержка автоматической синхронизации обычно меньше двух (2) минут.
    • Задержка автоматической синхронизации может составлять до пяти (5) минут для базы данных с общей пропускной способностью и большим количеством контейнеров.
    • После завершения автоматической синхронизации последние данные можно запрашивать из Azure Synapse.
  • Хранилище аналитического хранилища использует модель ценообразования на основе потребления, которая взимает плату за объем данных и количество операций чтения и записи. Цены на аналитическое хранилище отделены от цен на транзакционные хранилища.

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

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

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

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

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

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

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

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

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

Azure Synapse

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

  • 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 Link с Аналитическим хранилищем Azure Cosmos DB для анализа операционных данных Azure Cosmos DB, создав оптимизированное хранилище данных, которое не повлияет на производительность транзакций.

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

• Приоритет аналитического хранилища Azure Cosmos DB с Помощью Azure Synapse Link вместо использования канала изменений Azure Cosmos DB для поддержания аналитического хранилища данных.

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

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

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

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

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

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

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

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