서비스 대 서비스 통신

팁

이 콘텐츠는 Azure용 클라우드 네이티브 .NET 애플리케이션 설계 eBook 에서 발췌한 것으로, .NET 문서에서 제공되거나 오프라인 상태에서도 읽을 수 있는 PDF(무료 다운로드 가능)로 제공됩니다.

PDF 다운로드

프런트 엔드 클라이언트에서 이동하여 이제 백 엔드 마이크로 서비스가 서로 통신하는 문제를 해결합니다.

클라우드 네이티브 애플리케이션을 구성할 때 백 엔드 서비스가 서로 통신하는 방식이 중요합니다. 이상적으로는 서비스 간 통신이 적을수록 좋습니다. 그러나 백 엔드 서비스가 작업을 완료하기 위해 서로 의존하는 경우가 많기 때문에 회피가 항상 가능한 것은 아닙니다.

서비스 간 통신을 구현하기 위해 널리 인정되는 몇 가지 방법이 있습니다. 통신 상호 작용 유형에 따라 가장 적합한 방법이 결정되는 경우가 많습니다.

다음 상호 작용 유형을 고려합니다.

• 쿼리 – 호출하는 마이크로 서비스가 호출된 마이크로 서비스의 응답을 요구하는 경우(예: "지정된 고객 ID에 대한 구매자 정보를 주세요.")

• 명령 – 호출하는 마이크로 서비스가 작업을 실행하기 위해 다른 마이크로 서비스가 필요하지만 응답이 필요하지 않은 경우(예: "이 주문만 출하하세요.")

• 이벤트 – 게시자라고 하는 마이크로 서비스가 상태가 변경되었거나 작업이 발생했다는 이벤트를 발생시키는 경우. 관심이 있는 구독자라고 하는 다른 마이크로 서비스는 이벤트에 적절하게 대응할 수 있습니다. 게시자와 구독자는 서로를 인식하지 못합니다.

마이크로 서비스 시스템은 일반적으로 서비스 간 상호 작용이 필요한 작업을 실행할 때 이러한 상호 작용 형식의 조합을 사용합니다. 각각에 대해 자세히 살펴보고 어떻게 구현할 수 있는지 살펴보겠습니다.

쿼리

한 마이크로 서비스가 다른 마이크로 서비스를 여러 번 쿼리해야 하며 작업을 완료하려면 즉각적인 응답이 필요합니다. 장바구니 마이크로 서비스는 장바구니에 항목을 추가하기 위해 제품 정보와 가격이 필요할 수 있습니다. 쿼리 작업을 구현하는 방법에는 여러 가지가 있습니다.

요청/응답 메시징

이 시나리오를 구현하기 위한 한 가지 옵션은 그림 4-8과 같이 호출하는 백 엔드 마이크로 서비스가 쿼리해야 하는 마이크로 서비스에 직접 HTTP 요청을 하는 것입니다.

그림 4-8. 직접 HTTP 통신

마이크로 서비스 간의 직접 HTTP 호출은 구현하기가 비교적 간단하지만 이 사례를 최소화하기 위해 주의를 기울여야 합니다. 시작하려면 이러한 호출은 항상 동기이며 결과가 반환되거나 요청 시간이 초과될 때까지 작업을 차단합니다. 자체 포함되어 독립적으로 발전하고 자주 배포할 수 있었던 독립 서비스가 이제는 서로 결합됩니다. 마이크로 서비스 간의 결합이 증가함에 따라 아키텍처 이점이 감소합니다.

다른 마이크로 서비스에 대한 단일 직접 HTTP 호출을 수행하는 간헐적 요청을 실행하는 것은 일부 시스템에서 허용될 수 있습니다. 그러나 여러 마이크로 서비스에 대한 직접 HTTP 호출을 호출하는 대량 호출은 권장되지 않습니다. 대기 시간을 늘리고 시스템의 성능, 확장성 및 가용성에 부정적인 영향을 줄 수 있습니다. 설상가상으로 긴 일련의 직접 HTTP 통신은 그림 4-9와 같이 동기 마이크로 서비스 호출의 깊고 복잡한 체인으로 이어질 수 있습니다.

그림 4-9 HTTP 쿼리 연결

