Azure에서 큐 기반 메시징 솔루션의 확장성 및 비용 효율성을 극대화하기 위한 모범 사례

업데이트 날짜: 2015년 3월

작성: Amit Srivastava 및 Valery Mizonov

검토: Brad Calder, Sidney Higa, Christian Martinez, Steve Marx, Curt Peterson, Paolo Salvatori 및 Trace Young

이 문서에서는 Azure 플랫폼에서 확장성, 효율성, 비용 효율성이 뛰어난 큐 기반 메시징 솔루션을 작성하기 위한 지침 및 모범 사례를 제공합니다. 이 문서는 Azure 플랫폼의 큐 저장소 서비스를 활용하는 클라우드 기반 솔루션을 설계 및 구현하는 솔루션 설계자 및 개발자를 대상으로 합니다.

요약

기존 큐 기반 메시징 솔루션은 메시지 큐라고도 부르는 메시지 저장소 위치 개념을 이용합니다. 메시지 큐는 하나 이상의 참가자가 일반적으로 비동기 통신 메커니즘을 통해 서로 주고 받는 데이터의 리포지토리입니다.

이 문서의 목적은 개발자가 Azure에서 제공하는 기능과 함께 특정 디자인 패턴을 활용하여 최적화되고 비용 효율적인 큐 기반 메시징 솔루션을 구축하는 방법을 보여주기 위한 것입니다. 이 문서에서는 Azure 솔루션에서 큐 기반 상호 작용을 구현하기 위해 가장 일반적으로 사용되는 접근 방식을 자세히 살펴보고 성능 및 확장성 향상, 운영 비용 감소를 위한 권장 사항을 제공합니다.

이 문서의 토론 내용에는 경우에 따라 관련된 모범 사례, 힌트 및 권장 사항 등이 포함됩니다. 이 문서에 설명된 시나리오에서는 실제 고객의 프로젝트를 기반으로 기술적 구현을 강조해서 보여줍니다.

큐 기반 메시징 기본

메시지 큐를 사용해서 분산된 구성 요소 간에 데이터를 교환하는 일반적인 메시징 솔루션에는 메시지를 여러 큐에 배치하는 게시자와 이러한 메시지를 수신하는 하나 이상의 구독자가 포함됩니다. 대부분의 경우 구독자(일부 경우에는 큐 수신기라고도 부름)는 지속적으로 실행되거나 예약 패턴별로 요청 시에 시작되는 단일 또는 다중 스레드 프로세스로 구현됩니다.

일반적으로 큐 수신기가 큐에 저장된 메시지를 수신하는 데 사용되는 기본적인 디스패치 메커니즘은 두 가지입니다.

  • 폴링(풀 기반 모델): 수신기가 큐에서 새 메시지를 주기적으로 검사하여 큐를 모니터링합니다. 큐가 비어 있으면 수신기가 큐를 계속 폴링하고 중지 상태로 전환함으로써 주기적으로 폴링을 중지합니다.

  • 트리거(푸시 기반 모델): 수신기가 메시지가 큐에 도착할 때마다 트리거되는 이벤트를 구독합니다. 트리거는 게시자 자체에 의해 또는 큐 서비스 관리자에 의해 수행됩니다. 그런 다음 수신기가 메시지 처리를 시작할 수 있습니다. 따라서 새 작업이 있는지 여부를 확인하기 위해 큐를 폴링할 필요가 없습니다.

이 두 가지 메커니즘은 서로의 장단점을 확인할 필요가 있습니다. 예를 들어, 폴링의 경우에는 차단 또는 비차단 방식을 사용할 수 있습니다. 차단 방식의 경우 새 메시지가 큐에 표시될 때까지(또는 제한 시간이 초과될 때까지) 요청을 보류 상태로 유지할 수 있습니다. 반면에 비차단 방식의 경우에는 큐에 아무 것도 없을 경우 요청이 즉시 완료됩니다. 트리거 모델의 경우에는 새 메시지가 있을 때마다, 비어 있는 큐에 첫 번째 메시지가 도착할 때만 또는 큐 크기가 특정 수준에 도달할 때 등으로 큐 수신기에 알림을 푸시하도록 설정할 수 있습니다.

