Azure Event Hubs의 기능 및 용어

Azure Event Hubs는 확장 가능한 처리 서비스로 대량의 이벤트 및 데이터를 수집하여 처리하며, 대기 시간이 낮고 안정성이 우수합니다. 서비스에 대한 개략적인 개요는 Event Hubs란?을 참조하세요.

이 문서는 개요 문서의 정보를 기반으로 하며, Event Hubs 구성 요소 및 기능에 대한 기술 정보와 구현 정보를 제공합니다.

네임스페이스

Event Hubs 네임스페이스는 이벤트 허브(또는 Kafka 구문 분석의 토픽)에 대한 관리 컨테이너입니다. DNS 통합 네트워크 엔드포인트와, IP 필터링, 가상 네트워크 서비스 엔드포인트 및 프라이빗 링크와 같은 다양한 액세스 제어 및 네트워크 통합 관리 기능을 제공합니다.

파티션

Event Hubs는 이벤트 허브로 전송되는 이벤트 시퀀스를 하나 이상의 파티션으로 구성합니다. 최신 이벤트가 도착하면 이 시퀀스의 끝에 추가됩니다.

파티션을 커밋 로그로 생각할 수 있습니다. 파티션은 다음 정보를 포함하는 이벤트 데이터를 보유합니다.

• 이벤트의 본문
• 이벤트를 설명하는 사용자 정의 속성 모음
• 파티션의 오프셋, 스트림 시퀀스의 번호와 같은 메타데이터
• 승인된 서비스 쪽 타임스탬프

파티션 사용의 이점

Event Hubs는 대량의 이벤트를 처리하는 데 도움이 되도록 설계되었으며, 분할은 다음과 같은 두 가지 방면에서 유용합니다.

• Event Hubs는 PaaS 서비스이지만 그 아래에는 실제 현실이 있습니다. 이벤트 순서를 유지하는 로그를 유지 관리하려면 이러한 이벤트가 기본 스토리지와 해당 복제본에 함께 보관되어야 하며 이로 인해 해당 로그에 대한 처리량 한도가 발생합니다. 분할을 사용하면 동일한 이벤트 허브에 여러 병렬 로그를 사용할 수 있으므로 사용 가능한 원시 IO(입력-출력) 처리량 용량이 크게 증가합니다.
• 자체 애플리케이션은 이벤트 허브로 전송되는 이벤트의 볼륨 처리를 유지할 수 있어야 합니다. 복잡할 수 있으며 상당한 규모의 확장된 병렬 처리 용량이 필요합니다. 이벤트를 처리하는 단일 프로세스의 용량이 제한되어 있으므로 여러 프로세스가 필요합니다. 파티션은 솔루션이 이러한 프로세스를 피드하는 동시에 각 이벤트에 명확한 처리 소유자가 있는지 확인하는 방법입니다.

파티션 수

이벤트 허브를 만들 때 파티션 수가 지정됩니다. 1과 각 가격 책정 계층에 대해 허용된 최대 파티션 수 사이여야 합니다. 각 계층에 대한 파티션 수 제한은 이 문서를 참조하세요.

특정 이벤트 허브에서 애플리케이션의 부하가 가장 높을 때는 최소한 필요한 만큼의 파티션을 선택하는 것이 좋습니다. 프리미엄 및 전용 계층 이외의 계층의 경우 이벤트 허브를 만든 후에는 파티션 수를 변경할 수 없습니다. 프리미엄 또는 전용 계층의 이벤트 허브의 경우 만든 후 파티션 수를 늘릴 수 있지만 줄일 수는 없습니다. 이 작업이 완료되면 파티션에 대한 파티션 키 매핑이 변경되어 파티션 전체의 스트림 분포가 변경되므로 애플리케이션에서 이벤트의 상대적인 순서가 중요한 경우에는 이러한 변경을 방지하기 위해 열심히 노력해야 합니다.

