• 8분

Microsoft Azure 내의 여러 개를 포함해 배포 애플리케이션의 안정성을 높이는 데 도움이 되는 많은 통신 플랫폼이 있습니다. 각 플랫폼은 서로 다른 용도로 사용되는 도구입니다. 애플리케이션의 각 요구 사항에 적합한 도구를 선택하는 것이 중요합니다. Azure Service Bus 옵션을 살펴보세요.

제안된 Contoso Bikes 주문 및 추적 애플리케이션의 분산 아키텍처에는 웹 사이트, 데이터 스토리지 및 백 엔드 서비스를 비롯한 여러 구성 요소가 필요합니다. 다양한 방법으로 애플리케이션의 구성 요소를 함께 바인딩할 수 있으며, 단일 애플리케이션으로 여러 기술을 활용할 수 있습니다.

새로운 Contoso Bicycles 애플리케이션에서 사용할 기술을 결정해야 합니다. 첫 단계는 여러 부분 간에 통신이 이뤄지는 각 위치를 평가하는 것입니다. 일부 구성 요소는 애플리케이션이 해당 작업을 수행할 수 있도록 적시에 실행되어야 합니다. 일부 구성 요소는 중요할 수 있지만 시간이 관건은 아닙니다. 마지막으로, 모바일 앱 알림 같은 기타 구성 요소는 좀 더 선택적입니다.

메시지 및 이벤트 중 결정

메시지와 이벤트는 모두 한 구성 요소에서 다른 구성 요소로 전송된 데이터의 패키지인 datagrams입니다. 이들은 처음에는 미묘하게 다르지만 이러한 차이 때문에 애플리케이션을 설계하는 방법이 크게 다를 수 있습니다.

메시지

분산 앱 용어에서 메시지를 규정하는 특성은 애플리케이션의 전체 무결성이 수신되는 메시지에 의존할 수도 있다는 점입니다. 워크플로의 배턴을 다른 구성 요소에 전달하는 하나의 구성 요소로 메시지 전송을 고려할 수 있습니다. 전체 워크플로가 중요한 비즈니스 프로세스일 수 있으며, 메시지는 구성 요소를 함께 고정하는 본드가 됩니다.

일반적으로 메시지에는 실제 데이터뿐만 아니라 데이터에 대한 참조(예: ID 또는 URL)도 포함됩니다. 데이터그램의 일부로 데이터를 전송하면 참조를 전송할 때보다 더 안정적입니다. 메시지 아키텍처는 메시지 배달을 보장하며, 추가 조회가 필요하지 않기 때문에 메시지가 안정적으로 처리됩니다. 그러나 너무 많은 데이터를 전송하면 수신 구성 요소가 불필요한 작업을 수행해야 하므로 이를 방지하기 위해 전송 애플리케이션은 어떤 데이터를 포함하는지 정확히 알아야 합니다. 이러한 관점에서 메시지 발신자와 수신자는 종종 엄격한 데이터 계약을 체결하기도 합니다.

Contoso Bikes의 새 아키텍처에서는 주문이 완료되면 회사에서 메시지를 사용할 가능성이 높습니다. 웹 프런트 엔드 또는 모바일 앱이 백 엔드 처리 구성 요소로 메시지를 보냅니다. 백 엔드에서는 고객과 가장 가까운 매장으로 라우팅하고 신용 카드를 청구하는 등의 단계가 이루어집니다.

이벤트

이벤트는 무언가가 발생했다는 알림을 트리거합니다. 이벤트는 메시지보다 “간단하며” 브로드캐스트 통신에 가장 많이 사용됩니다.

이벤트에는 다음과 같은 특성이 있습니다.

• 이벤트가 여러 수신자에게 발신되거나 전혀 발신되지 않을 수도 있습니다.
• 이벤트는 종종 각 게시자에 대한 다수의 구독자를 “팬아웃”하거나 포함해야 합니다.
• 이벤트 게시자는 수신 구성 요소가 수행하는 작업에 대해 어떠한 기대도 하지 않습니다.

