Azure 서비스 버스 : 개념, 설명, 예제, 방법

서비스 버스를 사용하여 애플리케이션과 서비스를 분리할 때 다음과 같은 이점을 얻을 수 있습니다.

 

 

소개

메시지 대기열 및 게시-구독 항목은 네임스페이스에서 완전히 관리되는 엔터프라이즈 메시지 브로커 Azure Service Bus의 기능입니다. 서비스 버스를 사용하여 애플리케이션과 서비스를 서로 분리할 때 다음과 같은 이점을 얻을 수 있습니다:

• 경쟁사 직원들에게 업무를 분배합니다.
• 서비스 및 애플리케이션 경계를 넘어 안전한 방식으로 데이터와 제어를 교환합니다.
• 높은 수준의 신뢰성을 요구하는 트랜잭션 작업을 조정합니다.

 

 

Microsoft의 Azure 버스 서비스 개요

메시지는 다양한 앱과 서비스 간에 데이터를 이동하는 데 사용됩니다. 메시지는 메타데이터가 있는 데이터로 채워진 컨테이너입니다. JSON, XML, Apache Avro 및 일반 텍스트와 같은 일반적인 형식으로 저장된 구조화된 데이터를 포함하여 모든 유형의 정보를 데이터로 사용할 수 있습니다.

일반적인 메시지 상황은 다음과 같습니다:

메시징. 

저널, 재고 이동 또는 판매 또는 구매 주문과 같은 회사 정보를 전송합니다.

 

 

응용 프로그램 분리

애플리케이션과 서비스는 더욱 확장성과 안정성이 높아야 합니다. 생산자와 소비자 모두가 온라인 상태이거나 동시에 사용할 수 있는 것은 아닙니다. 트래픽 급증이 서비스에 과도한 부담을 주지 않도록 부하가 수평으로 조정됩니다.

 

로드 밸런싱

많은 동시 소비자가 대기열에서 읽는 동안 개별 메시지에 대한 독점 소유권을 안전하게 주장할 수 있습니다.

 

주제 및 구독

게시자와 구독자 간의 1:n 관계를 활성화하면 구독자가 게시된 메시지 스트림에서 메시지를 선택할 수 있습니다.

트랜잭션을 사용하면 단일 원자성 트랜잭션의 컨텍스트 내에서 많은 작업을 수행할 수 있습니다. 예를 들어 트랜잭션의 매개 변수 내에서 다음 작업을 수행할 수 있습니다.

• 하나의 대기열에서 메시지를 얻어야 합니다.
• 처리 결과를 하나 이상의 대기열에 게시해야 합니다.
• 입력 메시지는 원래 대기열에서 이동해야 합니다.

 

입력 메시지의 성공적인 정착을 포함하여 성공적인 경우에만 다운스트림 소비자에게 결과가 명백해져 의미론을 한 번만 처리할 수 있습니다. 더 큰 솔루션 맥락에서 보상 트랜잭션 패턴은 이 트랜잭션 모델에서 확고한 기반을 가지고 있습니다.

 

 

메시지 세션

메시지 지연 또는 엄격한 메시지 순서 지정을 요구하는 높은 수준의 프로세스 조정 및 다중 전송을 구현합니다.

서비스 버스의 개념은 Apache ActiveMQ와 같은 다른 메시지 브로커의 개념과 유사합니다. 한 가지 중요한 차이점은 서비스 버스가 PaaS(Platform-as-a-Service) 솔루션이기 때문에 다음 작업을 수행할 걱정이 없다는 것입니다. 애저가 그 심부름들을 대신해 줍니다.

• 하드웨어 오작동 우려
• 제품 또는 운영 체제 패치 유지
• 디스크 공간 관리 및 로그 추가
• 백업 관리
• 백업 시스템으로 전환

 

 

큐

대기열은 메시지를 보내고 받는 데 모두 사용됩니다. 메시지는 수신 응용 프로그램이 메시지를 수락하고 처리할 준비가 될 때까지 대기열에 보관됩니다.

Azure 서비스 버스 : 개념, 설명, 예제, 방법 1

 

 

