[AZ-204] Azure Event

게시 2025/01/07

15 분읽는 시간

아키텍쳐

Azure Event Grid는 서버리스로 운영되며 App의 통합하는데 사용되는 이벤트 브로커이다.

이벤트들은 Event Grid에서 Azure 서비스나 엔드포인트 같은 곳으로 전달되며 이러한 원본은 Azure나 다른 서비스일 수 있다.

이러한 Event Grid를 사용하면 리소스 그룹과 스토리지 등의 필터를 사용한 이벤트 기반 아키텍쳐 AP를 쉽게 빌드가 가능하다.

Azure Event Grid의 개념

이벤트 : 시스템에서 발생하는 가장 작은 크기의 정보 또는 이벤트에 대한 특정정보 ex) Azure Storage에서 새 파일을 만드는 이벤트(이러한 이벤트에는 listTimeModired 와 같은 세부정보도 포함됨) 또는 캡쳐 파일의 URL

이벤트 원본 이벤트가 발생하는 위치 예를 들어 Azure Storage에서 생성딘 Blob은 Azure Storage가 이벤트 원본이다. 주로 이벤트 원본은 Event Grid에 보내는 역할을 담당

토픽 이벤트를 받는 주소를 말한다. 이때 Event grid 토픽은 얼마나 많은 토픽(주소)를 만들지 결정할 수 있다. 이러한 토픽은 시스템 토픽과 사용자 지정 토픽으로 나뉠 수 있다.

시스템 토픽 Azure에서 제공하는 기본 제공 토픽, 마치 Azure의 리소스들의 주소이다. 이를 활성화하기 위해서는 리소스에 대한 정보만 제공하면 가능하다.

사용자 지정 토픽 사용자가 직접 생성하는 토픽

이벤트 처리기 이벤트가 전송되는 곳으로 처리기의 형식에 따라 이벤트 배달의 보장은 다양한 메커니즘을 따른다.

Webhook 이벤트 처리 엔드포인트로 이벤트를 처리하고 구독자에게 전달 하는 방식

이벤트 스키마

Azure Event Grid는 Event Grid 이벤트 스키마와 Cloud 이벤트 스키마라는 두 가지 유형의 이벤트 스키마를 지원한다. 이러한 모든 이벤트는 공통적으로 가지고 있는 속성이 있는데 이러한 속성은 리소스 공급자에 있어 차이가 있다. (topic, id, data…) 이러한 이벤트의 원본은 주로 이벤트 배열(최대 1MB)에 담겨 전송하는데 최대 1MB을 넘을시에는 오류가 발생한다. 또한 비용부과는 64KB단위로 계산되어진다.. (130kb 이벤트라면 3개의 이벤트로 요금이 부과)

Cloud 이벤트 스키마도 지원하는데 타 클라우드 플랫폼간 데이터 일관성을 위한 표준 사양이다. 일반적인 Azure Event Grid 스키마의 헤더 값이 "content-type":"application/json; charset=utf-8" 이다면 Cloud 스키아의 헤더는 "content-type":"application/cloudevents+json; charset=utf-8" 이다.

이벤트 배달 내구성

EventGrid는 지속성 있는 배달을 위해 한번 이상의 즉시 배달을 제공한다. 하지만 일반적으로 Event Grid는 배달 순서를 보장하지는 않는다.

다시 시도 일정 만약 Event가 정상 수신이 불가능할 때 배달을 다시 시도할지 다시 시도 일정을 설정할 수 있다. 일반적으로 배달을 하고 30초간 응답을 기다린다. 만약 엔드포인트가 응답하지 않으면 다시 시도 일정을 위해 큐에 대기시킨다.

하지만 만약 구성 관련 오류(엔드포인트 삭제, 엔티티가 너무 큼, 권한 없음) 같은 문제일 경우 다시 시도 일정은 이뤄지지 않는다.

재시도 정책 이벤트를 만들 때 재시도 정책 사용이 가능하다. 정책 중 하나라도 값에 도달하면 이벤트가 삭제된다.

최대 시도 회수 : 1 ~ 30의 정수 값
이벤트 TTL : 값은 1 ~ 1440 정수 값

출력 일괄 처리

일괄 처리 이벤트 수 : 여러 이벤트를 모아 한번에 전달하는 방법 시스템 자원의 효율성을 증대할 수 있다. 1~5000 사이의 정수 값
기본 일괄 처리 크기 : 일괄 처리의 총 크기를 제한한다. 만약 하나의 이벤트가 이 크기보다 크다면 해당 이벤트는 단독으로 일괄 처리되어 전송되어진다.

배달 지연 이벤트가 정상적으로 배달하지 못한 엔드포인트에 대해서 재시도를 얼마동안 지연시킨다. 이는 비정상 엔드포인트와 Event Grid 시스템을 과부하로부터 보호한다.

배달불가 여러 번 시도 후 배달할 수 없는 경우(TTL 초과, 시도 횟수 초과) 기본적으로 이벤트는 삭제되지만 별도의 정책을 허용하고 스토리지 계정을 생성한 경우 해당 Storage에 저장한다.

이벤트 송/수신

Azure Event Grid에서 이벤트를 수신하는 방법 중 하나로 일반적인 통신처럼 Event 송수신에 앞서 소유권과 유효성을 검사한다. Azure Logic apps와 Azure Function은 자동적으로 해당 유효성을 검사처리한다.

Event Grid 이벤트를 사용한 엔드포인트 유효성 검사