note참고
Azure 큐 서비스 API에서 지원하는 큐에서 제거 작업은 비차단 방식입니다. 즉, 큐에서 메시지를 찾을 수 없으면 GetMessage 또는 GetMessages와 같은 API 메서드가 즉시 반환됩니다. 반면에 Azure Service Bus 큐는 메시지가 큐에 도착할 때까지 또는 지정한 기간이 경과할 때까지 호출하는 스레드를 차단하는 차단 방식의 수신 작업을 제공합니다.

오늘날 Azure 솔루션에서 큐 수신기를 구현하는 가장 일반적인 접근 방식은 다음과 같이 요약할 수 있습니다.

  1. 수신기는 작업자 역할 인스턴스의 일부로 인스턴스화되고 실행되는 하나의 응용 프로그램 구성 요소로 구현됩니다.

  2. 큐 수신기 구성 요소의 수명 주기는 종종 호스팅 역할 인스턴스의 실행 시간에 묶여 있습니다.

  3. 기본 처리 논리는 메시지가 큐에서 제거되고 처리를 위해 디스패치되는 루프로 구성됩니다.

  4. 수신되는 메시지가 없으면 일반적으로 해당 응용 프로그램의 백오프 알고리즘에 따라 구동되는 기간 동안 수신 스레드가 정지 상태로 전환됩니다.

  5. 수신기에 루프 종료 및 프로세스 종료 알림이 수신될 때까지는 수신 루프가 계속 실행되고 큐가 계속 폴링됩니다.

다음 순서도에서는 Azure 응용 프로그램에서 폴링 메커니즘을 사용해서 큐 수신기를 구현할 때 일반적으로 사용되는 논리를 보여줍니다.

최선의 구현 방법-메시징-솔루션-Azure2
note참고
이 문서에서 중앙 큐 관리자(브로커)를 사용해야 하는 것과 같은 보다 복잡한 디자인 패턴은 다루지 않습니다.

Azure 큐를 사용할 때 폴링 메커니즘을 사용하는 기본적인 큐 수신기는 최상의 선택이 아닐 수 있습니다. Azure 가격 책정 모델에 따르면 큐가 비어 있는지 여부에 관계없이 큐에 대해 수행되는 응용 프로그램 요청을 기준으로 저장소 트랜잭션 양이 측정되기 때문입니다. 다음 섹션에서는 Azure 플랫폼에서 성능을 극대화하고 큐 기반 메시징 솔루션의 비용을 최소화하기 위한 몇 가지 기법들에 대해 설명합니다.

성능, 확장성 및 비용 최적화를 위한 모범 사례

이 섹션에서는 더 나은 성능, 확장성 및 비용 효율성을 얻기 위해 관련 설계 요소를 개선하는 방법을 찾아야 합니다.

"보다 효율적인 솔루션"을 위한 구현 패턴은 다음과 같은 목적을 충족할 수 있는 설계를 통해서 가능할 것입니다.

  • 운영 비용 감소 - 저장소 트랜잭션 중 유용성이 없는 요소를 상당 부분 제거합니다.

  • 과도한 지연 시간 제거 - 큐에서 새 메시지를 확인할 때 폴링 간격을 효과적으로 조정합니다.

  • 동적 확장/축소 - 유동적인 작업 볼륨에 맞게 처리 능력을 조정합니다.

또한 이러한 목적을 달성하기 위한 구현 패턴이 관련된 이점을 얻기 위해 너무 복잡해져도 안됩니다.

저장소 트랜잭션 비용 최적화를 위한 모범 사례

Azure 플랫폼으로 배포되는 솔루션의 TCO(총소유비용) 및 ROI(투자수익)를 계산할 때 중요한 변수 중 하나는 저장소 트랜잭션 볼륨입니다. Azure 큐에 대한 트랜잭션 수를 줄이면 Azure에서 실행되는 솔루션과 관련된 운영 비용을 줄일 수 있습니다.

Azure 큐와 관련된 저장소 공간 비용은 다음과 같이 계산될 수 있습니다.

큐 공간: 24바이트 + 길이(큐 이름) * 2 +  각 메타데이터(4바이트 + Len(큐 이름) * 2바이트 + 길이(값) * 2바이트)

메시지 공간: 12바이트 + 길이(메시지)

