다음을 통해 공유

네임스페이스 항목을 사용한 메시지 푸시 배달 및 다시 시도

  • 아티클

Event Grid 네임스페이스 푸시 배달은 지속적인 배달을 제공합니다. Event Grid는 일치하는 각 구독에 대해 각 메시지를 한 번 이상 즉시 배달하려고 합니다. 구독자 엔드포인트에서 이벤트 수신을 승인하지 않거나 오류가 있는 경우 Event Grid는 고정된 재시도 일정 및 재시도 정책에 따라 전송을 다시 시도합니다. 기본적으로 Event Grid는 구독자에게 한 번에 하나의 이벤트를 전달합니다.

참고 항목

Event Grid는 이벤트 배달 순서를 보장하지 않으므로 구독자가 잘못된 순서로 메시지를 받을 수 있습니다.

이벤트 구독

이벤트 구독은 단일 네임스페이스 항목과 연결된 구성 리소스입니다. 무엇보다도 이벤트 구독을 사용해 이벤트 선택 조건을 설정하여 토픽에서 사용 가능한 총 이벤트 집합 중 구독자가 사용할 수 있는 이벤트 컬렉션을 정의합니다. 이벤트 구독을 사용하여 이벤트가 전송되는 대상 엔드포인트도 정의합니다. 또한 이벤트 구독을 사용하면 최대 배달 다시 시도 횟수, 이벤트 수명 등 이벤트 배달의 런타임 동작을 정의하는 기타 속성을 설정할 수 있습니다.

다시 시도 일정

Event Grid가 이벤트 배달 시도에 대한 오류를 받으면 Event Grid는 오류 형식에 따라 배달을 다시 시도해야 하는지 여부를 결정합니다.

구독된 엔드포인트에서 반환된 오류가 다시 시도로 해결할 수 없는 구성 관련 오류인 경우 Event Grid는 구성된 데드레터 대상으로 이벤트를 보냅니다. 데드레터가 구성되지 않은 경우 이벤트가 삭제됩니다. 예를 들어, 이벤트 구독에 구성된 엔드포인트가 삭제되어 도달할 수 없는 경우 이벤트는 데드레터되거나 삭제됩니다. 다음 조건 및 오류에는 전송 다시 시도가 발생하지 않습니다.

조건:

  • ArgumentException
  • TimeoutException
  • UnauthorizedAccessException
  • OperationCanceledException
  • SocketException |

오류 코드

  • 404 - NotFound
  • 401 - Unauthorized
  • 403 - Forbidden
  • 400 -BadRequest
  • 414 RequestUriTooLong

참고 항목

엔드포인트에 대해 데드레터가 구성되지 않은 경우 위의 오류나 조건이 발생하면 이벤트가 삭제됩니다. 이러한 종류의 이벤트를 삭제하지 않으려면 이벤트 구독에 데드레터를 구성하는 것이 좋습니다. 배달 못한 편지 대상을 찾을 수 없으면 배달 못한 편지 이벤트가 삭제됩니다.

구독된 엔드포인트에서 반환된 조건 또는 오류가 위 목록에 없는 경우 Event Grid는 다음 지수 백오프 다시 시도 일정을 사용하여 기본 활동 기반으로 다시 시도합니다.

  • 0초(즉시 다시 시도)
  • 10초
  • 30초
  • 1분
  • 5분

5분 후에 Event Grid는 이벤트가 배달되거나 최대 다시 시도 횟수 또는 이벤트 지속 시간에 도달할 때까지 5분마다 계속 다시 시도합니다.

다시 시도 정책

다음 두 가지 이벤트 구독 구성 속성을 사용하여 재시도 정책을 사용자 지정할 수 있습니다. 속성 중 하나가 구성된 제한에 도달하면 이벤트가 삭제되거나(데드레터가 구성되지 않음) 데드레터링됩니다.

  • 최대 배달 수 - 값은 1에서 10 사이의 정수여야 합니다. 기본값은 10입니다. 푸시 배달의 경우 이 속성은 최대 배달 시도를 정의합니다.
  • 보존 - 이 속성은 event time to live이라고도 합니다. 값은 분 단위의 ISO 8601 기간 값이어야 합니다. 이벤트가 게시된 시간부터 시작하여 이 속성은 메시지가 만료되는 기간을 정의합니다. 허용되는 최솟값은 "PT1M"(1분)입니다. 허용되는 최댓값은 7일 또는 기본 항목의 보존 시간 중 더 낮은 값입니다. Azure Portal은 일, 시간, 분을 정수로 지정하는 간단한 사용자 환경을 제공합니다.