이전 이미지에 표시된 디자인의 위험을 확실히 상상할 수 있습니다. 3단계가 실패하면 어떻게 되나요? 또는 8단계가 실패하면 어떻게 되나요? 어떻게 복구하나요? 기본 서비스가 사용 중이므로 6단계가 느리면 어떻게 해야 할까요? 계속하려면 어떻게 해야 할까요? 모든 것이 올바르게 작동하더라도 이 호출이 발생하는 대기 시간을 각 단계의 대기 시간의 합계라고 생각해 보세요.

이전 이미지에서 큰 수준의 결합은 서비스가 최적으로 모델링되지 않았음을 나타냅니다. 팀은 해당 디자인을 재검토해야 합니다.

구체화된 뷰 패턴

마이크로 서비스 결합을 제거하는 데 널리 사용되는 옵션은 구체화된 뷰 패턴입니다. 이 패턴을 사용하면 마이크로 서비스는 다른 서비스에서 소유한 데이터의 비정규화된 로컬 복사본을 저장합니다. 제품 카탈로그 및 가격 책정 마이크로 서비스를 쿼리하는 장바구니 마이크로 서비스 대신 해당 데이터의 자체 로컬 복사본을 유지 관리합니다. 이 패턴은 불필요한 결합을 제거하고 안정성과 응답 시간을 개선시킵니다. 전체 작업은 단일 프로세스 내에서 실행됩니다. 5장에서는 이 패턴과 기타 데이터 문제를 살펴봅니다.

서비스 집계 패턴

마이크로 서비스와 마이크로 서비스 간 결합을 제거하기 위한 또 다른 옵션은 그림 4-10에서 자주색으로 표시된 집계 마이크로 서비스입니다.

그림 4-10 집계 마이크로 서비스

이 패턴은 여러 백 엔드 마이크로 서비스를 호출하는 작업을 격리하여 해당 논리를 특수 마이크로 서비스로 중앙 집중화합니다. 이전 그림의 자주색 체크 아웃 집계 마이크로 서비스는 체크 아웃 작업에 대한 워크플로를 오케스트레이션합니다. 여기에는 여러 백 엔드 마이크로 서비스에 대한 호출이 시퀀스된 순서로 포함됩니다. 워크플로의 데이터가 집계되어 호출자에게 반환됩니다. 여전히 직접 HTTP 호출을 구현하지만 집계 마이크로 서비스는 백 엔드 마이크로 서비스 간의 직접적인 종속성을 줄입니다.

요청/회신 패턴

동기 HTTP 메시지를 분리하는 또 다른 방법은 큐 통신을 사용하는 요청-회신 패턴입니다. 큐를 사용하는 통신은 항상 단방향 채널이며 생산자는 메시지를 보내고 소비자는 메시지를 수신합니다. 이 패턴을 사용하면 그림 4-11과 같이 요청 큐와 응답 큐가 모두 구현됩니다.

그림 4-11 요청-회신 패턴

여기서 메시지 생산자는 고유한 상관 관계 ID가 포함된 쿼리 기반 메시지를 만들어 요청 큐에 배치합니다. 소비 서비스는 메시지를 큐에서 제거하고, 처리하고, 동일한 상관 관계 ID를 가진 응답 큐에 응답을 배치합니다. 생산자 서비스는 메시지를 큐에서 제거하고 상관 관계 ID와 일치시키고 처리를 계속합니다. 다음 섹션에서 큐에 대해 자세히 다룹니다.

명령

또 다른 형식의 통신 상호 작용은 명령입니다. 마이크로 서비스는 작업을 수행하기 위해 다른 마이크로 서비스가 필요할 수 있습니다. 주문 마이크로 서비스는 승인된 주문에 대한 배송을 만들기 위해 배송 마이크로 서비스가 필요할 수 있습니다. 그림 4-12에서 생산자라고 하는 하나의 마이크로 서비스는 다른 마이크로 서비스인 소비자에게 메시지를 보내 무언가를 하도록 명령합니다.

그림 4-12. 큐와 명령 상호 작용

