.NET 서비스 버스 대기열과 Azure 대기열 서비스 중에서 선택
Azure 애플리케이션에 대한 간단한 질문입니다.통신해야 하는 웹 및 작업자 역할이 여러 개 있는 경우 설명서에 Azure 대기열 서비스를 사용하도록 나와 있습니다.
하지만 새로운 .NET 서비스 버스는 이제 대기열도 제공한다고 방금 읽었습니다.이것들은 훨씬 더 상세한 API를 제공하는 것처럼 보이기 때문에 더 강력한 것으로 보입니다..NSB가 더 흥미로워 보이지만 분산 응용 프로그램에서 .NSB를 사용하는 것을 경계하게 만드는 몇 가지 문제가 있습니다(예: 대기열 만료...대기열이 제 시간에 갱신될 것이라는 보장을 할 수 없다면 모든 것을 잃을 수도 있습니다!).
이 두 가지 기술 중 하나를 사용해 본 경험이 있는 사람이 있다면 언제 다른 기술을 선택해야 하는지에 대한 조언을 해 줄 수 있습니다.
저는 서비스 버스가 더 강력해 보이지만, 제 사용 사례는 웹/작업자 역할이 서로 통신할 수 있도록 하는 것이기 때문에 Azure 큐 서비스가 제가 추구하는 것이라고 생각합니다.하지만 저는 코너에 몰리기 전에 그것에 대한 확인을 정말로 찾고 있습니다 :-)
잘 부탁드립니다.
갱신하다
휴식 시간 동안 두 시스템에 대해 자세히 읽어 보았습니다..NET 서비스 버스는 일반적으로 신뢰할 수 있는 메시징 시스템을 제공하기보다는 시스템 통합을 위해 특별히 설계된 것으로 보입니다.Azure 큐는 .NSB 큐가 Azure 자체 내에서 호스팅되는 코드에 적합하지 않은 방식으로 분산되고 매우 안정적이며 확장 가능합니다.
답변 감사합니다.
스토리지 대기열 대 서비스 버스
다음은 제가 이 질문을 통해 생각할 때 고려했던 몇 가지 사항들을 정리한 것입니다.
유용성
지난 11월 스토리지 운영 중단 이후 Azure는 다시는 모든 지역에 코드를 동시에 배포하지 않겠다고 약속했습니다. 이를 시스템에 구축하여 불가능하게 만들었습니다.https://azure.microsoft.com/en-us/blog/final-root-cause-analysis-and-improvement-areas-nov-18-azure-storage-service-interruption/
가용성에 대한 msdn의 설명은 다음과 같습니다.
이미 Azure 스토리지 Blobs 또는 Tables를 사용하고 있고 대기열을 사용하기 시작한 경우 99.9%의 가용성이 보장됩니다.서비스 버스 대기열이 있는 Blobs 또는 Tables를 사용하는 경우 가용성이 낮아집니다.
Azure Queues는 애플리케이션 구성 요소의 디커플링을 지원하여 확장성과 장애 허용성을 높이도록 설계되었습니다.
발전
개인적으로, 저는 스토리지 API에 익숙하며 이미 대부분의 앱의 다른 영역에서 BLOB 스토리지를 필요로 합니다.스토리지 대기열은 스토리지 BLOB와 동일한 SDK를 사용합니다.Azure Queues는 큐, 테이블 및 BLOB 전반에 걸쳐 균일하고 일관된 프로그래밍 모델을 제공합니다.
비용.
서비스 버스에서 지원하는 수신 및 삭제 모드는 배달 보증을 낮추는 대신 메시징 작업 수(및 관련 비용)를 줄일 수 있는 기능을 제공합니다.
애플리케이션을 실행하기 위해 예산을 유지해야 하는 경우 서비스 버스를 위한 비용 관리에 대한 툴이 몇 가지 있는 것 같습니다. 아래에서 잠재적인 스토리지 대기열 비용을 분석해 보았습니다.GRS의 경우 한 시간에 40,000개 이상의 대기열에서 한 달에 100달러 미만으로 나옵니다.나머지 스토리지 비용과 함께 분류하면 비용 절감에 집중할 수 있는 이점이 없습니다. (대역폭은 둘 다 동일하며 비교 시 자동으로 취소됩니다.)
스토리지 가격
무제한 무료 대기열 및 운영 제공 - 공간 비용 지불
- 평균 메시지 크기를 30K로 가정
- 1024가 아닌 MB 단위로 1000K로 가정
- 등급별 가격이 1TB를 초과하지 않는다고 가정합니다.
30K / 1 메시지 * 1TB / 1,000,000K * $.095 / 1GB * 1000GB / 1TB = $0.00000285 / 처음 사용한 TB에 대한 메시지
메시지 1개 / ~30K * 1000000000K / 1TB = TB 내 메시지 3333333
33333333 메시지 * $0.00000285 / 메시지 = 첫 번째 TB에 대해 ~ 95달러
한 달에 걸쳐 퍼져있는 그 첫 번째 TB로 우리는 한 시간에 40,000개의 메시지를 할 수 있습니다.
서비스 버스 가격
- 월 10달러의 기본 가격
- pay per operation (api 호출은 op) - 대기열 추가 / 대기열 수신 / 대기열 모니터링 등
- 한 달에 1250만 건의 무료 운영 혜택을 받습니다.
- 그 후 백만 ops당 지불
여기서는 사용량을 예측하기 어렵지만 1억 개의 작업에 한 달에 80달러가 듭니다.
일괄 수신
스토리지는 메시지 검색 시 메시지 수를 지정하여 최대 32개의 메시지를 배치할 수 있으며, 서비스 버스를 통해 대기열 클라이언트는 여러 메시지를 단일 전송 작업으로 배치할 수 있습니다.
따라서 스토리지는 일괄 수신되고 서비스 버스는 일괄 전송됩니다.
모니터링
Azure Queues를 사용하면 집계된 메트릭뿐만 아니라 대기열에 대해 실행된 모든 트랜잭션의 상세 로그를 가져올 수 있습니다.이러한 종류의 지원은 서비스 버스와 함께 즉시 제공되는 것이 아니라 사전 구축된 솔루션을 어딘가에서 찾을 수 있을 것입니다.
출고
서비스 버스에는 스토리지 대기열이 누락된 자동 전달 기능이 있습니다.
자동 전달을 사용하면 수천 개의 대기열에서 메시지를 단일 대기열로 자동 전달할 수 있으며, 여기서 수신 응용 프로그램은 메시지를 사용합니다.이 메커니즘을 사용하여 보안을 달성하고 흐름을 제어하며 각 메시지 게시자 간의 저장소를 분리할 수 있습니다.
중복
서비스 버스 대기열에서 지원하는 중복 탐지 기능은 메시지 값에 따라 대기열 또는 주제로 전송된 중복 메시지를 자동으로 제거합니다.ID 속성.
스토리지 대기열 메시지는 경고 없이 복제될 수 있습니다.
메타데이터
서비스 버스는 메시지 헤더와 본문의 두 부분을 제공합니다.이 기능은 글로벌하게 구축된 인프라에 매우 유용합니다.지역 이름 및 인스턴스 ID와 같은 항목으로 메시지를 장식할 수 있습니다.대기열 메시지는 단순 문자열입니다.반면 Azure 스토리지 대기열은 이름/값 쌍의 형태로 대기열 설명에 적용할 수 있는 임의 속성을 지원합니다.따라서 서비스 버스에서 메시지를 장식하고 스토리지 큐로 큐를 장식할 수 있습니다.
배송 보증
서비스 버스는 At-Most-Once 및 At-Lest-Once를 제공하는 반면 큐는 At-Lest-Once 배달만 제공합니다.이는 동시 가입자가 문제가 되는 경우 대기열을 사용할 수 있는 능력을 제한할 수 있습니다.
성능
Zure 스토리지 대기열은 10ms(데이터 센터 내)의 대기 시간을 제공하는 반면 서비스 버스는 20-25ms의 대기 시간을 제공합니다.서비스 버스는 긴 폴링을 제공합니다. 필요하다면 10ms보다 훨씬 더 좋을 것입니다.
보안.
스토리지 대기열은 기본/보조 공유 키를 사용하는 반면, 서비스 버스는 발신자/수신자/관리자 역할이 있는 Active Directory를 통해 RBAC를 제공합니다.
참고 문헌
- https://msdn.microsoft.com/en-us/library/azure/hh767287.aspx
- http://azure.microsoft.com/en-us/pricing/details/storage/
- http://azure.microsoft.com/en-us/pricing/details/service-bus/
- https://alexandrebrisebois.wordpress.com/2013/10/20/windows-azure-storage-queues-vs-windows-azure-service-bus-queues/
웹 역할과 작업자 역할 간의 통신을 위해 Azure 큐를 사용하는 것이 좋습니다.대기열을 사용하는 것은 Azure 프로세스 간의 공식적이고 승인된 의사소통 방법이며 저는 당신이 코너에 자신을 프로그래밍할 것인지 진심으로 의심합니다.서비스 버스(AppFabric)는 오버헤드가 높고 외부 앱과 대화하기에 매우 좋지만 Azure 앱 내의 빠르고 간단한 메시지에는 최적이 아닐 수 있습니다.
제가 이해한 바로는 서비스 버스(현재 상태)에 한동안 대기열이 있었지만, 메시지를 전달할 수 있는 것은 아닙니다. 가능성이 큽니다.
간단한 REST 기반 Get/Put/Peek 인터페이스를 통해 사용 사례가 기본적으로 유지되므로 Azure 큐가 일치합니다.
설명서는 최근(2015년 5월 21일) 업데이트되었으며, 둘 중 하나를 사용할 때와 일반적인 기능(트랜잭션 지원, 대기열 및 메시지 크기, Time to Live 등)에 대해 자세히 설명합니다.
개발자가 학습하는 큐 관련 패턴은 두 가지 모두에 적용할 수 있습니다.두 가지 모두 안정성 및 구현 용이성 측면에서 사용할 수 있습니다.
스토리지 큐만 할 수 있는 작업 1) 메시지를 처리하는 작업자가 충돌합니다.다음 작업자가 이전 작업자가 중단한 위치에서 계속 메시지 상태를 읽으려고 합니다. 2) 대기열에 대해 실행된 모든 트랜잭션의 서버 측 로그가 필요합니다.
하지만 비교는 중요하지 않습니다.사용자 지정 대기열 개발이 필요한 경우 항상 스토리지 대기열을 사용합니다.그것은 마이크로소프트에 의해 개발된 최초의 것이었습니다.서비스 버스는 BizTalk를 복사하여 도입되었으며, 통합(하이브리드)을 목적으로 하기 때문에 세션, 트랜잭션, 자동 데드 레터 등의 고급 기능이 있습니다.
이 링크는 비교를 제공하며, 이 링크도 비교를 제공합니다.모든 것을 분석하고 민첩한 개발을 시작하는 것은 어려울 것이므로 위에서 언급한 규칙입니다.
이것은 서로 다른 이유로 서로 다른 시점에 생성된 두 Azure 구성 요소를 비교한 것입니다.
스토리지 대기열 및 서비스 버스 대기열 - 비교 및 대조
Azure는 두 가지 유형의 대기열 메커니즘을 지원합니다.스토리지 대기열 및 서비스 버스 대기열.
Azure 스토리지 인프라의 일부인 스토리지 대기열은 간단한 REST 기반 GET/PUT/PEEK 인터페이스를 제공하여 서비스 내부 및 서비스 간에 안정적이고 지속적인 메시징을 제공합니다.
서비스 버스 대기열은 대기열뿐만 아니라 게시/구독 및 고급 통합 패턴을 지원하는 광범위한 Azure 메시징 인프라의 일부입니다.서비스 버스 대기열/항목/구독에 대한 자세한 내용은 서비스 버스 개요를 참조하십시오.
두 큐잉 기술이 동시에 존재하지만 스토리지 큐는 Azure 스토리지 서비스 위에 구축된 전용 큐 스토리지 메커니즘으로 처음 도입되었습니다.서비스 버스 대기열은 여러 통신 프로토콜, 데이터 계약, 신뢰 도메인 및/또는 네트워크 환경에 걸쳐 있는 애플리케이션 또는 애플리케이션 구성 요소를 통합하도록 설계된 광범위한 메시징 인프라 위에 구축됩니다.
언급URL : https://stackoverflow.com/questions/1906244/choosing-between-net-service-bus-queues-vs-azure-queue-service
'source' 카테고리의 다른 글
| LINQ를 사용하여 최소 또는 최대 속성 값을 가진 개체를 선택하는 방법 (0) | 2023.05.29 |
|---|---|
| Excel VBA에서 워크시트 생성 및 이름 지정 (0) | 2023.05.29 |
| 식별자 Cell로 셀을 디큐할 수 없음 - 식별자에 대한 nib 또는 클래스를 등록하거나 스토리보드에서 프로토타입 셀을 연결해야 합니다. (0) | 2023.05.29 |
| 데이터 세트 읽기 (0) | 2023.05.29 |
| Git를 사용하여 전체 파일에서 '내 것' 또는 '내 것'을 수락하는 간단한 도구 (0) | 2023.05.29 |