자전거 부품 체인은 상태 변경에 대해 사용자에게 알리기 위해 이벤트를 사용할 가능성이 높습니다. 완전한 서버리스 솔루션을 위해 상태 변경 이벤트를 Azure Event Grid에 이어 Azure Functions 및 Azure Notification Hubs에 보낼 수 있습니다.

통신 플랫폼이 일반적으로 둘 중 하나만 처리하도록 설계되었기 때문에 이벤트와 메시지 간의 이 차이는 당연한 것입니다. Service Bus는 메시지를 처리하도록 설계되었습니다. 이벤트를 전송하려는 경우 Event Grid를 선택할 가능성이 있습니다.

Azure에는 Azure Event Hubs도 있지만 분석에 사용된 특정 유형 통신의 높은 흐름 스트림에 가장 많이 사용됩니다. 예를 들어, 제조 창고에 네트워크로 연결된 센서가 있는 경우 Azure Stream Analytics와 연결된 Event Hubs를 사용하여 원하지 않는 화재 또는 구성 요소 마모를 나타내는 온도 변화의 패턴을 지켜볼 수 있습니다.

Service Bus 토픽 및 큐

Azure Service Bus는 큐 및 토픽이라는 두 가지 방법으로 메시지를 교환할 수 있습니다.

큐란?

Service Bus 큐는 메시지용 간단한 임시 스토리지 위치입니다. 전송 구성 요소는 큐에 메시지를 추가합니다. 대상 구성 요소는 큐의 앞에서 메시지를 선택합니다. 일반적인 상황에서 각 메시지는 받는 사람 한 명만 수신합니다.

큐는 많은 요구에서 대상 구성 요소를 보호하기 위해 원본 및 대상 구성 요소를 분리합니다.

피크 타임 동안 메시지는 대상 구성 요소가 메시지를 처리할 수 있는 것보다 빠르게 들어올 수도 있습니다. 원본 구성 요소가 대상에 직접 연결되지 않으므로 원본은 영향을 받지 않고 큐는 증가합니다. 대상 구성 요소는 메시지를 처리할 수 있으므로 큐에서 메시지를 제거합니다. 수요가 감소하면 대상 구성 요소가 따라잡을 수 있고 큐가 단축됩니다.

큐는 시스템에 리소스를 추가하지 않고서도 이처럼 많은 요구에 응답할 수 있습니다. 그러나 신속하게 처리해야 하는 메시지의 경우 대상 구성 요소의 추가 인스턴스를 만들면 로드를 공유할 수 있습니다. 각 메시지는 하나의 인스턴스에서만 처리됩니다. 이 방법은 실제로 리소스가 필요한 구성 요소에 리소스를 추가하는 방식으로만 전체 애플리케이션을 효과적으로 스케일링할 수 있습니다.

항목이란?

Service Bus 토픽은 큐와 유사하지만 여러 구독이 있을 수 있습니다. 즉, 각 메시지가 여러 수신자에게 배달되도록 여러 대상 구성 요소가 특정 토픽을 구독할 수 있습니다. 구독은 관련이 있는 메시지만 수신하려면 토픽에서 메시지를 필터링할 수도 있습니다. 구독은 큐와 동일한 분리된 통신을 제공하고 동일한 방식으로 많은 요구에 응답합니다. 하나를 초과하는 대상 구성 요소에 각 메시지를 전달하려는 경우 토픽을 사용하세요.

Service Bus 큐 및 스토리지 큐

두 개의 Azure 서비스에는 Service Bus 및 Azure Storage 메시지 큐가 포함됩니다. 일반적으로 스토리지 큐는 사용이 간단하지만 Service Bus 큐에 비해 정교하지 못하며 유연성도 떨어집니다.

Service Bus 큐의 주요 장점은 다음과 같습니다.