도착하면 대기열의 메시지가 정렬되고 타임스탬프가 표시됩니다. 네임스페이스가 영역을 사용하도록 설정된 경우 메시지는 브로커가 수락한 후 항상 삼중 이중 저장소에 보관됩니다. 클라이언트가 메시지를 승인된 것으로 보고할 때까지 서비스 버스는 이 메시지를 메모리 또는 기타 휘발성 저장소에 보관합니다.

풀 모드 메시지 배달은 요청에 대한 응답으로만 메시지를 보냅니다. 일부 다른 클라우드 대기열의 바쁜 폴링 모델과 달리 풀 작업은 시간이 오래 걸릴 수 있으며 메시지가 준비되었을 때만 완료됩니다.

 

 

토픽

메시지를 보내고 받는 데도 항목을 사용할 수 있습니다. 포인트 투 포인트 통신의 경우 큐가 자주 사용됩니다. 그러나 항목은 응용프로그램 게시/구독에 유용합니다.

Azure 서비스 버스 : 개념, 설명, 예제, 방법 2

 

토픽에 대해 여러 개의 독립 구독이 가능합니다. 이러한 구독은 주제에 첨부되며 그렇지 않으면 수신자 측의 대기열처럼 정확하게 작동합니다. subject로 발송된 각 메시지는 복사되어 해당 항목의 가입자에게 발송될 수 있습니다. 명명된 엔티티는 구독입니다. 구독은 무기한으로 유지되도록 설계되었지만 만료된 후 자동으로 삭제되도록 설정할 수 있습니다. 연결이 활성화된 동안만 활성화되는 Java Message Service(JMS) API를 사용하여 Service Bus Premium에서 휘발성 구독을 구축할 수도 있습니다.

헤드라인 등록에서 규칙을 설정할 수 있습니다. 헤드라인 등록에 복사할 메시지의 전제 조건을 지정하는 필터와 메시지 정보를 변경하는 선택적 작업이 헤드라인 등록 규칙에 모두 포함됩니다. 자세한 내용은 항목 필터 및 작업을 참조하십시오.

다음과 같은 상황에서 이 기능을 사용해야 합니다:

• 주제에 등록된 모든 메시지를 수신하도록 헤드라인 등록을 설정해서는 안 됩니다.
• 메시지가 헤드라인 등록을 통과할 때 추가 메타데이터로 메시지를 표시하려고 합니다.

 

 

네임스페이스

모든 메시징 구성요소는 네임스페이스(큐 및 항목)에 포함되어 있습니다. 네임스페이스는 많은 큐와 주제를 포함할 수 있으므로 네임스페이스는 종종 응용프로그램의 컨테이너 역할을 합니다.

네임스페이스는 다른 브로커의 용어로 서버와 비교할 수 있지만 개념이 직접적으로 동일하지는 않습니다. 서비스 버스 네임스페이스는 수십 개의 All-Active 가상 시스템으로 구성된 대규모 클러스터의 고유한 용량 슬라이스입니다. 선택적으로 세 개의 Azure 가용성 영역에 걸쳐 있을 수 있습니다. 따라서 메시지 브로커를 대규모로 실행함으로써 모든 가용성 및 견고성 이점을 얻을 수 있습니다. 그리고 근본적인 복잡성에 대해 걱정할 필요가 없습니다. 서비스 버스는 서버가 없는 메시징입니다.

 

고급 기능

또한 서비스 버스에는 까다로운 메시징 문제를 처리할 수 있는 정교한 기능이 포함되어 있습니다. 이러한 주요 특성은 아래 섹션에서 설명합니다:

 

메시지 세션

세션을 사용하여 서비스 버스에서 선입선출(FIFO) 보증을 구현합니다. 연결된 메시지의 무제한 시퀀스를 결합하고 체계적으로 처리하는 것은 메시지 세션에 의해 가능합니다.

 

자동 전달

자동 전달 기능을 사용하여 큐 또는 헤드라인 등록을 동일한 네임스페이스의 일부인 다른 큐 또는 항목에 연결할 수 있습니다. 자동 전달이 활성화되면 서비스 버스는 첫 번째 구독(소스) 또는 대기열(주제)에서 두 번째 대기열(주제)(대상)로 메시지를 자동으로 이동합니다.

 

데드 레터링