큐 기반 메시징 솔루션의 컨텍스트에서 저장소 트랜잭션 볼륨은 다음과 같은 방식을 조합하여 줄일 수 있습니다.

  1. 큐에 메시지를 넣을 때는 관련 메시지를 하나의 보다 큰 일괄 처리로 그룹화하고, 압축한 후 압축된 메시지를 BLOB에 저장한 다음, 실제 데이터가 저장된 BLOB에 대한 참조만 큐에 넣습니다. 이 접근 방식은 트랜잭션 비용과 저장소 공간 비용을 최적화하도록 도와줍니다.

  2. 큐에서 메시지를 검색할 때는 여러 메시지를 단일 저장소 트랜잭션으로 일괄 처리합니다. 큐 서비스 API의 GetMessages 메서드는 단일 트랜잭션에서 지정된 개수의 메시지를 큐에서 제거할 수 있게 해줍니다(아래 설명 참조).

  3. 큐에 작업 항목이 있는지 확인할 때는 공격적인 폴링 간격을 방지하고 큐가 계속해서 비어 있을 경우 폴링 요청 사이의 시간을 늘리도록 백오프 지연을 구현합니다.

  4. 큐 수신기 수 감소 – 풀 기반 모델을 사용할 때는 큐가 비어 있을 경우 역할 인스턴스당 큐 수신기를 한 개만 사용합니다. 역할 인스턴스당 큐 수신기 수를 0개로 더욱 줄이기 위해서는 큐에 작업 항목이 수신될 때 큐 수신기를 인스턴스화할 수 있도록 알림 메커니즘을 사용합니다.

  5. 큐가 대부분의 시간 동안 비어 있는 상태로 유지될 경우에는 역할 인스턴스 수를 자동으로 줄이고 응용 프로그램이 늘어나는 작업을 처리할 수 있도록 인스턴스 수를 늘려야 하는 경우 및 시간을 확인할 수 있도록 관련 시스템 메트릭을 지속적으로 모니터링합니다.

  6. 포이즌 메시지를 제거하는 메커니즘을 구현합니다. 포이즌 메시지는 일반적으로 응용 프로그램에서 처리할 수 없는 잘못된 형식의 메시지입니다. 이러한 메시지를 처리하지 않고 그대로 두면 누적되어 반복된 트랜잭션 및 처리 비용이 발생할 수 있습니다. 임계값 기간이 지난 메시지를 큐에서 제거하고 향후 평가를 위해 보관 시스템에 기록하는 것이 간단한 구현 메커니즘일 수 있습니다.

  7. 예상된 시간 초과 오류를 줄입니다. 서비스로 요청을 보낼 때 원하는 제한 시간을 지정하고 SLA 제한 시간과 유사하게 설정할 수 있습니다. 이 시나리오에서는 요청 시간이 초과하면 해당 요청이 예상된 시간 초과로 분류되어 청구 가능한 트래잭션으로 계산됩니다.

위에서 설명한 대부분의 권장 사항은 메시지 일괄 처리를 수행하고 많은 기본 큐/BLOB 저장소와 스레드 관리 작업을 캡슐화하는 상당히 일반적인 구현 방식입니다. 이 문서의 뒷부분에서는 이러한 방식을 수행하는 방법에 대해 살펴봅니다.

Important중요
GetMessages 메서드를 통해 메시지를 검색할 때 단일 큐에서 제거 작업으로 큐 서비스 API가 지원하는 최대 일괄 처리 크기는 32로 제한됩니다.

일반적으로 Azure 큐 트랜잭션 비용은 역할 인스턴스 수를 확장하거나 큐에서 제거 스레드 수를 늘릴 때와 같이 큐 서비스 클라이언트 수 증가에 따라 거의 선형적으로 늘어납니다. 위의 권장 사항을 사용하지 않는 솔루션 설계로 인해 발생하는 잠재적인 비용 영향을 확인할 수 있도록 구체적인 수치가 포함된 예를 보여드리겠습니다.

비효율적인 설계로 인한 비용 영향

솔루션 설계자가 관련된 최적화를 구현하지 않고 위에 설명한 청구 시스템 아키텍처를 Azure 플랫폼에 배포하고 실행하면 운영 비용이 과다하게 늘어날 수 있습니다. 다음 섹션에서는 이러한 비용 증가가 발생할 수 있는 이유에 대해 설명합니다.

