
모든 소스에서 모든 대상으로 데이터를 스트리밍할 수 있는 클라우드 네이티브 서비스


관리 컨테이너. 용량 할당 및 재해 복구 설정 단위
폴더 같은 느낌. 중첩 구조는 아님.
추가 전용(Append-only) 분산 로그
처리량을 늘리기 위한 확장의 기본 단위
여러 소비자가 독립적인 속도와 오프셋으로 읽기 수행

공급자를 통해 메시지 전송된 뒤 이벤트 허브에 저장되고, 최종적으로 컨슈머 그룹에 제공됨.

사용량 요구에 맞춰 처치량 단위(TU) 자동 확장
다만 비용 관리 면에서 주의해서, 확장 상한선을 정해두어야 한다.
확장시 관리자에게 알림을 보내도록 처리한다던지 하는것이 바람직하다.

최대 20MB의 이벤트 수용 가능. 작은 세그먼트로 나눌 수 없는 데이터 처리
시스템로그, 이미지 파일 같은 경우를 처리할 때 유용

실시간 로그 분석을 통한 핵/부정 사용자 감지
스마트 팩토리 설비 이상 징후 모니터링
실시간 트랜잭션 모니터링 및 이상 거래 탐지
Kafka 워크로드를 위한 서버리스 접근 방식
| 구분 | 직접 구축한 Kafka (Legacy) | Azure Event Hubs (Modern) |
|---|---|---|
| 구성 | 자체 서버 기반 Kafka 클러스터 | Kafka + Azure Event Hubs |
| 운영 요소 | Zookeeper 관리, 브로커 구성, 서버 패치 필요 | Azure 관리형 서비스 |
| 운영 비용 | 높음 | 상대적으로 낮음 |
| 마이그레이션 | - | Seamless Migration 지원 |
| Kafka 호환성 | Kafka 자체 | Kafka 1.0+ 프로토콜 지원 |
| 코드 변경 | - | Endpoint 변경만으로 완료 |
| 프로토콜 지원 | Kafka 전용 | Kafka + Azure Native(AMQP) |
| 확장성/유지보수 | 직접 관리 필요 | 자동 확장 및 관리 |
마이그레이션 시 환경변수등에서 endpoint만 변경해주면 됨
둘 다 스트리밍 데이터를 위한 파티션 분할 로그

| Standard | Premium | Dedicated | |
|---|---|---|---|
| 버전 | 1.0이상 지원 | 1.0이상 지원 | 1.0이상 지원 |
| Streams | - | 클라이언트 라이브러리 지원 | 클라이언트 라이브러리 지원 |
| Transactions | - | 트랜잭션 API 지원 | 트랜잭션 API 지원 |
| Compression | - | Gzip 지원(클라이언트 측 배치) | Gzip 지원(클라이언트 측 배치) |
| Idempotency | 생산자 및 소비자 멱등성 지원 | 생산자 및 소비자 멱등성 지원 | 생산자 및 소비자 멱등성 지원 |
AMPQ 소비자는 압축된 Kafka 트래픽을 압축 해제된 메시지로 소비 가능MPQ 소비자는 압축된 Kafka 트래픽을 압축 해제된 메시지로 소비 가능
AMPQ: Advanced Message Queuing Protocol(고급 메시지 큐잉 프로토콜)
ksqlDB는 Confluent의 독점 라이선스 제품. 라이선스 조건으로 인해 Azure Event Hubs(또는 경쟁 클라우드 서비스)에서는 ksqlDB를 제공하거나 사용할 수 없음.
다음 통합 서비스를 이용해 SQL 기반 스트림 분석 가능