동기 handshake: 이벤트 구독이 생성되는대로 엔드포인트에 유효성 검사를 한다. 단 이 이벤트는 데이터 부분에 vaildationCode를 포함한다. 그리고 이러한 유효성 검사 코드를 동기식으로 반환한다.
비동기 handshake: 유효성 검사에 있어 동기식 반환이 안되는 경우가 있다.. (타사 서비스)

이것 이외에도 수동 유효성 검사 handshake를 제공한다.

이벤트 그리드 역할 제공

구독 Reader, 구독 Contributor는 Event Grid를 읽거나 관리할 수 있다. Event Grid Contributor는 역할을 사용하여 Event Grid 리소스를 만들고 관리할 수 있으며 데이터 전송자는 이벤트를 Event Grid 토픽에 보낼 수 있는 역할을 제공한다.

이벤트 필터링

기본적으로 이벤트 원본에 대한 모든 이벤트 유형은 엔드포인트로 전송되어진다. 여기서 특정 이벤트 유형만 전송되게 할 수 있는데 리소스에 대한 업데이트 알림만 받고 삭제 알림은 받지 않는 식으로 진행이 가능하다.

  
"filter": {
  "includedEventTypes": [
    "Microsoft.Resources.ResourceWriteFailure",
    "Microsoft.Resources.ResourceWriteSuccess"
  ]
}

위 JSON은 리소스 쓰기 성공과 실패에 대한 이벤트만 받도록 필터링한다.

또한 제목에 대한 시작과 끝을 기준으로 필터링도 가능하다.

  
"filter": {
  "subjectBeginsWith": "/blobServices/default/containers/mycontainer/log",
  "subjectEndsWith": ".jpg"
}

"/blobServices/default/containers/mycontainer/log" 로 시작하고 .jpg 로 끝나는 제목의 이벤트만 받는 필터

또한 세부조건으로 필터링이 가능하며, 조건, 문자열 포함 여부 등도 가능하다.

  
"filter": {
  "advancedFilters": [
    {
      "operatorType": "NumberGreaterThanOrEquals",
      "key": "Data.Key1",
      "value": 5
    },
    {
      "operatorType": "StringContains",
      "key": "Subject",
      "values": ["container1", "container2"]
    }
  ]
}

Data.key1 의 값이 5 이상, Subject에 values 의 값을이 포함된 이벤트만 받는 필터

Azure Event Hubs

수백만개의 Azure Event를 관리할 수 있는 클라우드 네이티브 데이터 스트리밍 서비스이다.

Apache Kafka, AMQP, HTTPS 프로토콜을 지원하는 다중 프로토콜 이벤트 스트리밍 엔진이다.

또한 Azuure 스키마 레지스트리라는 중앙 집중식 레포지터리를 제공하는데 네임스페이스와 함께 무료로 제공된다.

추가적으로 Azure Stream Analytics와 실시간 통합하여 스트림처리를 제공하는데 이를 통해 쿼리 언어를 실행하여 데이터 분석 기능을 제공한다.

즉 Azure Event hubs는 생산자 AP(Kafka)와 EventHub/Kafka 토픽등을 사용해 로그를 추척할 수 있으며 파티션을 통해 스트리밍 처리량을 조절하며 소비자 AP를 통해 데이터를 사용가능하다.

Event Hubs 캡처

파티션이란 이벤트 허브의 크기를 조정하는데 이는 고속도로의 차선과 같은 기능을 제공한다. 만약 스트리밍 처리량이 더 필요한 경우 파티션을 더 추가하는 방식으로 조절이 가능하다.

이는 자동적으로 조절되는 분산된 로그 형식이며 각 파티션은 독립적인 세그먼트로 관리된다. 즉 Event Hub는 꽉 참 상태가 존재할 수 없다.

이를 통해 유연하게 지정하여 스트리밍 데이터를 캡쳐해 Azure Blob Storage에 저장이 가능하다.

처리량 단위 크기 조정

Azure Event hubs 트래픽은 일반적으로 처리량 단위로 제어되며 수신에는 초당 1mb 속도이고 송신에는 그 두배를 허용한다. 이러한 처리는 1~20개 단위로 이루어지며 추가 구입이 가능하다.

Azure Event Hubs를 사용한 예제 시나리오

100,000명의 고객을 보유한 보안 회사에서 1분마다 100,000의 집에서 부착된 센서로 들어오는 데이터를 가져온다. 이 시나리오를 위해서는 여러 소비자의 생성과 동적으로 크기를 조정, 오류 복구의 기능이 필요하다.

이러한 요구사항을 충족하기 위해 Azure Event Hubs SDK를 사용할 수 있다. 해당 이벤트 프로세서 클라이언트 - EventProcessorClient는 아래와 같은 기능을 제공한다.

자동 부하 분산: 인스턴스 간 파티션 소유권과 작업을 자동 관리.
파티션 소유권 추적: 각 인스턴스는 고유 식별자로 파티션 소유권을 관리.
이벤트 및 오류 처리: 특정 파티션에서 전달된 이벤트를 처리하는 함수 정의.

또한 분리된 파티션의 소유권을 추적하여 각 고객의 코드를 조회할 수 있으며, 마지막으로 처리된 이벤트의 위치를 커밋하고 함수를 실행하는 검사점 설정을 제공하며 일반적으로 스레드 안정성을 자체적으로 가지고 있다.

요약

Event Grid의 작동 박식과 서비스 및 이벤트 처리기에 대해 배웠다.
Event Grid의 배달 방법 및 오류 처리 방법을 배웠다.
Event Hubs의 이점과 데이터 캡쳐 방법

Azure, Azure 204