Publisher-Subscriber 패턴을 사용하면 애플리케이션이 보낸 사람과 수신기를 결합하지 않고도 여러 관심 있는 소비자에게 이벤트를 비동기적으로 브로드캐스트할 수 있습니다. 이 접근 방식을 pub/sub 메시징이라고 합니다.
컨텍스트 및 문제점
클라우드 기반 및 분산 애플리케이션에는 이벤트가 발생할 때 다른 구성 요소에 정보를 보내는 시스템 구성 요소가 포함되는 경우가 많습니다. 보낸 사람이 해당 소비자와 직접 통신하는 경우 모든 소비자의 ID 및 엔드포인트를 알고, 각 소비자에게 메시지를 전달하고, 오류를 개별적으로 관리해야 합니다. 소비자를 추가하거나 제거하려면 발신자를 변경해야 하며, 이는 팀이 구성 요소를 독립적으로 개발하고 배포할 수 있는 방법을 제한합니다.
메시지 큐는 보낸 사람을 소비자와 분리하고 발신자가 응답을 기다리는 동안 프로세스를 차단하지 못하도록 합니다. 표준 큐는 발신자와 단일 소비자 간에 직접 관계를 만듭니다. 여러 소비자를 지원하려면 발신자가 각 소비자에 대해 별도의 큐를 만들어야 하므로 라우팅 복잡성이 증가하고 크기가 잘 조정되지 않습니다. 일부 소비자는 발신자가 생성하는 정보의 하위 집합만 필요하지만 큐는 콘텐츠 또는 범주별로 메시지를 필터링하는 기본 제공 방법을 제공하지 않습니다.
많은 시나리오에서는 발신자가 해당 소비자가 누구인지 모르고 많은 관심 있는 소비자에게 이벤트를 알려야 합니다. 각 소비자는 수신할 이벤트를 독립적으로 결정하는 방법도 필요합니다.
해결 방법
다음 구성 요소를 포함하는 비동기 메시징 하위 시스템을 소개합니다.
발신자가 사용하는 입력 메시징 채널입니다. 발신자는 알려진 메시지 형식을 사용하여 이벤트를 메시지로 패키지하고 입력 채널을 통해 이러한 메시지를 보냅니다. 이 패턴의 발신자를 게시자라고도 합니다.
비고
메시지는 데이터 패킷입니다. 이벤트는 변경 또는 발생하는 작업에 대해 다른 구성 요소에 알리는 메시지입니다. 이 패턴은 일반적으로 이벤트와 함께 작동하지만 명령 및 상태 알림을 비롯한 모든 유형의 메시지를 전달합니다.
각 소비자에 대한 하나의 출력 메시징 채널입니다. 소비자는 구독자라고 합니다.
입력 채널의 각 메시지를 해당 메시지에 관심이 있는 모든 구독자의 출력 채널로 복사하는 메커니즘입니다. 메시지 브로커 또는 이벤트 버스와 같은 중개자가 일반적으로 이 작업을 처리합니다.
다음 다이어그램에서는 이 패턴의 논리적 구성 요소를 보여 줍니다.
게시/구독 메시지에는 다음과 같은 혜택이 있습니다.
통신해야 하는 하위 시스템을 분리합니다. 하위 시스템은 독립적인 관리를 지원하며 하나 이상의 수신기가 오프라인인 경우에도 broker는 메시지를 유지합니다.
확장성을 높이고 발신자 응답성을 향상시킵니다. 보낸 사람 입력 채널에 단일 메시지를 보낸 다음 핵심 처리 책임으로 돌아갑니다. 메시징 인프라는 관심 있는 구독자에게 메시지를 라우팅합니다.
오류를 격리합니다. 구독자 오류는 게시자 또는 다른 구독자에게 영향을 주지 않으며, 브로커는 복구된 구독자가 메시지를 처리할 준비가 될 때까지 메시지를 유지합니다.
지연 또는 예약된 처리를 지원합니다. 구독자는 사용량이 많은 시간까지 메시지를 받기 위해 기다리거나 시스템에서 특정 일정에 따라 메시지를 라우팅하거나 처리할 수 있습니다.
다양한 플랫폼, 프로그래밍 언어 및 통신 프로토콜을 사용하는 시스템 간의 통합을 지원하고 온-프레미스 시스템을 클라우드에서 실행되는 애플리케이션과 연결합니다.
테스트 용이성을 향상시킵니다. 채널은 모니터링을 지원하며, 메시지는 통합 테스트 전략의 일환으로 검사 또는 로깅에 사용할 수 있습니다.
응용 프로그램의 관심사를 분리합니다. 메시징 인프라가 메시지를 여러 소비자에게 안정적으로 라우팅하는 데 필요한 작업을 처리하는 동안 각 애플리케이션은 핵심 기능에 집중할 수 있습니다.
문제 및 고려 사항
이 패턴을 구현하는 방법을 결정할 때 다음 사항을 고려합니다.
기존 기술: 직접 빌드하는 대신 게시-구독 모델을 지원하는 메시징 제품 및 서비스를 사용합니다. Azure 다음 서비스를 고려합니다.
Azure Service Bus 트랜잭션, 주문, 세션 또는 배달 못 한 편지 큐가 필요한 메시징용입니다.
이벤트 기반 푸시 전달 알림의 경우 Azure Event Grid 특히 Azure 리소스가 상태를 변경하고 구독된 구성 요소에 알려야 하는 경우입니다.
원격 분석 수집 및 로그 집계와 같은 처리량이 높은 이벤트 스트리밍 시나리오의 경우 Azure Event Hubs. Event Hubs는 기존 pub/sub 메시징이 아닌 로그 기반 스트리밍 모델을 사용하지만 동일한 스트림을 독립적으로 읽는 여러 소비자 그룹을 지원합니다.
자세한 내용은 메시지를 배달하는 Azure 서비스 간 선택 참조하세요. pub/sub 메시징을 지원하는 다른 기술로는 Redis, RabbitMQ 및 Apache Kafka가 있습니다.
MassTransit 및 NServiceBus 같은 라이브러리는 Service Bus 및 기타 메시징 기술에 대한 게시-구독 모델에 대한 기본 제공 지원을 제공합니다.
구독 처리: 메시징 인프라는 소비자가 사용 가능한 채널을 구독하거나 구독을 취소하는 데 사용하는 메커니즘을 제공해야 합니다.
보안: 토픽별로 게시자와 구독자 모두를 인증하고 권한을 부여합니다. 메시지를 삽입하는 권한이 없는 게시자는 해당 메시지를 읽는 권한이 없는 구독자만큼 시스템을 손상시킬 수 있습니다. 전송 중인 메시지를 암호화하고 콘텐츠가 중요한 경우 브로커에서 미사용 메시지를 암호화하여 도청을 방지합니다.
메시지의 하위 집합: 구독자는 일반적으로 게시자의 메시지 하위 집합에만 관심이 있습니다. 메시징 서비스를 통해 구독자는 다음과 같은 메커니즘을 통해 받는 것을 선택할 수 있습니다.
항목: 각 토픽에는 전용 출력 채널이 있으며 각 소비자는 모든 관련 항목을 구독할 수 있습니다.
콘텐츠 필터링: 브로커는 해당 콘텐츠에 따라 메시지를 검사하고 배포합니다. 각 구독자는 필요한 콘텐츠를 지정할 수 있습니다.
의도적으로 토픽 세분성을 선택합니다. 광범위한 토픽은 관리가 더 간단하지만 구독자가 필요하지 않은 메시지를 필터링하도록 요구합니다. 좁은 토픽은 구독자 쪽 필터링을 줄이지만 관리할 토픽 수를 늘입니다. 일부 브로커는 구독자가
orders.*를 사용하여 각 항목을 열거하지 않고도 다수의 주제를 일치시킬 수 있도록 하는 와일드카드 구독을 지원합니다.양방향 통신: 게시-구독 시스템의 채널은 단방향입니다. 구독자가 상태를 승인하거나 게시자에게 다시 전달해야 하는 경우 Request-Reply 패턴을 사용합니다. 이 패턴은 하나의 채널을 사용하여 구독자에게 메시지를 보내고 별도의 회신 채널을 사용하여 게시자와 다시 통신합니다.
메시지 순서: 구독자가 메시지를 받는 순서는 보장되지 않으며 발신자가 메시지를 만든 순서를 반드시 반영하지는 않습니다. 주문이 중요한 경우 Broker는 파티션 또는 세션 내에서 정렬된 배달을 지원할 수 있지만 확장성이 제한됩니다. 도착 주문과 독립적으로 메시지를 처리하도록 구독자를 디자인합니다.
메시지 우선 순위: 일부 워크로드에서는 특정 메시지를 다른 워크로드 앞에 처리해야 합니다. 우선 순위 큐 패턴은 우선 순위가 낮은 메시지보다 우선 순위가 높은 메시지를 라우팅하는 메커니즘을 제공합니다.
포이즌 메시지: 잘못된 형식의 메시지 또는 사용할 수 없는 리소스에 액세스해야 하는 작업으로 인해 서비스 인스턴스가 실패할 수 있습니다. 분석을 위해 이러한 메시지 세부 정보를 캡처하고 다른 곳에 저장합니다. Service Bus 같은 일부 메시지 브로커는 디드 문자 큐 통해 이 프로세스를 지원합니다.
메시지 크기: Broker는 메시지 크기 제한을 적용합니다. 페이로드가 크면 파일 또는 이미지와 같은 콘텐츠를 외부 데이터 저장소에 저장하고 메시지에 참조를 포함합니다. Claim-Check 패턴은 이 방법을 설명합니다.
배달 보장 및 중복 메시지: 메시징 시스템은 서로 다른 배달 보장을 제공하며 각 시스템에는 절충점이 있습니다.
한 번만 배달 하면 오버헤드가 최소화되지만 broker 또는 구독자가 실패하면 메시지가 손실될 수 있습니다.
적어도 한 번 이상 전달은 메시지 전달을 보장하지만, 메시지를 게시한 후 발신자가 실패하고 새 인스턴스가 동일한 메시지를 다시 게시하는 경우와 같이 중복이 발생할 수 있습니다.
정확히 한 번 배달 하면 중복 항목이 제거되지만 조정 오버헤드와 대기 시간이 추가되며 가용성은 메시징 인프라에 따라 달라집니다.
브로커가 중복 제거를 제공하지 않는 경우 메시지를 멱등하게 처리하도록 구독자를 디자인합니다. 동일한 워크로드의 다른 구독자에게는 서로 다른 보장이 필요할 수 있습니다.
메시지 만료: 일부 메시지의 수명은 제한됩니다. 받는 사람이 해당 기간 내에 메시지를 처리하지 않으면 메시지는 관련이 없으며 시스템에서 메시지를 삭제합니다. 수신자가 처리하기 전에 관련성을 확인할 수 있도록 메시지 데이터에 만료 타임스탬프를 설정합니다.
메시지 예약: 특정 날짜 및 시간까지 메시지가 금지되고 처리할 수 없을 수 있습니다. 메시징 시스템이 해당 시점까지 메시지를 보류하도록 릴리스 타임스탬프를 설정합니다.
메시지 스키마 진화: 게시자와 구독자는 독립적으로 배포되므로 메시지 스키마는 시간이 지남에 따라 변경됩니다. 기존 구독자가 계속 작동하도록 선택적 필드 추가와 같이 이전 버전과 호환되는 변경 내용을 선호합니다. 호환성이 손상되는 변경의 경우, 토픽 이름(예:
orders.v1,orders.v2) 또는 메시지 메타데이터의 버전 필드를 통해 버전 관리합니다. 구독자는 인식하지 못하는 필드를 무시해야 합니다.상관 관계: 브로커는 구독자에서 게시자를 분리하므로 메시지의 엔드 투 엔드 흐름을 추적하기가 더 어려워집니다. 구독자와 로깅 시스템이 관련 작업을 단일 추적에 연결할 수 있도록 모든 메시지에 상관 관계 ID를 포함합니다.
백프레셔 및 크기 조정: 구독자가 따라갈 수 없는 경우 처리되지 않은 메시지가 브로커에 누적되어 리소스가 고갈될 수 있습니다. broker 흐름 제어 설정을 사용하여 각 구독자에 대해 승인되지 않은 메시지를 제한합니다. 흐름 제어만으로는 충분하지 않은 경우 경쟁 소비자 패턴을 사용하여 구독자를 확장합니다.
이 패턴을 사용하는 경우
다음 경우에 이 패턴을 사용합니다.
애플리케이션이 수많은 소비자에게 정보를 브로드캐스트해야 합니다.
애플리케이션은 독립적으로 개발된 애플리케이션 또는 서비스와 통신해야 합니다. 서로 다른 플랫폼, 프로그래밍 언어 또는 통신 프로토콜을 사용할 수 있습니다.
애플리케이션은 소비자로부터 실시간 응답을 요구하지 않고도 정보를 소비자에게 보낼 수 있습니다.
통합되는 시스템은 데이터에 대한 결과적 일관성 모델을 지원하도록 설계됩니다.
애플리케이션은 보낸 사람보다 가용성 요구 사항 또는 가동 시간 일정이 다른 여러 소비자에게 정보를 전달해야 합니다.
이 패턴은 다음과 같은 경우에 적합하지 않을 수 있습니다.
애플리케이션에는 생성 애플리케이션과 크게 다른 정보가 필요한 소비자가 몇 명뿐입니다. 브로커의 오버헤드는 크기 조정 이점 없이 복잡성을 더합니다. 직접 통신 또는 별도의 큐가 더 적합할 수 있습니다.
애플리케이션이 소비자와 거의 실시간으로 상호 작용해야 합니다. pub/sub 모델은 broker를 통해 대기 시간을 도입합니다. 게시자에 동기 응답이 필요한 경우 요청-회신 패턴을 사용합니다.
소비자는 특정하고 보장된 순서로 메시지를 처리해야 합니다. Pub/sub 시스템은 일반적으로 구독자 간 순서를 보장하지 않으며 주문을 유지 관리하면 broker 및 소비자 디자인에 상당한 제약 조건이 추가됩니다.
작업을 수행하려면 게시자와 해당 소비자 간에 단일 원자성 트랜잭션이 필요합니다. Pub/sub 메시징은 본질적으로 비동기적이며 결국 일관성이 있습니다. 트랜잭션 보장이 필요한 경우 분산 트랜잭션을 조정하기 위해 직접 데이터베이스 트랜잭션 또는 Saga 패턴을 고려합니다.
워크로드 디자인
워크로드 디자인에서 Publisher-Subscriber 패턴을 사용하여 Azure Well-Architected Framework 핵심 요소 다루는 목표와 원칙을 해결하는 방법을 평가합니다. 다음 표에서는 이 패턴이 각 핵심 요소의 목표를 지원하는 방법에 대한 지침을 제공합니다.
| 핵심 요소 | 이 패턴으로 핵심 목표를 지원하는 방법 |
|---|---|
| 안정성 설계 결정을 통해 워크로드가 오작동에 대한 복원력을 높일 수 있으며 오류가 발생한 후 완전히 작동하는 상태로 복구 되도록 할 수 있습니다. | 이 패턴은 독립적인 안정성 대상을 설정하고 직접 종속성을 제거할 수 있도록 구성 요소를 분리합니다. - RE:03 오류 모드 분석 - RE:07 백그라운드 작업 |
| 보안 디자인 결정은 워크로드의 데이터 및 시스템의 기밀성, 무결성 및 가용성을 보장하는 데 도움이 됩니다. | 이 패턴은 명확한 보안 구분 경계를 도입합니다. 이를 사용하여 네트워크 수준에서 게시자로부터 큐 구독자를 분리합니다. - SE:04 세분화 |
| 비용 최적화는 워크로드의 ROI(투자 수익률)를 유지하고개선하는 데 중점을 둡니다. | 이 분리된 디자인은 소비 기반 청구 모델에 부합하고 과잉 프로비전을 방지하는 데 도움이 되는 이벤트 기반 아키텍처를 지원합니다. - CO:05 속도 최적화 - CO:12 크기 조정 비용 |
| 운영 우수성은 표준화된 프로세스와 팀 응집력을 통해 워크로드 품질을 제공하는 데 도움이 됩니다. | 브로커를 중개자로 사용하면 두 구성 요소 간에 변경 내용을 조정하지 않고 게시자 또는 구독자 쪽에서 구현을 변경할 수 있습니다. - OE:06 워크로드 개발 - OE:11 안전한 배포 사례 |
| 성능 효율성은 크기 조정, 데이터 및 코드의 최적화를 통해 워크로드가 수요를 효율적으로 충족 하는 데 도움이 됩니다. | 소비자에서 게시자를 분리하면 각 소비자가 지정된 메시지 유형에 대해 처리하는 특정 작업에 대한 컴퓨팅 및 코드를 최적화할 수 있습니다. - PE:02 용량 계획 - PE:05 크기 조정 및 분할 |
이 패턴이 하나의 기둥 내에서 절충을 도입하는 경우, 이를 다른 기둥의 목표와 비교해서 고려해 보세요.
예시
다음 다이어그램에서는 Service Bus 사용하여 워크플로 및 Event Grid를 조정하여 발생하는 이벤트의 하위 시스템에 알리는 엔터프라이즈 통합 아키텍처를 보여 줍니다. 자세한 내용은 메시지 큐 및 이벤트를 사용하여 Azure Enterprise 통합 참조하세요.