대부분의 경우 생산자는 응답이 필요하지 않으며 메시지를 시작하고 잊어버릴 수 있습니다. 회신이 필요한 경우 소비자는 별도의 메시지를 다른 채널의 생산자에게 다시 보냅니다. 명령 메시지는 메시지 큐와 비동기식으로 보내는 것이 가장 좋습니다. 간단한 메시지 브로커에서 지원합니다. 이전 다이어그램에서 큐가 두 서비스를 어떻게 분리하는지 확인합니다.

메시지 큐는 생산자와 소비자가 메시지를 전달하는 중간 구조입니다. 큐는 비동기 지점 간 메시징 패턴을 구현합니다. 생산자는 명령을 보내야 하는 위치와 적절하게 라우팅하는 위치를 알고 있습니다. 큐는 채널에서 읽고 있는 소비자 인스턴스 중 정확히 하나에서 메시지가 처리되도록 합니다. 이 시나리오에서 생산자 또는 소비자 서비스는 다른 서비스에 영향을 주지 않고 스케일 아웃할 수 있습니다. 또한 기술이 서로 다를 수 있습니다. 즉, Golang 마이크로 서비스를 호출하는 Java 마이크로 서비스가 있을 수 있습니다.

1장에서 지원 서비스에 대해 설명했습니다. 지원 서비스는 클라우드 네이티브 시스템이 의존하는 보조 리소스입니다. 메시지 큐는 지원 서비스입니다. Azure 클라우드는 클라우드 네이티브 시스템이 명령 메시징을 구현하기 위해 사용할 수 있는 두 가지 형식의 메시지 큐인 Azure Storage 큐 및 Azure Service Bus 큐를 지원합니다.

Azure Storage 큐

Azure Storage 큐는 빠르고 저렴하며 Azure Storage 계정으로 지원되는 간단한 큐 인프라를 제공합니다.

Azure Storage 큐는 안정적이고 지속적인 메시징을 통해 REST 기반 큐 메커니즘을 제공합니다. 최소한의 기능 집합을 제공하지만 저렴하며 수백만 개의 메시지를 저장합니다. 용량 범위는 최대 500TB입니다. 단일 메시지의 크기는 최대 64KB입니다.

전 세계 어디서나 인증된 호출을 통해 HTTP 또는 HTTPS를 사용하여 메시지에 액세스할 수 있습니다. Storage 큐는 트래픽 급증을 처리하기 위해 많은 수의 동시 클라이언트로 스케일 아웃할 수 있습니다.

하지만 서비스에는 다음과 같은 제한이 있습니다.

• 메시지 순서는 보장되지 않습니다.

• 메시지는 자동으로 제거되기 전까지 7일 동안만 유지될 수 있습니다.

• 상태 관리, 중복 검색 또는 트랜잭션에 대한 지원은 사용할 수 없습니다.

그림 4-13은 Azure Storage 큐의 계층 구조를 보여 줍니다.

그림 4-13. Storage 큐 계층 구조

이전 그림에서 스토리지 큐가 기본 Azure Storage 계정에 메시지를 저장하는 방법을 확인합니다.

개발자를 위해 Microsoft는 Storage 큐 처리를 위한 여러 클라이언트 및 서버 쪽 라이브러리를 제공합니다. .NET, Java, JavaScript, Ruby, Python 및 Go를 포함한 대부분의 주요 플랫폼이 지원됩니다. 개발자는 이러한 라이브러리와 직접 통신해서는 안 됩니다. 이렇게 하면 마이크로 서비스 코드가 Azure Storage 큐 서비스에 밀접하게 연결됩니다. API의 구현 세부 정보를 격리하는 것이 좋습니다. 일반 작업을 노출하고 구체적인 라이브러리를 캡슐화하는 중개 계층 또는 중간 API를 도입합니다. 이 느슨한 결합을 통해 주요 서비스 코드를 변경하지 않고도 하나의 대기열 서비스를 다른 대기열 서비스로 교환할 수 있습니다.

Azure Storage 큐는 클라우드 네이티브 애플리케이션에서 명령 메시징을 구현하는 경제적인 옵션입니다. 특히 큐 크기가 80GB를 초과하거나 단순한 기능 집합이 허용되는 경우에 그렇습니다. 메시지 스토리지에 대해서만 비용을 지불합니다. 고정된 시간당 요금은 없습니다.