https://learn.microsoft.com/ko-kr/azure/event-hubs/azure-event-hubs-apache-kafka-overview#oauth-20
모든 전송 데이터는 TLS로 암호화
Micorosft Entra ID 통합
security.protocol = SASL_SSL
sasl.mechanism = OAUTHBEARER
sasl.jaas.config = org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;
sasl.login.callback.handler.class = CustomAuthenticateCallbackHandler
레거시/단순 연결
security.protocol = SASL_SSL
sasl.mechanism = PLAIN
username = "$ConnectionString"
password = {YOUR>EVENTHUBS.CONNECTION>STRING}
주의: 키가 재생성되어도 기존 연결은 끊어지지 않음. 수동 키 관리 필요.

이벤트 스트리밍을 위한 중앙 집중식 스키마 관리 및 데이터 무결성 확보

분산된 애플리케이션 간의 통신은 주로 데이터를 통해 이루어지지만, 생산자와 소비자 간의 데이터 계약이 명확하지 않으면 대규모 처리 시 안정성이 저하
스키마 관리자 이벤트 데이터 외부에서 이루어지지 않을 경우, 데이터 구조 변경 시 파이프라인이 중단되거나 호환성 문제가 발생

신뢰할 수 있는 단일 소스
스키마를 위한 중앙 집중식 리포지토리로, 스키마의 등록, 관리 및 진화를 담당
모든 스키마화된 데이터에 대해 엄격한 유효성 검사를 수행하여 무결성 보장
다양한 호환성 규칙을 적용하여 중단 없는 스키마 진화를 지원
생산자와 소비자 간의 명확한 계약을 통해 데이터 품질 보장
비즈니스 요구사항 변화에 따른 데이터 구조 변경을 유연하게 수용
서로 다른 시스템 간의 원활한 데이터 교환을 지원
전체 스키마 정의 대신 스키마 ID만 전달하여 페이로드 크기를 감소


Producer와 Consumer는 동일한 스키마를 통해 데이터의 무결성을 상호 검증 가능
스키마가 인프라 내부에 안전하게 저장되므로 데이터 해석 오류를 원천 차단
Azure Event Hubs의 스트리밍 데이터를 Azure Blob Storage 또는 Azure Data Lake Storage 계쩡으로 자동 전송하는 기능
Azure Event Hub는 Buffer의 기능이므로, 휘발된다. 따라서 이 데이터를 보관하기 위한 기능.
Event Hub에서 들어온 데이터를 Storage에 저장, 즉 내부망 이용 → 별도 네트워크 비용 X
Event Hubs 용량에 맞춰 자동으로 확장
데이터 로드 과정을 단순화하여 엔지니어가 수집이 아닌 처리에 집중할 수 있게 함
시간 또는 크기 간격을 지정하여 데이터 저장 시점을 정밀하게 제어

Event Hubs와 Capture는 같은 구독에 있어야 함
SSD를 사용하는 프리미엄 플랜 지원 X

1. 수집: 원격 분석 데이터가 분산 로그 형태의 내구성 있는 버퍼로 유입
2. 파티셔닝: 각 파티션은 독립적인 데이터 세그먼트로 작동하여 확장성 보장
3. 캡처: 설정된 정책에 따라 Storage로 데이터를 자동 기록, 데이터는 영구 보존
4. 분석: 저장된 데이터는 Azure Stream Analytics, HDInsight 등에서 활용
First Wins(선착순) 정책: 크기 vs 시간
예시 설정: 시간 윈도우 15분 vs 크기 윈도우 100MB (데이터 유입 속도: 1MB/Sec)

작동 방식: 두 조건 중 먼저 충족되는 조건이 캡처를 트리거
결과: 1분 40초 시점에 100MB가 먼저 충족되므로, 5분을 기다리지 않고 즉시 파일 생성

Event Hubs의 용량이 확장됨에 따라 Capture 성능도 자동으로 확장
Capture 트래픽은 처리량 단위의 송신 할당량을 소모하지 않음
Stream Analytics나 Spark와 같은 다른 Reader를 위한 대역폭이 온전히 보존

