Azure Functions 오류 처리 및 다시 시도

  • 아티클

Azure Functions의 오류를 처리하는 작업은 손실된 데이터, 누락된 이벤트를 방지하고 애플리케이션의 상태를 모니터링하는 데 중요합니다. 또한 이벤트 기반 트리거의 다시 시도 동작을 이해하는 것도 중요합니다.

이 문서에서는 오류 처리에 대한 일반적인 전략과 사용 가능한 다시 시도 전략에 대해 설명합니다.

Important

이 기능을 일반 공급(GA)하면 타이머, Kafka 및 Event Hubs 이외의 트리거에 대한 런타임의 다시 시도 정책 지원이 제거됩니다. 타이머 및 Event Hubs 이외의 모든 트리거에 대한 미리 보기 다시 시도 정책 지원은 2022년 12월에 제거됩니다. 자세한 내용은 다시 시도 섹션을 참조하세요.

오류 처리

Azure 함수에서 발생하는 오류는 다음 중 하나에서 발생할 수 있습니다.

  • Azure Functions 트리거 및 바인딩 사용
  • 기본 Azure 서비스의 API에 대한 호출
  • REST 엔드포인트에 대한 호출
  • 클라이언트 라이브러리, 패키지 또는 타사 API에 대한 호출

데이터 손실이나 누락된 메시지를 방지하려면 좋은 오류 처리를 연습하는 것이 중요합니다. 이 섹션에서는 몇 가지 권장되는 오류 처리 사례에 대해 설명하고 자세한 정보에 대한 링크를 제공합니다.

Application Insights 사용

Azure Functions는 Application Insights와 통합하여 오류 데이터, 성능 데이터 및 런타임 로그를 수집합니다. Application Insights를 사용하여 함수 실행에서 발생하는 오류를 검색하고 더 잘 이해해야 합니다. 자세히 알아보려면 Azure Functions 모니터링을 참조하세요.

구조적 오류 처리 사용

오류 캡처 및 로깅은 애플리케이션의 상태를 모니터링하는 데 매우 중요합니다. 함수 코드의 최상위 수준에는 Try/Catch 블록이 포함되어야 합니다. Catch 블록에서 오류를 캡처 및 기록할 수 있습니다. 바인딩으로 인해 발생할 수 있는 오류에 대한 자세한 내용은 바인딩 오류 코드를 참조하세요.

다시 시도 전략 계획

여러 Functions 바인딩 확장은 다시 시도에 대한 기본 제공 지원을 제공합니다. 또한 런타임을 통해 타이머, Kafka 및 Event Hubs 트리거 함수에 대한 다시 시도 정책을 정의할 수 있습니다. 자세한 내용은 다시 시도를 참조하세요. 다시 시도 동작을 제공하지 않는 트리거의 경우 사용자 고유의 다시 시도 체계를 구현할 수 있습니다.

멱등원을 위한 디자인

데이터를 처리할 때 오류가 발생하는 것은 특히 메시지를 처리할 때 함수에 대한 문제일 수 있습니다. 오류가 발생할 때 수행되는 작업과 중복 처리를 방지하는 방법을 고려해야 합니다. 자세한 내용은 동일한 입력에 대한 Azure Functions 디자인을 참조하세요.

재시도

함수에 사용할 수 있는 두 가지 유형의 다시 시도가 있습니다.

  • 개별 트리거 확장의 기본 제공 다시 시도 동작
  • 함수 런타임에서 제공하는 다시 시도 정책

다음 표에서는 다시 시도를 지원하는 트리거와 다시 시도 동작이 구성되는 위치를 나타냅니다. 또한 기본 서비스에서 발생하는 오류에 대한 자세한 정보로도 연결됩니다.

트리거/바인딩 다시 시도 원본 구성
Azure Cosmos DB 다시 시도 정책 함수 수준
Azure Blob Storage 바인딩 확장 host.json
Azure Event Grid 바인딩 확장 이벤트 구독
Azure Event Hubs 다시 시도 정책 함수 수준
Azure Queue Storage 바인딩 확장 host.json
RabbitMQ 바인딩 확장 배달 못한 편지 큐
Azure Service Bus 바인딩 확장 배달 못한 편지 큐
타이머 다시 시도 정책 함수 수준
Kafka 다시 시도 정책 함수 수준

재시도 정책

Azure Functions 런타임 버전 3.x부터 Functions 런타임에서 적용되는 타이머, Kafka, Event Hubs 및 Azure Cosmos DB 트리거에 대한 다시 시도 정책을 정의할 수 있습니다.

다시 시도 정책은 성공적인 완료가 발생하거나 최대 다시 시도 횟수에 도달할 때까지 실패한 실행을 다시 실행하도록 런타임에 지시합니다.

타이머, Kafka 또는 Event Hubs 또는 Azure Cosmos DB 트리거 함수에서 catch되지 않은 예외가 발생하면 다시 시도 정책이 평가됩니다. 코드에서 모든 예외를 catch하고 다시 시도하도록 하려는 오류를 모두 다시 throw하는 것이 가장 좋습니다.