• Azure Storage 큐 메시지당 64KB가 아닌 256KB(표준 계층) 또는 100MB(프리미엄 계층)의 큰 메시지 크기를 지원합니다.
• 최대 한 번 및 최소 한 번 전송을 모두 지원합니다. 메시지가 손실될 가능성이 매우 작거나 메시지가 두 번 처리될 가능성이 매우 작은 경우 중에서 선택합니다.
• FIFO(선입선출) 순서를 보장합니다. 메시지는 추가되는 순서와 동일한 순서로 처리됩니다. FIFO는 큐의 정상 작업이지만 조직이 시퀀스된 또는 예약된 메시지를 설정하거나 시스템 충돌과 같은 중단 시에는 기본 FIFO 패턴이 변경됩니다. 자세한 내용은 Azure Storage 큐 및 Azure Service Bus 큐 비교를 참조하세요.
• 한 트랜잭션에서 여러 메시지를 그룹화할 수 있습니다. 트랜잭션에서 메시지 하나가 전송하지 못한다고 해서 트랜잭션의 모든 메시지가 전송되지 않는 것은 아닙니다.
• 역할 기반 보안을 지원합니다.
• 큐를 계속 폴링하려면 대상 구성 요소가 필요하지 않음

스토리지 큐의 이점은 다음과 같습니다.

• 무제한 큐 크기 지원(대 Service Bus 큐에 대한 80GB 제한)
• 모든 메시지의 로그 유지 관리

통신 기술을 선택하는 방법

Azure에서 제공하는 다양한 개념 및 구현을 살펴보았습니다. 다음으로 각 통신마다 의사 결정 과정이 어떤지 살펴보겠습니다.

고려 사항

메시지를 보내고 받는 방법을 선택할 때 다음 질문을 고려해야 합니다.

• 통신이 이벤트인가요? 그렇다면 Event Hubs 또는 Event Grid를 사용하는 것이 좋습니다.

• 단일 메시지가 하나를 초과하는 대상에 배달되어야 하나요? 그렇다면 Service Bus 항목을 사용합니다. 아닌 경우에는 Service Bus 큐를 사용합니다.

큐: Service Bus와 스토리지 비교

큐가 필요하다고 결정했다면 선택 범위를 더 좁혀야 합니다.

다음 경우에 Service Bus 큐를 선택합니다.

• 최대 1회(At-Most-Once) 전송을 보장해야 합니다.
• FIFO 보장이 필요합니다(기본 FIFO 순서를 선점하는 다른 설정이 없는 경우).
• 메시지를 트랜잭션으로 그룹화해야 합니다.
• 큐를 폴링하지 않고 메시지를 수신하려고 합니다.
• 큐에 역할 기반 액세스 권한을 제공해야 합니다.
• 표준 계층의 경우 64KB보다 크지만 256KB보다 작고, 프리미엄 계층의 경우 100MB보다 작은 메시지를 처리해야 합니다.
• 큐 크기는 80GB보다 크게 증가하지 않습니다.
• 일괄 처리 메시지를 게시하고 사용할 수 있기를 원할 것입니다.

다음 경우에는 스토리지 큐를 선택합니다.

• 특정 추가 요구 사항 없는 간단한 큐 필요
• 큐를 통과하는 모든 메시지의 감사 추적이 필요합니다.
• 큐의 크기가 80GB를 초과할 것으로 예상됩니다.
• 큐 내부의 메시지 처리 진행률을 추적해야 합니다.

분산 앱의 구성 요소는 직접 통신할 수 있지만 Azure Event Hubs 또는 Azure Event Grid 같은 중간 통신 플랫폼을 사용하여 종종 해당 통신의 안정성을 높일 수 있습니다.

Event Hubs와 Event Grid는 이벤트만 받는 사람에게 알리고 해당 이벤트와 연결된 원시 데이터를 포함하지 않는 이벤트용으로 설계되었습니다. Azure Event Hubs는 높은 흐름 분석 유형의 이벤트용으로 설계되었습니다.

Azure Service Bus 및 스토리지 큐는 애플리케이션 워크플로의 핵심 부분을 바인딩하는 데 사용할 수 있는 메시지를 위한 것입니다.

요구 사항이 간단한 경우, 하나의 대상에만 각 메시지를 전송하려는 경우 또는 최대한 신속하게 코드를 작성하려는 경우, 스토리지 큐가 가장 좋은 선택지일 수도 있습니다. 그렇지 않은 경우 Service Bus 큐에서 더 많은 옵션과 유연성을 제공합니다.

여러 구독자에게 메시지를 보내려는 경우 Service Bus 토픽을 사용합니다.