시나리오 정의에서 언급했듯이 비즈니스 트랜잭션 데이터는 주기적으로 수신됩니다. 하지만 솔루션이 일반적으로 하루 8시간의 근무 시간 중에 실제로 작업을 처리하는 시간은 25%뿐이라고 가정해보겠습니다. 그러면 8시간의 75%에 해당하는 6시간이 "유휴 시간"이 됩니다. 이 시간 동안에는 시스템에 어떠한 트랜잭션도 유입되지 않습니다. 또한 매일 16시간의 비영업 시간 중에는 어떠한 데이터도 솔루션에 수신되지 않습니다.

이렇게 총 22시간의 유휴 시간 동안 솔루션은 새로운 데이터가 도착했는지 알 수 없는 상태로 여전히 큐에서 제거 작업을 계속해서 수행합니다. 이 시간 동안 수행되는 각각의 큐에서 제거 스레드는 기본 폴링 간격을 1초라고 가정했을 때 입력 큐에 대해 최대 79,200건의 트랜잭션(22시간 * 60분 * 분당 처리 트랜잭션 60건)을 수행합니다.

앞에서 설명한 것처럼 Azure 플랫폼의 가격 책정 모델은 개별 "저장소 트랜잭션"을 기준으로 합니다. 저장소 트랜잭션이란 사용자 응용 프로그램이 데이터 추가, 읽기, 업데이트 또는 삭제를 위해 수행하는 요청을 의미합니다. 이 백서를 작성할 당시 저장소 트랜잭션의 요금은 트랜잭션 10,000개당 0.01달러입니다. 홍보용 제품이나 특별 가격 행사는 이 가격에 적용되지 않습니다.

Important중요
큐 트랜잭션 수를 계산할 때는 하나의 큐에 단일 메시지를 넣는 것도 한 건의 트랜잭션으로 계산되며, 메시지 소비는 종종 검색과 큐에서 메시지를 제거하기 위한 요청이 포함된 2단계 프로세스라는 것에 주의해야 합니다. 따라서 큐에서 제거 작업을 성공적으로 수행하는 데에는 2건의 저장소 트랜잭션이 발생합니다. 큐에서 제거 요청으로 데이터가 전혀 검색되지 않더라도 이 요청 작업은 여전히 청구 대상이 되는 트랜잭션 건수로 계산됩니다.

위 시나리오에서 단일 큐에서 제거 스레드로 발생하는 저장소 트랜잭션에 따라 매월 청구 요금에 추가되는 금액은 약 $2.38(79,200 / 10,000 * $0.01 * 30일)입니다. 큐에서 제거 스레드 수가 200개(또는 200개의 작업자 역할 인스턴스에서 1개의 큐에서 제거 스레드 사용)면 매월 비용이 $457.20로 증가합니다. 이 비용은 솔루션이 어떠한 계산도 수행하지 않으면서 단순히 사용 가능한 작업 항목이 있는지 큐를 확인하는 동안에 발생한 비용입니다. 위에서 든 예는 단순히 추상적인 예이며, 아무도 서비스를 이렇게 구현하지는 않겠지만, 최적화 작업이 왜 중요한지 이유를 알려줍니다.

과도한 지연 시간을 제거하기 위한 모범 사례

큐 기반 Azure 메시징 솔루션의 성능을 최적화하기 위한 한 가지 접근 방식은 이 섹션에 설명된 대로 Azure Service Bus에 제공되는 게시/구독 메시징 계층을 사용하는 것입니다.

이 접근 방식에서는 개발자가 폴링 및 실시간 푸시 기반 알림을 조합하고, 새 작업이 큐에 배치되었음을 나타내기 위해 특정 조건에 따라 발생하는 알림 이벤트(트리거)를 수신기가 구독할 수 있도록 하는 데 집중해야 합니다. 이 접근 방식은 기존의 큐 폴링 루프를 알림 디스패치를 위한 게시/구독 메시징 계층으로 향상시켜 줍니다.

복잡한 분산 시스템에서 이 접근 방식을 사용하려면 느슨한 방식으로 결합된 하나 이상의 구독자에게 알림이 안정적으로 중계될 수 있도록 보장하기 위해 "메시지 버스" 또는 "메시지 지향 미들웨어"를 사용해야 합니다. Azure Service Bus는 Azure 및 온-프레미스로 실행되는 느슨하게 결합된 분산 응용 프로그램 서비스 간의 메시징 요구 사항을 처리하기 위한 자연스러운 선택입니다. 또한 큐 기반 통신에 관련된 프로세스 간에 알림을 교환할 수 있게 해주는 "메시지 버스" 아키텍처에도 최상의 선택입니다.

