격벽 패턴은 실패에 관대한 애플리케이션 디자인의 한 유형입니다. 격벽 패턴에서 하나가 고장 나더라도 나머지는 정상적으로 작동하도록 애플리케이션의 요소를 여러 풀에 격리합니다. 그것은 배 선체의 단면 파티션(격벽)의 이름을 따서 명명됩니다. 선박의 선체가 손상되면 손상된 구역만 물로 채워 배가 가라앉지 못하게 합니다.
컨텍스트 및 문제점
클라우드 기반 애플리케이션은 각 서비스에 하나 이상의 소비자가 있는 여러 서비스를 포함할 수 있습니다. 서비스의 과도한 로드 또는 오류는 서비스의 모든 소비자에게 영향을 미칩니다.
또한 소비자는 각 요청에 대한 리소스를 사용하여 동시에 여러 서비스에 요청을 보낼 수 있습니다. 소비자가 잘못 구성되었거나 응답하지 않는 서비스에 요청을 보내면 클라이언트의 요청에서 사용하는 리소스가 적시에 해제되지 않을 수 있습니다. 서비스에 대한 요청이 계속되면 해당 리소스가 소진될 수 있습니다. 예를 들어 클라이언트의 연결 풀이 소진될 수 있습니다. 이때 다른 서비스에 대한 소비자의 요청이 영향을 받습니다. 결국 소비자는 원래 응답하지 않는 서비스뿐만 아니라 다른 서비스에도 더 이상 요청을 보낼 수 없습니다.
리소스 고갈의 동일한 문제는 여러 소비자의 서비스에 영향을 줍니다. 한 클라이언트에서 시작된 많은 수의 요청은 서비스에서 사용 가능한 리소스를 소진할 수 있습니다. 다른 소비자는 더 이상 서비스를 사용할 수 없으므로 연속 실패 효과가 발생합니다.
솔루션
소비자 부하 및 가용성 요구 사항에 따라 서비스 인스턴스를 서로 다른 그룹으로 분할합니다. 이 디자인은 오류를 격리하는 데 도움이 되며, 오류 발생 시에도 일부 소비자의 서비스 기능을 유지할 수 있습니다.
또한 소비자는 리소스를 분할하여 한 서비스를 호출하는 데 사용되는 리소스가 다른 서비스를 호출하는 데 사용되는 리소스에 영향을 주지 않도록 할 수 있습니다. 예를 들어 여러 서비스를 호출하는 소비자는 각 서비스에 대한 연결 풀을 할당할 수 있습니다. 서비스가 실패하기 시작하면 해당 서비스에 할당된 연결 풀에만 영향을 주어 소비자가 다른 서비스를 계속 사용할 수 있습니다.
이 패턴의 이점은 다음과 같습니다.
- 소비자와 서비스를 연속 오류로부터 격리합니다. 소비자 또는 서비스에 영향을 주는 문제는 자체 격벽 내에서 격리되어 전체 솔루션이 실패하지 않도록 방지할 수 있습니다.
- 서비스 오류가 발생할 경우 일부 기능을 유지할 수 있습니다. 애플리케이션의 다른 서비스 및 기능은 계속 작동합니다.
- 다른 품질의 소비 애플리케이션 서비스를 제공하는 서비스를 배포할 수 있습니다. 우선 순위가 높은 소비자 풀은 우선 순위가 높은 서비스를 사용하도록 구성할 수 있습니다.
다음 다이어그램에서는 개별 서비스를 호출하는 연결 풀을 중심으로 구조화된 격벽을 보여 줍니다. 서비스 A가 실패하거나 다른 문제가 발생하면 연결 풀이 격리되므로 서비스 A에 할당된 스레드 풀을 사용하는 워크로드만 영향을 받습니다. 서비스 B와 C를 사용하는 워크로드는 영향을 받지 않고 중단 없이 계속 작업할 수 있습니다.
다음 다이어그램은 단일 서비스를 호출하는 여러 클라이언트를 보여 줍니다. 각 클라이언트에는 별도의 서비스 인스턴스가 할당됩니다. 클라이언트 1이 너무 많은 요청을 수행하고 인스턴스를 압도했습니다. 각 서비스 인스턴스는 다른 서비스 인스턴스와 격리되어 있으므로 다른 클라이언트는 계속 호출할 수 있습니다.
문제 및 고려 사항
- 애플리케이션의 비즈니스 및 기술 요구 사항과 관련하여 파티션을 정의합니다.
- 서비스 또는 소비자를 격벽으로 분할할 때 비용, 성능 및 관리 효율성 측면에서의 오버헤드뿐만 아니라 기술에서 제공되는 격리 수준을 고려합니다.
- 보다 정교한 오류 처리 방법을 제공하려면 다시 시도, 회로 차단기 및 패턴 제한을 조합한 격벽을 사용하는 것이 좋습니다.
- 소비자를 격벽으로 분할할 때 프로세스, 스레드 풀 및 세마포를 사용하는 것이 좋습니다. resilience4j 및 Polly와 같은 프로젝트는 소비자 격벽을 만들기 위한 프레임워크를 제공합니다.
- 격벽으로 서비스를 분할할 때 별도의 가상 머신, 컨테이너 또는 프로세스에 배포하는 것이 좋습니다. 컨테이너는 리소스 오버헤드가 매우 낮은 적절히 균형 잡힌 리소스 격리를 제공합니다.
- 비동기 메시지를 사용하여 통신하는 서비스는 다른 큐 집합을 통해 격리할 수 있습니다. 각 큐에는 큐에서 메시지를 처리하는 전용 인스턴스 집합 또는 처리를 큐에서 제거하고 디스패치하는 알고리즘을 사용하는 단일 인스턴스 그룹이 있을 수 있습니다.
- 격벽의 세분성 수준을 결정합니다. 예를 들어 파티션 간에 테넌트를 배포하려는 경우 각 테넌트를 별도의 파티션에 배치하거나 여러 테넌트를 하나의 파티션에 배치할 수 있습니다.
- 각 파티션의 성능 및 SLA를 모니터링합니다.
이 패턴을 사용해야 하는 경우
다음 경우에 이 패턴을 사용합니다.
- 특히 서비스 중 하나가 응답하지 않는 경우에도 애플리케이션이 일정 수준의 기능을 제공할 수 있는 경우 백 엔드 서비스 집합을 사용하는 데 사용되는 리소스를 격리합니다.
- 표준 소비자로부터 중요한 소비자를 격리합니다.
- 연속 오류로부터 애플리케이션을 보호합니다.
이 패턴은 다음과 같은 경우에 적합하지 않을 수 있습니다.
- 프로젝트에서 리소스 사용 효율성이 떨어지면 안 되는 경우
- 복잡성이 더해지지 않아도 됩니다.
워크로드 디자인
설계자는 워크로드 디자인에서 Bulkhead 패턴을 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:
| 핵심 요소 | 이 패턴이 핵심 목표를 지원하는 방법 |
|---|---|
| 안정성 디자인 결정은 워크로드가 오작동에 대한 복원력을 갖도록 하고 오류가 발생한 후 완전히 작동하는 상태로 복구 되도록 하는 데 도움이 됩니다. | 구성 요소 간의 의도적이고 완전한 분할을 통해 도입된 오류 격리 전략은 문제가 발생한 벌크헤드에만 오류를 포함하려고 시도하여 다른 격벽에 미치는 영향을 방지합니다. - RE:02 중요 흐름 - RE:07 자기 보존 |
| 보안 디자인 결정은 워크로드의 데이터 및 시스템의 기밀성, 무결성 및 가용성을 보장하는 데 도움이 됩니다. | 구성 요소 간 구분은 보안 인시던트를 손상된 격벽으로 제한하는 데 도움이 됩니다. - SE:04 구분 |
| 성능 효율성은 크기 조정, 데이터, 코드의 최적화를 통해 워크로드가 수요를 효율적으로 충족하는 데 도움이 됩니다. | 각 격벽은 격벽에 캡슐화된 작업의 요구 사항을 효율적으로 충족하도록 개별적으로 확장할 수 있습니다. - PE:02 용량 계획 - PE:05 크기 조정 및 분할 |
디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.
예시
다음 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"