Microsoft AZ-305: Хранение данных и решения для баз данных — Руководство по подготовке

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

Часть Microsoft Azure Solutions Architect Expert AZ-305 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

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

Реляционные службы данных в Azure

Azure SQL Database предлагает две модели приобретения. Модель DTU объединяет CPU, память и операции ввода-вывода в единый смешанный юнит в рамках уровней Basic, Standard и Premium; она проста, но непрозрачна для планирования мощностей. Модель vCore разделяет вычислительные ресурсы, память и хранилище, предлагая выбор оборудования, предсказуемое масштабирование и рычаги управления затратами, такие как Azure Hybrid Benefit и зарезервированные мощности. В рамках vCore основными уровнями обслуживания являются General Purpose (разделенные вычислительные ресурсы и удаленное хранилище, сбалансированная стоимость), Business Critical (локальные SSD с репликами Always On для ввода-вывода с низкой задержкой и быстрого переключения при сбое) и Hyperscale (архитектура с журнальной структурой, страничными серверами и распределенным хранилищем для масштабирования до многих терабайт и быстрых операций на основе моментальных снимков). Уровень Serverless для General Purpose автоматически масштабирует вычислительные ресурсы в пределах настроенного минимума и максимума и может автоматически приостанавливаться в периоды простоя; вы платите за секунды вычислений и за хранилище. Это хорошо подходит для прерывистых рабочих нагрузок или сред разработки, но при возобновлении работы сталкивается с холодным стартом и прогревом кэша.

Эластичные пулы (Elastic pools) позволяют нескольким базам данных совместно использовать вычислительный бюджет и резерв по вводу-выводу, сглаживая пиковые нагрузки и снижая затраты для множества небольших баз данных с переменной нагрузкой. Пулы существуют как в модели DTU, так и в vCore; правильный подбор размера требует понимания совокупной конкуренции и лимитов пиковой нагрузки для каждой базы данных, чтобы избежать эффекта «шумного соседа».

Шаблоны отказоустойчивости Azure SQL включают активную георепликацию и группы автоматической отработки отказа (auto-failover groups). Активная георепликация асинхронно поддерживает до четырех вторичных баз данных, доступных для чтения, в любом регионе Azure, при этом отработка отказа инициируется для каждой базы данных отдельно. Группы автоматической отработки отказа управляют несколькими базами данных как единым целым на парных логических серверах, предоставляют конечные точки прослушивателя для чтения/записи и только для чтения, а также обрабатывают плановое или внеплановое переключение с настраиваемыми льготными периодами — идеальное решение для многопользовательских SaaS-приложений. Избыточность между зонами (Zone redundancy) доступна на уровнях Business Critical (и Hyperscale) для охвата нескольких зон доступности (Availability Zones) в пределах одного региона, что повышает отказоустойчивость внутри региона.

Azure SQL Managed Instance (MI) нацелен на почти 100% совместимость с SQL Server (SQL Agent, межобъектные запросы, Linked Servers, CLR, Service Broker). Он работает внутри вашей виртуальной сети в выделенной, делегированной подсети (Microsoft.Sql/managedInstances). Экземпляры используют только частные IP-адреса; настройте группы безопасности сети и таблицы маршрутизации, чтобы разрешить трафик управления к плоскостям управления Azure и трафик данных к вашим приложениям. Интегрируйте с Azure Private DNS (или пользовательским DNS), чтобы клиенты могли разрешать частное FQDN управляемого экземпляра. Для гибридного подключения и миграции обеспечьте прямую видимость через VPN типа «сеть-сеть» или ExpressRoute. Пути миграции включают нативное резервное копирование/восстановление в Azure Blob Storage (WITH COPY_ONLY, WITH MOVE), онлайн- или офлайн-миграции с использованием Azure Database Migration Service (DMS), а также транзакционную репликацию или доставку журналов, где это уместно. Уровень Business Critical для MI добавляет хранилище с низкой задержкой и высокую доступность; General Purpose предлагает экономичное хранилище с удаленными дисками.

