Microsoft AZ-204: Кэширование, CDN и производительность в Azure — Руководство по подготовке

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

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

Обзор

Быстрая и надежная работа пользователей в Azure зависит от размещения контента и состояния ближе к пользователям, минимизации нагрузки на источник и корректной обработки сбоев. Azure Cache for Redis, Azure CDN и Azure Front Door вместе обеспечивают ускорение в памяти, кэширование на границе сети и глобальную anycast-маршрутизацию с обеспечением безопасности. Освоение структур данных Redis и шаблонов подключения, семантики профилей и кэширования CDN, а также маршрутизации и проб работоспособности Front Door позволяет проектировать устойчивые приложения с низкой задержкой.

Azure Cache for Redis: уровни, структуры данных, вытеснение и шаблоны

Azure Cache for Redis — это управляемый сервис Redis, который обеспечивает доступ к данным с задержкой менее миллисекунды, поддерживая распространенные структуры данных Redis и расширенные возможности на более высоких уровнях.

Уровни:

• Basic: Одноузловой кэш без SLA и репликации данных. Подходит для разработки/тестирования и некритичных нагрузок. Без сохранения данных, кластеризации и интеграции с VNet.
• Standard: Двухузловой (основной/реплика) с автоматическим переключением при сбое и SLA. Подходит для производственной среды. Поддерживает вертикальное масштабирование с минимальными перебоями, но без кластеризации и сохранения данных.
• Premium: Более высокая производительность и пропускная способность, большие размеры кэша, сохранение данных Redis (RDB и AOF), кластеризация (шардинг) для горизонтального масштабирования, интеграция с виртуальной сетью, избыточность между зонами (в поддерживаемых регионах) и георепликация для аварийного восстановления (DR). Также поддерживает окна для планового применения исправлений и расширенную безопасность.

Структуры данных и когда их использовать:

• Strings: Базовые пары ключ-значение, счетчики, JSON-объекты; атомарные операции INCR/DECR для ограничения скорости и счетчиков.
• Hashes: Хранение полей объекта (например, профиля пользователя) в одном ключе с парами поле-значение для частичных обновлений и эффективного использования пространства.
• Lists: Очереди или стеки, упорядоченные по времени добавления; используйте с LPUSH/BRPOP для простых очередей задач.
• Sets: Уникальные коллекции; используйте для тегов, проверки принадлежности, нахождения пересечений.
• Sorted Sets: Ранжирование с помощью очков (scores); идеально для таблиц лидеров и событий, упорядоченных по времени.
• Bitmaps/Bitfields: Компактное отслеживание булевых флагов и счетчиков по позициям.
• HyperLogLog: Приблизительный подсчет кардинальности (уникальных элементов) с фиксированным объемом памяти.
• Geospatial: Хранение и запрос координат (широта/долгота), поиск в радиусе.
• Streams: Журнал только для добавления (append-only) для приема событий и групп потребителей.

Политики вытеснения (применяются при достижении maxmemory):

• volatile-lru: Вытеснять наименее давно использовавшиеся ключи с установленным сроком действия (по умолчанию в Azure Cache for Redis).
• allkeys-lru: Вытеснять наименее давно использовавшиеся ключи независимо от срока действия.
• volatile-ttl: Вытеснять ключи с ближайшим временем истечения срока действия.
• volatile-random / allkeys-random: Вытеснять случайные ключи, ограниченные ключами с истекающим сроком действия или всеми ключами.
• noeviction: Не вытеснять; команды записи, которые добавляют данные, завершаются с ошибкой.
• volatile-lfu / allkeys-lfu: Варианты вытеснения наименее часто используемых ключей (для более новых версий Redis).

Выбирайте политику вытеснения в зависимости от критичности данных и шаблонов доступа. Для кэшей allkeys-lru или allkeys-lfu обеспечивают наилучший процент попаданий в кэш (hit rate). Для смешанных хранилищ с тщательно настроенными сроками действия volatile-ttl или volatile-lru могут учитывать установленные вами TTL.

