격벽 패턴

한 요소가 실패할 경우 다른 요소가 계속 작동하도록 애플리케이션의 요소를 풀로 격리합니다. 셀 기반 아키텍처라고도 하는 이 접근 방식은 애플리케이션에서 오류를 용인하고 시스템의 한 부분에서 오류가 나머지 부분에 걸쳐 연속되는 것을 방지합니다.

컨텍스트 및 문제점

클라우드 기반 애플리케이션에는 여러 서비스가 포함될 수 있으며 각 서비스에는 하나 이상의 소비자가 있습니다. 서비스의 과도한 로드 또는 오류는 서비스의 모든 소비자에게 영향을 줍니다.

또한 소비자는 동시에 여러 서비스에 요청을 보내고 각 요청에 대해 리소스를 사용할 수 있습니다. 소비자가 잘못 구성되거나 응답하지 않는 서비스에 요청을 보내면 클라이언트의 요청에서 사용하는 리소스를 장기간 사용할 수 없게 될 수 있습니다. 서비스에 대한 요청이 계속되면 해당 리소스가 소진될 수 있습니다. 예를 들어 클라이언트의 연결 풀이 소진될 수 있습니다. 이 시점에서 다른 서비스에 대한 소비자의 요청이 영향을 받습니다. 결국 소비자는 원래 응답하지 않는 서비스뿐만 아니라 다른 서비스에 요청을 보낼 수 없습니다.

리소스 고갈은 여러 소비자가 있는 서비스에 영향을 줍니다. 한 클라이언트의 많은 요청은 서비스에서 사용 가능한 리소스를 소진할 수 있습니다. 리소스 소모는 다른 소비자가 서비스를 사용할 수 없다는 것을 의미할 수 있으며, 이로 인해 연속 실패 효과가 발생합니다.

해결 방법

서비스 인스턴스를 소비자 부하 및 가용성 요구 사항에 따라 서로 다른 그룹으로 분할합니다. 이 디자인은 오류를 격리하는 데 도움이 됩니다. 오류 발생 시에도 일부 소비자의 서비스 기능을 유지할 수 있습니다.

또한 소비자는 리소스를 분할하여 한 서비스를 호출하는 데 사용되는 리소스가 다른 서비스를 호출하는 데 사용되는 리소스에 영향을 주지 않도록 할 수 있습니다. 예를 들어 여러 서비스를 호출하는 소비자는 각 서비스에 대한 연결 풀을 할당할 수 있습니다. 서비스가 실패하기 시작하면 해당 서비스에 할당된 연결 풀에만 영향을 줍니다. 소비자는 다른 서비스를 계속 사용할 수 있습니다.

이 패턴은 다음과 같은 이점을 제공합니다.

• 소비자와 서비스를 연속 오류로부터 격리합니다. 소비자 또는 서비스에 영향을 주는 문제는 전체 솔루션이 실패하지 않도록 자체 격벽 내에서 격리할 수 있습니다.

• 서비스 오류가 발생하는 경우 일부 기능을 유지합니다. 애플리케이션의 다른 서비스 및 기능은 계속 작동합니다.

• 애플리케이션을 소비하기 위한 다양한 서비스 수준의 품질을 제공합니다. 우선 순위가 높은 서비스를 사용하도록 우선 순위가 높은 소비자 풀을 구성할 수 있습니다.

다음 다이어그램에서는 개별 서비스를 호출하는 연결 풀을 중심으로 구조화된 격벽을 보여 줍니다. 서비스 A가 실패하거나 문제가 발생하면 연결 풀이 격리되므로 서비스 A에 할당된 스레드 풀을 사용하는 워크로드만 영향을 받습니다. 서비스 B 및 C를 사용하는 워크로드는 영향을 받지 않으며 중단 없이 작업을 계속할 수 있습니다.

다음 다이어그램에서는 단일 서비스를 호출하는 여러 클라이언트를 보여 줍니다. 각 클라이언트는 별도의 서비스 인스턴스에 할당됩니다. 클라이언트 1은 너무 많은 요청을 수행하고 인스턴스를 압도합니다. 각 서비스 인스턴스는 다른 서비스 인스턴스와 격리되므로 다른 클라이언트는 계속 호출할 수 있습니다.

문제 및 고려 사항

이 패턴을 구현하는 방법을 결정할 때 다음 사항을 고려합니다.