큐 기반 메시지 교환에 포함된 프로세스는 다음과 같은 패턴을 사용할 수 있습니다.

최선의 구현 방법-메시징-솔루션-Azure3

특히 큐 서비스 구독자와 게시자 간의 상호 작용과 관련해서는 Azure 역할 인스턴스 간의 통신에 적용되는 동일한 원칙으로 푸시 기반 알림 메시지 교환을 위한 요구 사항이 상당 부분 충족될 것입니다.

Important중요
Azure Service Bus 사용은 큐 또는 항목과 같은 서비스 버스 메시징 엔터티에 대해 메시징 작업 볼륨을 계산하는 가격 책정 모델로 인한 것입니다.

따라서 서비스 버스를 특정 아키텍처에 도입하는 데 따른 장점과 단점을 평가하기 위해서는 비용 효율성 분석을 수행하는 것이 중요합니다. 이에 따라 서비스 버스를 기반으로 알림 디스패치 계층을 도입함으로써 실제로 투자 및 추가적인 개발 노력을 정당화할 수 있는 비용 절감 효과가 있는지 여부를 평가해봐야 합니다.

서비스 버스의 가격 책정 모델에 대한 자세한 내용은 Azure 플랫폼 FAQ에서 관련 섹션을 참조하세요.

게시/구독 메시징 계층을 사용하면 지연 시간에 대한 영향을 상당히 쉽게 해결할 수 있지만 다음 섹션에 설명하는 것처럼 동적인(탄력적인) 크기 조정 방식을 사용하면 추가적인 비용 감소 효과를 얻을 수 있습니다.

확장성에 대한 모범 사례

Azure 저장소는 전체 계정 수준 및 파티션별 수준에서 확장성 목표를 정의합니다. Azure의 큐는 그 자체가 단일 파티션이므로 초당 최대 2,000개의 메시지를 처리할 수 있습니다. 메시지 수가 이 할당량을 초과하면 저장소 서비스가 HTTP 503 서버 작업 중 메시지로 응답합니다. 이 메시지는 플랫폼에서 할당량을 제한하고 있음을 나타냅니다. 응용 프로그램 디자이너는 적절한 수의 큐에서 응용 프로그램의 요청 속도를 유지할 수 있도록 용량 계획을 수행해야 합니다. 단일 큐에서 응용 프로그램의 요청 속도를 처리할 수 없는 경우 여러 큐로 분할된 큐 아키텍처를 디자인하여 확장성을 유지합니다.

응용 프로그램에서 메시지 유형별로 서로 다른 큐를 활용할 수도 있습니다. 이렇게 하면 단일 큐를 소진하지 않고 여러 큐를 함께 사용할 수 있으므로 응용 프로그램 확장성이 보장됩니다. 또한 서로 다른 여러 큐에 저장된 메시지의 우선 순위와 민감도를 기준으로 하여 큐 처리를 별도로 제어할 수 있습니다. 우선 순위가 높은 큐에는 우선 순위가 낮은 큐보다 전용 작업자가 더 많이 할당됩니다.

동적 크기 조정에 대한 모범 사례

Azure 플랫폼에서는 고객이 이전보다 훨씬 빠르고 쉬운 방식으로 크기를 늘리거나 줄일 수 있습니다. 변동이 많은 작업 및 트래픽에 따라 크기를 조정할 수 있는 능력은 클라우드 플랫폼이 갖는 중요한 가치 중 하나입니다. 즉, "확장성"은 더 이상 값비싼 IT 용어가 아닙니다. 이제는 잘 설계된 클라우드 솔루션에서 필요에 따라 프로그래밍 방식으로 지원되는 기성품과 같은 기능이 되었습니다.

동적 크기 조정은 특정 솔루션이 런타임에 작업 용량 및 처리 능력을 늘리거나 줄임으로써 변화하는 작업량에 맞게 조정할 수 있는 기술적인 능력입니다. Azure 플랫폼은 컴퓨팅 시간을 필요에 따라 구입할 수 있는 분산 컴퓨팅 인프라를 프로비전함으로써 동적 크기 조정을 기본적으로 지원합니다.

