Azure Service Bus

서비스가 여러 개로 나뉘면 한 서비스의 결과를 다른 서비스에 전달해야 하는 상황이 반복됩니다. 가장 직관적인 방법은 HTTP로 직접 호출하는 것이지만, 받는 쪽이 잠깐이라도 다운되면 요청은 유실됩니다. 재시도 로직을 호출자가 직접 구현해야 하고, 받는 서비스가 여러 개면 호출자가 모든 대상을 일일이 알고 있어야 합니다. 트래픽이 몰릴 때 받는 쪽이 처리 속도를 따라가지 못하면 호출자까지 느려지거나 에러를 맞습니다. 이런 문제는 서비스 수가 늘수록, 트래픽 변동이 클수록 빠르게 악화됩니다.

초기에는 서비스 간 통신을 HTTP 직접 호출로 해결하는 것이 자연스러웠습니다. 서비스가 몇 개 안 될 때는 호출 관계를 머릿속에 그릴 수 있었고, 장애도 드물었습니다. 하지만 서비스가 수십 개로 늘고, 트래픽 패턴이 불규칙해지면서 문제가 달라졌습니다. 하나가 느려지면 호출 체인 전체가 느려지는 연쇄 장애가 반복됐고, 일시적 장애에도 데이터가 유실됐습니다. 호출자마다 재시도, 타임아웃, 폴백 로직을 따로 구현하면서 코드 복잡도는 폭발적으로 늘었습니다. 이런 압력 속에서 '보내는 쪽과 받는 쪽을 분리하고, 중간에 메시지를 안전하게 보관하는 계층'이라는 해법이 엔터프라이즈 메시징 패턴으로 정착했습니다. Service Bus는 이 패턴의 클라우드 네이티브 구현으로, 직접 호출의 강결합에서 벗어나 서비스 간 독립적 확장과 장애 격리를 가능하게 합니다.

Service Bus는 보내는 쪽과 받는 쪽 사이에 메시지를 보관하는 중간 저장소를 둡니다. 보내는 쪽은 메시지를 큐나 토픽에 넣기만 하면 되고, 받는 쪽은 자기 속도에 맞춰 꺼내 갑니다. 큐는 하나의 소비자가 메시지를 가져가는 1:1 구조이고, 토픽은 여러 구독이 같은 메시지를 각각 받는 1:N 구조입니다. 구독에는 필터를 걸 수 있어서, 결제 서비스는 결제 관련 메시지만, 알림 서비스는 알림 관련 메시지만 받도록 분기할 수 있습니다. 메시지를 꺼내 간 소비자가 처리를 완료하면 '완료' 신호를 보내고, 일정 시간 안에 완료 신호가 없으면 Service Bus는 그 메시지를 다시 꺼낼 수 있게 돌려놓습니다. 여러 번 실패한 메시지는 데드 레터 큐로 옮겨져 별도로 확인하고 원인을 추적할 수 있습니다. 이 구조 덕분에 받는 쪽이 잠시 다운되더라도 메시지는 사라지지 않고, 복구되면 이어서 처리됩니다.

Service Bus와 Event Grid는 둘 다 Azure에서 비동기 메시징을 담당하지만, 해결하는 문제가 다릅니다. Service Bus는 메시지가 반드시 전달되고 순서대로 처리되어야 하는 업무 트랜잭션에 맞춰져 있습니다. 큐에 쌓인 메시지를 소비자가 자기 속도로 꺼내가고, 실패하면 재시도하고, 그래도 안 되면 데드 레터 큐에 보관합니다. 반면 Event Grid는 이벤트가 발생했다는 사실을 빠르게 여러 곳에 알리는 데 집중합니다. 저장소에 파일이 올라갔다, 리소스 상태가 바뀌었다 같은 시스템 이벤트를 실시간으로 구독자에게 푸시하는 방식입니다. 따라서 메시지 손실 없이 정확히 한 번 처리해야 하거나, 소비자의 처리 속도를 보호해야 하는 상황이면 Service Bus가 맞습니다. 이벤트 발생을 빠르게 전파하되 개별 이벤트의 재처리나 순서 보장이 덜 중요한 상황이면 다른 선택이 더 적합합니다.

주문 → 결제 → 재고 → 배송처럼 여러 단계를 거치는 업무 흐름에서 각 단계를 큐로 연결하면, 한 단계가 느려져도 앞 단계가 멈추지 않습니다. 이벤트를 여러 팀의 서비스에 동시에 전달해야 할 때는 토픽/구독 구조가 유용합니다. 결제팀은 결제 이벤트만, 마케팅팀은 마케팅 이벤트만 필터링해서 받을 수 있습니다. 반면 단순히 두 서비스가 빠르게 데이터를 주고받기만 하면 되고, 메시지 유실을 감수할 수 있다면 메시지 브로커 없이 직접 통신하는 편이 더 단순합니다. 또한 대용량 스트리밍 데이터를 시간순으로 연속 처리해야 하는 상황에는 메시지 브로커보다는 스트리밍 전용 서비스가 더 적합합니다.

다음에 볼 개념

함께 보면 좋은 개념