편집

메시징 브리지 패턴

Azure Service Bus

이 문서에서는 다양한 메시징 인프라를 기반으로 구축된 서로 다른 시스템을 통합하는 데 사용할 수 있는 메시징 브리지 패턴을 설명합니다.

컨텍스트 및 문제점

많은 조직 및 워크로드에는 실수로 MSMQ(Microsoft Message Queueing), RabbitMQ, Azure Service Bus 및 Amazon SQS와 같은 여러 메시징 인프라를 사용하는 IT 시스템이 있을 수 있습니다. 이 문제는 합병, 인수 또는 비용 효율성 및 기본 테넌트 용이성을 위해 현재 온-프레미스 시스템을 클라우드 호스팅 구성 요소로 확장하기 때문에 발생할 수 있습니다.

개발자는 HTTP 기반 웹 서비스를 사용하여 통신하도록 통합되는 시스템을 수정하여 이 문제를 해결할 수 있습니다. 그러나 이 접근 방식에는 다음과 같은 단점이 있습니다.

  • 한쪽에는 HTTP 클라이언트를 추가하고 다른 쪽에는 HTTP 요청 처리기를 추가하여 시스템을 수정해야 합니다. 그런 다음 시스템을 다시 테스트하고 다시 배포해야 합니다.
  • HTTP 엔드포인트를 호스트해야 하므로 웹 서비스를 안전하고 고가용성으로 만들 때 복잡성이 더해집니다.
  • 사용자 지정 빌드 재시도 메커니즘이 필요한 네트워크 연결 문제가 자주 발생합니다.

솔루션

통합되는 시스템이 메시지를 교환하여 통신하는 구성 요소로 구성된 경우 메시징 브리지 패턴은 통합을 개선하고 단점을 완화합니다.

이 시나리오에서는 각 시스템이 하나의 메시징 인프라에 연결합니다. 서로 다른 메시징 인프라에 통합하려면 둘 이상의 메시징 인프라에 동시에 연결하는 브리지 구성 요소를 도입합니다. 브리지는 하나의 메시지를 끌어와 페이로드를 변경하지 않고 다른 메시지로 푸시합니다.

통합되는 시스템은 다른 시스템이나 브리지를 인식할 필요가 없습니다. 보낸 사람 시스템은 기본 메시징 인프라의 지정된 큐에 특정 메시지를 보내도록 구성됩니다. 브리지는 이러한 메시지를 선택하고 수신자 시스템에서 메시지를 선택하는 다른 메시징 인프라의 다른 큐로 전달합니다.

이점

  • 메시징 브리지를 통해 통합되는 시스템은 수정할 필요가 없습니다. 이상적으로 엔드포인트는 메시지가 브리지되는 것을 인식하지 못합니다.
  • 최소 한 번 이상의 메시지 배달 메커니즘 보장으로 인해 HTTP 대안에 비해 통합이 더 안정적입니다.
  • 마이그레이션 시나리오는 더 유연할 수 있습니다. 예를 들어 일정이 모두 한꺼번에 허용되기 때문에 엔드포인트를 한 메시징 인프라에서 다른 메시징 인프라로 마이그레이션할 수 있습니다.

단점

  • 하나 또는 두 메시징 기술의 고급 기능은 브리지된 경로에서 사용할 수 없습니다.
  • 브리지된 경로는 두 기술의 제한 사항을 모두 고려해야 합니다. 예를 들어 최대 메시지 크기는 MSMQ에서 4MB일 수 있지만 Azure Storage 큐에서는 64KB에 불과합니다.

문제 및 고려 사항

메시징 브리지 패턴을 구현할 때 다음 사항을 고려합니다.

  • 통합 시스템 중 하나가 분산 트랜잭션(예: Microsoft DTC)에 의존하는 경우 정확성을 위해 브리지에서 중복 제거 메커니즘을 구현해야 합니다.

  • 통합되는 시스템 중 하나가 메시징 인프라를 사용하지 않고 수정할 수 없는 경우 다른 시스템에서 사용하는 인프라와 SQL Server 에뮬레이트된 큐 간에 메시징 브리지를 빌드할 수 있습니다. 레거시 시스템은 SQL Server의 변경 데이터 캡처 기능을 사용하여 전용 큐 테이블에 변경 내용을 푸시하여 메시지를 보낼 수 있습니다. 브리지는 이러한 메시지를 실제 메시징 인프라로 전달할 수 있습니다.

  • 브리징 큐로 지정된 각 메시징 인프라에서 단일 큐를 사용할 수 있습니다. 이 토폴로지에서 해당 특정 큐를 다른 시스템으로 전송되는 메시지 유형의 대상으로 사용하도록 보내는 시스템을 구성합니다. 각 메시징 인프라에서 여러 쌍의 큐를 사용할 수도 있으므로 보낸 사람이 브리지를 인식하지 못합니다. 대상 시스템의 메시징 인프라에 있는 각 대상 큐에 대해 섀도 큐가 만들어집니다. 브리지는 섀도 큐와 해당 큐 간에 메시지를 전달합니다.

  • 원하는 SLA(가용성 서비스 수준 계약)를 충족하려면 경쟁 소비자 접근 방식을 사용하여 메시징 브리지를 확장해야 할 수 있습니다.

  • 일반 메시지 처리 구성 요소는 재시도 패턴을 사용하여 일시적인 오류를 처리합니다. 재시도 카운터 제한을 사용하면 구성 요소가 포이즌 메시지를 검색하고 큐에서 제거하여 처리 차단을 해제할 수 있습니다. 인프라 오류가 발생할 경우 메시지를 포이즌으로 잘못 식별하는 것을 방지하기 위해 브리지에 다른 재시도 정책이 필요할 수 있습니다. 회로 차단기 패턴을 사용하여 전달을 일시 중지할 수 있습니다.