Azure 플랫폼에서 제공되는 동적 크기 조정 기능은 다음과 같은 두 가지 유형으로 구분할 수 있습니다.

  • 역할 인스턴스 크기 조정 - 해당 시점의 작업을 처리하기 위해 웹 또는 작업자 역할 인스턴스를 추가하거나 제거하는 방식입니다. 이 방식에는 일반적으로 서비스 구성에서 인스턴스 수를 변경하는 방법이 사용됩니다. 인스턴스 수를 늘리면 Azure 런타임이 새 인스턴스를 시작하고, 인스턴스 수를 줄이면 실행 중인 인스턴스를 종료합니다.

  • 프로세스(스레드) 크기 조정 - 현재 작업에 따라 스레드 수를 상향 및 하향 조정함으로써 특정 역할 인스턴스에서 처리 중인 스레드 용량을 충분하게 유지 관리합니다.

큐 기반 메시징 솔루션에서 동적 크기 조정은 다음과 같은 일반적인 권장 사항의 조합에 영향을 줍니다.

  1. KPI(핵심 성과 지표) 모니터링 - CPU 사용률, 큐 크기, 응답 시간 및 메시지 처리 지연 시간을 포함합니다.

  2. 역할 인스턴스 수의 동적 증가 또는 감소 - 예측되었거나 예측되지 않았든 간에 갑작스러운 작업량 증가에 대처합니다.

  3. 프로그래밍 방식의 처리 스레드 수 확장 및 축소 - 특정 역할 인스턴스에서 처리되는 가변 부하 조건에 맞게 조정합니다.

  4. 세분화된 작업의 동시 분할 및 처리 - .NET Framework 4의 작업 병렬 라이브러리를 사용합니다.

  5. 가변 용량 유지 관리 - 추가 인스턴스를 설정하는 오버헤드 없이 갑작스러운 작업 증가를 처리할 수 있도록 작업 변동폭이 클 것으로 예상되는 솔루션에서 사용됩니다.

서비스 관리 API를 통해 Azure 호스팅 서비스는 런타임에 배포 구성을 변경함으로써 실행 중인 역할 인스턴스 수를 수정할 수 있습니다.

note참고
일반적인 구독에서 Azure의 소형 컴퓨팅 인스턴스의 최대 개수(또는 코어 수를 기준으로 이에 상응하는 다른 크기의 컴퓨팅 인스턴스 개수)는 기본적으로 20으로 제한됩니다. 이러한 할당량을 늘려야 할 경우에는 Azure 지원 팀에 요청해야 합니다. 자세한 내용은 Azure 플랫폼 FAQ를 참조하세요.

Azure 자동 크기 조정의 도입으로 플랫폼에서 큐 메시지 수준에 따라 인스턴스 수를 늘리거나 줄일 수 있습니다. 이는 동적 크기 조정에 매우 적합합니다. 이 기능은 Azure 플랫폼에서 응용 프로그램에 대한 작업을 모니터링하고 크기를 조정할 수 있는 장점을 제공합니다.

갑작스러운 부하 증가를 처리하는 데 있어서 역할 인스턴스 수를 동적으로 늘리는 방법이 항상 가장 적합한 선택이 될 수는 없습니다. 예를 들어, 새 역할 인스턴스를 스핀업하는 데 몇 초 정도 걸릴 수 있으며 현재는 스핀업 기간과 관련하여 제공된 SLA 메트릭이 없습니다. 대신 변동되는 작업 증가를 처리하기 위해 솔루션에서 단순히 작업자 스레드 수를 늘려야 할 수 있습니다. 작업을 처리하는 동안 솔루션은 관련 부하 메트릭을 모니터링하고 작업자 프로세스 수를 동적으로 줄이거나 늘려야 하는지를 확인합니다.

Important중요
현재 단일 Azure 큐의 확장성 목표는 초당 2,000개의 트랜잭션으로 "제한"됩니다. 응용 프로그램이 수백 개의 큐에서 제거 스레드를 실행하는 여러 역할 인스턴스에서 큐 작업을 수행하는 등의 방식으로 이 목표를 초과하려고 하면 저장소 서비스에서 HTTP 503 "서버 작업 중" 응답이 반환될 수 있습니다. 이 경우 응용 프로그램은 기하급수적인 백오프 지연 알고리즘을 사용하여 재시도 메커니즘을 구현해야 합니다. 하지만 HTTP 503 오류가 주기적으로 발생할 경우에는 다중 큐를 사용하고 여러 큐 간 크기 조정을 위해 분할 기반 전략을 구현하는 것이 좋습니다.

