Event Hubs 및 안정성

아티클
11/14/2023

Azure Event Hubs는 확장 가능한 처리 서비스로 대량의 이벤트 및 데이터를 수집하여 처리하며, 대기 시간이 낮고 안정성이 우수합니다. 초당 수백만 개의 이벤트를 수신하고 처리할 수 있습니다. 이벤트 허브로 전송된 데이터는 실시간 분석 공급자 또는 일괄 처리 및 스토리지 어댑터를 사용하여 변환하고 저장할 수 있습니다.

Event Hubs 사용에 대한 자세한 내용을 보려면 Azure Event Hubs 설명서를 참조하여 Event Hubs를 통해 연결된 디바이스와 애플리케이션에서 초당 수백만 개의 이벤트를 수집하는 방법을 알아보세요.

Event Hubs를 사용하여 보다 안정적인 워크로드를 만드는 방법을 이해하려면 Azure Event Hubs - 지역 재해 복구를 참조하세요.

다음 섹션은 Azure Event Hubs 및 안정성과 관련이 있습니다.

디자인 고려 사항
구성 검사 목록
권장 구성 옵션
원본 아티팩트

디자인 고려 사항

Azure Event Hubs는 작동 시간 SLA를 제공합니다. 자세한 내용은 Event Hubs에 대한 SLA를 참조하세요.

검사 목록

안정성을 염두에 두고 Azure Event Hubs를 구성했나요?

이벤트 게시자 및 소비자를 위해 각각 SendOnly 및 ListenOnly 정책을 만듭니다.
SDK를 사용하여 Event Hubs에 이벤트를 보내는 경우 재시도 정책(EventHubsException 또는 OperationCancelledException)에 의해 throw된 예외가 제대로 catch되는지 확인합니다.
높은 처리량 시나리오에서는 일괄 처리 이벤트를 사용합니다.
모든 소비자는 1~32개 파티션에서 이벤트를 읽을 수 있습니다.
새 애플리케이션을 개발할 때 EventProcessorClient(.NET 및 Java) 또는 EventHubConsumerClient(Python 및 JavaScript)를 클라이언트 SDK로 사용합니다.
솔루션 전체 가용성 및 재해 복구 전략의 일환으로 Event Hubs 지역 재해 복구 옵션을 사용하는 것이 좋습니다.
솔루션에 다수의 독립 이벤트 게시자가 있는 경우 세분화된 액세스 제어를 위해 이벤트 게시자를 사용하는 것이 좋습니다.
특정 파티션에 이벤트를 게시하지 마세요.
이벤트를 자주 게시하는 경우 되도록이면 AMQP 프로토콜을 사용합니다.
파티션 수는 달성할 수 있는 다운스트림 병렬 처리 수준을 반영합니다.
각 사용 애플리케이션이 개별 소비자 그룹을 사용하고 소비자 그룹당 활성 수신기가 하나만 있는지 확인합니다.
캡처 기능을 사용하는 경우 특히 이벤트 볼륨이 적은 기간과 파일 크기 구성을 신중하게 고려해야 합니다.

구성 권장 사항

Azure Event Hubs를 구성할 때 안정성을 최적화하려면 다음 권장 사항을 고려하세요.

권장	Description
SDK를 사용하여 Event Hubs에 이벤트를 보내는 경우 재시도 정책(`EventHubsException` 또는 `OperationCancelledException`)에 의해 throw된 예외가 제대로 catch되는지 확인합니다.	`HTTPS`를 사용하는 경우 적절한 재시도 패턴이 구현되었는지 확인합니다.
높은 처리량 시나리오에서는 일괄 처리 이벤트를 사용합니다.	이 서비스는 하나의 이벤트가 있는 배열 대신 여러 이벤트가 있는 `json` 배열을 구독자에게 전달합니다. 사용 애플리케이션은 이 배열을 처리해야 합니다.
모든 소비자는 1~`32`개 파티션에서 이벤트를 읽을 수 있습니다.	사용 애플리케이션 쪽에서 최대 스케일링을 달성하려면 모든 소비자가 단일 파티션에서 읽어야 합니다.
새 애플리케이션을 개발할 때 `EventProcessorClient`(.NET 및 Java) 또는 `EventHubConsumerClient`(Python 및 JavaScript)를 클라이언트 SDK로 사용합니다.	`EventProcessorHost`는 사용되지 않습니다.
솔루션 전체 가용성 및 재해 복구 전략의 일환으로 Event Hubs 지역 재해 복구 옵션을 사용하는 것이 좋습니다.	이 옵션을 사용하면 다른 지역에 보조 네임스페이스를 만들 수 있습니다. 언제든지 활성 네임스페이스만 메시지를 수신합니다. 메시지와 이벤트는 보조 지역에 복제되지 않습니다. 지역 장애 조치(failover)의 RTO는 최대 30분입니다. 이 RTO가 고객의 요구 사항에 부합하고 더 광범위한 가용성 전략에 적합한지 확인합니다. 더 높은 RTO가 필요한 경우 클라이언트 쪽 장애 조치(failover) 패턴을 구현하는 것이 좋습니다.
솔루션에 다수의 독립 이벤트 게시자가 있는 경우 세분화된 액세스 제어를 위해 이벤트 게시자를 사용하는 것이 좋습니다.	이벤트 게시자는 파티션 키를 게시자 이름으로 자동으로 설정하므로 이벤트가 모든 게시자에서 균등하게 발생하는 경우에만 이 기능을 사용해야 합니다.
특정 파티션에 이벤트를 게시하지 마세요.	이벤트 순서 지정이 필수적인 경우 순서 지정 다운스트림을 구현하거나 다른 메시징 서비스를 대신 사용합니다.
이벤트를 자주 게시하는 경우 되도록이면 AMQP 프로토콜을 사용합니다.	AMQP는 세션을 초기화할 때 네트워크 비용이 더 많이 듭니다. 그러나 `HTTPS`를 사용하려면 모든 요청에 대한 TLS 오버헤드가 필요합니다. AMQP는 빈번한 게시자에게 더 높은 성능을 제공합니다.
파티션 수는 달성할 수 있는 다운스트림 병렬 처리 수준을 반영합니다.	최대 처리량의 경우 이벤트 허브를 만들 때 최대 파티션 수(`32`)를 사용합니다. 최대 파티션 수를 사용하면 `32`개 동시 처리 엔터티로 스케일 업할 수 있으며 가장 높은 송신 및 수신 가용성이 제공됩니다.
캡처 기능을 사용하는 경우 특히 이벤트 볼륨이 적은 기간과 파일 크기 구성을 신중하게 고려해야 합니다.	Data Lake는 스토리지의 최소 파일 크기(gen1) 또는 최소 트랜잭션 크기(gen2)에 해당하는 요금이 부과됩니다. 기간을 너무 낮게 설정하여 파일이 최소 크기에 도달하지 않으면 추가 비용이 발생합니다.

원본 아티팩트

기본 SKU가 있는 Event Hubs 네임스페이스를 찾으려면 다음 쿼리를 사용합니다.

Resources 
| where type == 'microsoft.eventhub/namespaces'
| where sku.name == 'Basic'
| project resourceGroup, name, sku.name

다음 단계

Event Hubs 및 운영 우수성

Share via