Шаблон отсеков

Шаблон "Bulkhead" — это тип проектирования приложений, устойчивый к сбоям. В архитектуре «перегородка», также известной как архитектура на основе ячеек, элементы приложения изолированы в пулы, чтобы при сбое одного из них, другие продолжали функционировать. Шаблон переборки назван в честь секционированных перегородок корабельного корпуса. Если корпус корабля будет поврежден, вода заполнит только один поврежденный отсек, и корабль останется на плаву.

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

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

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

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

Решение

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

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

Такой подход обеспечивает следующие преимущества:

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

• Сохраняет некоторые функции, если происходит сбой службы. Другие службы и функции приложения продолжают работать.

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

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

Схема с двумя рабочими нагрузками, рабочей нагрузкой 1 и рабочей нагрузкой 2 и тремя службами, службой A, Service B и Service C. Рабочая нагрузка 1 использует пул подключений, назначенный службе A. Рабочая нагрузка 2 использует два пула подключений. Один пул подключений назначается службе B, а другой — службе C. Пул подключений, который использует рабочая нагрузка 1, изолирован. Пулы подключений, которые использует рабочая нагрузка 2, могут продолжать вызывать службу B и Службу C.

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

Схема с тремя клиентами, клиентом 1, клиентом 2 и клиентом 3 и тремя экземплярами служб, каждый из которых является частью службы A. Каждый клиент подключается к собственному экземпляру службы. Экземпляры службы изолированы. Если клиент 1 перегружает свой экземпляр, клиенты 2 и 3 остаются незатронутыми.

Проблемы и рекомендации

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

• Проектируйте отсеки с учетом коммерческих и технических требований приложения.

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

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

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

• При разделении потребителей на блоки, рассмотрите использование процессов, пулов потоков и семафоров. Проекты, такие как resilience4j и Polly, предлагают платформу для создания разделения нагрузки потребителей.

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

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

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

• Отслеживайте производительность каждого раздела и выполнение SLA.

• Используйте встроенные элементы управления платформой, такие как ограничения скорости управления API Azure, изоляция единиц запросов Azure Cosmos DB (ЕЗ) и ограничения ресурсов в службе Azure Kubernetes (AKS) или приложениях контейнеров Azure. Не создавайте эти механизмы ограничения и изоляции в коде приложения.

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

Когда следует использовать этот шаблон

Используйте этот шаблон, когда:

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

Этот шаблон может быть не подходит, если:

• Менее эффективное использование ресурсов может быть неприемлемым в проекте.
• Добавленная сложность не требуется.

Проектирование рабочей нагрузки

Оцените, как использовать шаблон Bulkhead в проектировании рабочей нагрузки для достижения целей и соблюдения принципов, описанных в Azure Well-Architected Framework pillars. В следующей таблице приведены рекомендации по использованию этого шаблона для целей каждого компонента.

Столп	Как этот шаблон поддерживает цели основных компонентов
Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и гарантировать, что она восстанавливается до полнофункционального состояния после сбоя.	Стратегия изоляции сбоев, представленная посредством преднамеренной и полной сегментации между компонентами, пытается ограничить сбои переборкой, испытывающей проблему, так, чтобы они не влияли на другие переборки. - Критически важные потоки RE:02 - RE:07 Самосохранение
Решения по проектированию безопасности помогают обеспечить конфиденциальность, целостность и доступность данных и систем рабочей нагрузки.	Сегментация между компонентами помогает ограничить инциденты безопасности внутри скомпрометированной переборки. - SE:04 Сегментация
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных и кода.	Каждая переборка может быть масштабируемой по отдельности для эффективного удовлетворения потребностей задачи, которая инкапсулируется в переборке. - Планирование емкости PE:02 - Pe:05 Масштабирование и секционирование

Если этот шаблон вводит компромиссы внутри столпа, рассмотрите их против целей других столпов.

Пример

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

apiVersion: v1
kind: Pod
metadata:
  name: drone-management
spec:
  containers:
  - name: drone-management-container
    image: drone-service
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "1"

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

• Используйте политики ограничения скорости управления API для управления пропускной способностью запросов на каждого клиента.
• Используйте элементы управления параллелизмом функций Azure , чтобы ограничить параллельные выполнения.
• Установите ограничения ресурсов для контейнерных приложений для управления ЦП и памятью для каждой рабочей нагрузки.
• Назначение пропускной способности Azure Cosmos DB для каждого контейнера для прогнозируемой изоляции.

Связанные ресурсы

• Шаблон прерывателя цепи
• шаблон повторных попыток
• Шаблон регулирования