파티션 수를 최대 허용 값으로 설정하고 싶겠지만 여러 파티션을 활용할 수 있도록 이벤트 스트림을 구성해야 한다는 점을 항상 유의해야 합니다. 모든 이벤트 또는 소수의 하위 스트림에서 절대 순서를 유지해야 하는 경우 많은 파티션을 활용하지 못할 수 있습니다. 또한 파티션이 많으면 처리가 더 복잡해집니다.

가격 책정과 관련하여 이벤트 허브에 있는 파티션의 수는 중요하지 않습니다. 네임스페이스 또는 전용 클러스터의 가격 책정 단위 수(표준 계층의 경우 TU(처리량 단위), 프리미엄 계층의 경우 PU(처리 단위), 전용 계층의 경우 CU(용량 단위))에 따라 달라집니다. 예를 들어 32개 파티션이 있는 표준 계층의 이벤트 허브 또는 1개 파티션이 있는 이벤트 허브는 네임스페이스가 1TU 용량으로 설정된 경우 정확히 동일한 비용을 발생시킵니다. 또한 파티션 수에 관계없이 네임스페이스의 TU나 PU 또는 전용 클러스터의 CU를 스케일링할 수 있습니다.

파티션은 데이터를 병렬 방식으로 게시하고 사용할 수 있는 데이터 구성 메커니즘입니다. 최적의 규모를 달성하려면 크기 조정 단위(표준 계층의 처리량 단위, 프리미엄 계층의 처리 단위 또는 전용 계층의 용량 단위)와 파티션의 균형을 맞추는 것이 좋습니다. 일반적으로 파티션당 최대 처리량은 1MB/s를 권장합니다. 따라서 파티션 수를 계산하는 방법은 최대 예상 처리량을 1MB/s로 나누는 것입니다. 예를 들어, 사용 사례에 20MB/s가 필요한 경우 최적의 처리량을 달성하려면 최소 20개 이상의 파티션을 선택하는 것이 좋습니다.

그러나 애플리케이션이 특정 파티션에 대한 선호도를 갖는 모델이 있는 경우 파티션 수를 늘리는 것은 유익하지 않습니다. 자세한 내용은 가용성 및 일관성을 참조하세요.

이벤트를 파티션에 매핑

파티션 키를 사용하여 들어오는 이벤트 데이터를 데이터 구성을 위한 특정 파티션으로 맵핑할 수 있습니다. 파티션 키는 Event Hub로 전달된 발신자가 제공하는 값입니다. 이 키는 파티션 할당을 만드는 정적 해싱 기능을 통해 처리됩니다. 이벤트를 게시할 때 파티션 키를 지정하지 않으면 라운드 로빈 할당이 사용됩니다.

이벤트 게시자는 이벤트를 게시하는 파티션이 아니라 파티션 키만 인식합니다. 이렇게 키와 파티션을 분리하면 발신자가 다운스트림 처리에 대해 너무 많이 알 필요가 없습니다. 디바이스 단위 또는 사용자 공유 ID는 좋은 파티션 키가 되지만 지리와 같은 다른 특성은 단일 파티션으로 관련 이벤트를 그룹화하는 데도 사용할 수 있습니다.

파티션 키를 지정하면 관련 이벤트를 동일한 파티션에 함께 유지하고 정확히 도착한 순서대로 유지할 수 있습니다. 파티션 키는 애플리케이션 컨텍스트에서 파생되고 이벤트의 상호 관계를 식별하는 문자열입니다. 파티션 키로 식별되는 이벤트 시퀀스는 스트림입니다. 파티션은 이러한 여러 스트림에 대한 멀티플렉싱 로그 저장소입니다.

이벤트 게시자

이벤트 허브로 데이터를 전송하는 모든 엔터티는 이벤트 게시자(이벤트 생산자에서 동의어처럼 사용됨)입니다. 이벤트 게시자는 HTTPS, AMQP 1.0 또는 Kafka 프로토콜을 사용하여 이벤트를 게시할 수 있습니다. 이벤트 게시자는 OAuth2에서 발급한 JWT 토큰 또는 Event Hub 관련 SAS(공유 액세스 서명) 토큰과 함께 Microsoft Entra ID 기반 권한 부여를 사용하여 게시 액세스 권한을 얻습니다.

