Microsoft AZ-204: Azure Storage и хранилище BLOB-объектов — Руководство по подготовке

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

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

Обзор

Azure Storage предоставляет надёжное, хорошо масштабируемое облачное хранилище для неструктурированных и структурированных данных. При разработке приложений важно сосредоточиться на выборе правильного типа учётной записи хранения, настройке избыточности для достижения целевых показателей RTO/RPO, выборе подходящего типа BLOB-объектов и уровня доступа для оптимизации затрат/производительности, а также на обеспечении безопасности доступа с помощью Azure AD и SAS. Используйте политики жизненного цикла для автоматизации перемещения данных между уровнями, размещайте статические веб-сайты непосредственно в хранилище BLOB-объектов, когда это целесообразно, и применяйте Azure Files и Queue Storage там, где требуется семантика файлового доступа или асинхронное взаимодействие на основе сообщений.

Типы учётных записей хранения и основы избыточности

General-purpose v2 (GPv2) — это стандартный тип учётной записи для большинства рабочих нагрузок. Он поддерживает BLOB-объекты, файлы, очереди и таблицы, все уровни доступа, управление жизненным циклом и новейшие функции. Устаревшие учётные записи BlobStorage предоставляют только службу BLOB-объектов и уровни доступа, но не обладают таким же набором функций и возможностей оптимизации затрат, как GPv2; в новых развёртываниях следует отдавать предпочтение GPv2. Учётные записи FileStorage — это премиальные учётные записи на базе SSD, предназначенные для Azure Files и обеспечивающие стабильно низкую задержку, высокое число IOPS и пропускную способность для корпоративных файловых нагрузок (например, общие папки профилей, бизнес-приложения). Выбирайте FileStorage, когда вам требуется премиальная производительность для общих ресурсов SMB/NFS; в остальных случаях по умолчанию используется GPv2.

Выбор типа избыточности определяет долговечность и доступность данных в разных доменах сбоя:

LRS (Locally Redundant Storage) синхронно хранит три копии в одном центре обработки данных. Самая низкая стоимость, без защиты на уровне зоны или региона. Используйте для разработки/тестирования, эфемерных нагрузок или при наличии репликации на более высоком уровне.
ZRS (Zone-Redundant Storage) синхронно реплицирует данные между зонами доступности в одном регионе, защищая от сбоя зоны с высокой доступностью и нулевым RPO. Выбирайте для производственных сред в регионах с зонами доступности, где требуется устойчивость в пределах региона.
GRS (Geo-Redundant Storage) хранит три синхронные копии в основном регионе (как LRS) и асинхронно реплицирует их во вторичный парный регион (где используется LRS). Типичный RPO составляет менее 15 минут; вторичный регион по умолчанию недоступен для чтения. Выбирайте для аварийного восстановления, когда доступ на чтение не требуется.
RA-GRS (Read-Access Geo-Redundant Storage) добавляет доступ на чтение ко вторичному региону через конечные точки с суффиксом -secondary. Используйте, когда вам требуется устойчивость к сбоям между регионами и для нагрузок с преобладанием чтения во время инцидентов в основном регионе, или для чтения из географически близкого расположения, где допустима согласованность в конечном счёте.

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

Модель данных BLOB-объектов, уровни доступа и управление жизненным циклом

Существует три типа BLOB-объектов с различной семантикой. Блочные BLOB-объекты (Block blobs) оптимизированы для потоковой передачи и произвольного чтения больших объектов, таких как изображения, видео и резервные копии. Загружаемые данные разбиваются на блоки, которые затем фиксируются, что позволяет выполнять параллельные загрузки и эффективные повторные попытки. Дополняемые BLOB-объекты (Append blobs) оптимизированы для нагрузок, требующих только добавления данных, таких как сбор телеметрии и журналов; разрешены только операции добавления, что упрощает управление параллелизмом. Страничные BLOB-объекты (Page blobs) предоставляют выровненные по 512 байт страницы для операций произвольного чтения/записи и лежат в основе виртуальных жёстких дисков Azure (VHD), используемых дисками виртуальных машин Azure; это единственный поддерживаемый тип BLOB-объектов для дисков IaaS и нагрузок с большим объёмом произвольного ввода-вывода.