참고 항목

Retention 및 Maximum delivery count를 모두 설정하면 Event Grid는 이를 사용하여 이벤트 배달을 중지할 시기를 결정합니다. 둘 중 하나는 이벤트 배달을 중지합니다. 예를 들어, 보존 시간을 20분으로 설정하고 최대 배달 시도 횟수를 10번으로 설정한 경우 이벤트가 20분 후에 배달되지 않거나 10번의 시도 후에도 배달되지 않으면 이벤트는 데드레터링됩니다. 그러나 다시 시도 일정으로 인해 최대 전송 시도 횟수를 10으로 설정해도 이벤트는 20분 후에 먼저 데드레터링되므로 아무런 영향을 미치지 않습니다. 이는 20분에 배달 시도 #8(0, 10s, 30s, 1m, 5m, 10m, 15m, 20m)이 발생하지만 해당 시간에 이벤트가 데드레터링되었기 때문입니다.

출력 일괄 처리

대상 엔드포인트 형식으로 웹후크를 사용하는 경우 Event Grid는 기본적으로 각 이벤트를 구독자에게 개별적으로 전송합니다. 처리량이 높은 시나리오에서 향상된 HTTP 성능으로 배달하기 위해 이벤트를 일괄 처리하도록 Event Grid를 구성할 수 있습니다. Batch는 기본적으로 해제되어 있으며 이벤트 구독별로 설정할 수 있습니다.

Event Hubs를 대상 엔드포인트 형식으로 사용하는 경우 Event Grid는 효율성과 성능을 극대화하기 위해 항상 이벤트를 일괄 처리합니다. 기본적으로 Event Grid는 Azure Event Hubs에 배달할 때 일괄 처리 동작을 처리하므로 사용 가능한 일괄 처리 정책 구성이 없습니다.

일괄 처리 정책

일괄 배달에는 두 가지 설정이 있습니다.

  • 일괄 처리당 최대 이벤트 수 - Event Grid에서 일괄 처리당 배달할 최대 이벤트 수입니다. 값은 1~5,000 사이의 정수여야 합니다. 이 숫자는 절대 초과되지 않습니다. 그러나 배달 시 더 이상 이벤트를 사용할 수 없는 경우 더 적은 수의 이벤트가 배달될 수 있습니다. 사용할 수 있는 이벤트 수가 더 적으면 Event Grid가 이벤트를 지연시켜 일괄 처리를 만들 수 없습니다.
  • 기본 일괄 처리 크기(KB) - 일괄 처리 크기의 목표 상한(KB)입니다. 값은 1~1024 사이의 숫자여야 합니다. 최대 이벤트와 유사하게, 배달 시 충분한 이벤트를 사용할 수 없는 경우 일괄 처리 크기가 더 작을 수 있습니다. 단일 이벤트가 기본 크기보다 큰 경우, 일괄 처리가 기본 일괄 처리 크기보다 클 수 있습니다. 예를 들어, 기본 크기가 4Kb이고 10Kb 이벤트가 Event Grid로 푸시되는 경우 10Kb 이벤트는 삭제되지 않고 배달됩니다.

포털, CLI, PowerShell 또는 SDK를 통해 이벤트 구독별로 구성된 일괄 배달

일괄 처리 동작

  • 모두 성공 또는 실패

    Event Grid는 모두 성공 또는 실패 의미 체계로 작동합니다. 일괄 처리 전송에서는 일부 성공이 지원되지 않습니다. 구독자는 합리적으로 30초 이내에 처리할 수 있는 만큼의 일괄 처리당 이벤트만 요청하도록 주의해야 합니다.

  • 최적 일괄 처리

    일괄 처리 정책 설정은 일괄 처리 동작을 엄격하게 제한하지 않으며 가장 효율적인 방식으로 적용됩니다. 이벤트율이 낮은 경우 일괄 처리 크기가 일괄 처리당 요청된 최대 이벤트 수보다 작은 경우가 많습니다.

  • 기본적으로 해제로 설정

    기본적으로 Event Grid는 전송 요청마다 이벤트를 하나만 추가합니다. Batch를 활성화하는 방법은 Batch 정책에 언급된 설정 중 하나를 설정하는 것입니다.

  • 기본값

    이벤트 구독을 만들 때 설정(일괄 처리당 최대 이벤트 수 및 대략적인 일괄 처리 크기(킬로바이트))을 둘 다 지정할 필요는 없습니다. 하나의 설정만 설정된 경우 Event Grid는 기본값을 사용합니다. 기본값과 기본값을 재정의하는 방법은 다음 섹션을 참조하세요.