AMQP 1.0, Kafka 프로토콜 또는 HTTPS를 통해 이벤트를 게시할 수 있습니다. Event Hubs 서비스는 이벤트 허브에 이벤트를 게시하기 위한 REST API and .NET, Java, Python, JavaScript 및 Go 클라이언트 라이브러리를 제공합니다. 다른 런타임 및 플랫폼의 경우, Apache Qpid와 같은 모든 AMQP 1.0 클라이언트를 사용할 수 있습니다.

AMQP 또는 HTTPS 사용 선택은 사용량 시나리오에 해당됩니다. 전송 수준 보안(TLS) 또는 SSL/TLS 외에 AMQP는 영구 양방향 소켓을 설정해야 합니다. AMQP는 세션을 초기화할 때 네트워크 비용이 더 많이 듭니다. 그러나 HTTPS를 사용하려면 모든 요청에 대한 추가 TLS 오버헤드가 필요합니다. AMQP는 빈번한 게시자의 경우 성능이 높고 비동기 게시 코드와 함께 사용하는 경우 대기 시간이 훨씬 짧아질 수 있습니다.

이벤트를 개별적으로 게시하거나 일괄처리할 수 있습니다. 단일 게시는 단일 이벤트 또는 일괄 처리인지에 관계없이 1MB로 제한됩니다. 이 임계값보다 큰 이벤트 게시는 거부됩니다.

Event Hubs 처리량은 파티션 및 처리량 단위 할당을 사용하여 스케일링됩니다. 게시자는 이벤트 허브에 대해 선택한 특정 분할 모델을 인식하지 못하고 동일한 파티션에 관련 이벤트를 일관되게 할당하는 데 사용되는 파티션 키만 지정하는 것이 가장 좋습니다.

Event Hubs는 파티션 키 값을 공유하는 모든 이벤트가 함께 저장되고 도착하는 순서대로 배달되도록 합니다. 파티션 키가 게시자 정책과 함께 사용되는 경우 게시자 ID와 파티션 키 값이 일치해야 합니다. 그렇지 않은 경우 오류가 발생합니다.

이벤트 보존

게시된 이벤트는 구성 가능한 시간 기반 보존 정책을 기반으로 하여 이벤트 허브에서 제거됩니다. 다음은 몇 가지 중요한 사항입니다.

• 기본값 및 가능한 가장 짧은 보존 기간은 1시간입니다.
• Event Hubs Standard의 경우 최대 보존 기간은 7일입니다.
• Event Hubs 프리미엄 및 전용의 경우 최대 보존 기간은 90일입니다.
• 보존 기간을 변경하는 경우 이벤트 허브에 이미 있는 이벤트를 포함하여 모든 이벤트에 적용됩니다.

Event Hubs는 모든 파티션에 적용되도록 구성된 보존 시간에 대한 이벤트를 유지합니다. 보존 기간에 도달하면 이벤트가 자동으로 제거됩니다. 보존 기간을 1일(24시간)으로 지정한 경우 이벤트가 수락된 후 정확히 24시간이 지나면 해당 이벤트를 사용할 수 없게 됩니다. 이벤트는 명시적으로 삭제할 수 없습니다.

허용되는 보존 기간을 초과하여 이벤트를 보관해야 하는 경우 Event Hubs 캡처 기능을 켜서 Azure Storage 또는 Azure Data Lake에 이벤트를 자동으로 저장할 수 있습니다. 이러한 심층 보관을 검색하거나 분석해야 하는 경우 간편하게 해당 항목을 Azure Synapse또는 비슷한 저장소 및 분석 플랫폼에 가져올 수 있습니다.