Azure Service Bus 큐

더 복잡한 메시징 요구 사항의 경우 Azure Service Bus 큐를 고려합니다.

강력한 메시지 인프라 위에 있는 Azure Service Bus는 조정된 메시징 모델을 지원합니다. 메시지는 소비자가 수신할 때까지 브로커(큐)에 안정적으로 저장됩니다. 큐는 메시지가 큐에 추가된 순서에 따라 FIFO(선입 선출) 메시지 배달을 보장합니다.

메시지 크기는 최대 256KB로 훨씬 클 수 있습니다. 메시지는 무제한 기간 동안 큐에 유지됩니다. Service Bus는 HTTP 기반 호출을 지원할 뿐만 아니라 AMQP 프로토콜을 완벽하게 지원합니다. AMQP는 이진 파일 프로토콜과 더 높은 수준의 안정성을 지원하는 공급업체 전반에 걸친 공개 표준입니다.

Service Bus는 트랜잭션 지원 및 중복 검색 기능을 비롯한 다양한 기능을 제공합니다. 큐는 메시지당 "최대 한 번 배달"을 보장합니다. 이미 전송된 메시지는 자동으로 삭제됩니다. 생산자가 확실하지 않은 경우 동일한 메시지를 다시 전송할 수 있으며 Service Bus는 하나의 복사본만 처리되도록 보장합니다. 중복 검색을 통해 추가 인프라 연결을 빌드할 필요가 없습니다.

두 가지 추가 엔터프라이즈 기능은 분할 및 세션입니다. 기존 Service Bus 큐는 단일 메시지 브로커에 의해 처리되고 단일 메시지 저장소에 저장됩니다. 그러나 Service Bus 분할은 여러 메시지 브로커와 메시지 저장소에 큐를 분산시킵니다. 전체 처리량은 더 이상 단일 메시지 브로커 또는 메시징 저장소의 성능에 의해 제한되지 않습니다. 메시징 저장소가 일시적으로 중단된 경우 분할된 큐를 계속 렌더링할 수 없습니다.

Service Bus 세션은 관련 메시지를 그룹화하는 방법을 제공합니다. 메시지를 함께 처리하고 마지막에 작업을 완료해야 하는 워크플로 시나리오를 상상해 보세요. 이점을 활용하려면 큐에 대해 세션을 명시적으로 사용하도록 설정해야 하며 메시지와 관련된 각 세션 ID가 동일해야 합니다.

그러나 몇 가지 중요한 주의 사항이 있습니다. Service Bus 큐 크기는 저장소 큐에서 사용할 수 있는 것보다 훨씬 작은 80GB로 제한됩니다. 또한 Service Bus 큐에는 작업당 기본 비용과 요금이 발생합니다.

그림 4-14에서는 Service Bus 큐의 개략적인 아키텍처를 간략하게 설명합니다.

그림 4-14. Service Bus 큐

이전 그림에서 지점 간 관계에 유의합니다. 동일한 공급자의 두 인스턴스가 단일 Service Bus 큐에 메시지를 넣고 있습니다. 각 메시지는 오른쪽에 있는 3개의 소비자 인스턴스 중 하나에서만 사용됩니다. 다음으로, 서로 다른 소비자가 모두 같은 메시지에 관심을 가질 수 있는 메시징을 구현하는 방법에 대해 설명합니다.

이벤트

메시지 큐는 생산자가 소비자에게 메시지를 비동기적으로 보낼 수 있는 통신을 구현하는 효과적인 방법입니다. 하지만 여러 다른 소비자가 동일한 메시지에 관심이 있으면 어떻게 되나요? 각 소비자를 위한 전용 메시지 큐는 크기 조정이 잘 되지 않고 관리하기 어려워집니다.

이 시나리오를 해결하기 위해 세 번째 유형의 메시지 상호 작용인 이벤트로 이동합니다. 한 마이크로 서비스에서 작업이 발생했음을 알립니다. 다른 마이크로 서비스는 관심 있는 경우 작업 또는 이벤트에 반응합니다. 이를 이벤트 기반 아키텍처 스타일이라고도 합니다.