Распространенные сценарии использования:

• Кэширование сеансов: Хранение состояния сеанса пользователя через IDistributedCache или ПО для управления сеансами. Делайте ключи короткими, используйте TTL, согласованный с тайм-аутом сеанса, и при необходимости включите привязку сеанса (session affinity) на границе сети.
• Кэширование вывода: Кэширование отрендеренных фрагментов страниц или полных ответов с ключами на основе маршрута и сегмента пользователей. Инвалидируйте при изменении контента с помощью версионирования ключей или явной команды DEL.
• Pub/Sub: Обмен сообщениями в близком к реальному времени для уведомлений или веерной инвалидации кэша. Используйте каналы для рассылки изменений нескольким подписчикам.
• Таблицы лидеров: Отсортированные наборы с очками (scores) для ранжирования; ZADD/ZREVRANGE для обновления и чтения топ-N; используйте вторичные отсортированные наборы для ранжирования по временным окнам.

Подключение к Azure Redis: строки подключения, StackExchange.Redis и отказоустойчивость

Конечные точки подключения и ключи доступны на портале Azure в разделе Access keys. Основная строка подключения включает хост, порт, TLS и пароль (например, contoso.redis.cache.windows.net:6380,password=…;ssl=True;abortConnect=False). В производственной среде всегда используйте TLS на порту 6380.

Рекомендации по использованию StackExchange.Redis:

• Используйте один долгоживущий экземпляр ConnectionMultiplexer на процесс. Он потокобезопасен и эффективно мультиплексирует запросы. Создайте его один раз, сохраните в статическом поле или DI-контейнере и используйте повторно.
• Параметры конфигурации: установите AbortOnConnectFail=false для устойчивости к облачным сбоям; установите ConnectRetry и ConnectTimeout для обработки временных проблем; SyncTimeout, настроенный под вашу нагрузку; KeepAlive для поддержания открытых соединений через NAT. Пример параметров в текстовом виде: ssl=True, abortConnect=False, connectRetry=5, connectTimeout=5000.
• Используйте асинхронные методы, чтобы избежать истощения пула потоков под нагрузкой. Методы IDatabase (StringGetAsync, HashSetAsync, SortedSetAddAsync) являются неблокирующими.
• Обрабатывайте события, связанные с отказоустойчивостью: подпишитесь на события ConnectionFailed, ConnectionRestored и ConfigurationChanged, чтобы логировать и отслеживать изменения топологии и отказы. StackExchange.Redis автоматически переопределяет основной узел при отработке отказа.
• Избегайте длительных Lua-скриптов и тяжелых транзакций; отдавайте предпочтение небольшим атомарным командам. Конвейерная обработка (pipelining) естественным образом происходит через мультиплексор; не объединяйте в пакеты слишком много команд, чтобы не вызывать тайм-ауты.
• Не повторяйте слепо неидемпотентные команды. Используйте идемпотентные шаблоны или очереди со сквозной записью для критически важных операций записи.
• Сериализация: храните компактные данные (например, в формате MessagePack), чтобы минимизировать сетевой трафик и использование памяти. Избегайте гигантских значений; предпочитайте хэши с доступом на уровне полей.
• Именование ключей: используйте префиксы с названием приложения/среды (prod:session:{userId}), чтобы избежать коллизий и упростить массовые операции и очистку.
• Безопасность: выполняйте ротацию ключей доступа, ограничивайте доступ через VNet (уровень Premium) и рассмотрите использование Private Link для частного доступа. Не устанавливайте для параметра “Allow access only via SSL” значение false в производственной среде.

Azure CDN: профили, конечные точки, источники, оптимизация и актуальность содержимого