Azure Database for PostgreSQL и MySQL Flexible Server предоставляют детальный контроль над окнами обслуживания, возможность остановки/запуска для экономии средств и сетевую изоляцию через интеграцию с VNet. Варианты высокой доступности включают синхронный резервный экземпляр в той же зоне для максимально быстрого переключения и высокую доступность с избыточностью между зонами для устойчивости к сбоям на уровне зоны (синхронная репликация с автоматическим переключением). Реплики чтения (в том же регионе и, для многих версий, между регионами) снимают нагрузку по чтению и поддерживают аналитику в режиме, близком к реальному времени; они асинхронны и не подходят для строго согласованного чтения. Выбирайте уровни вычислений и хранения на основе целевых показателей IOPS/задержки и спланируйте обработку переключения соединений в клиентских библиотеках.

Нереляционные и глобально распределённые хранилища

Azure Cosmos DB — это полностью управляемая, мультимодельная, глобально распределённая база данных с глобальной репликацией «под ключ», обеспечивающая чтение и запись с задержкой в несколько миллисекунд на 99-м перцентиле. Выбирайте API в зависимости от экосистемы и модели данных: Core (SQL) API для документов и SQL-подобных запросов с обширной поддержкой SDK; MongoDB API для совместимости с протоколом Mongo; Cassandra API для ширококолоночных нагрузок; Gremlin API для обхода графов; и Table API для сценариев «ключ-атрибут». Пропускная способность выделяется в единицах запросов (request units, RUs) в режимах с фиксированной или автоматической масштабируемостью; проектируйте секции и индексацию так, чтобы минимизировать потребление RU.

Секционирование (partitioning) имеет фундаментальное значение. Выбирайте ключ секционирования с высокой кардинальностью, который равномерно распределяет хранилище и трафик, позволяет избежать «горячих» секций и соответствует вашим шаблонам доступа (например, tenantId или userId для многопользовательских записей, или синтетический составной ключ для балансировки чтений). Логические секции ограничены по размеру и пропускной способности; моделируйте так, чтобы «горячие» рабочие наборы данных оставались распределёнными. Ключ секционирования контейнера нельзя изменить после его создания; миграция требует создания новых контейнеров и перемещения данных.

Cosmos DB предлагает пять настраиваемых уровней согласованности: строгая (Strong) (линеаризуемая, самые высокие RU/задержка), с ограниченным устареванием (Bounded Staleness) (предсказуемая задержка или окно версий), сеансовая (Session) (клиент-центричная, «чтение собственных записей», популярный вариант по умолчанию), с согласованным префиксом (Consistent Prefix) (чтения не нарушают порядок) и итоговая (Eventual) (максимальная доступность и производительность с возможными аномалиями). Выбирайте уровень по умолчанию для учётной записи и при необходимости переопределяйте его для каждого запроса. Запись в несколько регионов (multi-region writes) обеспечивает настоящую мультимастер-архитектуру для глобальных записей с низкой задержкой и повышенной доступности; для разрешения конфликтов используйте механизм «побеждает последняя запись» (Last-Writer-Wins) (по указанному свойству), пользовательские политики или логику приложения с хранимыми процедурами и каналом конфликтов (conflict feed).

При выборе подходящего хранилища данных сопоставляйте требования с возможностями. Строгая реляционная целостность, сложные соединения и транзакционные гарантии говорят в пользу Azure SQL Database или Managed Instance. Массивный глобальный масштаб, гибкая схема и геораспределённый доступ с низкой задержкой — в пользу Cosmos DB. Графовые задачи (социальные сети, рекомендации, топология сети) соответствуют Gremlin API в Cosmos DB или графовым функциям в Azure SQL, когда важна реляционная колокация. Интенсивный приём телеметрии временных рядов, ad hoc-исследования и аналитика в почти реальном времени соответствуют Azure Data Explorer. Неструктурированные BLOB-объекты, медиафайлы и большие двоичные данные следует хранить в Azure Blob Storage или ADLS Gen2, а метаданные — в дополняющей их базе данных.

