Azure Functions와 함께 Azure Event Hubs를 사용하는 솔루션은 확장성 있고 비용 효율적이며 근 실시간으로 대량의 데이터를 처리할 수 있는 서버리스 아키텍처의 이점을 제공합니다. 이러한 서비스가 함께 원활하게 작동하는 만큼 관계에 복잡성을 더하는 많은 기능, 설정 및 복잡성이 있습니다. 이 문서에서는 성능, 복원력, 보안, 가시성 및 규모에 대한 주요 고려 사항과 기술을 강조하여 이 통합을 효과적으로 활용하는 방법에 대한 지침을 제공합니다.
Event Hubs 핵심 개념
Azure Event Hubs는 초당 수백만 개의 이벤트를 수신할 수 있는 확장성이 뛰어난 이벤트 처리 서비스입니다. Azure Functions 통합에 대한 패턴 및 모범 사례를 살펴보기 전에 Event Hubs의 기본 구성 요소를 이해하는 것이 가장 좋습니다.
다음 다이어그램은 Event Hubs 스트림 처리 아키텍처를 보여줍니다.
이벤트
이벤트는 과거에 발생한 사실로 표시되는 알림 또는 상태 변경입니다. 이벤트는 변경되지 않으며 Kafka에서 토픽이라고도 하는 이벤트 허브에서 유지됩니다. 이벤트 허브는 하나 이상의 파티션으로 구성됩니다.
파티션
발신자가 파티션을 지정하지 않으면 수신된 이벤트가 이벤트 허브의 파티션에 분산됩니다. 각 이벤트는 정확히 1개 파티션에 기록되며 파티션 간에 멀티캐스트되지 않습니다. 각 파티션은 레코드가 추가 전용 패턴으로 기록되는 로그로 작동합니다. 커밋 로그의 비유는 파티션에서 시퀀스의 끝에 이벤트가 추가되는 방식의 특성을 설명하는 데 자주 사용됩니다.
둘 이상의 파티션을 사용하면 동일한 이벤트 허브 내에서 병렬 로그를 사용할 수 있습니다. 이 동작은 여러 수준의 병렬 처리를 제공하고 소비자의 처리량을 향상시킵니다.
소비자 및 소비자 그룹
파티션은 둘 이상의 소비자가 사용할 수 있으며, 각 소비자는 자체 오프셋을 읽고 관리할 수 있습니다.
Event Hubs에는 소비자 그룹이라는 개념이 있습니다. 이를 통해 여러 소비 애플리케이션이 각각 이벤트 스트림에 대한 별도의 보기를 갖고 자체 속도와 자체 오프셋으로 독립적으로 스트림을 읽을 수 있습니다.
자세한 내용은 Event Hubs 개념 및 기능에 대한 심층 분석을 참조하세요.
Azure Functions로 이벤트 사용
Azure Functions는 Event Hubs에 대한 트리거 및 출력 바인딩을 지원합니다. 이 섹션에서는 Azure Functions가 트리거를 사용하여 이벤트 허브 이벤트 스트림으로 전송된 이벤트에 응답하는 방법을 설명합니다.
Event Hubs 트리거 함수의 각 인스턴스는 단일 EventProcessorHost 인스턴스에서 지원됩니다. 트리거(Event Hubs 구동)는 하나의 EventProcessorHost 인스턴스만 지정된 파티션에서 임대를 받을 수 있도록 합니다.
예를 들어 다음과 같은 특성을 가진 이벤트 허브를 고려합니다.
- 10개의 파티션
- 1,000개의 이벤트가 모든 파티션에 균등하게 분산되었고 각 파티션의 메시지 수가 다양합니다.
함수가 처음 활성화되면 함수 인스턴스가 하나만 있습니다. 첫 번째 함수 인스턴스인 Function_1을 호출해 보겠습니다. Function_1에는 10개 파티션 모두에 대한 임대를 보유하는 EventProcessorHost의 단일 인스턴스가 있습니다. 이 인스턴스는 파티션 1-10에서 이벤트를 읽습니다. 이 지점부터 다음 중 하나가 발생합니다.
새 함수 인스턴스가 필요하지 않음:
Function_1은 Functions 크기 조정 논리가 적용되기 전에 1,000개 이벤트를 모두 처리할 수 있습니다. 이 경우 1,000개 메시지는 모두Function_1에서 처리됩니다.
추가 함수 인스턴스가 추가됨: 이벤트 기반 크기 조정 또는 기타 자동화 또는 수동 논리는
Function_1에 처리할 수 있는 것보다 더 많은 메시지가 있다고 판단한 다음, 새 함수 앱 인스턴스(Function_2)를 만들 수 있습니다. 이 새 함수에도 EventProcessorHost의 연결된 인스턴스가 있습니다. 기본 이벤트 허브는 새 호스트 인스턴스가 메시지 읽기를 시도하고 있음을 감지하면 호스트 인스턴스 간에 파티션의 부하를 분산합니다. 예를 들어 파티션 1-5는Function_1에 할당되고 파티션 6-10은Function_2에 할당될 수 있습니다.
N개 이상의 함수 인스턴스가 추가됨: 이벤트 기반 크기 조정 또는 기타 자동 또는 수동 논리가
Function_1및Function_2둘 다에 처리할 수 있는 것보다 더 많은 메시지가 있다고 판단하면 새로운 Function_N 함수 앱 인스턴스가 생성됩니다. N이 이벤트 허브 파티션 수보다 크거나 같은 지점까지 인스턴스가 생성됩니다. 이 예에서 Event Hubs는 다시 파티션을 부하 분산합니다(이 경우, 인스턴스Function_1...Function_10로).
크기 조정이 수행되면 N 인스턴스는 이벤트 허브 파티션 수보다 클 수 있습니다. 이 상황은 이벤트 기반 크기 조정이 인스턴스 수를 안정화하는 동안 또는 다른 자동화 또는 수동 논리가 파티션보다 더 많은 인스턴스를 만들었기 때문에 발생할 수 있습니다. 이 경우 EventProcessorHost 인스턴스는 다른 인스턴스에서 사용할 수 있을 때만 파티션에 대한 잠금을 얻습니다. 지정된 시간에 동일한 소비자 그룹의 함수 인스턴스 하나만 잠겨 있는 파티션에서 액세스/읽을 수 있기 때문입니다.
모든 함수 실행이 오류 없이 완료되면 연결된 스토리지 계정에 검사점이 추가됩니다. 검사점이 성공적으로 설정되면 1,000개 메시지 모두가 다시 검색되지 않습니다.
동적 이벤트 기반 크기 조정은 사용량 및 프리미엄 Azure 플랜에서 가능합니다. Kubernetes 호스팅 함수 앱은 Event Hubs용 KEDA 스케일러를 활용할 수도 있습니다. 워크로드에 따라 적절한 인스턴스 수를 결정해야 하는 전용(App Service) 플랜에서 함수 앱이 호스트되는 경우 이벤트 기반 크기 조정은 현재 불가능합니다.
자세한 내용은 Azure Functions의 Azure Event Hubs 바인딩 및 Azure Functions의 Azure Event Hubs 트리거를 참조하세요.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- David Barkol | 수석 솔루션 전문가 GBB
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.
다음 단계
관련 참고 자료
- 서버리스 이벤트 처리 모니터링은 서버리스 이벤트 기반 아키텍처 모니터링에 대한 지침을 제공합니다.
- 서버리스 이벤트 처리는 코드 샘플 및 중요한 고려 사항에 대한 논의와 함께 이 유형의 일반적인 아키텍처를 자세히 설명하는 참조 아키텍처입니다.
- Event Hubs를 사용하여 서버리스 이벤트 처리에서 일괄 처리 해제 및 필터링은 참조 아키텍처의 이러한 부분이 작동하는 방식을 자세히 설명합니다.