이벤트는 2단계 프로세스입니다. 지정된 상태 변경에 대해 마이크로 서비스는 이벤트를 메시지 브로커에 게시하여 다른 관심 있는 마이크로 서비스에서 사용할 수 있도록 합니다. 관심 있는 마이크로 서비스는 메시지 브로커의 이벤트를 구독하여 알림을 받습니다. 게시/구독 패턴을 사용하여 이벤트 기반 통신을 구현합니다.

그림 4-15는 두 개의 다른 마이크로 서비스가 구독하는 이벤트를 게시하는 장바구니 마이크로 서비스를 보여 줍니다.

그림 4-15. 이벤트 기반 메시징

통신 채널 중간에 있는 이벤트 버스 구성 요소에 유의합니다. 메시지 브로커를 캡슐화하고 기본 애플리케이션에서 분리하는 사용자 지정 클래스입니다. 주문 및 재고 마이크로 서비스는 서로 알지도 못하고 장바구니 마이크로 서비스도 모르는 상태에서 이벤트를 독립적으로 운영합니다. 등록된 이벤트가 이벤트 버스에 게시되면 해당 이벤트에 따라 작동합니다.

이벤트를 통해 큐 기술에서 토픽으로 이동합니다. 토픽은 큐와 유사하지만 일대다 메시징 패턴을 지원합니다. 하나의 마이크로 서비스가 메시지를 게시합니다. 여러 구독 마이크로 서비스는 해당 메시지를 수신하고 조치를 취할 수 있습니다. 그림 4-16은 토픽 아키텍처를 보여 줍니다.

그림 4-16. 토픽 아키텍처

이전 그림에서 게시자는 토픽에 메시지를 보냅니다. 마지막으로 구독자는 구독에서 메시지를 받습니다. 중간에서 토픽은 진한 파란색 상자에 표시된 규칙 집합에 따라 구독에 메시지를 전달합니다. 규칙은 특정 메시지를 구독으로 전달하는 필터 역할을 합니다. 여기서는 로깅 구독이 모든 메시지를 수신하도록 선택되었으므로 "GetPrice" 이벤트가 가격 및 로깅 구독으로 전송됩니다. "GetInformation" 이벤트는 정보 및 로깅 구독으로 전송됩니다.

Azure 클라우드는 Azure Service Bus 토픽 및 Azure EventGrid라는 두 가지 토픽 서비스를 지원합니다.

Azure Service Bus Topics

Azure Service Bus 큐의 동일하고 강력한 조정된 메시지 모델 위에는 Azure Service Bus 토픽이 있습니다. 토픽은 여러 독립 게시자로부터 메시지를 수신하고 최대 2,000명의 구독자에게 메시지를 보낼 수 있습니다. 시스템을 중지하거나 토픽을 다시 만들지 않고 런타임에 구독을 동적으로 추가하거나 제거할 수 있습니다.

중복 검색 및 트랜잭션 지원을 비롯한 Azure Service Bus 큐의 많은 유용한 기능도 토픽에 사용할 수 있습니다. 기본적으로 Service Bus 토픽은 단일 메시지 브로커에서 처리되고 단일 메시지 저장소에 저장됩니다. 그러나 Service Bus 분할은 토픽을 여러 메시지 브로커와 메시지 저장소에 분산시켜 크기를 조정합니다.

예약된 메시지 배달은 처리할 특정 시간으로 메시지에 태그를 지정합니다. 해당 시간 전에는 토픽에 메시지가 표시되지 않습니다. 메시지 지연을 사용하면 메시지 검색을 나중으로 연기할 수 있습니다. 둘 다 작업이 특정 순서로 처리되는 워크플로 처리 시나리오에서 일반적으로 사용됩니다. 이전 작업이 완료될 때까지 수신된 메시지 처리를 연기할 수 있습니다.

토픽Service Bus 항목은 클라우드 네이티브 시스템에서 게시/구독 통신을 가능하게 하는 강력하고 입증된 기술입니다.

Azure Event Grid

Azure Service Bus는 전체 엔터프라이즈 기능 세트를 갖춘 검증된 메시징 브로커인 반면, Azure Event Grid는 새로운 기술입니다.

