Dapr 구성 요소 복원력(미리 보기)
복원력 정책은 컨테이너 앱 오류를 적극적으로 방지, 검색 및 복구합니다. 이 문서에서는 상태 저장소, 게시/구독 메시지 브로커, 비밀 저장소 등과 같은 다양한 클라우드 서비스와 통합하기 위해 Dapr을 사용하는 애플리케이션에 대한 복원력 정책을 적용하는 방법을 알아봅니다.
Dapr 구성 요소를 통해 다음 아웃바운드 및 인바운드 작업 방향에 대해 다시 시도, 시간 제한 및 회로 차단기와 같은 복원력 정책을 구성할 수 있습니다.
- 아웃바운드 작업: Dapr 사이드카에서 다음과 같은 구성 요소를 호출합니다.
- 상태 유지 또는 검색
- 메시지 게시
- 출력 바인딩 호출
- 인바운드 작업: 다음과 같이 Dapr 사이드카에서 컨테이너 앱으로의 호출입니다.
- 메시지 배달 시 구독
- 이벤트를 배달하는 입력 바인딩
다음 애플리케이션이 재시도 정책을 사용하여 실패한 요청 복구를 시도하는 방법을 보여 주는 스크린샷.
지원되는 복원력 정책
복원력 정책 구성
Bicep, CLI 또는 Azure Portal을 사용하여 복원력 정책을 만들지 여부를 선택할 수 있습니다.
다음 복원력 예에서는 사용 가능한 모든 구성을 보여 줍니다.
resource myPolicyDoc 'Microsoft.App/managedEnvironments/daprComponents/resiliencyPolicies@2023-11-02-preview' = {
name: 'my-component-resiliency-policies'
parent: '${componentName}'
properties: {
outboundPolicy: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
inboundPolicy: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
}
}
Important
모든 복원력 정책을 적용한 후에는 Dapr 애플리케이션을 다시 시작해야 합니다.
정책 사양
시간 제한
시간 제한은 장기 실행 작업을 조기에 종료하는 데 사용됩니다. 시간 제한 정책에는 다음 속성이 포함됩니다.
properties: {
outbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
inbound: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
}
}
}
| 메타데이터 | Required | 설명 | 예시 |
|---|---|---|---|
responseTimeoutInSeconds |
예 | Dapr 구성 요소의 응답을 기다리는 동안 시간이 초과되었습니다. | 15 |
재시도
실패한 작업에 대한 httpRetryPolicy 전략을 정의합니다. 재시도 정책에는 다음 구성이 포함됩니다.
properties: {
outbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
inbound: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
}
}
}
| 메타데이터 | Required | 설명 | 예시 |
|---|---|---|---|
maxRetries |
예 | 실패한 http 요청에 대해 실행될 최대 다시 시도 횟수입니다. | 5 |
retryBackOff |
예 | 시간 제한 및 다시 시도 기준이 충족되면 요청을 모니터링하고 영향을 받는 서비스에 대한 모든 트래픽을 차단합니다. | 해당 없음 |
retryBackOff.initialDelayInMilliseconds |
예 | 첫 번째 오류와 첫 번째 다시 시도 사이1의 지연입니다. | 1000 |
retryBackOff.maxIntervalInMilliseconds |
예 | 다시 시도 사이의 최대 지연입니다. | 10000 |
회로 차단기
특정 기준이 충족되면 실패율을 높이는 요청을 모니터링하고 영향을 받는 서비스에 대한 모든 트래픽을 차단하려면 circuitBreakerPolicy를 정의합니다.
properties: {
outbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
},
inbound: {
circuitBreakerPolicy: {
intervalInSeconds: 15
consecutiveErrors: 10
timeoutInSeconds: 5
}
}
}
| 메타데이터 | Required | 설명 | 예시 |
|---|---|---|---|
intervalInSeconds |
아니요 | 회로 차단기가 내부 카운트를 지우는 데 사용하는 주기적인 시간(초)입니다. 제공되지 않으면 간격은 timeoutInSeconds에 대해 제공된 것과 동일한 값으로 설정됩니다. |
15 |
consecutiveErrors |
예 | 회로가 트립하고 열리기 전에 발생할 수 있는 요청 오류 수입니다. | 10 |
timeoutInSeconds |
예 | 실패 직후의 열린 상태의 시간 간격(초)입니다. | 5 |
회로 차단기 프로세스
consecutiveErrors를 지정하면(회로 트립 조건을 consecutiveFailures > $(consecutiveErrors)-1로 지정) 회로가 트립되고 반쯤 열리기 전에 허용되는 오류 수가 설정됩니다.
회로는 timeoutInSeconds초 동안 반 열린 상태로 대기하며, 이 시간 동안 요청의 consecutiveErrors 수가 연속적으로 성공해야 합니다.
- 요청이 성공하면 회로가 닫힙니다.
- 요청이 실패하면 회로는 반 열린 상태를 유지합니다.
intervalInSeconds 값을 설정하지 않으면 연속적인 요청 성공 또는 실패와 관계없이 timeoutInSeconds에 대해 설정한 시간이 지나면 회로가 닫힌 상태로 다시 설정됩니다. intervalInSeconds를 0으로 설정하면 회로는 자동으로 다시 설정되지 않으며, 연속한 요청의 consecutiveErrors 수를 성공적으로 완료해야만 반 열린 상태에서 닫힌 상태로 전환됩니다.
intervalInSeconds 값을 설정하면, 반 열린 상태에서 전송된 요청이 성공했는지 여부에 관계없이 회로가 닫힌 상태로 다시 설정되기 전의 시간이 결정됩니다.
복원력 로그
컨테이너 앱의 모니터링 섹션에서 로그를 선택합니다.
로그 창에서 쿼리를 작성하고 실행하여 컨테이너 앱 시스템 로그를 통해 복원력을 찾습니다. 예를 들어, 복원력 정책이 로드되었는지 확인하려면 다음을 수행합니다.
ContainerAppConsoleLogs_CL
| where ContainerName_s == "daprd"
| where Log_s contains "Loading Resiliency configuration:"
| project time_t, Category, ContainerAppName_s, Log_s
| order by time_t desc
실행을 클릭하여 쿼리를 실행하고 정책이 로드 중임을 나타내는 로그 메시지와 함께 결과를 확인합니다.
또는 컨테이너 앱에서 디버그 로그를 사용하도록 설정하고 쿼리하여 복원력 리소스가 로드되었는지 확인하여 실제 복원력 정책을 찾을 수 있습니다.
디버그 로그를 사용하도록 설정하면 다음과 유사한 쿼리를 사용합니다.
ContainerAppConsoleLogs_CL
| where ContainerName_s == "daprd"
| where Log_s contains "Resiliency configuration ("
| project time_t, Category, ContainerAppName_s, Log_s
| order by time_t desc
실행을 클릭하여 쿼리를 실행하고 정책 구성이 포함된 결과 로그 메시지를 확인합니다.
관련 콘텐츠
서비스 검색에 기본 제공된 Azure Container Apps를 사용한 서비스 간 통신에서 복원력이 어떻게 작동하는지 알아봅니다.