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

Azure

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

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

When you build a service that multiple customers or tenants share, you can build it to be multitenanted. Преимущество мультитенантных систем заключается в том, что ресурсы могут быть объединены в пулы и совместно использоваться арендаторами. Общий доступ к ресурсам часто приводит к снижению затрат и повышению эффективности. Но если отдельный арендатор использует несоразмерный объем ресурсов, доступных в системе, общая производительность системы может ухудшиться. The noisy neighbor problem occurs when one tenant's performance is degraded because of the activities of another tenant.

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

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

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

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

На изображении показаны три графика строки, представляющие использование ресурсов для трех клиентов: Tenant A, Tenant B и Tenant C. Эти графы показывают общую емкость системы с течением времени. На другом графике показана общая емкость системы и использование ресурсов всех трех клиентов.

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

Solution

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

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

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

• Приобрести резервную мощность (при ее доступности). For example, when you use Azure Cosmos DB, purchase reserved throughput.

• При наличии миграции на уровень служб с более строгими гарантиями изоляции. Например, при использовании служебной шины Azure перейдите на уровень "Премиум". При использовании кэша Azure для Redis подготовьте стандартный или премиум-кэш.

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

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

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

• Применение управления ресурсами. Рассмотрите возможность применения политик, которые не позволяют одному клиенту подавлять систему и уменьшать емкость, доступную другим клиентам. This step might take the form of quota enforcement through the Throttling pattern or the Rate Limiting pattern.

• Подготовьте дополнительную инфраструктуру. Этот процесс может включать масштабирование, обновив некоторые компоненты решения. Or it might include scaling out by provisioning extra shards if you follow the Sharding pattern, or stamps if you follow the Deployment Stamps pattern.

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

• Сбалансируйте использование ресурсов клиента. Например, можно попробовать один из следующих подходов:

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

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

• Проверьте, предоставляют ли подчиненные службы элементы управления для устранения шумных проблем соседей. For example, when you use Kubernetes, consider using pod limits. При использовании Azure Service Fabric рекомендуется использовать встроенные возможности управления.

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

• Предоставление системы качества обслуживания (QoS). При применении QoS необходимо определить приоритеты некоторых процессов или рабочих нагрузок перед другими процессами или рабочими нагрузками. Реализовав QoS в своей системе и архитектуре, вы сможете обеспечить доступность ресурсов для определенных операций при ограниченности ресурсов.

Considerations

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

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

Note

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

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

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

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

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

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

• Сбои при выполнении операции для клиента: Найдите сбои, возникающие, когда клиент не потребляет большую долю ресурсов системы. Этот шаблон может указывать на то, что у клиента возникает шумная проблема соседа. Отслеживание потребления ресурсов клиентом. Например, при использовании Azure Cosmos DB регистрируют единицы запросов для каждого запроса и включают идентификатор клиента в телеметрию, чтобы можно было агрегировать использование единиц запросов для каждого клиента.

Contributors

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Principal author:

• John Downs | Principal Software Engineer, Azure Patterns & Practices

Other contributors:

• Chad Kittel | Principal Software Engineer, Azure Patterns & Practices
• Paolo Salvatori | Principal Customer Engineer, FastTrack for Azure
• Daniel Scott-Raynsford | Partner Technology Strategist
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

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

Related resources

• Рекомендации по архитектуре для мультитенантного решения
• Рекомендации по обработке временных сбоев

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

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

When you build a service that multiple customers or tenants share, you can build it to be multitenanted. Преимущество мультитенантных систем заключается в том, что ресурсы могут быть объединены в пулы и совместно использоваться арендаторами. Общий доступ к ресурсам часто приводит к снижению затрат и повышению эффективности. Но если отдельный арендатор использует несоразмерный объем ресурсов, доступных в системе, общая производительность системы может ухудшиться. The noisy neighbor problem occurs when one tenant's performance is degraded because of the activities of another tenant.

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

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

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

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

На изображении показаны три графика строки, представляющие использование ресурсов для трех клиентов: Tenant A, Tenant B и Tenant C. Эти графы показывают общую емкость системы с течением времени. На другом графике показана общая емкость системы и использование ресурсов всех трех клиентов.

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

Solution

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

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

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

• Приобрести резервную мощность (при ее доступности). For example, when you use Azure Cosmos DB, purchase reserved throughput.

• При наличии миграции на уровень служб с более строгими гарантиями изоляции. Например, при использовании служебной шины Azure перейдите на уровень "Премиум". При использовании кэша Azure для Redis подготовьте стандартный или премиум-кэш.

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

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

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

• Применение управления ресурсами. Рассмотрите возможность применения политик, которые не позволяют одному клиенту подавлять систему и уменьшать емкость, доступную другим клиентам. This step might take the form of quota enforcement through the Throttling pattern or the Rate Limiting pattern.

• Подготовьте дополнительную инфраструктуру. Этот процесс может включать масштабирование, обновив некоторые компоненты решения. Or it might include scaling out by provisioning extra shards if you follow the Sharding pattern, or stamps if you follow the Deployment Stamps pattern.

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

• Сбалансируйте использование ресурсов клиента. Например, можно попробовать один из следующих подходов:

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

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

• Проверьте, предоставляют ли подчиненные службы элементы управления для устранения шумных проблем соседей. For example, when you use Kubernetes, consider using pod limits. При использовании Azure Service Fabric рекомендуется использовать встроенные возможности управления.

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

• Предоставление системы качества обслуживания (QoS). При применении QoS необходимо определить приоритеты некоторых процессов или рабочих нагрузок перед другими процессами или рабочими нагрузками. Реализовав QoS в своей системе и архитектуре, вы сможете обеспечить доступность ресурсов для определенных операций при ограниченности ресурсов.

Considerations

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

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

Note

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

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

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

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

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

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

• Сбои при выполнении операции для клиента: Найдите сбои, возникающие, когда клиент не потребляет большую долю ресурсов системы. Этот шаблон может указывать на то, что у клиента возникает шумная проблема соседа. Отслеживание потребления ресурсов клиентом. Например, при использовании Azure Cosmos DB регистрируют единицы запросов для каждого запроса и включают идентификатор клиента в телеметрию, чтобы можно было агрегировать использование единиц запросов для каждого клиента.

Contributors

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Principal author:

• John Downs | Principal Software Engineer, Azure Patterns & Practices

Other contributors:

• Chad Kittel | Principal Software Engineer, Azure Patterns & Practices
• Paolo Salvatori | Principal Customer Engineer, FastTrack for Azure
• Daniel Scott-Raynsford | Partner Technology Strategist
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

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

Related resources

• Рекомендации по архитектуре для мультитенантного решения
• Рекомендации по обработке временных сбоев