Уровни доступа к BLOB-объектам управляют стоимостью и производительностью. Горячий (Hot) уровень оптимизирован для частого доступа, имеет самую низкую задержку чтения/записи и самую высокую стоимость хранения. Холодный (Cool) уровень предназначен для редко используемых данных, хранящихся не менее 30 дней, и имеет более низкую стоимость хранения, но более высокие затраты на транзакции/чтение и плату за минимальный срок хранения. Архивный (Archive) уровень — самый дешёвый уровень для долгосрочного хранения; объекты находятся в автономном режиме и перед чтением должны быть восстановлены (rehydrated) на горячий или холодный уровень. Восстановление можно запросить со стандартным или высоким приоритетом, выбирая между стоимостью и скоростью. Можно установить уровень доступа по умолчанию на уровне учётной записи (горячий или холодный) и переопределить его для каждого BLOB-объекта; архивный уровень задаётся только для отдельных объектов.

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

Перемещают BLOB-объекты или их версии/моментальные снимки на холодный или архивный уровень через N дней с момента последнего изменения
Удаляют BLOB-объекты, моментальные снимки или версии по истечении определённого срока
Фильтруют по префиксу контейнера и по тегам индекса BLOB-объектов для применения к определённым наборам данных (например, тег env=prod и policy=retention-7y) Сочетайте правила жизненного цикла с управлением версиями и обратимым удалением для защиты от случайных удалений, обеспечивая при этом соблюдение политик хранения. Помните, что архивный уровень имеет минимальный срок хранения и плату за досрочное удаление; разрабатывайте политики так, чтобы минимизировать ненужные восстановления.

Для отслеживания изменений и последующей обработки включите канал изменений (change feed) учётной записи хранения, чтобы получать упорядоченный, неизменяемый журнал операций создания, обновления, удаления и копирования BLOB-объектов. Это обеспечивает соответствие требованиям и поддержку асинхронных обработчиков, которым нужна семантика «ровно один раз» или «хотя бы один раз» с использованием контрольных точек.

Размещение статических веб-сайтов в хранилище BLOB-объектов предоставляет специальный контейнер $web, обслуживаемый через выделенную веб-конечную точку. Настройте индексный документ и документ об ошибке и публикуйте статические ресурсы напрямую. Конечная точка статического веб-сайта предоставляет анонимный доступ на чтение к содержимому сайта независимо от настройки публичного доступа к BLOB-объектам; доступ через конечную точку BLOB-объектов может оставаться отключённым. Для использования пользовательских доменов и глобального ускорения используйте Azure Front Door или Azure CDN перед конечной точкой. Частные конечные точки (Private endpoints) не поддерживаются для конечной точки статического веб-сайта; используйте пограничный сервис для обеспечения безопасности и ускорения доставки, где требуется частный доступ.

Основы Azure Files и Queue Storage

Azure Files предоставляет полностью управляемые общие файловые ресурсы SMB и опцию NFS для POSIX-сценариев. Используйте общие ресурсы SMB для миграций lift-and-shift и обеспечения совместимости приложений. Учетные записи хранения Premium FileStorage обеспечивают предсказуемую производительность с низкой задержкой, в то время как стандартные общие ресурсы экономичны для файловых данных общего назначения. Управляйте общими ресурсами и файлами через клиенты SMB или REST API/SDK. Azure File Sync позволяет создавать гибридные файловые службы, кэшируя облачный общий ресурс на Windows Server, что обеспечивает локальную производительность и перемещение холодных данных в облако, синхронизацию между несколькими площадками, а также резервное копирование и аварийное восстановление на удаленной площадке без традиционных циклов обновления NAS. Сочетайте идентификацию на основе Azure AD со списками ACL NTFS для обеспечения принципа наименьших привилегий и используйте Private Endpoints для ограничения риска утечки данных.

Azure Queue Storage позволяет создавать развязанные, отказоустойчивые рабочие процессы приложений. Каждое сообщение может иметь размер до 64 КБ (для более крупных данных следует ссылаться на URI blob-объектов). Время жизни сообщения (TTL) определяет его автоматическое истечение; укажите положительное значение от нескольких секунд до семи дней или -1 для отсутствия срока истечения. Когда рабочий процесс извлекает сообщение, оно становится невидимым на время своего тайм-аута видимости. Если обработка завершается неудачно и сообщение не удаляется до истечения тайм-аута, оно снова становится видимым для другого потребителя. Настраивайте тайм-аут видимости так, чтобы он превышал время обработки в худшем случае, и используйте идемпотентные обработчики вместе с экспоненциальной задержкой для уменьшения конфликтов. Отслеживайте счетчик извлечений из очереди для обнаружения отравленных сообщений; когда он превышает пороговое значение, перемещайте сообщение в специальную очередь отравленных сообщений для карантина и анализа. Триггеры очередей Azure Functions реализуют этот шаблон автоматически с очередью -poison. Для более высокой пропускной способности или потребностей в FIFO с гарантиями порядка рассмотрите очереди Service Bus; в противном случае Azure Queue Storage является простым и экономичным решением.

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

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

Создайте учетную запись хранения GPv2 с RA-GRS

Почему: GPv2 открывает доступ к службам Blob, Files и Queue с функциями управления жизненным циклом и распределения по уровням. RA-GRS обеспечивает устойчивость к сбоям в разных регионах и доступ на чтение к вторичным конечным точкам для непрерывности доступа к активам, которые в основном читаются, во время региональных инцидентов.

Включите хостинг статических веб-сайтов и разверните активы сайта в контейнер $web

Почему: Статические веб-сайты в Blob Storage устраняют необходимость в управлении веб-серверами, обеспечивают чтение с низкой задержкой с уровня Hot и масштабируются глобально. Позже можно интегрировать с Azure Front Door для использования пользовательских доменов, WAF и кэширования на границе сети.

Храните оригинальные RAW-изображения как блочные blob-объекты; телеметрию с однократной записью — как дополняемые blob-объекты

Почему: Блочные blob-объекты поддерживают большие параллельные загрузки и эффективную доставку оптимизированных для веба производных изображений. Дополняемые blob-объекты упрощают одновременную запись логов из конвейеров обработки без конфликтов.

Определите политики жизненного цикла для перемещения оригиналов на уровень Cool через 30 дней и в Archive через 180 дней; удаляйте версии старше одного года

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

Обеспечьте безопасность доступа к данным с помощью Azure AD и SAS с делегированием пользователя для партнеров

Почему: Назначьте роль Storage Blob Data Reader управляемому удостоверению в службе обмена, получите ключи делегирования пользователя и создавайте недолговечные SAS-токены только для HTTPS с ограничениями по IP. Это позволяет избежать распространения ключей учетной записи и привязывает авторизацию к Azure AD.

Включите ключи, управляемые клиентом (CMK), с помощью Key Vault и шифрования инфраструктуры

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

Интегрируйте Azure Queue Storage для фоновой обработки изображений с триггером очередей Azure Functions; установите тайм-аут видимости, превышающий максимальное время обработки, и настройте обработку отравленных сообщений

Почему: Очереди отделяют путь загрузки от вычислительных ресурсов. Тайм-аут видимости предотвращает дублирование работы, а среда выполнения Functions автоматически направляет неудачно обработанные элементы в очередь -poison для расследования.

Опубликуйте редакторские инструменты через Azure Files, используя учетную запись хранения Premium FileStorage и Azure File Sync на локальном Windows Server

Почему: Редакторы получают доступ по SMB с низкой задержкой с использованием списков ACL NTFS и аутентификации на основе удостоверений через AD, в то время как Azure File Sync обеспечивает локальное кэширование и перемещение данных в облако. Уровень Premium гарантирует стабильную производительность для интерактивных рабочих нагрузок.

Используйте Azure Front Door перед статическим веб-сайтом и включите кэширование и пользовательский HTTPS

Почему: Точки присутствия (POP) на границе сети снижают задержку по всему миру, пользовательские домены соответствуют требованиям брендинга, а WAF добавляет безопасность без изменения бэкенда хранилища.

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

Почему: Неизменяемый, упорядоченный журнал изменений blob-объектов поддерживает последующую аналитику, аудит и воспроизведение для создания воспроизводимых конвейеров обработки контента.

← Azure Functions и бессерверные вычисления · Все домены · Azure Cosmos DB →

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