Event Hubs에서 데이터 보존 시간을 제한하는 이유는 타임스탬프로만 인덱싱되는 심층 저장소에 대량의 고객 데이터 기록이 모이지 않게 방지하고 순차적 액세스만 허용하도록 하기 위해서입니다. 여기에는 Event Hubs 또는 Kafka에서 제공하는 실시간 이벤트 인터페이스보다 풍부한 인덱싱 및 직접 액세스가 데이터 기록에 필요하다는 아키텍처 철학이 적용되었습니다. 이벤트 스트리밍 엔진은 이벤트 소싱을 위해 데이터 레이크 또는 장기 보관의 역할을 수행하는 데 적합하지 않습니다.

게시자 정책

Event Hubs는 게시자 정책을 통한 이벤트 게시자에 대한 세부적 제어를 사용합니다. 게시자 정책은 많은 수의 독립 이벤트 게시자를 지원하도록 설계된 런타임 기능입니다. 게시자 정책을 사용하여 다음 메커니즘을 사용하여 Event Hub로 이벤트를 게시하는 경우 각 게시자는 자체 고유 식별자를 사용합니다.

//<my namespace>.servicebus.windows.net/<event hub name>/publishers/<my publisher name>

시간에 앞서 게시자 이름을 미리 만들 필요가 없지만, 독립 게시자 ID를 보장하기 위해 이벤트를 게시하는 경우 사용하는 SAS 토큰과 일치해야 합니다. 게시자 정책을 사용하는 경우 PartitionKey 값을 게시자 이름으로 설정해야 합니다. 제대로 작동하려면 이 값이 일치해야 합니다.

Capture

Event Hubs 캡처를 사용하면 Event Hubs의 스트리밍 데이터를 자동으로 캡처하고 선택한 Blob Storage 계정 또는 Azure Data Lake Storage 계정에 저장할 수 있습니다. Azure Portal에서 캡처를 사용하도록 설정하고 캡처를 수행할 최소 크기와 시간 범위를 지정할 수 있습니다. Event Hubs 캡처를 사용하여 자신의 Azure Blob Storage 계정 및 컨테이너 또는 Azure Data Lake Storage 계정을 지정합니다. 이 중 하나는 캡처된 데이터를 저장하는 데 사용됩니다. 캡처된 데이터는 Apache Avro 형식으로 기록됩니다.

Event Hubs 캡처에서 생성된 파일에는 다음과 같은 Avro 스키마가 있습니다.

SAS 토큰

Event Hubs는 네임스페이스 및 Event Hubs 수준에서 사용할 수 있는 공유 액세스 서명을 사용합니다. SAS 토큰은 SAS 키에서 생성되고 특정 형식으로 인코딩된 URL의 SHA 해시입니다. Event Hubs는 키(정책)와 토큰의 이름을 사용하여 해시를 다시 생성하여 발신자를 인증할 수 있습니다. 일반적으로 이벤트 게시자에 대한 SAS 토큰은 특정 Event Hub에 대한 전송 권한만으로 작성됩니다. 이 SAS 토큰 URL 메커니즘은 게시자 정책에 도입된 게시자 ID에 대한 기반이 됩니다. SAS 작업에 대한 자세한 내용은 Service Bus를 사용한 공유 액세스 서명 인증을 참조하세요.

이벤트 소비자

Event Hubs에서 이벤트 데이터를 읽는 모든 엔터티는 이벤트 소비자입니다. 소비자 또는 수신기는 AMQP 또는 Apache Kafka를 사용하여 이벤트 허브에서 이벤트를 수신합니다. Event Hubs는 소비자가 이벤트를 수신할 수 있도록 끌어오기 모델만 지원합니다. 이벤트 처리기를 사용하여 이벤트 허브의 이벤트를 처리하는 경우에도 이벤트 프로세서는 내부적으로 끌어오기 모델을 사용하여 이벤트 허브에서 이벤트를 받습니다.

소비자 그룹