대부분의 경우 작업자 프로세스를 자동으로 크기 조정하는 것은 개별 역할 인스턴스의 책임입니다. 반면 역할 인스턴스 크기 조정 시에는 성능 메트릭을 모니터링하고 적절한 크기 조정 작업을 수행하는 솔루션 아키텍처의 중앙 요소가 포함되는 경우가 많습니다. 아래 다이어그램은 부하 메트릭을 수집 및 분석하여 새 인스턴스를 프로비전해야 하는지 또는 유휴 인스턴스를 해제해야 하는지를 결정하는 동적 크기 조정 에이전트라는 서비스 구성 요소를 보여줍니다.

최선의 구현 방법-메시징-솔루션-Azure4

크기 조정 에이전트 서비스는 Azure에서 또는 온-프레미스 서비스로 실행되는 작업자 역할로 배포할 수 있다는 점에 유의해야 합니다. 배포 토폴로지와 관계없이 이 서비스는 Azure 큐에 액세스할 수 있습니다.

note참고
수동 동적 크기 조정의 대안으로 Azure의 기본 제공 자동 크기 조정 기능을 사용하는 것이 좋습니다.

지금까지 지연 시간 영향, 저장소 트랜잭션 비용 및 동적 크기 조정 요구 사항에 대해 살펴봤으므로, 이제는 기술적인 구현을 위한 권장 사항을 집중적으로 살펴보도록 하겠습니다.

고객 시나리오

구체적인 예를 들어 보이기 위해 여기에서는 다음과 같이 실제 고객의 시나리오를 일반화하여 보여줍니다.

이 시나리오에서 한 SaaS 솔루션 공급업체는 규모에 따라 유동적으로 고객 트랜잭션 처리 요구 사항을 해결할 수 있도록 Azure 응용 프로그램으로 새로운 청구 시스템 구현을 시작합니다. 이 솔루션의 핵심 명제는 컴퓨팅 집약 작업을 클라우드로 오프로드하고 Azure의 탄력적인 인프라를 활용해서 컴퓨팅 집약 작업을 수행하는 데 중점을 둡니다.

이 종단 간 아키텍처의 온-프레미스 요소는 매일 정기적으로 대량의 트랜잭션을 통합하고 Azure 호스팅 서비스로 디스패치합니다. 트랜잭션 볼륨은 한 번의 제출 당 수천 건에서 수십만 건까지 다양하며, 하루 트랜잭션 양은 수백만 건에 달합니다. 또한 이 솔루션은 최대 처리 지연 시간에 대한 보장을 위해 SLA 기준 요구 사항을 충족해야 한다고 가정합니다.

이 솔루션의 아키텍처는 분산된 맵 감소 디자인 패턴을 기초로 하며 작업 디스패치를 위해 Azure 큐 저장소를 사용하는 다중 인스턴스 작업자 역할 기반 클라우드 계층으로 구성됩니다. 트랜잭션 일괄 처리 묶음은 Process Initiator라는 작업자 역할 인스턴스에 의해 수신되며, 소규모 작업 항목으로 분해(분산)되고 부하 분산 목적에 따라 Azure 큐 컬렉션에 배치됩니다.

작업 처리는 큐에서 작업 항목을 가져오고 컴퓨팅 절차를 통해 작업 항목을 전달하는 처리 작업자 역할의 여러 인스턴스에서 수행됩니다. 처리 인스턴스는 최적의 성능을 얻기 위해 다중 스레드 큐 수신기를 사용하여 병렬 데이터 처리를 구현합니다.

처리된 작업 항목은 전용 큐로 라우팅된 후 Process Controller 작업자 역할 인스턴스에 의해 큐에서 제거되고, 데이터 마이닝, 보고 및 분석을 위한 데이터 저장소에 집계 및 저장됩니다.

이 솔루션 아키텍처는 다음과 같이 표시할 수 있습니다.

AzureGuidance_MaxScale

