큐를 사용하는 메시지 기반 전송 선택
여러분이 음악 공유 애플리케이션의 아키텍처를 계획한다고 가정해 봅시다. 모바일 앱에서 웹 API에 음악 파일이 안정적으로 업로드되는지 확인하려고 합니다. 그리고 아티스트가 컬렉션에 새 음악을 추가하는 경우 새 노래에 대한 세부 정보를 앱에 곧바로 전송하고자 합니다. 이 시나리오는 메시지 기반 시스템을 완벽하게 사용하는 사례이며 Azure는 이 문제에 대한 두 가지 솔루션을 제공합니다.
- Azure Queue Storage
- Azure Service Bus
Azure Queue Storage란?
Queue storage는 Azure Storage를 사용하여 간단한 REST 기반 인터페이스를 통해 전 세계 어디서나 안전하게 액세스할 수 있는 대량의 메시지를 저장하는 서비스입니다. 큐는 수백만 개의 메시지를 포함할 수 있으며, 큐를 소유한 스토리지 계정의 용량 제한만 적용됩니다.
Azure Service Bus 큐란?
Service Bus는 엔터프라이즈 애플리케이션을 위한 메시지 브로커 시스템입니다. 이러한 앱은 종종 여러 통신 프로토콜을 활용하고, 다양한 데이터 계약을 맺고, 높은 보안 요구 사항을 갖고 있으며 클라우드 및 온-프레미스 서비스를 모두 포함할 수 있습니다. Service Bus는 정확하게 이러한 시나리오를 위해 설계된 전용 메시지 인프라를 기반으로 합니다.
두 서비스는 대상이 메시지를 수신할 때까지 보낸 메시지를 보관하는 큐라는 개념을 기반으로 합니다.
Azure Service Bus 토픽이란?
Azure Service Bus 토픽은 큐와 유사하지만 여러 구독자를 포함할 수 있습니다. 메시지가 큐 대신 토픽으로 전송되면 해당 작업을 수행하기 위해 여러 구성 요소가 트리거될 수 있습니다. 음악 공유 애플리케이션에서 노래를 듣는 사용자를 생각해 보세요. 모바일 앱에서 “듣기 완료” 토픽에 메시지를 보낼 수 있습니다. 이 토픽에는 “UpdateUserListenHistory”에 대한 구독과 “UpdateArtistsFanList”에 대한 다양한 구독이 있습니다. 이러한 각 기능은 자체 메시지 사본을 수신하는 다양한 구성 요소에 의해 처리됩니다.
내부적으로 토픽은 큐를 사용합니다. 토픽에 게시하면 메시지가 복사되어 각 구독마다 큐에 드롭됩니다. 큐는 구독을 처리하는 구성 요소가 너무 바빠서 감당하지 못하는 경우에도 각 구독 지점에서 메시지 복사본이 처리되도록 유지된다는 것을 의미합니다.
큐의 이점
큐 인프라는 다음과 같은 방법으로 유용하게 활용할 수 있는 다양한 고급 기능을 지원할 수 있습니다.
향상된 안정성
큐는 분산 애플리케이션이 대상 구성 요소로 전송 보류 중인 메시지를 임시로 스토리지하는 위치로 사용됩니다. 원본 구성 요소는 메시지를 큐에 추가할 수 있고, 대상 구성 요소는 큐 앞에서 메시지를 검색하여 처리할 수 있습니다. 수요가 많을 경우 대상 구성 요소가 처리 준비를 완료할 때까지 메시지가 대기할 수 있기 때문에 큐는 메시지 교환의 안정성을 높입니다.
메시지 전송 보장
큐 시스템은 일반적으로 큐의 각 메시지를 대상 구성 요소에 전송하도록 보장합니다. 그러나 이러한 보장에는 다음과 같은 다양한 방법이 사용될 수 있습니다.
최소 1회(At-Least-Once) 전송: 이 방법에서 각 메시지는 큐에서 메시지를 검색하는 하나 이상의 구성 요소에 전송되도록 보장됩니다. 그러나 특정 상황에서는 동일한 메시지가 두 번 이상 전송될 수 있습니다. 예를 들어 큐에서 메시지를 검색하는 웹앱의 두 인스턴스가 있는 경우 일반적으로 각 메시지는 해당 인스턴스 중 하나로만 이동합니다. 그러나 한 인스턴스가 메시지를 처리하는 데 시간이 오래 걸리고 시간 제한이 만료되면 메시지가 다른 인스턴스에도 전송될 수 있습니다. 웹앱 코드는 이 가능성을 염두에 두고 디자인해야 합니다.
최대 1회(At-Most-Once) 전송: 이 방법에서 각 메시지의 전송은 보장되지 않으며 도착하지 않을 가능성이 약간 있습니다. 그러나 최소 1회(At-Least-Once) 전송과 달리, 메시지가 두 번 전송될 가능성은 없습니다. 이것을 자동 중복 검색이라고도 합니다.
FIFO(선입 선출): 대부분의 메시징 시스템에서 메시지는 일반적으로 추가된 것과 동일한 순서로 큐를 떠나지만 이 전송이 보장되는지 여부를 고려해야 합니다. 배포 애플리케이션에서 메시지를 올바른 순서로 정확하게 처리해야 하는 경우, FIFO 보장을 포함하는 큐 시스템을 선택해야 합니다.
트랜잭션 지원
그룹의 한 메시지에 대한 전송이 실패하면 일부 밀접하게 관련된 메시지 그룹으로 인해 문제가 발생할 수 있습니다.
예를 들어 전자상거래 애플리케이션을 생각해 보세요. 사용자가 구매 단추를 클릭하면 일련의 메시지가 생성되어 다양한 처리 대상으로 전송됩니다.
- 주문 세부 정보가 포함된 메시지가 물류 센터로 전송됩니다.
- 총 금액 및 결제 정보가 포함된 메시지가 신용 카드 프로세서로 전송됩니다
- 영수증 정보가 포함된 메시지가 데이터베이스로 전송되어 고객용 송장이 생성됩니다.
이 경우 모든 메시지가 처리되는지 아니면 일부 메시지만 처리되는지 확인해야 합니다. 신용 카드 메시지가 전송되지 않았는데도 결제 없이 주문이 처리된다면 회사는 곧 망할 것입니다! 두 메시지를 한 트랜잭션으로 그룹화하여 이런 종류의 문제점을 방지할 수 있습니다. 메시지 트랜잭션은 데이터베이스와 마찬가지로 단일 단위로 성공하거나 실패합니다. 신용 카드 정보 메시지 전송이 실패하면 주문 정보 메시지 전송도 실패합니다.
어떤 서비스를 선택해야 할까요?
이 아키텍처의 통신 전략이 메시지인 것을 확인했으므로 Azure Storage 큐 또는 Azure Service Bus를 사용할지 여부를 선택해야 합니다. 두 서비스 모두 메시지를 저장하고 구성 요소 간에 전송하는 데 사용할 수 있습니다. 각각은 약간씩 다른 기능 집합을 가지고 있으며, 해결하려는 문제에 따라 둘 중 하나를 선택해도 되고 둘 다 사용해도 됩니다.
다음의 경우 Service Bus 큐를 사용합니다.
- 최대 1회(At-Most-Once) 전송 보장이 필요합니다.
- FIFO 보장이 필요합니다.
- 메시지를 트랜잭션으로 그룹화해야 합니다.
- 큐를 폴링하지 않고 메시지를 수신하고자 합니다.
- 큐에 역할 기반 액세스 모델을 제공해야 합니다.
- 64KB보다 크고 100KB보다 작은 메시지를 처리해야 합니다. 표준 계층에서 지원하는 최대 메시지 크기는 256KB이고 프리미엄 계층은 100MB입니다.
- 큐 크기가 1TB보다 커지지 않습니다. 표준 계층의 최대 큐 크기는 80GB이고 프리미엄 계층의 경우 1TB입니다.
- 일괄 처리 메시지를 게시 및 사용하고자 합니다.
다음의 경우 Service Bus 토픽을 사용합니다.
- Service Bus 큐에서 제공하는 모든 기능이 필요하고, 메시지를 여러 구독 중 하나로 라우팅할 수 있는 pub-sub 패턴을 구현합니다. 각 구독에는 고유한 독립 수신기가 있습니다.
큐 스토리지는 많은 기능을 제공하지 않지만, 많은 기능이 필요하지도 않은 간단한 선택 옵션입니다. 또한 앱의 요구 사항이 다음과 같은 경우에 가장 좋은 솔루션입니다.
다음의 경우 Queue 스토리지를 사용합니다.
- 큐를 통과하는 모든 메시지의 감사 추적이 필요합니다.
- 큐의 크기가 1TB를 초과할 것으로 예상됩니다.
- 큐 내부의 메시지 처리 진행률을 추적하고자 합니다.
큐는 배포 애플리케이션의 구성 요소 간에 전송되는 메시지에 대한 단순 임시 스토리지 위치입니다. 큐를 사용하여 메시지를 구성하고 필요에 따라 예기치 않은 서지를 정상적으로 처리할 수 있습니다.
단순하고 코딩하기 쉬운 큐 시스템을 원하는 경우 스토리지 큐를 사용해야 합니다. 더 높은 수준의 요구 사항에는 Service Bus 큐를 사용합니다. 단일 메시지에 대한 대상이 여러 개 있지만 큐와 비슷한 동작이 필요한 경우 Service Bus 토픽을 사용합니다.