Горячие разделы в Хранилище BLOB-объектов Azure: обнаружение, мониторинг и смягчение

Хранилище BLOB-объектов Azure распределяет данные по разделам для обеспечения масштабируемой производительности. Когда трафик сосредоточен на одном разделе, этот раздел может стать узким местом — состояние, известное как горячий раздел. В этой статье объясняется, что такое горячие разделы, как их распознавать через метрики Azure Monitor и журналы ресурсов, а также какие шаги можно предпринять для более равномерного распределения нагрузки и снижения ошибок троттлинга.

Понимание горячих разделов

Хранилище BLOB-объектов Azure автоматически распределяет данные между разделами для масштабирования производительности и пропускной способности. Когда один раздел получает значительно больше трафика, чем другие, он становится горячим разделом. Горячий раздел возникает, когда большое количество запросов на чтение, запись или обновление отправляется в один и тот же раздел, что ограничивает способность сервиса эффективно балансировать нагрузку. В результате запросы испытывают повышенную задержку, троттлинг и ошибки тайм-аута до тех пор, пока нагрузка не будет перераспределена или не оптимизируется паттерн доступа. Схемы разбивания или именований, концентрирующие трафик на небольшой подмножестве данных вместо распределения запросов между несколькими разделами, часто вызывают горячие разделы.

Симптомы и влияние горячих перегородок

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

Распространённые симптомы горячей перегородки включают:

  • HTTP 503 (Server Busy ) ответы, указывающие на то, что раздел временно не способен обрабатывать дополнительные запросы.
  • Ответы HTTP 500 (Operation Timeout) возникают, когда выполнение запросов занимает слишком много времени из-за высокой нагрузки на раздел.
  • Повышенная задержка запросов, даже для тех запросов, которые в итоге были успешны.
  • Автоматические повторные попытки со стороны клиента, которые могут ещё больше увеличить трафик и продлить проблемы с производительностью, если множество клиентов одновременно выполняют повторные попытки.
  • Сниженная пропускная способность, когда приложение обрабатывает меньше операций в секунду, чем ожидалось, несмотря на достаточную объёмную ёмкость аккаунта хранения.

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

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

Выявление ошибок регулирования с помощью метрик Azure Monitor и журналов ресурсов

служба хранилища Azure ограничивает запросы, когда нагрузка превышает целевую масштабируемость аккаунта хранения или раздела. Обычно ограничение скорости проявляется в виде ответов HTTP 503 (Server Busy) или 500 (Operation Timeout). Клиентские библиотеки служба хранилища Azure часто автоматически повторяют запросы, подвергшиеся троттлингу, поэтому мониторинг необходим для выявления троттлинга до того, как он начнёт существенно влиять на производительность приложения.

Используйте метрики Azure Monitor, чтобы выявить ошибки ограничения запросов

Чтобы обнаружить троттлинг, проанализируйте метрики в Azure Monitor для учетной записи хранения. Метрика Транзакций в сочетании с измерением ResponseType обеспечивает видимость результатов запросов на хранение и помогает выявлять сбои, связанные с троттлингом.

Метрики для выявления троттлинга

Следующие метрики Azure Monitor полезны при анализе троттлинга:

Metric Purpose
Транзакции Измеряет количество запросов, обрабатываемых сервисом хранения. Используйте параметр ResponseType, чтобы определить запросы, подвергшиеся ограничению.
Availability Показывает процент успешных запросов. Снижение доступности может указывать на троттлинг или другие сбои при выполнении запросов.
Задержка успешного выполнения E2E Измеряет сквозную задержку запросов, включая сетевую и клиентскую обработку. Увеличение может указывать на повторные попытки, вызванные троттлингом.
Серверная задержка успешного запроса Измеряет время, необходимое сервису хранения для обработки запросов. Сравнение этой метрики с задержкой E2E помогает отличить задержки на стороне сервиса от повторных попыток клиента.

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

Используйте измерение ResponseType для определения троттлинга

Измерение ResponseType — основной способ выявления ситуаций ограничения запросов в метриках Azure Monitor. К соответствующим значениям относятся:

значение ResponseType Описание
ServerBusyError Сервис хранения возвращал HTTP 503, потому что цель масштабируемости была превышена.
ClientThrottlingError Запрос был ограничен до того, как он достиг службы хранения.
ClientAccountRequestThrottlingError Лимиты запросов на уровне аккаунта были превышены.
ClientAccountBandwidthThrottlingError Лимиты пропускной способности аккаунта были превышены.
УспехС Троттлингом Первоначально запрос был ограничен, но в итоге был выполнен после повторных попыток.

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

Используйте размеры, чтобы точно определить источник троттлинга

Измерения метрик Azure Monitor могут помочь изолировать рабочую нагрузку, ответственную за троттлинг:

Dimension Purpose
ResponseType Определяет конкретное условие троттлинга или ошибки.
ApiName Определяет операцию, для которой применяется ограничение скорости, например PutBlob, GetBlob или ListBlobs.
GeoType Различает трафик к первичным и вторичным конечным точкам в георезервных аккаунтах хранения.
Аутентификация Помогает определить, связано ли ограничение с использованием определенного метода аутентификации.

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

Анализ журналов ресурсов Azure Monitor

Хотя метрики выявляют наличие троттлинга, журналы ресурсов Azure Monitor предоставляют данные на уровне запроса, которые могут помочь диагностировать коренную причину. Журналы ресурсов фиксируют как успешные, так и неудачные запросы, включая троттлинг, тайм-ауты, авторизацию и ошибки, связанные с сетью.

Для Хранилище BLOB-объектов Azure записи доступны в таблице StorageBlobLogs после отправки логов ресурсов в рабочее пространство Log Analytics.

Запрос в журналы ресурсов для событий троттлинга

Перед запуском этих запросов убедитесь, что логи ресурсов отправляются в рабочее пространство Log Analytics.

Используйте язык запросов Kusto (KQL), чтобы определить запросы, которые возвращают распространённые коды состояния, связанные с ограничением запросов:

StorageBlobLogs
| where StatusCode in (500, 503)
| summarize RequestCount = count() by OperationName, StatusCode, bin(TimeGenerated, 15m)
| order by TimeGenerated desc

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

Условия оповещения о дросселировании

Создание оповещений Azure Monitor для:

  • Постоянное возникновение транзакций ServerBusyError.
  • Увеличение значений ResponseType , связанных с троттлингом.
  • Снижение показателя доступности ниже приемлемого порога.
  • Увеличение задержки, коррелирующее с событиями троттлинга.
  • Резкие увеличения объема запросов, которые приближаются к пределам масштабируемости хранилища.
  1. Отслеживайте метрику транзакций и делите результаты по типу ответа.
  2. Обратите внимание на увеличение типов ответов, связанных с троттлингом, таких как ServerBusyError и ClientThrottlingError.
  3. Используйте параметр ApiName, чтобы определить затронутые операции.
  4. Сопоставьте события ограничения пропускной способности с изменениями доступности, сквозной задержки успешных запросов и серверной задержки успешных запросов.
  5. Используйте журналы ресурсов Azure Monitor, чтобы определить, какие запросы, операции или приложения генерируют ограниченный трафик.
  6. Настройте оповещения так, чтобы проблемы с троттлингом выявлялись до того, как они затронут пользователей.

Объединяя метрики, размеры и журналы ресурсов Azure Monitor, вы можете быстро выявить условия ограничения, выявить источник чрезмерного спроса и принять корректирующие меры до того, как производительность приложения снизится.

Минимизация горячих разделов

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

Используйте эффективные схемы разбиения и именования

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

Используйте экспоненциальный откат для повторных попыток

Если скорость обработки запросов ограничивается и запросы возвращают ошибки 503 (Server Busy) или 500 (Operation Timeout), повторяйте запросы, используя стратегию экспоненциальной задержки. Такой подход снижает нагрузку на затронутый раздел и даёт служба хранилища Azure время для восстановления нагрузки или восстановления после временных скачков спроса.

Поведение механизма повторных попыток с экспоненциальной задержкой наиболее актуально для пользовательских приложений, которые обращаются к служба хранилища Azure с помощью клиентских библиотек служба хранилища Azure, SDK или REST API. Многие службы Майкрософт, управляемые приложения и сторонние клиенты уже реализуют соответствующую логику повторных попыток, так что, возможно, вам не потребуется ничего дополнительного. Если вы разрабатываете собственное приложение, убедитесь, что политики повторных попыток включены и настроены в соответствии с лучшими практиками служба хранилища Azure. Ознакомьтесь с любой из следующих статей:

Избегайте резких скачков объёма запросов

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

Дальнейшие действия

Для подробного руководства по реализации см.:

  • Last updated on