Azure Portal

이러한 설정은 이벤트 구독 페이지의 추가 기능 탭에서 확인하거나 이벤트 구독이 만들어진 후 이벤트 구독에 액세스할 때 구성 메뉴 옵션에서 확인할 수 있습니다.

일괄 처리 섹션이 강조 표시된 이벤트 구독 페이지의 추가 기능 탭을 보여 주는 스크린샷.

배달 못한 편지 이벤트

Event Grid는 특정 기간 내에 이벤트를 배달할 수 없거나 특정 횟수만큼 이벤트 배달을 시도한 후에 이벤트를 스토리지 계정으로 보냅니다. 이 프로세스를 배달 못한 편지 처리라고 합니다. Event Grid는 다음 조건 중 하나가 충족되면 이벤트를 배달 못한 편지로 처리합니다.

  • 이벤트가 수명(이벤트 구독에 정의된 보존) 기간 내에 배달되지 않습니다.
  • 이벤트 전달 시도 횟수가 한도를 초과한 경우

둘 중 하나라도 충족되면 이벤트가 삭제되거나 데드레터링됩니다. 기본적으로 Event Grid에서는 배달 못한 편지를 켜지 않습니다. 이 기능을 사용하려면 이벤트 구독을 만들 때 전송되지 않은 이벤트를 보유할 스토리지 계정을 지정해야 합니다. 배달을 해결하려면 이 스토리지 계정에서 이벤트를 읽습니다.

Event Grid가 모든 재시도 시도 횟수를 시도한 경우 이벤트를 배달 못한 편지로 보냅니다. Event Grid가 400(잘못된 요청) 또는 413(요청 엔터티가 너무 큼) 응답 코드를 수신하는 경우, 즉시 이벤트의 배달 못한 편지 처리를 예약합니다. 이 응답 코드는 이벤트 전달이 실패하지 않음을 나타냅니다.

TTL(Time to Live) 만료는 다음에 예약된 배달 시도 시에만 확인됩니다. 따라서 다음에 예약된 배달 시도 전에 TTL(Time to Live)이 만료되는 경우에도 다음 배달 시점에만 이벤트 만료가 확인된 후 나중에 배달 못한 편지로 처리됩니다.

이벤트를 배달하기 위한 마지막 시도 및 배달 못한 편지 위치로 이벤트를 배달하는 경우, 그 사이에 5분의 지연이 발생합니다. 이 지연은 Blob Storage 작업 수를 줄이기 위함입니다. 배달 못한 편지 위치를 4시간 동안 사용할 수 없는 경우 이벤트가 삭제됩니다.

배달 못한 편지 위치를 설정하기 전에 컨테이너를 포함하는 스토리지 계정이 있어야 합니다. 이벤트 구독을 만들 때 이 컨테이너에 대한 엔드포인트를 제공합니다. 엔드포인트는 다음과 같은 형식입니다. /subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>

이벤트가 배달 못한 편지 위치로 전송된 경우 알림을 받을 수 있습니다. Event Grid를 사용하여 전송되지 않은 이벤트에 응답하려면 배달 못한 편지 Blob Storage에 대한 이벤트 구독을 만듭니다. 배달 못한 편지 Blob Storage가 전송되지 않은 이벤트를 수신할 때마다 Event Grid에서 처리기에 알립니다. 처리기는 전송되지 않은 이벤트를 조정하기 위해 수행할 작업으로 응답합니다.

데드레터링을 구성할 때 데드레터된 이벤트를 보관할 Azure Storage 계정의 적절한 RBAC(역할 기반 액세스 제어) 역할에 관리 ID를 추가해야 합니다. 자세한 내용은 지원되는 대상 및 Azure 역할을 참조하세요.

배달 이벤트 형식

이 섹션에서는 네임스페이스 항목에서 지원되는 메시지 메타데이터 서식인 CloudEvents 1.0 스키마를 사용하는 이벤트 및 데드레터된 이벤트의 예를 제공합니다.