언뜻 보기에 Event Grid는 또 다른 항목 기반 메시징 시스템처럼 보일 수 있습니다. 그러나 여러 면에서 다릅니다. 이벤트 기반 워크로드에 중점을 두고 서버리스 인프라에서 실시간 이벤트 처리, 심층 Azure 통합 및 오픈 플랫폼을 지원합니다. 최신 클라우드 네이티브 및 서버리스 애플리케이션용으로 설계되었습니다.

중앙 집중식 이벤트 백플레인 또는 파이프인 Event Grid는 Azure 리소스 내부 및 자체 서비스의 이벤트에 반응합니다.

이벤트 알림은 Event Grid 토픽에 게시되며, 차례로 각 이벤트를 구독으로 라우팅합니다. 구독자는 구독에 매핑되고 이벤트를 사용합니다. Service Bus와 마찬가지로 Event Grid는 구독이 수신하려는 이벤트에 대한 규칙을 설정하는 필터링된 구독자 모델을 지원합니다. Event Grid는 초당 1,000만 개의 이벤트를 보장하여 빠른 처리량을 제공하므로 거의 실시간 배달이 가능하며 Azure Service Bus가 생성할 수 있는 것보다 훨씬 많습니다.

Event Grid의 장점은 Azure 인프라 패브릭에 대한 긴밀한 통합입니다. Cosmos DB와 같은 Azure 리소스는 사용자 지정 코드 없이 기본 제공 이벤트를 관심 있는 다른 Azure 리소스에 직접 게시할 수 있습니다. Event Grid는 Azure 구독, 리소스 그룹 또는 서비스의 이벤트를 게시하여 개발자가 클라우드 리소스의 수명 주기를 세밀하게 제어할 수 있도록 합니다. 그러나 Event Grid는 Azure로 제한되지 않습니다. 애플리케이션 또는 타사 서비스에서 게시된 사용자 지정 HTTP 이벤트를 사용하고 이벤트를 외부 구독자에게 라우팅할 수 있는 오픈 플랫폼입니다.

Azure 리소스에서 네이티브 이벤트를 게시하고 구독할 때 코딩이 필요하지 않습니다. 간단한 구성으로 토픽 및 구독에 대한 기본 제공 연결을 활용하여 Azure 리소스 간에 이벤트를 통합할 수 있습니다. 그림 4-17은 Event Grid의 구조를 보여 줍니다.

그림 4-17. Event Grid 분석

EventGrid와 Service Bus의 주요 차이점은 기본 메시지 교환 패턴입니다.

Service Bus는 다운스트림 구독자가 새 메시지에 대한 토픽 구독을 적극적으로 폴링하는 이전 스타일의 끌어오기 모델을 구현합니다. 반대로 이 방법은 구독자가 메시지를 처리하는 속도를 완전히 제어할 수 있도록 합니다. 메시지 처리 시간과 지정된 시간에 처리할 메시지 수를 제어합니다. 읽지 않은 메시지는 처리될 때까지 구독에 남아 있습니다. 중요한 단점은 이벤트가 생성된 시간과 처리를 위해 해당 메시지를 구독자에게 가져오는 폴링 작업 사이의 대기 시간입니다. 또한 다음 이벤트에 대한 지속적인 폴링의 오버헤드는 리소스와 비용을 소모합니다.

그러나 EventGrid는 다릅니다. 이벤트가 수신된 대로 EventHandler로 전송되는 밀어넣기 모델을 구현하여 거의 실시간으로 이벤트를 배달합니다. 또한 폴링과 같이 지속적으로가 아니라 이벤트를 소비해야 할 때만 서비스가 트리거되므로 비용이 절감됩니다. 즉, 이벤트 처리기는 들어오는 로드를 처리하고 과부하가 걸리지 않도록 보호하기 위해 제한 메커니즘을 제공해야 합니다. Azure Functions 및 Logic Apps와 같이 이러한 이벤트를 사용하는 많은 Azure 서비스는 증가된 로드를 처리하기 위한 자동 크기 조정 기능을 제공합니다.