위의 다이어그램은 대규모 또는 복잡한 컴퓨팅 작업을 크기 조정하기 위한 일반적인 아키텍처를 보여줍니다. 이 아키텍처에서 채택된 큐 기반 메시지 교환 패턴은 큐를 통해 서로 통신해야 하는 다른 여러 Azure 응용 프로그램 및 서비스에서도 매우 일반적으로 사용됩니다. 이러한 패턴은 정석적인 접근 방식에 따라 큐 기반 메시지 교환과 관련된 특정 기본 구성 요소를 검사할 수 있게 해줍니다.

결론

Azure 플랫폼에서 실행되는 큐 기반 메시징 솔루션의 효율성 및 비용 효율을 극대화하기 위해서는 솔루션 설계자와 개발자가 다음과 같은 권장 사항을 고려해야 합니다.

솔루션 설계자에게 필요한 내용은 다음과 같습니다.

  • 클라우드 기반 또는 하이브리드 솔루션에서 계층 및 서비스 간에 확장성이 뛰어난 비동기 통신을 위해 Azure 큐 저장소 서비스를 사용하는 큐 기반 메시징 아키텍처를 프로비전합니다.

  • 초당 2,000개 이상의 메시지로 확장할 수 있도록 분할된 큐 아키텍처를 권장합니다.

  • Azure 가격 책정 모델의 기본 개념을 이해하고 일련의 모범 사례 및 디자인 패턴을 통해 트랜잭션 비용을 낮출 수 있도록 솔루션을 최적화합니다.

  • 가변 또는 변동 작업에 대처할 수 있는 아키텍처를 프로비전함으로써 동적 크기 조정 요구 사항을 고려합니다.

  • 올바른 자동 크기 조정 기법 및 접근 방식을 사용해서 컴퓨팅 성능을 탄력적으로 확장 및 축소함으로써 운영 비용을 더욱 최적화합니다.

  • Azure 자동 크기 조정을 평가하여 응용 프로그램의 동적 크기 조정 요구 사항에 적합한지 확인합니다.

  • 실시간 푸시 기반 알림 디스패치를 위해 Azure Service Bus에 대한 종속성을 통해 대기 시간을 줄이는 데 따른 비용과 이점을 평가합니다.

개발자에게 필요한 내용은 다음과 같습니다.

  • Azure 큐에서 데이터를 저장 및 검색할 때는 일괄 처리를 사용하는 메시징 솔루션을 설계합니다.

  • Azure 자동 크기 조정을 평가하여 응용 프로그램의 동적 크기 조정 요구 사항에 적합한지 확인합니다.

  • 큐가 비어 있을 경우 큐가 최대 한 개의 큐에서 제거 스레드로 폴링되는지 확인하여 효율적인 큐 수신기 서비스를 구현합니다.

  • 큐가 장기간 동안 비어 있는 상태로 유지될 경우 작업자 역할 인스턴스 수를 동적으로 축소합니다.

  • 응용 프로그램별 임의 지수 백오프 알고리즘을 구현해서 저장소 트랜잭션 비용에 대한 유휴 큐 폴링 효과를 줄입니다.

  • 멀티스레딩 수준이 높은 다중 인스턴스 큐 게시자 및 소비자를 구현하여 단일 큐에 대한 확장성 목표를 초과하지 않도록 방지하는 올바른 기법을 채택합니다.

  • Azure 큐에서 데이터를 게시 및 소비할 때 다양한 임시 조건을 처리할 수 있는 강력한 재시도 정책을 적용합니다.

  • Azure Service Bus에서 큐 기반 메시징 솔루션의 지연 시간 감소 및 성능 향상을 위해 푸시 기반 알림을 지원하는 단방향 이벤트 지정 기능을 사용합니다.

  • TPL, PLINQ 및 병렬 수준을 극대화하기 위한 Observer 패턴과 같은 .NET Framework 4의 새로운 기능을 확인하고 멀티스레드 서비스 설계를 간소화합니다.

포함된 예제 코드는 MSDN 코드 갤러리에서 다운로드할 수 있습니다. 예제 코드에는 또한 위의 코드 조각에 제공되지 않은 Azure 큐 서비스에 대한 제네릭 인식 추상 계층과 같은 모든 필수 인프라 구성 요소가 포함됩니다. 모든 원본 코드 파일은 해당 법적 고지 사항에 설명된 것처럼 Microsoft Public License에 의해 제어됩니다.

추가 리소스 및 참조

커뮤니티 추가 항목

표시: