Изменить

Поделиться через

Антишаблон "шумный сосед"

Azure

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

Описание проблемы

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

Рассмотрим пример мультитенантной системы с двумя арендаторами. Шаблоны использования клиента A и шаблоны использования клиента B совпадают. В пиковые периоды клиент A использует все ресурсы системы, что означает, что все запросы, которые клиент B делает сбоем. Другими словами, общее использование ресурсов превышает емкость системы:

Рисунок, показывающий использование ресурсов двух клиентов. Клиент A использует полный набор системных ресурсов, т. е. сбои клиента B.

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

"Проблема шумного соседа" также возникает, даже если каждый отдельный арендатор потребляет относительно небольшой объем ресурсов системы, но общее использование множества арендаторов приводит к пиковой нагрузке:

Рис. с 3 клиентами, каждый из которых потребляет меньше максимальной пропускной способности решения. В общей сложности три клиента используют полные системные ресурсы.

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

Как устранить проблему

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

Действия, которые могут предпринять клиенты

Действия, которые могут предпринять поставщики услуг

  • Отслеживайте использование ресурсов для системы. Отслеживайте общее использование ресурсов и ресурсы, используемые каждым клиентом. Настроить оповещения для обнаружения всплесков в нагрузке на ресурсы и при возможности настроить средства для автоматического устранения известных проблем путем горизонтального или вертикального масштабирования.
  • Применение управления ресурсами. Рассмотрите возможность применения политик, которые не позволяют одному клиенту подавлять систему и уменьшать емкость, доступную другим пользователям. Это можно сделать путем принудительного применения квот с помощью шаблона регулирования или шаблона ограничения скорости.
  • Подготовьте дополнительную инфраструктуру. Этот процесс может включать обновление некоторых компонентов решения (вертикальное масштабирование) или подготовку дополнительных сегментов (горизонтальное масштабирование), если вы следуете шаблону сегментирования, либо единиц масштабирования, если вы следуете шаблону единиц масштабирования развертывания.
  • Позволяет клиентам приобретать предварительно подготовленную или зарезервированную емкость. Эта емкость обеспечивает клиентам более определенную уверенность в том, что ваше решение надлежащим образом обрабатывает свою рабочую нагрузку.
  • Сглаживание использования ресурсов клиентов. Например, можно попробовать один из следующих подходов:
    • Если вы размещаете несколько экземпляров решения, рассмотрите возможность повторного распределения арендаторов между экземплярами или единицами масштабирования. Например, рассмотрите возможность размещения клиентов с прогнозируемыми и аналогичными шаблонами использования на нескольких метках, чтобы сложить пики их использования.
    • Определите, есть ли у вас фоновые процессы или требовательные к ресурсам рабочие нагрузки, которым не требуется низкая задержка. Запустите эти рабочие нагрузки асинхронно в нерабочее время, чтобы сохранить пиковую емкость ресурсов для рабочих нагрузок с учетом времени.
  • Проверьте, предоставляют ли подчиненные службы элементы управления для устранения шумных проблем соседей. Например, при использовании Kubernetes вы можете задать ограничения pod, а при использовании Service Fabric активировать встроенные возможности управления.
  • Ограничить операции, которые могут выполнять клиенты. Например, ограничить клиентов выполнением операций, которые будут выполнять очень большие запросы к базе данных, например указав максимальное количество возвращаемых записей или ограничение времени на запросы. Это снижает риск тех действий со стороны арендаторов, которые могут негативно повлиять на работу других арендаторов.
  • Предоставление системы качества обслуживания (QoS). При применении QoS некоторым процессам или рабочим нагрузкам назначается повышенный приоритет. Реализовав QoS в своей системе и архитектуре, вы сможете обеспечить доступность ресурсов для определенных операций при ограниченности ресурсов.

Рекомендации

В большинстве случаев отдельные клиенты не намерены вызывать шумные проблемы соседей. Отдельные клиенты могут даже не знать, что их рабочие нагрузки вызывают шумные проблемы соседей для других. Однако также возможно, что некоторые клиенты могут использовать уязвимости в общих компонентах для атаки на службу либо по отдельности, либо путем выполнения распределенной атаки типа "отказ в обслуживании" (DDoS).

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

Примечание.

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

Как определить проблему

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

С точки зрения службы, шумная проблема соседа может появиться несколькими способами:

  • Возникновение пиковой нагрузки на ресурсы. Очень важно знать обычные базовые показатели для использования ресурсов и настроить мониторинг и оповещения для обнаружения всплесков. Обязательно учитывайте все ресурсы, которые могут повлиять на производительность или доступность службы. К ним относятся такие метрики, как нагрузка на ЦП и память сервера, интенсивность операций ввода-вывода для дисков, использование баз данных, сетевой трафик, а также метрики, которые предоставляются управляемыми службами, такие как число запросов и синтетические и абстрактные метрики производительности (например, единицы запросов Azure Cosmos DB).
  • Сбои при выполнении операции для клиента. В частности, найдите сбои, возникающие, когда клиент не использует большую часть ресурсов системы. Такой шаблон может указывать на то, что клиент является жертвой шумной проблемы соседа. В таком случае рекомендуется отслеживать потребление ресурсов арендатором. Например, при использовании Azure Cosmos DB вы можете вести журнал единиц запросов, используемых для каждого запроса, и добавлять идентификатор арендатора в качестве измерения в телеметрию. Это поможет в последующем агрегировать потребление единиц ресурсов по каждому арендатору.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

  • Джон Даунс | Главный инженер программного обеспечения

Другие участники:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.