CloudEvents 1.0 스키마

이벤트

{
    "id": "caee971c-3ca0-4254-8f99-1395b394588e",
    "source": "mysource",
    "dataversion": "1.0",
    "subject": "mySubject",
    "type": "fooEventType",
    "datacontenttype": "application/json",
    "data": {
        "prop1": "value1",
        "prop2": 5
    }
}

배달 못한 편지 이벤트

[
  {
    "deadLetterProperties": {
      "deadletterreason": "Maximum delivery attempts was exceeded.",
      "deliveryattempts": 1,
      "deliveryresult": "Event was not acknowledged nor rejected.",
      "publishutc": "2023-11-01T20:33:51.4521467Z",
      "deliveryattemptutc": "2023-11-01T20:33:52.3692079Z"
    },
    "event": {
      "comexampleextension1": "value1",
      "id": "A234-1234-1234",
      "comexampleothervalue": "5",
      "datacontenttype": "text/xml",
      "specversion": "1.0",
      "time": "2018-04-05T17:31:00Z",
      "source": "/mycontext",
      "type": "com.example.someevent",
      "data": <your-event-data>
    }
  }
]

LastDeliveryOutcome: 테스트

대상에 대한 이벤트 배달이 실패하기 시작하면 일정 기간 동안 Event Grid에 의해 이벤트 구독이 시험 기간에 들어갑니다. 테스트 시간은 대상 엔드포인트에서 반환된 다른 오류에 따라 다릅니다. 이벤트 구독이 테스트 중이면 이벤트가 테스트 중인 오류 코드에 따라 배달을 시도하지 않고도 배달 못하거나 삭제될 수 있습니다.

오류 테스트 기간
약속 있음 10초
NotFound 5분
SocketError 30초
ResolutionError 5분
사용 안 함 5분
전체 5분
시간 초과 10초
Unauthorized 5분
금지 5분
InvalidAzureFunctionDestination 10분

참고 항목

Event Grid는 더 나은 배달 관리를 위해 테스트 기간을 사용하며 향후 기간이 변경될 수 있습니다.

메시지 배달 상태

Event Grid는 HTTP 응답 코드를 사용하여 이벤트의 수신을 승인합니다.

성공 코드

Event Grid는 다음 HTTP 응답 코드만 성공한 배달로 간주합니다. 다른 모든 상태 코드는 실패한 배달로 간주되며 적절하게 다시 시도하거나 배달 못한 편지로 처리됩니다. Event Grid가 성공적인 상태 코드를 수신하면 배달이 완료된 것으로 간주합니다.

  • 200 OK
  • 201 생성됨
  • 202 수락됨
  • 203 신뢰할 수 없는 정보
  • 204 콘텐츠 없음

실패 코드

위의 집합(200-204)에 없는 다른 모든 코드는 오류로 간주되며 필요한 경우 다시 시도됩니다. 일부에는 아래에 설명된 특정 다시 시도 정책이 연결되어 있고 다른 모든 정책은 표준 다시 시도 일정을 따릅니다. Event Grid 아키텍처의 고도로 병렬화된 특성으로 인해 재시도 동작이 비결정적이라는 사실을 유념해야 합니다.

상태 코드 다시 시도 동작
400 잘못된 요청 다시 시도 안 함
401 권한 없음 Azure 리소스 엔드포인트에 대해 5분 이상 후 다시 시도
403 금지 다시 시도 안 함
404 찾을 수 없음 Azure 리소스 엔드포인트에 대해 5분 이상 후 다시 시도
408 요청 시간 초과 2분 이상 후 다시 시도
413 요청 엔터티가 너무 큼 다시 시도 안 함
503 서비스를 사용할 수 없음 30초 이상 후 다시 시도
나머지 10초 이상 후 다시 시도

사용자 지정 전달 속성

이벤트 구독을 사용하면 배달된 이벤트에 포함 되는 HTTP 헤더를 설정할 수 있습니다. 이 기능을 사용하여 대상에 필요한 사용자 지정 헤더를 설정할 수 있습니다. 이벤트 구독을 만들 때 최대 10개의 헤더를 설정할 수 있습니다. 각 헤더 값은 4,096(4K)바이트 이하여야 합니다. 다음 대상에 배달되는 이벤트에 사용자 지정 헤더를 설정할 수 있습니다.

  • Webhook
  • Azure Event Hubs

다음 단계