블롭 이름은 캡처 간격이 발생한 정확한 시점을 반영하며, 날짜 및 시간 값은 0으로 채워짐
/{Namespace}/{EventHub}/{PartitionID}/{Year}/{Month}/{Day}/{Hour}/{Minute}/{Second}
https://mystorage.blob.core.window.net/container/mynamespace/myeventhub/2026/01/18/03/03/17.avro
Producer에서 메시지 아웃바운딩을 통해 Event Hub로 보내는 실습

Event Hubs 네임스페이스는 Event Hub를 포함하는 상위 개념
1. Azure Portal의 왼쪽 메뉴에서 모든서비스 선택
2. EventHubs를 검색하고 선택




강의에서 제공된 샘플 코드 데이터를 git clone 했다.
이 과정에서 github_pat.txt 파일을 사용했다.
git clone https://{pat파일 내용 붙여넣기}@{github주소봍북}
{
"IsEncrypted": false,
"Values": {
"AzureWebJosbStorage": "UseDevelopmentStorage=true",
"FUNCTIONS_WORKER_RUNTIME": "python",
"SolarEventHubName":"",
"SolarEventHubConnectionString":""
}
}

1. 리소스 그룹 내의 Event Hubs 네임스페이스 페이지에 접속
2. 좌측 설정 - 공유 액세스 정책
3. Primary connection string(기본 연결 문자열)
4. "SolarEventHubConnectionString" 에 넣기
5. "SolarEventHubName" 에 Event Hubs Namespace 이름 입력
F1 azurite startF5로 실행Execute Function Now 선택(혹은 리턴된 http 주소를 열거나, postman을 사용해도 무방)
7. 요청 본문에 {"name":"Solar Energy"} 입력 후 실행


1. Azure Portal의 EventHubs 네임스페이스 개요 페이지에서 EventHub 클릭

Data Explorer 메뉴 선택
이벤트 보기

이벤트 본문 확인







다른 애플리케이션이나 서비스와의 통합을 위한 HTTP 호출 지점
특정 이벤트가 발생했을 때 자동으로 지정된 URL로 데이터를 전송하는 프로세스

반복적인 작업을 자동화하여 업무 효율성 향상

태양광 발전량 예측 API, Azure Functions, Event Hubs를 연동해 태양광 발전량 예측 데이터 수집



새 흐름 버튼 클릭
자동화된 클라우드 흐름 버튼 클릭
건너뛰기

웹 후크 검색

Teams 웹후크 요청이 수신된 경우 클릭
Anyone 입력

새 단계 버튼 클릭
작업 선택 폼에서 Microsoft Teams 버튼 클릭
채팅 또는 채널에서 메시지 게시 클릭

채팅 또는 채널에서 메시지 게시 폼에 입력


curl -X POST "웹 훅 주소"

이후 저장된 웹 훅은 채널 자체의 PowerAutomate 탭이 아닌, 더보기의 워크플로우에서 볼 수 있다.

동일하게 github pat 사용
{
"IsEncrypted": false,
"Values": {
"AzureWebJosbStorage": "UseDevelopmentStorage=true",
"FUNCTIONS_WORKER_RUNTIME": "python",
"SolarEventHubName": "",
"SolarEventHubConnectionString": "",
"AzureWebHookUrl": ""
}
}
py -3.11 venv .venv
.venv/Scripts/activate
pip install -r requirements.txt
F1후 start azurite
F5
좌측 local에서 함수 우클릭 후solar_predict_event_scheduler 에서 마우스 오른쪽 버튼
Execute Function Now 클릭

터미널에서 태양광 발전량 예측 데이터 수집 스케줄러 로그 확인

팀즈에서 웹훅 메시지 확인

EventHub에서 태양광 발전량 예측 API 데이터 확인하기



VSCode 에서 F1 → deploy → 우측하단 upload settings(혹은 f1 → upload settings)

azure portal에서 환경변수 설정 (만약 upload settings를 안했다면)

함수 실행 확인



Event Hub 확인