DLQ(Dead-letter Queues)는 서비스 버스에서 지원되며, 처리하거나 수신자에게 배달할 수 없는 메시지를 저장하는 데 사용됩니다. 그런 다음 DLQ에서 메시지를 검사하고 제거할 수 있습니다.

 

예약된 배달

추가 처리를 위해 메시지를 대기열 또는 항목에 추가할 수 있습니다. 예를 들어 특정 시간에 시스템에서 작업을 처리할 수 있도록 작업을 계획합니다.

 

메시지 연기

대기열 또는 구독 클라이언트가 처리하려고 하지만 응용 프로그램의 고유한 조건으로 인해 지금은 처리할 수 없는 메시지를 수신하면 엔티티는 나중으로 메시지 검색을 연기할 수 있습니다. 메시지가 옆에 있지만 대기열 또는 헤드라인 등록에 남아 있습니다.

 

트랜잭션

트랜잭션은 두 개 이상의 작업을 결합하여 실행 범위를 만듭니다. 트랜잭션의 맥락에서 서비스 버스는 단일 메시징 엔터티(큐, 주제 또는 구독)에 대한 그룹화 작업을 지원합니다.

 

필터링 및 작업

가입자는 제목에서 수신할 메시지를 지정할 수 있습니다. 이러한 메시지는 하나 이상의 명명된 등록 규칙 형식으로 설명됩니다. 헤드라인 등록은 각 일치 규칙 조건에서 메시지의 복사본을 생성하며, 각 일치 규칙에 대해 주석이 다르게 표시될 수 있습니다.

 

유휴 시 자동 삭제

대기열이 자동으로 삭제되는 "아이돌 시 자동 삭제"를 사용하여 유휴 간격을 정의할 수 있습니다. 대기열에 활동이 있으면 간격이 재설정됩니다. 최소 5분입니다.

 

중복 탐지

다중 탐지는 발신인이 동일한 메시지를 다시 전송할 수 있게 함으로써 이러한 경우의 불확실성을 제거하며, 클라이언트가 전송 작업의 결과를 불확실하게 만드는 오류가 발생할 경우 대기열 또는 항목이 중복된 사본을 삭제합니다. 

 

공유 액세스 서명(SAS), 역할 기반 액세스 제어 및 관리 ID

Azure 리소스에 대해 서비스 버스는 관리 ID, 역할 기반 액세스 제어 및 공유 액세스 서명(SAS)과 같은 보안 프로토콜을 제공합니다.

 

지리적 재해 복구

지리적 재해 복구를 사용하면 다른 Azure 지역 또는 데이터 센터에서 해당 지역 또는 데이터 센터가 다운될 때 데이터 처리를 계속할 수 있습니다.

 

보안.

서비스 버스는 표준 HTTP/REST 및 AMQP(Advanced Message Queuing Protocol) 1.0 프로토콜을 지원합니다.

 

표준 및 프로토콜 준수

개방형 ISO/IEC 표준인 AMQP(Advanced Messaging Queueing Protocol) 1.0은 서비스 버스를 위한 기본 와이어 프로토콜입니다. 고객은 이를 사용하여 ActiveMQ 또는 RabbitMQ와 같은 로컬로 설치된 브로커와 상호 작용하는 프로그램을 만들 수 있습니다. 이러한 추상화를 구성하려면 AMQP 프로토콜 가이드에서 포괄적인 지침을 제공합니다.

Java/Jakarta EE용 JMS(Java Message Service) 2.0 API는 Service Bus Premium과 완벽하게 호환됩니다. 또한 서비스 버스 표준은 JMS 1.1의 대기열 중심 하위 집합을 지원합니다. JMS는 잘 알려진 Spring 프레임워크를 포함하여 광범위한 프로그램 및 프레임워크와 함께 작동하는 전형적인 메시지 브로커 추상화입니다. 대기열 및 주제 구조를 재구성하고, 클라이언트 제공자 종속성을 업데이트하고, 다른 브로커를 대체하도록 Azure Service Bus를 구성하기만 하면 됩니다. 자세한 내용은 ActiveMQ 마이그레이션 안내서를 참조하십시오.

 

클라이언트 라이브러리

Azure SDK는 완전히 지원되는 서비스 버스 클라이언트 라이브러리를 제공합니다.