• 애플리케이션의 비즈니스 및 기술 요구 사항과 관련하여 파티션을 정의합니다.

• 전술 도메인 기반 디자인을 사용하여 마이크로 서비스를 디자인하는 경우 파티션 경계는 경계가 제한된 컨텍스트와 일치해야 합니다.

• 서비스 또는 소비자를 격벽으로 분할하는 경우 기술에서 제공하는 격리 수준과 비용, 성능 및 관리 효율성 측면에서 오버헤드를 고려합니다.

• 보다 정교한 오류 처리를 위해, 벌크헤드를 재시도, 회로 차단기, 그리고 제한 패턴과 결합하는 것을 고려하십시오.

• 소비자를 격벽으로 구분할 때, 프로세스, 스레드 풀, 세마포어를 사용하는 것을 고려하세요. resilience4j 및 Polly와 같은 프로젝트는 소비자 격벽을 만들기 위한 프레임워크를 제공합니다.

• 서비스를 격벽으로 분할하는 경우 별도의 가상 머신, 컨테이너 또는 프로세스에 배포하는 것이 좋습니다. 컨테이너는 비교적 낮은 오버헤드로 리소스를 격리하여 균형을 잘 잡아줍니다.

• 비동기 메시지를 사용하여 통신하는 서비스는 여러 큐 집합을 통해 격리할 수 있습니다. 각 큐에는 큐에서 메시지를 처리하는 전용 인스턴스 집합 또는 처리를 큐에서 제거하고 디스패치하는 알고리즘을 사용하는 단일 인스턴스 그룹이 있을 수 있습니다.

• 격벽의 세분성 수준을 결정합니다. 예를 들어 파티션 간에 테넌트를 분산하려는 경우 각 테넌트를 별도의 파티션에 배치하거나 여러 테넌트를 하나의 파티션에 배치할 수 있습니다.

• 각 파티션의 성능 및 SLA(서비스 수준 계약)를 모니터링합니다.

• Azure API Management 속도 제한, Azure Cosmos DB RU(요청 단위) 격리 및 AKS(Azure Kubernetes Service) 또는 Azure Container Apps의 리소스 제한과 같은 기본 제공 플랫폼 컨트롤을 사용합니다. 애플리케이션 코드에서 이러한 제한 및 격리 메커니즘을 다시 만들지 마세요.

• AI 및 유추 워크로드에는 배포 수준 할당량 및 동시성 제한(예: 워크로드당 또는 테넌트당 Azure OpenAI 배포 격리)으로 인해 엄격한 격벽이 필요한 경우가 많습니다.

이 패턴을 사용하는 경우

다음 경우에 이 패턴을 사용합니다.

• 한 서비스의 중단이 전체 애플리케이션에 영향을 주지 않도록 특정 종속성에 대한 리소스를 격리하려고 합니다.
• 중요한 소비자를 표준 소비자로부터 격리하려고 합니다.
• 연속 오류로부터 애플리케이션을 보호해야 합니다.

이 패턴은 다음과 같은 경우에 적합하지 않을 수 있습니다.

• 프로젝트에서 리소스를 덜 효율적으로 사용하는 것은 허용되지 않을 수 있습니다.
• 복잡성이 더해지지 않아도 됩니다.

워크로드 디자인

워크로드 디자인에서 Bulkhead 패턴을 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가합니다. 다음 표에서는 이 패턴이 각 핵심 요소의 목표를 지원하는 방법에 대한 지침을 제공합니다.

이 패턴이 하나의 기둥 내에서 절충을 도입하는 경우, 이를 다른 기둥의 목표와 비교해서 고려해 보세요.

예시

다음 Kubernetes 구성 파일은 자체 CPU 및 메모리 리소스 및 제한을 사용하여 단일 서비스를 실행하는 격리된 컨테이너를 만듭니다.

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 Management 속도 제한 정책을 사용하여 클라이언트당 요청 처리량을 제어합니다.
• Azure Functions 동시성 컨트롤을 사용하여 병렬 실행을 제한합니다.
• 워크로드당 CPU 및 메모리를 제어하도록 Container Apps 리소스 제한을 설정합니다.
• 예측 가능한 격리를 위해 컨테이너당 Azure Cosmos DB RU 처리량을 할당합니다.

관련 리소스

• 회로 차단기 패턴
• 패턴 다시 시도
• 스로틀링 패턴