Event Hubs의 게시/구독 메커니즘은 소비자 그룹을 통해 사용할 수 있습니다. 소비자 그룹은 이벤트 허브 또는 Kafka 토픽에서 데이터를 읽는 소비자의 논리적 그룹입니다. 이를 통해 여러 소비 애플리케이션이 오프셋을 사용하여 각자의 속도로 이벤트 허브에서 동일한 스트리밍 데이터를 독립적으로 읽을 수 있습니다. 이를 통해 메시지 소비를 병렬화하고 각 파티션 내에서 메시지 순서를 유지하면서 여러 소비자 간에 워크로드를 분산할 수 있습니다.

소비자 그룹 내의 파티션에 활성 수신기가 하나만 있는 것이 좋습니다. 그러나 특정 시나리오에서는 모든 수신기가 파티션의 모든 이벤트를 가져오는 파티션당 소비자 또는 수신기를 최대 5개까지 사용할 수 있습니다. 동일한 파티션에 여러 판독기가 있는 경우 중복 이벤트를 처리합니다. 코드에서 이를 처리해야 하는데 이는 쉽지 않습니다. 그러나 일부 시나리오에서는 유효한 방법입니다.

스트림 처리 아키텍처에서 각 다운스트림 애플리케이션은 소비자 그룹에 해당합니다. 이벤트 데이터를 장기 스토리지에 기록하려는 경우, 해당 스토리지 기록기 애플리케이션은 소비자 그룹입니다. 복합 이벤트 처리는 별도의 다른 소비자 그룹에서 수행될 수 있습니다. 소비자 그룹을 통해서만 파티션을 액세스할 수 있습니다. Event Hubs에는 항상 기본 소비자 그룹이 있으며 해당 가격 책정 계층에 대해 최대 소비자 그룹 수를 만들 수 있습니다.

Azure SDK에서 제공하는 일부 클라이언트는 각 파티션에 단일 판독기가 있는지와 이벤트 허브에 대한 모든 파티션을 읽을 수 있는지 확인하는 세부 정보를 자동으로 관리하는 인텔리전트 소비자 에이전트입니다. 이렇게 하면 코드에서 이벤트 허브에서 읽는 이벤트를 처리하는 데 집중할 수 있으므로 파티션의 여러 세부 정보를 무시할 수 있습니다. 자세한 내용은 파티션에 연결을 참조하세요.

다음 예에서는 소비자 그룹 URI 규칙을 보여 줍니다.

//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #1>
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #2>

다음 그림에서는 아키텍처를 처리하는 Event Hubs 스트림을 보여 줍니다.

스트림 오프셋

오프셋은 파티션 내의 이벤트 위치입니다. 오프셋을 클라이언트 쪽 커서로 생각할 수 있습니다. 오프셋은 이벤트의 바이트 번호입니다. 오프셋을 사용하여 이벤트 소비자(판독기)가 이벤트를 읽기 시작할 이벤트 스트림의 위치를 지정할 수 있습니다. 타임스탬프 또는 오프셋 값으로 오프셋을 지정할 수 있습니다. 소비자는 Event Hubs 서비스 외부에 자신의 오프셋 값을 저장하는 일을 담당합니다. 파티션 내에서 각 이벤트는 오프셋을 포함합니다.

검사점 설정

검사점 은 판독기가 파티션 이벤트 시퀀스 내에서 위치를 표시하거나 커밋하는 프로세스입니다. 검사점은 소비자의 책임으로 소비자 그룹 내에서 파티션별로 발생합니다. 이러한 책임은 각 소비자 그룹에 대해 각 파티션 판독기는 이벤트 스트림의 현재 위치를 추적해야 하며 데이터 스트림이 완료된 것으로 간주되면 서비스를 알릴 수 있다는 것을 의미합니다.

판독기가 파티션에서 연결을 끊은 경우 다시 연결하면 해당 소비자 그룹에서 해당 파티션의 마지막 판독기에서 이전에 제출한 검사점에서 읽기 시작합니다. 판독기가 연결하면, 오프셋을 이벤트 허브로 전달하여 읽기 시작할 위치를 지정합니다. 이러한 방식으로, 서로 다른 머신에서 실행되는 판독기 간의 장애 조치(failover)가 발생하는 경우 복원력을 제공하고 다운스트림 애플리케이션에서 이벤트를 "완료"로 표시하는 데 검사점을 사용할 수 있습니다. 이 검사점 프로세스에서 더 낮은 오프셋을 지정하면 이전 데이터로 돌아갈 수 있습니다. 이 메커니즘을 통해 검사점을 지정하면 장애 조치 복원력 및 제어된 이벤트 스트림 재생 모두를 사용할 수 있습니다.