• .NET Azure 서비스 버스
• 자바의 Azure 서비스 버스용 라이브러리
• Azure 서비스 버스용 Java JMS 2.0 공급자
• Azure 서비스 버스의 JavaScript 및 TypeScript 모듈
• Microsoft Azure 서비스 버스 라이브러리

 

AMQP 1.0 호환 프로토콜 클라이언트는 Azure Service Bus의 기본 프로토콜인 AMQP 1.0을 사용할 수 있습니다. 서비스 버스 호환성을 구체적으로 보여주는 여러 오픈 소스 AMQP 클라이언트에 사용할 수 있는 샘플이 있습니다. AMQP 1.0 클라이언트에서 서비스 버스 기능을 직접 사용하는 방법은 AMQP 1.0 프로토콜 가이드를 참조하십시오.

 

 

통합

서비스 버스는 다음과 같은 다양한 Azure 및 Microsoft 서비스와 원활하게 연결됩니다:

• 이벤트 그리드
• 로직 앱
• Azure 함수
• 파워 플랫폼
• 다이내믹스 365
• Azure 스트림 분석

 

 

Azure 버스 서비스의 특징

클라우드에서 비즈니스 메시징 간소화

앱과 서비스 간에 매우 안정적인 클라우드 메시징이 필요한 경우 서비스 버스를 이용하십시오. 모든 Azure 지역에서 액세스할 수 있는 이 완벽하게 관리되는 솔루션은 서버 관리 및 라이센스 책임을 제거합니다. 비동기 작업, FIFO(구조화된 선입선출) 메시징 및 게시/구독 기능은 클라이언트와 서버 간의 메시징을 중개할 때 더 많은 자유를 제공합니다.

 

확장 가능한 클라우드 솔루션 구축

비동기식 메시징 패턴의 장점을 활용하여 신뢰성을 갖춘 엔터프라이즈 시스템을 확장할 수 있습니다. 서비스 버스 통신을 Azure SQL Database, Azure 스토리지 및 Web Apps와 같은 클라우드 리소스와 통합하여 가변 부하에서도 안정적인 운영을 보장하고 간헐적인 장애에도 견딜 수 있는 복원력을 제공합니다.

 

복잡한 메시징 워크플로우 구현

복잡한 라우팅으로 메시징 구조를 구축하여 가용성을 높입니다. 서비스 버스를 활용하여 메시지 전달을 다운스트림 시스템으로 팬아웃하고 다양한 가입자에게 메시지를 전달합니다.

 

AMQP를 통해 서비스 버스와 통신할 수 있도록 기존 Java Message Service(JMS 2.0) 응용 프로그램 사용

사내 또는 서비스형 인프라(IaaS) 환경에서 메시징 브로커 실행과 관련된 라이센스 가격이나 운영 비용에 대한 걱정 없이 기본 JMS 지원을 통해 완벽하게 관리되는 기업 메시징 솔루션을 구입할 수 있습니다.

 

 

서비스 버스 가격

프라이빗 및 퍼블릭 클라우드 환경 간 연결

Azure Service Bus라는 메시징 아키텍처는 애플리케이션 사이에 서서 확장성과 복원력을 높이기 위한 메시지 교환을 가능하게 합니다.

자세한 내용을 보려면 여기를 클릭하십시오.

 

 

결론

메시지 대기열 및 게시-구독 항목은 네임스페이스에서 완전히 관리되는 엔터프라이즈 메시지 브로커 Azure Service Bus의 기능입니다. 서비스 버스를 사용하여 애플리케이션과 서비스를 서로 분리할 때 다음과 같은 이점을 얻을 수 있습니다:

• 경쟁사 직원들에게 업무를 분배합니다.
• 서비스 및 애플리케이션 경계를 넘어 안전한 방식으로 데이터와 제어를 교환합니다.
• 높은 수준의 신뢰성을 요구하는 트랜잭션 작업을 조정합니다.

 

메시지는 다양한 앱과 서비스 간에 데이터를 이동하는 데 사용됩니다. 메시지는 메타데이터가 있는 데이터로 채워진 컨테이너입니다. JSON, XML, Apache Avro 및 일반 텍스트와 같은 일반적인 형식으로 저장된 구조화된 데이터를 포함하여 모든 유형의 정보를 데이터로 사용할 수 있습니다.