Important

실행에 대한 다시 시도 정책을 완료할 때까지 Event Hubs 검사점이 작성되지 않습니다. 이 동작으로 인해 현재 일괄 처리를 완료할 때까지 특정 파티션의 진행이 일시 중지됩니다.

Event Hubs v5 확장은 Functions 호스트와 이벤트 허브 간의 상호 작용에 대한 추가 다시 시도 기능을 지원합니다. 자세한 내용은 host.json의 Event Hubs 섹션 파일의 clientRetryOptions를 참조하세요.

재시도 전략

정책에서 지원하는 두 가지 다시 시도 전략을 구성할 수 있습니다.

지정된 시간이 각 다시 시도 간에 경과할 수 있습니다.

최대 다시 시도 횟수

최종 실패 전에 함수 실행이 다시 시도되는 최대 횟수를 구성할 수 있습니다. 현재 재시도 횟수는 인스턴스의 메모리에 저장됩니다.

인스턴스는 다시 시도 사이에 오류가 있을 수 있습니다. 재시도 정책 중에 인스턴스가 실패하면 재시도 횟수가 손실됩니다. 인스턴스 오류가 발생하면 Event Hubs 트리거에서 처리를 다시 시작하고 다시 시도 횟수를 0으로 다시 설정하여 새 인스턴스에서 일괄 처리를 다시 시도할 수 있습니다. 타이머 트리거는 새 인스턴스에서 다시 시작되지 않습니다.

이 동작은 최대 재시도 횟수가 최선의 노력임을 의미합니다. 경우에 따라 실행이 요청된 최대 횟수보다 더 많이 다시 시도될 수 있습니다. 타이머 트리거의 경우 다시 시도 횟수는 요청된 최대 횟수보다 작을 수 있습니다.

다시 시도 예제

함수 수준 재시도는 다음 NuGet 패키지에서 지원됩니다.

[Function(nameof(TimerFunction))]
[FixedDelayRetry(5, "00:00:10")]
public static void Run([TimerTrigger("0 */5 * * * *")] TimerInfo timerInfo,
    FunctionContext context)
{
    var logger = context.GetLogger(nameof(TimerFunction));
    logger.LogInformation($"Function Ran. Next timer schedule = {timerInfo.ScheduleStatus.Next}");
}
속성 설명
MaxRetryCount 필수입니다. 함수 실행당 허용되는 최대 재시도 횟수입니다. -1은 무기한으로 재시도하는 것을 의미합니다.
DelayInterval 다시 시도 간에 사용되는 지연입니다. HH:mm:ss 형식을 사용하여 문자열로 지정합니다.

function.json 파일의 재시도 정책은 다음과 같습니다.

{
    "disabled": false,
    "bindings": [
        {
            ....
        }
    ],
    "retry": {
        "strategy": "fixedDelay",
        "maxRetryCount": 4,
        "delayInterval": "00:00:10"
    }
}
function.json 속성 설명
전략 필수입니다. 사용하는 재시도 전략입니다. 유효한 값은 fixedDelay 또는 exponentialBackoff입니다.
maxRetryCount 필수입니다. 함수 실행당 허용되는 최대 재시도 횟수입니다. -1은 무기한으로 재시도하는 것을 의미합니다.
delayInterval fixedDelay 전략을 사용하는 경우 다시 시도하는 사이에 사용되는 지연 시간입니다. HH:mm:ss 형식을 사용하여 문자열로 지정합니다.
minimumInterval exponentialBackoff 전략을 사용하는 경우 최소한의 다시 시도 지연 시간입니다. HH:mm:ss 형식을 사용하여 문자열로 지정합니다.
maximumInterval exponentialBackoff 전략을 사용하는 경우 최대 재시도 지연 시간입니다. HH:mm:ss 형식을 사용하여 문자열로 지정합니다.

함수에서 다시 시도 컨텍스트를 사용하는 Python 샘플은 다음과 같습니다.

import azure.functions
import logging


def main(mytimer: azure.functions.TimerRequest, context: azure.functions.Context) -> None:
    logging.info(f'Current retry count: {context.retry_context.retry_count}')

    if context.retry_context.retry_count == context.retry_context.max_retry_count:
        logging.warn(
            f"Max retries of {context.retry_context.max_retry_count} for "
            f"function {context.function_name} has been reached")


@FunctionName("TimerTriggerJava1")
@FixedDelayRetry(maxRetryCount = 4, delayInterval = "00:00:10")
public void run(
    @TimerTrigger(name = "timerInfo", schedule = "0 */5 * * * *") String timerInfo,
    final ExecutionContext context
) {
    context.getLogger().info("Java Timer trigger function executed at: " + LocalDateTime.now());
}

바인딩 오류 코드

Azure 서비스와 통합할 경우 기본 서비스의 API에서 오류가 발생할 수 있습니다. 바인딩 관련 오류에 대한 정보는 다음 문서의 “예외 및 반환 코드” 섹션에서 사용할 수 있습니다.

다음 단계