느슨하게 결합된 메시징을 위한 Azure Service Bus
큐와 토픽이 포함된 Service Bus 네임스페이스를 만들고, 애플리케이션에서 메시지를 보내고 받으며, 실패한 메시지를 처리할 배달 못한 편지 큐를 구성합니다.
느슨하게 결합된 메시징을 위한 Azure Service Bus은(는) CoddyKit의 무료 Azure Fundamentals 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Azure Fundamentals 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Azure Fundamentals 강의에는 총 4개의 강의가 포함되어 있습니다.
메시징으로 결합도를 낮추는 이유
강하게 결합된 아키텍처에서는 서비스가 서로를 동기식으로 호출하므로 다운스트림 서비스가 느리거나 중단되면 호출 측도 차단되거나 실패합니다. 메시징 queue는 생산자와 소비자 사이에 비동기 버퍼를 도입하므로 느린 다운스트림 서비스의 장애가 업스트림으로 연쇄되지 않습니다. Azure Service Bus는 엔터프라이즈급 메시징 서비스로, 안정적인 전달, 순서 보장, 배달 못한 메시지 처리 기능과 함께 queue(지점 간) 및 topic(게시-구독)을 제공합니다.
Service Bus 네임스페이스 및 계층
Service Bus namespace는 모든 메시징 엔터티(queue 및 topic)를 담는 최상위 컨테이너이며 FQDN 엔드포인트(예: myns.servicebus.windows.net)를 제공합니다. namespace에는 세 가지 계층이 있습니다. Basic(queue만 지원, topic은 지원하지 않으며 메시지 크기 최대 256 KB), Standard(queue와 topic, 최대 256 KB), Premium(queue와 topic, 최대 100 MB 메시지, 전용 용량, VNet 통합, 지역 재해 복구)입니다. SLA가 보장되는 성능이 필요한 프로덕션 워크로드에는 Premium이 필요합니다.
# Create a Service Bus namespace (Standard tier)
az servicebus namespace create \
--resource-group myRG \
--name myservicebusns \
--location eastus \
--sku Standardqueue: 지점 간 메시징
Service Bus queue는 메시지를 FIFO 순서로 저장하고 각 메시지를 정확히 하나의 소비자에게 전달합니다. 소비자는 peek-lock 메커니즘을 사용하여 메시지를 수신합니다. 즉, 메시지를 처리하는 동안 다른 소비자에게 일시적으로 표시되지 않습니다. 소비자가 처리를 성공적으로 완료하면 CompleteMessage()를 호출하여 queue에서 메시지를 제거합니다. 처리에 실패하면 AbandonMessage()를 호출하고, 메시지는 다시 표시되어 다른 시도에서 처리될 수 있습니다. 설정 가능한 전달 시도 횟수를 초과한 처리 불가 메시지는 배달 못한 메시지 queue(DLQ)로 이동합니다.
# Create a Service Bus queue with DLQ enabled
az servicebus queue create \
--resource-group myRG \
--namespace-name myservicebusns \
--name orders \
--max-delivery-count 5 \
--default-message-time-to-live P7D \
--dead-lettering-on-message-expiration truetopic 및 구독
topic은 게시-구독 패턴을 구현합니다. 생산자가 topic으로 메시지를 보내면 해당 topic의 여러 구독이 각각 메시지 사본을 수신합니다. 구독에는 필터(SQL 또는 상관 관계 표현식)를 설정하여 메시지의 일부만 수신하도록 할 수 있습니다. 예를 들어 HighPriority 구독은 Priority 속성이 High와 같은 메시지만 수신합니다. 이를 통해 하나의 topic에서 여러 다운스트림 서비스로 이벤트를 분기하고, 각 서비스가 서로 다른 이벤트 부분 집합에 관심을 갖도록 할 수 있습니다.
# Create a topic and two subscriptions with filters
az servicebus topic create \
--resource-group myRG \
--namespace-name myservicebusns \
--name order-events
az servicebus topic subscription create \
--resource-group myRG \
--namespace-name myservicebusns \
--topic-name order-events \
--name high-priority-sub
az servicebus topic subscription rule create \
--resource-group myRG \
--namespace-name myservicebusns \
--topic-name order-events \
--subscription-name high-priority-sub \
--name PriorityFilter \
--filter-sql-expression 'Priority = '"'"'High'"'"''메시지 보내기 및 받기
Azure Service Bus SDK는 메시지를 보내고 받기 위한 ServiceBusClient를 제공합니다. 보내려면 ServiceBusSender를 만들고 SendMessageAsync()를 호출합니다. 받으려면 ServiceBusReceiver를 만들고 ReceiveMessageAsync()를 호출하는 방식(가져오기 기반)을 사용하거나, 이벤트 처리기가 있는 ServiceBusProcessor를 사용하여 푸시 기반의 지속적인 처리를 수행합니다. Service Bus SDK에서 DefaultAzureCredential을 사용하면 연결 문자열이 필요하지 않으므로 암호 없는 패턴을 유지할 수 있습니다.
# Python: Send a message to a Service Bus queue
from azure.servicebus import ServiceBusClient, ServiceBusMessage
from azure.identity import DefaultAzureCredential
credential = DefaultAzureCredential()
client = ServiceBusClient(
fully_qualified_namespace='myservicebusns.servicebus.windows.net',
credential=credential
)
with client.get_queue_sender(queue_name='orders') as sender:
msg = ServiceBusMessage('{ 'orderId': '12345', 'amount': 99.99 }')
sender.send_messages(msg)
print('Message sent')배달 못한 메시지 queue
배달 못한 메시지 queue(DLQ)는 전달할 수 없는 메시지를 자동으로 받는 하위 queue입니다. 메시지가 최대 전달 횟수를 초과하거나, 만료되거나(TTL 경과), topic 구독 필터 평가에 실패하면 배달 못한 메시지로 처리됩니다. DLQ를 모니터링하는 것은 필수입니다. DLQ가 증가한다는 것은 처리에 체계적인 문제가 있음을 나타냅니다. DLQ 메시지에는 원래 내용과 함께 근본 원인을 진단하는 데 도움이 되도록 Service Bus가 추가한 배달 못한 메시지 사유 및 설명 속성이 유지됩니다.
# Read messages from the dead-letter queue
az servicebus queue show \
--resource-group myRG \
--namespace-name myservicebusns \
--name 'orders/$DeadLetterQueue' \
--query 'countDetails.deadLetterMessageCount'순서 지정을 위한 메시지 세션
세션을 사용하면 동일한 논리적 그룹에 속한 메시지의 엄격한 순서를 보장할 수 있습니다. 각 메시지에는 SessionId(예: 고객 ID 또는 주문 ID)가 지정되며, 세션을 인식하는 소비자는 특정 세션의 모든 메시지를 FIFO 순서로 독점 수신합니다. 세션은 특정 주문의 모든 이벤트 처리와 같이 단계가 순서대로 실행되어야 하는 워크플로에 필수적입니다: 생성됨 → PaymentReceived → 배송됨 → 배달됨. 세션은 queue 또는 구독을 만들 때 사용하도록 설정합니다.
Service Bus와 이벤트 그리드 및 이벤트 허브 비교
이 세 가지 Azure 메시징 서비스는 자주 혼동됩니다. Service Bus는 순서 지정, 세션, DLQ를 지원하는 안정적인 트랜잭션 엔터프라이즈 메시징용으로, 주문 처리, 금융 거래, 워크플로 오케스트레이션에 적합합니다. 이벤트 그리드는 반응형 이벤트 라우팅(Blob이 업로드되거나 VM이 삭제되는 경우)에 사용되며 여러 처리기로 분기할 수 있지만 순서 지정이나 재생은 지원하지 않습니다. 이벤트 허브는 초당 수백만 개의 이벤트를 처리하는 고처리량 이벤트 스트리밍용이며 재생 기능을 제공하므로 IoT 원격 분석과 로그 수집에 적합합니다. 순서, 처리량, 내구성 요구 사항을 기준으로 선택하세요.
지역 재해 복구
Service Bus 지역 재해 복구(Geo-DR)는 namespace 메타데이터(queue, topic, 구독, 액세스 정책)를 보조 지역에 복제합니다. 쌍으로 구성된 지역은 하나의 별칭 호스트 이름을 공유합니다. 주 지역에 장애가 발생하면 장애 조치를 시작하고 별칭이 보조 지역으로 확인되도록 합니다. Standard 계층에서는 메시지 데이터(처리 중인 메시지)가 복제되지 않으며, Premium 계층의 Geo-DR에서만 메시지가 복제된다는 점에 유의하세요. 업무상 중요한 메시징에는 Premium + Geo-DR을 사용하여 RTO 및 RPO 요구 사항을 충족하세요.
확장 및 분할된 엔터티
고처리량 시나리오에서는 queue와 topic을 만들 때 분할을 사용하도록 설정하세요. 분할된 엔터티는 내부적으로 여러 메시지 브로커와 저장소 조각을 사용하여 처리량 용량을 늘립니다. Standard 계층에서 분할된 엔터티의 전체 크기는 최대 80 GB입니다. 각 메시지는 PartitionKey 속성에 따라 파티션으로 라우팅되며(세션이 사용되도록 설정된 경우 기본값은 세션 ID), 분할 여부는 생성 시 결정하는 일회성 선택입니다. 기존 queue는 분할할 수 없습니다. 분할의 복잡성 없이 가장 높은 수준의 보장된 처리량을 사용하려면 Premium 계층을 이용하세요.
# Create a partitioned queue (Standard tier)
az servicebus queue create \
--resource-group myRG \
--namespace-name myservicebusns \
--name orders-partitioned \
--enable-partitioning trueService Bus 상태 모니터링
Azure Monitor에서 모니터링해야 할 주요 Service Bus 메트릭은 다음과 같습니다. Active Messages(queue 깊이 — 깊이가 증가하면 소비자 지연을 나타냄), Dead-lettered Messages(처리 실패), Server Errors 및 User Errors(인증 및 제한 문제), Incoming Requests(전체 처리량)입니다. 배달 못한 메시지 queue가 임계값을 초과하여 증가하거나 활성 메시지가 일정 시간 동안 소비되지 않을 때 운영 팀에 알림이 전송되도록 메트릭 경고를 구성하세요.
빠른 확인
이 레슨에서 다룬 Microsoft Azure Fundamentals (AZ-900) 개념에 대한 이해도를 확인해 보세요.
레슨 요약
이 레슨에서는 다음을 배웠습니다. Service Bus queue는 peek-lock 전달 및 실패한 메시지를 위한 배달 못한 메시지 queue를 사용하여 지점 간 메시징을 제공하고, topic과 구독은 필터 규칙을 사용하여 여러 소비자에게 메시지를 분배하며, 세션은 동일한 논리적 그룹에 속한 메시지를 순서대로 처리할 수 있게 합니다. 다음으로는 최신 마이크로서비스를 배포하기 위한 Azure Container Apps를 살펴봅니다.
자주 묻는 질문
“느슨하게 결합된 메시징을 위한 Azure Service Bus” 강의는 무료인가요?
네 — “느슨하게 결합된 메시징을 위한 Azure Service Bus” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Azure Fundamentals 강의 전체를 잠금 해제할 수 있습니다. Azure Fundamentals 강의에는 총 4개의 강의가 포함되어 있습니다.
“느슨하게 결합된 메시징을 위한 Azure Service Bus”에서 뭘 배우나요?
큐와 토픽이 포함된 Service Bus 네임스페이스를 만들고, 애플리케이션에서 메시지를 보내고 받으며, 실패한 메시지를 처리할 배달 못한 편지 큐를 구성합니다. 브라우저에서 직접 실행하는 실습 코드로 Azure Fundamentals을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
Azure Fundamentals을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 Azure Fundamentals은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.
“느슨하게 결합된 메시징을 위한 Azure Service Bus” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 Azure Fundamentals 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 Azure Fundamentals 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.
이 강의의 모든 강의
- 암호 없는 인증을 위한 관리 ID
- 느슨하게 결합된 메시징을 위한 Azure Service Bus
- Azure Container Apps
- 처음부터 끝까지의 개발자 작업 흐름