다음을 통해 공유

Azure Event Hubs에 대한 Azure 잘 설계된 프레임워크 관점

  • 아티클

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

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

Event Hubs를 사용하여 워크로드에 대한 운영 우수성과 안정성을 달성하는 데 도움이 되는 방법을 이해하려면 다음 문서를 참조하세요.

다음 섹션은 잘 설계된 프레임워크 관점에서 Azure Event Hubs와 관련이 있습니다.

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

디자인 고려 사항

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

검사 목록

운영 우수성을 염두에 두고 Azure Event Hubs를 구성했나요?

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

구성 권장 사항

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

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

원본 아티팩트

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

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

다음 단계

Service Bus 및 안정성