Объектные и аналитические хранилища

Azure Blob Storage — это основа для неструктурированных данных. Уровни доступа (access tiers) соотносят стоимость хранения с шаблонами доступа: «горячий» (Hot) для часто используемых данных, «холодный» (Cool) для редко используемых данных с минимальным сроком хранения 30 дней и «архивный» (Archive) для долгосрочного холодного хранения с минимальным сроком 180 дней и временем извлечения в несколько часов. Учётные записи Premium для блочных BLOB-объектов на SSD обеспечивают низкую задержку и высокую производительность для транзакционных нагрузок, таких как конвейеры приёма данных. Политики управления жизненным циклом автоматизируют переходы между уровнями и удаление на основе правил — времени последнего изменения, тегов индекса BLOB-объектов или префиксов, — снижая затраты без ручного вмешательства.

Репликация объектов для блочных BLOB-объектов асинхронно зеркалирует объекты и их версии между учётными записями хранения (в одном или разных регионах). Она требует включения версионирования BLOB-объектов на источнике и в месте назначения и управляется политиками для каждой пары контейнеров, обеспечивая соответствие требованиям и многорегиональное распределение, сохраняя при этом независимость от выбора избыточности на уровне учётной записи. Неизменяемость (WORM) может быть принудительно установлена на уровне контейнера или BLOB-объекта с помощью политик хранения на основе времени и юридических удержаний (legal holds), с опциями вроде allowProtectedAppendWrites для журналов, работающих только в режиме добавления. Неизменяемость на уровне версий защищает прошлые состояния от подделки и программ-вымогателей.

Azure Data Lake Storage Gen2 добавляет к Blob Storage иерархическое пространство имён, обеспечивая настоящие каталоги, атомарные операции переименования и оптимизированные файловые операции. Детализированные POSIX-подобные списки контроля доступа (ACL) управляют доступом на уровне каталогов и файлов, используя списки ACL для доступа (Access ACLs) и по умолчанию (Default ACLs), и оцениваются вместе с Azure RBAC. Аутентификация с помощью Azure AD и OAuth2 обеспечивает принцип наименьших привилегий и возможность аудита. Интеграция с аналитическими службами является нативной: Azure Synapse Analytics и Azure Databricks получают доступ к ADLS Gen2 через драйвер ABFS с масштабируемой пропускной способностью, в то время как сервисы, такие как Azure Data Factory, Azure Purview и Azure Machine Learning, интегрируются для оркестрации, управления данными и обучения моделей. Проектируйте структуры папок и наследование ACL для изоляции доменов и поддержки управления доступом для нескольких команд, а также используйте такие функции, как канал изменений (change feed) и обратимое удаление (soft delete) для отслеживания происхождения данных и их восстановления.

Кэширование и ускорение производительности

Azure Cache for Redis обеспечивает доступ к данным с задержкой менее миллисекунды, механизм публикации/подписки (pub/sub) и распределённые блокировки. Уровни (tiers) соответствуют потребностям в доступности и масштабе. Basic — это один узел для разработки/тестирования. Standard добавляет двухузловую конфигурацию «основной/реплика» с автоматическим переключением при сбое. Premium вводит кластеризацию по шардам, персистентность (снимки RDB и AOF), поддержку VNet и георепликацию в топологии «активный-пассивный». Enterprise и Enterprise Flash (Redis Enterprise) добавляют георепликацию Active-Active с использованием CRDT для записей в несколько регионов, большие объёмы памяти, многопоточную производительность и поддержку модулей; Flash дополняет DRAM накопителями NVMe для создания огромных кэшей по более низкой цене. Выбирайте политику вытеснения (eviction policy) в соответствии с TTL ключей и нагрузкой: allkeys-lru/allkeys-random, когда не у всех ключей есть TTL; volatile-lru/volatile-ttl, когда вытесняться должны только ключи с истекающим сроком жизни; и noeviction, когда сбои записи предпочтительнее вытеснения. Персистентность снижает потерю данных при сбое за счёт накладных расходов на ввод-вывод и задержку; включайте её только при необходимости и настраивайте интервалы создания снимков.

