Azure Event Hubs의 기능 및 용어

  • 아티클

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

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

네임스페이스

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

Image showing an Event Hubs namespace

파티션

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

Image that shows an event hub with a few partitions.

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

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

Diagram that displays the older to newer sequence of events.

파티션 사용의 이점

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

  • Event Hubs가 PaaS 서비스임에도 불구하고 그 아래에는 물리적 현실이 있습니다. 이벤트 순서를 유지하는 로그를 유지 관리하려면 이러한 이벤트가 기본 스토리지 및 해당 복제본(replica) 함께 유지되고 이러한 로그에 대한 처리량 한도가 발생해야 합니다. 분할을 사용하면 동일한 이벤트 허브에 여러 병렬 로그를 사용할 수 있으므로 사용 가능한 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 토큰 또는 이벤트 허브 관련 SAS(공유 액세스 서명) 토큰을 사용하여 Microsoft Entra ID 기반 권한 부여를 사용하여 게시 액세스 권한을 얻습니다.

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

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

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

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

Diagram that shows how partition keys are mapped to partitions in an event hub.

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

이벤트 보존

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

  • 기본값 및 가능한 가장 짧은 보존 기간은 1시간입니다. 현재는 Azure Portal에서만 보존 기간을 시간 단위로 설정할 수 있습니다. Resource Manager 템플릿, PowerShell 및 CLI를 사용하면 이 속성을 일 단위로만 설정할 수 있습니다.
  • 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 Hubs(또는 Apache Kafka)의 기능 범위 내에 있지 않습니다. 따라서 Azure Data Lake Store, Azure Data Lake Analytics 및 Azure Synapse와 같은 데이터베이스 및 특수 분석 저장소 및 엔진은 기록 이벤트를 저장하는 데 훨씬 더 적합합니다.

Event Hubs 캡처는 Azure Blob Storage 및 Azure Data Lake Storage와 직접 통합되며, 이러한 통합을 통해 Azure Synapse로 이벤트를 직접 이동할 수도 있습니다.

게시자 정책

Event Hubs는 게시자 정책을 통한 이벤트 게시자에 대한 세부적 제어를 사용합니다. 게시자 정책은 다수의 독립 이벤트 게시자를 용이하게 하기 위해 설계된 런타임 기능입니다. 게시자 정책을 사용하면 각 게시자는 다음 메커니즘을 사용하여 이벤트 허브에 이벤트를 게시할 때 고유한 고유 식별자를 사용합니다.

//<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 형식으로 작성됩니다.

Diagram that shows the capturing of Event Hubs data into Azure Storage or Azure Data Lake Storage.

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

Diagram showing the structure of captured Avro data.

참고 항목

Azure Portal에서 코드 편집기를 사용하지 않는 경우 Parquet 형식으로 Azure Data Lake Storage Gen2 계정의 Event Hubs에서 스트리밍 데이터를 캡처할 수 있습니다. 자세한 내용은 방법: Event Hubs에서 데이터를 Parquet 형식으로 캡처 및 자습서: Event Hubs 데이터를 Parquet 형식으로 캡처하고 Azure Synapse Analytics로 분석을 참조하세요.

SAS 토큰

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

이벤트 소비자

이벤트 허브에서 이벤트 데이터를 읽는 모든 엔터티는 이벤트 소비자입니다. 모든 Event Hubs 소비자는 AMQP 1.0 세션을 통해 연결되며, 이벤트를 사용할 수 있게 되면 세션을 통해 전달됩니다. 클라이언트는 데이터 가용성에 대해 폴링할 필요가 없습니다.

소비자 그룹

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

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

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

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 스트림을 보여 줍니다.

Diagram that shows the Event Hubs stream processing architecture.

스트림 오프셋

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

Diagram that shows a partition with an offset.

검사점 설정

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

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

Important

오프셋은 Event Hubs 서비스에서 제공합니다. 이벤트가 처리될 때 검사포인트를 지정하는 것은 소비자의 책임입니다.

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

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

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

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

로그 압축

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

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

일반 소비자 작업

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

파티션에 커넥트

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

읽기 이벤트

특정 파티션에 대한 AMQP 1.0 세션 및 링크가 열리면 Event Hubs 서비스에서 AMQP 1.0 클라이언트에 이벤트가 전달됩니다. 이 전달 메커니즘을 사용하면 HTTP GET과 같은 풀 기반 메커니즘보다 처리량이 높고 대기 시간이 짧아질 수 있습니다. 이벤트가 클라이언트로 전송되면 각 이벤트 데이터 인스턴스에는 이벤트 시퀀스에서 검사포인트를 쉽게 지정하는 데 사용되는 오프셋 및 시퀀스 번호와 같은 중요한 메타데이터가 포함됩니다.

이벤트 데이터:

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

오프셋을 관리하는 것은 사용자의 책임입니다.

애플리케이션 그룹

애플리케이션 그룹은 보안 컨텍스트와 같은 고유한 식별 조건(공유 액세스 정책 또는 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 broker와 동일한 핵심 기능을 얻는 것 외에도 Event Hubs 캡처를 통한 자동 일괄 처리 및 보관, 자동 크기 조정 및 분산, 재해 복구, 비용 중립적 가용성 영역 지원, 유연하고 안전한 네트워크 통합 및 방화벽 친화적인 AMQP-over-WebSockets 프로토콜을 포함한 다중 프로토콜 지원과 같은 Azure Event Hubs 기능에 액세스할 수 있습니다.

다음 단계

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