Azure Blob Storage를 검사점 저장소로 사용할 때 다음 권장 사항을 따릅니다.

• 각 소비자 그룹에 대해 별도의 컨테이너를 사용합니다. 동일한 스토리지 계정을 사용할 수 있지만 각 그룹당 하나의 컨테이너를 사용합니다.
• 컨테이너를 다른 용도로 사용하지 말고 스토리지 계정을 다른 용도로 사용하지 마세요.
• 스토리지 계정은 배포된 애플리케이션이 있는 지역과 동일한 지역에 있어야 합니다. 애플리케이션이 온-프레미스인 경우 가능한 가장 가까운 지역을 선택해 보세요.

Azure Portal에서 Storage 계정 페이지의 Blob service 섹션에서 다음 설정을 사용하지 않도록 설정해야 합니다.

• 계층 구조 네임스페이스
• Blob 일시 삭제
• 버전 관리

로그 압축

Azure Event Hubs는 특정 이벤트 키의 최신 이벤트를 유지하기 위해 이벤트 로그 압축을 지원합니다. 압축된 이벤트 허브/Kafka 토픽을 사용하면 대략적인 시간 기반 보존을 사용하는 대신 키 기반 보존을 사용할 수 있습니다.

로그 압축에 대한 자세한 내용은 로그 압축을 참조하세요.

일반 소비자 작업

모든 Event Hubs 소비자는 상태 인식 양방향 통신 채널인 AMQP 1.0 세션을 통해 연결됩니다. 각 파티션에는 AMQP 1.0 세션이 있어 파티션별로 분리된 이벤트를 쉽게 전송할 수 있습니다.

파티션에 연결

파티션에 연결할 때 일반적으로 임대 메커니즘을 사용하여 판독기 연결을 특정 파티션으로 조정합니다. 이러한 방식으로, 소비자 그룹의 모든 파티션에 활성 판독기가 하나만 있을 수 있습니다. 인텔리전트 소비자 에이전트 역할을 하는 Event Hubs SDK 내에서 클라이언트를 사용하여 판독기의 검사점 설정, 임대 및 관리를 간소화합니다. 화면은 다음과 같습니다.

• .NET용 EventProcessorClient
• Java용 EventProcessorClient
• Python용 EventHubConsumerClient
• JavaScript/TypeScript용 EventHubConsumerClient

읽기 이벤트

AMQP 1.0 세션 및 링크는 특정 파티션에 대해 열린 후, 이벤트는 이벤트 허브 서비스에서 AMQP 1.0 클라이언트로 전달됩니다. 이 배달 메커니즘은 HTTP GET과 같은 풀 기반 메커니즘보다 더 낮은 대기 시간 및 더 높은 처리량을 사용합니다. 이벤트가 클라이언트에 전송되므로, 각 이벤트 데이터 인스턴스는 이벤트 시퀀스에서 검사점을 용이하게 하는데 사용되는 오프셋 및 시퀀스 번호와 같은 중요한 메타데이터를 포함합니다.

이벤트 데이터:

• Offset
• 시퀀스 번호
• 본문
• 사용자 속성
• 시스템 속성

사용자의 책임 하에 오프셋을 관리해야 합니다.

애플리케이션 그룹

애플리케이션 그룹은 보안 컨텍스트와 같은 고유한 식별 조건(공유 액세스 정책 또는 Microsoft Entra 애플리케이션 ID)을 공유하는 Event Hubs 네임스페이스에 연결하는 클라이언트 애플리케이션의 컬렉션입니다.