이 패턴을 사용해야 하는 경우

다음을 수행해야 하는 경우 메시징 브리지 패턴을 사용합니다.

  • 기존 시스템을 최소한의 수정 요구 사항과 통합합니다.
  • 다른 메시징 기술을 사용할 수 없는 레거시 애플리케이션을 통합합니다.
  • 클라우드 호스팅 구성 요소를 사용하여 기존 온-프레미스 애플리케이션을 확장합니다.
  • 인터넷 연결이 안정적이지 않은 경우 지역 분산 시스템을 커넥트.
  • 한 가지 노력으로 전체 시스템을 마이그레이션할 필요 없이 단일 분산 시스템을 한 메시징 인프라에서 다른 메시징 인프라로 증분 방식으로 마이그레이션합니다.

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

  • 관련된 시스템 중 하나 이상은 다른 메시징 인프라에 없는 한 메시징 인프라의 기능을 사용합니다.
  • 통합은 본질적으로 동기적이며 시작 시스템에는 즉각적인 응답이 필요합니다.
  • 통합에는 보안 또는 개인 정보 보호 문제와 같은 특정 기능 또는 비기능적 요구 사항이 있습니다.
  • 통합에 대한 데이터 볼륨이 메시징 시스템의 용량을 초과하거나 메시징을 문제에 대한 비용이 많이 드는 솔루션으로 만듭니다.

워크로드 디자인

설계자는 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하기 위해 워크로드 디자인에 메시징 브리지 패턴을 사용하는 방법을 평가해야 합니다. 예시:

핵심 요소 이 패턴이 핵심 목표를 지원하는 방법
비용 최적화는 워크로드의 투자 수익률을 유지하고 개선하는 데 중점을 줍니다. 이 중간 단계는 다른 메시징 또는 이벤트 기술을 사용하는 시스템과의 상호 운용성을 허용하여 재작성 없이 기존 시스템의 수명을 높일 수 있습니다.

- CO:07 구성 요소 비용
운영 우수성은 표준화된 프로세스와 팀 응집력을 통해 워크로드 품질을 제공하는 데 도움이 됩니다. 이 분리는 워크로드 내에서 메시징 및 이벤트 기술을 전환하거나 외부 종속성에서 다른 유형의 요구 사항이 있는 경우 유연성을 제공합니다.

- OE:06 워크로드 변경 내용 배포

디자인 결정과 마찬가지로 이 패턴으로 도입될 수 있는 다른 핵심 요소의 목표에 대한 절충을 고려합니다.

예시

온-프레미스에서 호스트되는 직원 예약을 관리하기 위해 .NET Framework로 작성된 애플리케이션이 있습니다. 애플리케이션은 MSMQ를 통해 통신하는 별도의 구성 요소로 잘 구성됩니다. 애플리케이션이 작동하며 워크로드 팀은 다시 쓸 의도가 없습니다. 비즈니스 요구를 충족하기 위해 예약 데이터의 새 소비자를 구축해야 하며, IT 전략은 비용과 배달 시간을 최적화하기 위해 클라우드 네이티브 애플리케이션으로 새 소프트웨어를 빌드해야 합니다.

비동기 큐 기반 아키텍처는 과거에 워크로드 팀에서 작동했기 때문에 팀은 동일한 아키텍처 접근 방식을 사용하지만 최신 기술인 Service Bus를 사용합니다. 워크로드 팀은 클라우드와 온-프레미스 배포 간의 동기 통신을 도입하여 대기 시간 또는 다른 배포에 영향을 주는 통신의 사용 불가를 완화하려고 합니다.

팀은 메시징 브리지 패턴을 사용하여 두 시스템을 연결하기로 결정합니다. 패턴은 두 부분으로 구성됩니다. 한 부분은 기존 MSMQ 큐에서 메시지를 수신하고 Service Bus로 전달합니다. 다른 부분은 Service Bus에서 메시지를 가져와서 기존 MSMQ 큐로 전달합니다.

MSMQ 및 Service Bus를 통합하는 메시징 브리지의 다이어그램

구현 팀에서 이 방법을 사용하는 경우 기존 애플리케이션의 기존 인프라를 활용하여 새 구성 요소와 통합합니다. 기존 애플리케이션은 새 구성 요소가 Azure에서 호스트된다는 것을 인식하지 못합니다. 마찬가지로 새 구성 요소는 Service Bus 메시지를 전송하여 자체적으로 통신하는 것과 동일한 방식으로 레거시 애플리케이션과 통신합니다. 브리지는 두 시스템 간에 메시지를 전달합니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

주요 작성자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

  • 경쟁 소비자 패턴은 메시징 브리지의 구현이 부하를 처리할 수 있도록 합니다.
  • 재시도 패턴을 사용하면 메시징 브리지에서 일시적인 오류를 처리할 수 있습니다.
  • 회로 차단기 패턴은 브리지의 양쪽에서 가동 중지 시간이 발생할 때 리소스를 절약합니다.