Event Grid는 완전 관리형 서버리스 클라우드 서비스입니다. 트래픽에 따라 동적으로 크기 조정되며 사전 구매한 용량이 아닌 실제 사용량에 대해서만 요금을 청구합니다. 매월 처음 100,000개 작업은 무료입니다. 작업은 이벤트 수신(수신 이벤트 알림), 구독 배달 시도, 관리 호출 및 주체별 필터링으로 정의됩니다. 99.99%의 가용성을 제공하는 EventGrid는 배달 실패에 대한 기본 제공 다시 시도 기능을 통해 24시간 이내에 이벤트 배달을 보장합니다. 배달되지 않은 메시지는 해결을 위해 "배달 못 한 편지" 큐로 이동할 수 있습니다. Azure Service Bus와 달리 Event Grid는 빠른 성능을 위해 조정되며 정렬된 메시징, 트랜잭션 및 세션과 같은 기능을 지원하지 않습니다.

Azure 클라우드에서 메시지 스트리밍

Azure Service Bus 및 Event Grid는 Cosmos DB에 새 문서가 삽입된 것과 같은 단일 개별 이벤트를 노출하는 애플리케이션에 대한 뛰어난 지원을 제공합니다. 하지만 클라우드 네이티브 시스템이 관련 이벤트 스트림을 처리해야 하는 경우에는 어떻게 될까요? 이벤트 스트림은 더 복잡합니다. 일반적으로 시간 순서가 지정되고 상호 관련되어 있으며 그룹으로 처리되어야 합니다.

Azure Event Hubs는 이벤트를 수집, 변환 및 저장하는 데이터 스트리밍 플랫폼 및 이벤트 수집 서비스입니다. 원격 분석 컨텍스트에서 내보낸 연속 이벤트 알림과 같은 스트리밍 데이터를 캡처하도록 미세 조정됩니다. 이 서비스는 확장성이 뛰어나며 초당 수백만 개의 이벤트를 저장하고 처리할 수 있습니다. 그림 4-18에서 볼 수 있듯이 이벤트 사용량에서 수집 스트림을 분리하는 이벤트 파이프라인의 Front Door인 경우가 많습니다.

그림 4-18. Azure Event Hub

Event Hub는 짧은 대기 시간 및 구성 가능한 시간 보존을 지원합니다. 큐 및 토픽과 달리 Event Hubs는 소비자가 읽은 후 이벤트 데이터를 유지합니다. 이 기능을 사용하면 내부 및 외부의 다른 데이터 분석 서비스에서 추가 분석을 위해 데이터를 재생할 수 있습니다. 이벤트 허브에 저장된 이벤트는 보존 기간(기본적으로 하루지만 구성 가능)이 만료될 때만 삭제됩니다.

Event Hub는 HTTPS 및 AMQP를 포함한 일반적인 이벤트 게시 프로토콜을 지원합니다. Kafka 1.0도 지원합니다. 기존 Kafka 애플리케이션은 대규모 Kafka 클러스터 관리에 대한 대안을 제공하는 Kafka 프로토콜을 사용하여 Event Hub와 통신할 수 있습니다. 많은 오픈 소스 클라우드 네이티브 시스템이 Kafka를 수용합니다.

Event Hubs는 각 소비자가 메시지 스트림의 특정 하위 집합 또는 파티션만 읽는 분할된 소비자 모델을 통해 메시지 스트리밍을 구현합니다. 이 패턴에서는 이벤트 처리를 위해 매우 폭넓은 수평 확장이 가능하며, 큐와 항목에서는 사용할 수 없는 기타 스트림 중심 기능이 제공됩니다. 파티션은 Event Hub에서 보유하는 순서가 지정된 이벤트 시퀀스입니다. 최신 이벤트가 도착하면 이 시퀀스의 끝에 추가됩니다. 그림 4-19는 이벤트 허브의 분할을 보여 줍니다.

그림 4-19. Event Hub 분할

각 소비자 그룹은 동일한 리소스에서 읽는 대신 메시지 스트림의 하위 집합 또는 파티션에서 읽습니다.

많은 수의 이벤트를 스트리밍해야 하는 클라우드 네이티브 애플리케이션의 경우 Azure Event Hubs는 강력하고 경제적인 솔루션이 될 수 있습니다.

이전다음