Azure Event Hubs를 사용하면 지정된 애플리케이션 그룹에 대한 제한 정책과 같은 리소스 액세스 정책을 정의하고 클라이언트 애플리케이션과 Event Hubs 간의 이벤트 스트리밍(게시 또는 사용)을 제어할 수 있습니다.

자세한 내용은 애플리케이션 그룹을 사용한 클라이언트 애플리케이션에 대한 리소스 거버넌스를 참조하세요.

Apache Kafka 지원

Apache Kafka 클라이언트(버전 >=1.0)에 대한 프로토콜 지원은 기존 Kafka 애플리케이션이 Event Hubs를 사용할 수 있도록 하는 엔드포인트를 제공합니다. 대부분의 기존 Kafka 애플리케이션은 Kafka 클러스터 부트스트랩 서버 대신 네임스페이스를 가리키도록 다시 구성할 수 있습니다.

비용, 운영 활동, 안정성의 관점에서 Azure Event Hubs는 고유한 Kafka 및 Zookeeper 클러스터 배포와 운영 및 Azure에 기본 제공되지 않는 Kafka-as-a-Service 제품 대신 사용할 수 있습니다.

Apache Kafka 브로커와 동일한 핵심 기능을 제공하는 것 외에도, Event Hubs 캡처, 자동 스케일링 및 분산, 재해 복구, 비용 중립적인 가용성 영역 지원, 유연하고 안전한 네트워크 통합, 방화벽 AMQP-over-WebSockets 프로토콜을 포함한 다중 프로토콜 지원을 통해 자동 일괄 처리 및 보관과 같은 Azure Event Hubs 기능에 액세스할 수 있습니다.

프로토콜

생산자 또는 보낸 사람이 AMQP(Advanced Messaging Queuing Protocol), Kafka 또는 HTTPS 프로토콜을 사용하여 이벤트 허브로 이벤트를 보낼 수 있습니다.

소비자 또는 수신기는 AMQP 또는 Kafka를 사용하여 이벤트 허브에서 이벤트를 받습니다. Event Hubs는 소비자가 이벤트를 수신할 수 있도록 끌어오기 모델만 지원합니다. 이벤트 처리기를 사용하여 이벤트 허브의 이벤트를 처리하는 경우에도 이벤트 프로세서는 내부적으로 끌어오기 모델을 사용하여 이벤트 허브에서 이벤트를 받습니다.

AMQP

AMQP 1.0 프로토콜을 사용하여 Azure Event Hubs에 이벤트를 보내고 받을 수 있습니다. AMQP는 이벤트를 보내고 받는 데 안정적이고 성능이 뛰어나며 안전한 통신을 제공합니다. 고성능 및 실시간 스트리밍에 사용할 수 있으며 대부분의 Azure Event Hubs SDK에서 지원됩니다.

HTTPS/REST API

HTTP POST 요청을 사용하여 Event Hubs에만 이벤트를 보낼 수 있습니다. Event Hubs는 HTTPS를 통해 이벤트 수신을 지원하지 않습니다. 직접 TCP 연결을 사용할 수 없는 경량 클라이언트에 적합합니다.

Apache Kafka

Azure Event Hubs에는 Kafka 생산자 및 소비자를 지원하는 기본 제공 Kafka 엔드포인트가 있습니다. Kafka를 사용하여 빌드된 애플리케이션은 Kafka 프로토콜(버전 1.0 이상)을 사용하여 코드 변경 없이 Event Hubs에서 이벤트를 보내고 받을 수 있습니다.

Azure SDK는 기본 통신 프로토콜을 추상화하고 C#, Java, Python, JavaScript 등의 언어를 사용하여 Event Hubs에서 이벤트를 보내고 받는 간소화된 방법을 제공합니다.

다음 단계

Event Hubs에 대한 자세한 내용은 다음 링크를 방문하세요.

• Event Hubs 시작
  • .NET
  • Java
  • Python
  • JavaScript

• Event Hubs의 가용성 및 일관성
• Event Hubs FAQ
• Event Hubs 샘플