Azure CDN кеширует статический контент в пограничных точках присутствия (POP), чтобы уменьшить задержку и нагрузку на источник. Профиль CDN группирует конечные точки и тарифный план/поставщика; конечная точка определяет пограничное имя хоста и подключается к одному или нескольким источникам.

Профили и конечные точки:

• Создайте одну или несколько конечных точек для каждого приложения или среды в рамках одного профиля. Каждая конечная точка имеет собственное пограничное имя хоста (например, app.azureedge.net), которое вы сопоставляете с личными доменами с помощью TLS.
• Используйте отдельные профили для изоляции биллинга или применения различных поставщиков/функций при необходимости.

Типы источников:

• Azure Blob Storage: Идеально подходит для статических веб-сайтов и больших медиафайлов. Включите функцию статического веб-сайта или сопоставьте с контейнером; убедитесь в правильности MIME-типов и заголовков кеширования.
• App Service: Используйте для динамического контента или REST API, где отдельные ответы могут быть кешированы. Настройте заголовок Host источника на имя хоста вашего приложения и обеспечьте использование HTTPS.
• Пользовательский источник: Любая публично доступная конечная точка HTTP(S), включая локальные ресурсы, доступные через публичный IP-адрес или обратный прокси-сервер.

Типы оптимизации (применяются при создании конечной точки):

• Общая доставка веб-содержимого: Сбалансированный вариант для множества малых/средних ресурсов (HTML, CSS, JS, изображения) с широким покрытием POP.
• Скачивание больших файлов: Оптимизировано для больших файлов с настройкой запросов диапазона, управлением соединениями и параметрами, ориентированными на пропускную способность.
• Потоковое видео: Оптимизировано для прогрессивной загрузки или доставки сегментов HLS/DASH, обеспечивая эффективное кеширование сегментов и обработку запросов на получение части файла (byte-range requests).

Правила кеширования и очистка:

• Глобальные и пользовательские правила кеширования позволяют управлять TTL на основе пути, расширения файла, метода запроса и поведения строки запроса. На уровнях Standard правила настраиваются в параметрах кеширования конечной точки; на уровне Premium добавляются продвинутые механизмы правил.
• Очищайте недействительный контент по пути с использованием подстановочных знаков (например, /images/*) через портал, CLI или REST API. Очистка распространяется по всем POP; используйте целевые очистки, чтобы минимизировать радиус поражения. Уровни Premium поддерживают предварительную загрузку для прогрева кешей.

Элементы управления актуальностью содержимого:

• TTL: По умолчанию CDN учитывает заголовки Cache-Control и Expires от источника. Вы можете переопределить или установить минимальные/максимальные значения TTL с помощью правил. Для неизменяемых ресурсов используйте заголовок Cache-Control: public,max-age=31536000,immutable, чтобы максимизировать коэффициент попаданий в кеш.
• Директивы Cache-Control: no-store и private не кешируются CDN; must-revalidate и s-maxage позволяют детально управлять общим кешем. Предпочитайте s-maxage для TTL, специфичных для CDN, сохраняя консервативное значение max-age для браузеров.
• Поведение кеширования строк запроса: выберите игнорирование строк запроса (один кешированный объект на путь), кеширование каждого уникального URL (каждая комбинация строк запроса кешируется отдельно) или обход кеша при наличии строки запроса. Для версионированных ресурсов (например, app.css?v=hash) кешируйте каждый уникальный URL. Для параметров аналитики (utm_) игнорируйте строки запроса, чтобы повысить коэффициент попаданий в кеш.
• Vary и сжатие: При использовании сжатия убедитесь, что установлен заголовок Vary: Accept-Encoding; CDN будет кешировать отдельные варианты для каждого ключа Vary. Включите сжатие в CDN для текстовых ресурсов, чтобы уменьшить использование пропускной способности.

Azure Front Door: глобальная маршрутизация, работоспособность, безопасность и привязка сеансов

Azure Front Door обеспечивает глобальную балансировку нагрузки на 7-м уровне на основе anycast, динамическое ускорение сайтов и встроенный WAF. Он дополняет CDN, маршрутизируя и защищая динамический трафик, а также опционально кэшируя статический контент в версиях Standard/Premium.

Правила маршрутизации:

• Сопоставляют входящие имена хостов и шаблоны путей и направляют трафик в группу источников (пул бэкендов). Для каждого правила можно применять перезапись путей, преобразование заголовков, перенаправления и настройки протоколов.
• Настраивайте кэширование на уровне маршрута (в версиях Standard/Premium) для кэширования статических или полустатических ресурсов на границе сети, когда требуется более точный контроль на периферии приложения.
• Используйте отказоустойчивость на основе приоритетов и взвешенную балансировку нагрузки между источниками, опционально с геофильтрацией для маршрутизации в конкретные регионы.

Пробы работоспособности и состояние бэкенда:

• Определите путь для пробы, протокол, интервал и ожидаемые коды состояния HTTP. Пробы запускаются из нескольких пограничных расположений для определения работоспособности источника.
• Front Door использует информацию о работоспособности для направления трафика к исправным источникам с низкой задержкой. Настройте тайм-ауты и размер выборки, чтобы избежать флаппинга (частых переключений состояния); убедитесь, что конечная точка для проб является легковесной и не кэшируется.

Интеграция с WAF:

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

Привязка сеансов:

• Включайте привязку сеансов, когда вашему приложению требуется, чтобы последовательные запросы попадали на один и тот же бэкенд (например, при нераспределенном состоянии сеанса). Front Door внедряет cookie-файл привязки и направляет последующие запросы в рамках того же сеанса на выбранный бэкенд в соответствии с правилом маршрутизации.
• По возможности отдавайте предпочтение stateless-архитектурам или хранению состояния сеанса в Redis, чтобы избежать привязки; если привязка все же используется, тщательно определите ее область действия и установите соответствующие значения TTL для cookie-файлов.

Взаимодействие с CDN:

• CDN должен обслуживать статические ресурсы (изображения, скрипты, медиафайлы) с длительным TTL; Front Door маршрутизирует динамические запросы, применяя WAF, терминирование TLS и маршрутизацию на основе путей. Такое разделение максимизирует процент попаданий в кэш и минимизирует задержку для динамического контента.
• Для API или страниц, которые нельзя кэшировать, устанавливайте низкий TTL или обходите кэширование; для полустатического HTML рассмотрите использование коротких TTL с рабочими процессами очистки кэша при изменениях.

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

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

1. Front Door для глобальной точки входа и безопасности

• Создайте профиль Front Door Standard с пользовательским доменом и управляемым TLS. Определите правила маршрутизации: /api/* — в группу источников с API на App Service, а /* — на имя хоста конечной точки CDN.
• Почему: Anycast-маршрутизация направляет пользователей к ближайшей пограничной точке; WAF на Front Door блокирует вредоносные шаблоны до того, как они достигнут источников; маршрутизация на основе путей четко разделяет динамический и статический трафик.

2. Политика WAF и ограничение частоты запросов

• Прикрепите политику WAF с включенными управляемыми наборами правил и добавьте пользовательское правило для ограничения чрезмерного количества POST-запросов к /api/search.
• Почему: Это защищает API от атак класса OWASP и вредоносных клиентов, сохраняя ресурсы источников во время всплесков трафика.

3. Пробы работоспособности и группы источников

• Настройте группу источников API с двумя экземплярами App Service в разных регионах. Используйте пробы работоспособности для пути /healthz с ожидаемым статусом 200 и интервалом в 10 секунд. Установите для одного региона приоритет 1, а для другого — приоритет 2 для обеспечения отказоустойчивости (failover).
• Почему: Это обеспечивает автоматическое переключение на другой регион в случае сбоя основного; пробы определяют работоспособность независимо от кэшированных ответов.

4. Хранение сеансов в Redis и кэширование вывода

• Разверните Azure Cache for Redis Standard и интегрируйте API с IDistributedCache для хранения минимального состояния сеанса и краткоживущих фрагментов вывода для частых ответов API (например, списков популярных дополнений) с TTL от 60 до 300 секунд.
• Почему: Это снижает задержку API и нагрузку на базу данных, вынося состояние за пределы веб-уровня; короткие TTL поддерживают актуальность данных без необходимости ручной инвалидации.

5. Структуры данных Redis для таблиц лидеров

• Используйте отсортированное множество (sorted set) в Redis для каждой категории (например, addons:top:{category}) для ведения рейтингов на основе скачиваний. Обновляйте счетчики асинхронно через потребителя очереди и предоставьте API для чтения топ-N записей.
• Почему: Отсортированные множества обеспечивают обновления за O(log n) и быстрое чтение диапазонов, что идеально подходит для рейтингов в реальном времени с высокой конкуренцией при чтении.

6. Устойчивость соединений с помощью StackExchange.Redis

• Инициализируйте одиночный экземпляр (singleton) ConnectionMultiplexer с параметрами ssl=True, abortConnect=False, connectRetry=5 и разумными тайм-аутами. Обрабатывайте события ConnectionFailed/Restored для наблюдаемости и установите SyncTimeout достаточно высоким для обработки всплесков нагрузки при использовании асинхронных API.
• Почему: Это обеспечивает плавную обработку отказов и предотвращает сбои всего процесса во время кратковременных сетевых проблем или переключений Redis.

7. CDN для статических ресурсов с агрессивным кэшированием

• Создайте профиль и конечную точку Azure CDN, оптимизированные для общей доставки веб-содержимого (General web delivery), используя статический веб-сайт в учетной записи хранения в качестве источника. Настройте правила кэширования так, чтобы они учитывали заголовки источника, но переопределите TTL на 7 дней для /static/* и включите сжатие. Установите для кэширования строк запроса значение «Кэшировать каждый уникальный URL» (Cache every unique URL) и используйте отпечатки (fingerprinting) для ресурсов (app.css?v=hash).
• Почему: Кэширование на границе сети обеспечивает быструю доставку ресурсов по всему миру; использование отпечатков позволяет устанавливать длительные TTL с мгновенным обновлением при развертывании; сжатие уменьшает размер передаваемых данных.

8. Процесс очистки кэша в CI/CD

• Добавьте в процесс развертывания шаг, который при релизе очищает кэш CDN для путей к HTML и JSON-манифестам (например, /index.html, /manifest/*.json) и предварительно загружает критически важные страницы для «прогрева» кэша в поддерживаемых версиях.
• Почему: Это гарантирует, что пользователи быстро получат свежий HTML, в то время как неизменяемые ресурсы останутся в кэше; предварительная загрузка снижает задержку холодного старта после развертывания.

9. Привязка сеансов в Front Door только там, где это необходимо

• Оставляйте API без сохранения состояния (stateless) и используйте Redis для хранения состояния сеанса; отключите привязку сеансов в Front Door для маршрутов /api/. Для устаревшего инструмента администрирования, требующего привязки, включите ее для /admin/ с коротким TTL.
• Почему: Это максимизирует распределение нагрузки и кэшируемость для большинства пользователей, ограничивая привязку сеансов минимально необходимой областью.

Эта архитектура использует Front Door для безопасной, интеллектуальной маршрутизации на границе сети и WAF, Azure CDN для доставки статического контента с высоким процентом попадания в кэш и точным контролем актуальности, а также Azure Cache for Redis для разгрузки от частых операций чтения, поддержания данных сеансов и таблиц лидеров с низкой задержкой и плавной обработки всплесков нагрузки.

← Решения Azure для событий и сообщений · Все домены · Мониторинг →

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

Просмотреть Microsoft →