Интегрируйте Redis в качестве кэша с отложенной загрузкой (aside cache) для результатов запросов к базе данных, состояния сеансов и счётчиков ограничения скорости. Обеспечьте идемпотентное заполнение, применяйте подходящие TTL и реализуйте прерыватели цепи (circuit breakers). Для кластеризованных кэшей детерминированно шардируйте ключи; для Enterprise Active-Active тестируйте семантику разрешения конфликтов.

Шаблоны безопасности, доступа и отказоустойчивости

Делегирование доступа к Azure Storage использует токены и политики SAS. SAS службы предоставляет ограниченный доступ к конкретному ресурсу (контейнеру, BLOB-объекту, файловому ресурсу, очереди или таблице). SAS учетной записи охватывает несколько служб в учетной записи и является мощным инструментом; защищайте его тщательно. SAS с делегированием пользователя (только для службы BLOB-объектов) создается на основе Azure AD и ключа делегирования пользователя, что позволяет управлять доступом на уровне отдельных пользователей без использования ключей учетной записи — это идеальное решение для многопользовательских приложений и предоставления краткосрочного доступа. Сохраненные политики доступа (для контейнеров, общих папок, очередей и таблиц) привязывают токены SAS к политике на стороне сервера, что позволяет отозвать или сократить доступ без ротации ключей учетной записи; SAS без сохраненной политики доступа можно отозвать только по истечении срока действия токена или путем ротации ключей.

Для шифрования Azure Storage по умолчанию использует шифрование на стороне службы. Ключи, управляемые клиентом (CMK), хранящиеся в Azure Key Vault или Managed HSM, обеспечивают централизованный контроль над жизненным циклом ключей и возможность аудита. Области шифрования позволяют использовать разные CMK в одной и той же учетной записи хранения для разных контейнеров или префиксов, поддерживая шифрование для каждого клиента. Для контроля шифрования на уровне отдельных BLOB-объектов со стороны клиента можно предоставлять ключи, предоставляемые клиентом (CPK), в запросах. При необходимости комбинируйте CMK на уровне учетной записи или области с CPK для обеспечения изоляции в соответствии с нормативными требованиями.

Безопасность и отказоустойчивость Azure SQL основаны на уже описанных уровнях платформы и функциях репликации. Используйте группы автоматической отработки отказа для скоординированного межрегионального переключения и выделенных конечных точек прослушивателя, а также включайте избыточность в пределах зоны, где это возможно, для защиты от сбоев на уровне зоны. Для конфиденциальных данных применяйте динамическое маскирование данных, чтобы скрывать PII в результатах запросов для непривилегированных пользователей, и рассмотрите возможность использования Always Encrypted с безопасными анклавами для защиты столбцов на стороне клиента, когда администраторам необходимо запретить просмотр данных в открытом виде. Отслеживайте целевые показатели RPO/RTO в соответствии с поведением репликации вашего уровня и регулярно тестируйте отработку отказа.

При планировании комплексных архитектур унифицируйте управление удостоверениями (Azure AD для SQL, хранилища и аналитики), применяйте принцип наименьших привилегий с помощью RBAC и ACL, используйте Private Link или интеграцию с VNet, чтобы изолировать данные от общедоступного интернета, и реализуйте политики жизненного цикла, неизменяемости и репликации для достижения целей по хранению данных и аварийному восстановлению.

Практический сценарий

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

Разместите транзакционные базы данных каталога и заказов в Azure SQL Database, используя модель vCore:

Выбор уровня: Business Critical для заказов (хранилище с низкой задержкой и быстрая отработка отказа) и General Purpose serverless для каталога (всплески трафика с периодами простоя).
Почему: Модель vCore обеспечивает предсказуемое определение размера и использование Hybrid Benefit; уровень Business Critical соответствует требованиям к задержке/высокой доступности для заказов; бессерверная модель минимизирует затраты на вычисления во время низкой активности.

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

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

Храните изображения и видео продуктов в Azure Blob Storage (general-purpose v2) с управлением жизненным циклом и репликацией объектов:

Политика: Уровень Hot для активных элементов, Cool через 30 дней, Archive через 180 дней; репликация во вторичный регион с помощью репликации объектов.
Почему: Минимизирует затраты на хранение с течением времени, обеспечивая асинхронное региональное распределение независимо от избыточности учетной записи; соответствует требованиям к хранению с неизменяемостью для юридических активов (WORM на основе времени).

Создайте сервис профилей клиентов и корзины покупок на Azure Cosmos DB (Core API) с записью в несколько регионов и согласованностью на уровне сеанса:

Дизайн: Секционирование по userId для распределения записей; включение автомасштабирования RU.
Почему: Архитектура с несколькими основными репликами обеспечивает низкую задержку записи для глобальной аудитории и высокую доступность; согласованность на уровне сеанса гарантирует чтение собственных записей для каждого пользователя с высоким качеством UX и эффективным использованием RU.

Внедрите Azure Cache for Redis Enterprise для хранения состояния сеансов, кэширования сведений о продуктах и ограничения скорости запросов:

Режим: Кластеризация с георепликацией Active-Active для записи в несколько регионов.
Почему: Доступ за доли миллисекунды и разрешение конфликтов на основе CRDT поддерживают согласованность сеансов и счетчиков между регионами без единой основной реплики для записи.

Сохраняйте потоки кликов и операционные журналы в Azure Data Lake Storage Gen2 с иерархическим пространством имен и ACL в стиле POSIX:

Интеграция: Потоковая передача данных записывает их в курируемые папки; Databricks и Synapse читают данные через ABFS; включите канал изменений и обратимое удаление.
Почему: Детальные ACL на уровне каталогов/файлов поддерживают управление доступом для нескольких команд; иерархическое пространство имен оптимизирует операции с файлами; нативная интеграция с аналитическими службами сокращает время до получения ценной информации.

Используйте Azure Database for PostgreSQL Flexible Server для микросервиса рекомендаций:

Высокая доступность: Синхронный резервный экземпляр с избыточностью в пределах зоны; подготовьте реплики для чтения для экспериментов с новыми функциями.
Почему: Богатая экосистема расширений Postgres и возможности JSONB подходят для этого сервиса; управляемая высокая доступность снижает RTO; реплики снимают нагрузку чтения.

Обеспечьте безопасность доступа с помощью SAS с делегированием пользователя для временной загрузки медиафайлов и CMK с областями шифрования для каждого клиента:

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

Перенесите устаревшие данные о заказах из локального SQL Server в Управляемый экземпляр Azure SQL для архивной обработки и выполнения задач, управляемых агентом:

Шаги: Оцените с помощью Data Migration Assistant; выполните онлайн-миграцию через DMS; подключитесь по ExpressRoute.
Почему: MI сохраняет задания Агента SQL и межбазовые операции, упрощая модернизацию и размещая архивные рабочие нагрузки рядом с облачными данными.

Этот дизайн обеспечивает глобальную производительность за счет записи в несколько регионов в Cosmos DB и Redis Enterprise, обеспечивает управление с помощью ACL в ADLS Gen2 и неизменяемости в Storage, гарантирует транзакционную целостность и быструю отработку отказа с помощью уровней Azure SQL и групп автоматической отработки отказа, а также оптимизирует затраты за счет бессерверных вычислений и политик жизненного цикла.

← Идентификация · Все домены · Вычислительные ресурсы и архитектура приложений →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →