서비스 검색 복원력(미리 보기)
Azure Container Apps 복원력을 사용하면 간단한 복원력 정책을 사용하여 서비스 요청 오류를 적극적으로 방지, 검색 및 복구할 수 있습니다. 이 문서에서는 Azure Container Apps 서비스 검색을 사용하여 요청을 시작할 때 Azure Container Apps 복원력 정책을 구성하는 방법을 알아봅니다.
참고 항목
현재는 Dapr Service Invocation API를 사용하여 이루어진 요청에는 복원력 정책을 적용할 수 없습니다.
컨테이너 앱에 대한 각 요청에 대해 정책이 적용됩니다. 다음과 같은 구성을 사용하여 요청을 수락하는 컨테이너 앱에 맞게 정책을 조정할 수 있습니다.
- 다시 시도 횟수
- 다시 시도 및 시간 제한 기간
- 다시 시도 일치
- 회로 차단기 연속 오류 및 기타
다음 애플리케이션이 재시도 정책을 사용하여 실패한 요청 복구를 시도하는 방법을 보여 주는 스크린샷.
지원되는 복원력 정책
복원력 정책 구성
Bicep, CLI 또는 Azure Portal을 사용하여 복원력 정책을 구성하든 컨테이너 앱당 하나의 정책만 적용할 수 있습니다.
컨테이너 앱에 정책을 적용하면 규칙은 해당 컨테이너 앱에서 이루어진 요청이 아닌 해당 컨테이너 앱에 대한 모든 요청에 적용됩니다. 예를 들어, 재시도 정책은 App B라는 컨테이너 앱에 적용됩니다. App B에 대한 모든 인바운드 요청은 실패 시 자동으로 다시 시도됩니다. 그러나 App B에서 보낸 아웃바운드 요청은 실패 시 다시 시도가 보장되지 않습니다.
다음 복원력 예에서는 사용 가능한 모든 구성을 보여 줍니다.
resource myPolicyDoc 'Microsoft.App/containerApps/resiliencyPolicies@2023-11-02-preview' = {
name: 'my-app-resiliency-policies'
parent: '${appName}'
properties: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
connectionTimeoutInSeconds: 5
}
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
matches: {
headers: [
{
header: 'x-ms-retriable'
match: {
exactMatch: 'true'
}
}
]
httpStatusCodes: [
502
503
]
errors: [
'retriable-status-codes'
'5xx'
'reset'
'connect-failure'
'retriable-4xx'
]
}
}
tcpRetryPolicy: {
maxConnectAttempts: 3
}
circuitBreakerPolicy: {
consecutiveErrors: 5
intervalInSeconds: 10
maxEjectionPercent: 50
}
tcpConnectionPool: {
maxConnections: 100
}
httpConnectionPool: {
http1MaxPendingRequests: 1024
http2MaxRequests: 1024
}
}
}
정책 사양
시간 제한
시간 제한은 장기 실행 작업을 조기에 종료하는 데 사용됩니다. 시간 제한 정책에는 다음 속성이 포함됩니다.
properties: {
timeoutPolicy: {
responseTimeoutInSeconds: 15
connectionTimeoutInSeconds: 5
}
}
| 메타데이터 | Required | 설명 | 예시 |
|---|---|---|---|
responseTimeoutInSeconds |
예 | 컨테이너 앱의 응답을 기다리는 동안 시간이 초과되었습니다. | 15 |
connectionTimeoutInSeconds |
예 | 컨테이너 앱에 대한 연결 설정 시간이 초과되었습니다. | 5 |
재시도
실패한 작업에 대한 tcpRetryPolicy 또는 httpRetryPolicy 전략을 정의합니다. 재시도 정책에는 다음 구성이 포함됩니다.
httpRetryPolicy
properties: {
httpRetryPolicy: {
maxRetries: 5
retryBackOff: {
initialDelayInMilliseconds: 1000
maxIntervalInMilliseconds: 10000
}
matches: {
headers: [
{
header: 'x-ms-retriable'
match: {
exactMatch: 'true'
}
}
]
httpStatusCodes: [
502
503
]
errors: [
'retriable-headers'
'retriable-status-codes'
]
}
}
}
| 메타데이터 | Required | 설명 | 예시 |
|---|---|---|---|
maxRetries |
예 | 실패한 http 요청에 대해 실행될 최대 다시 시도 횟수입니다. | 5 |
retryBackOff |
예 | 시간 제한 및 다시 시도 기준이 충족되면 요청을 모니터링하고 영향을 받는 서비스에 대한 모든 트래픽을 차단합니다. | 해당 없음 |
retryBackOff.initialDelayInMilliseconds |
예 | 첫 번째 오류와 첫 번째 다시 시도 사이1의 지연입니다. | 1000 |
retryBackOff.maxIntervalInMilliseconds |
예 | 다시 시도 사이의 최대 지연입니다. | 10000 |
matches |
예 | 앱이 다시 시도를 시도해야 하는 시기를 제한하려면 일치 값을 설정합니다. | |
matches.headers |
Y* | 오류 응답에 특정 헤더가 포함된 경우 다시 시도합니다. *헤더는 retriable-headers 오류 속성을 지정하는 경우에만 필수 속성입니다. 사용 가능한 헤더 일치에 대해 자세히 알아봅니다. |
X-Content-Type |
matches.httpStatusCodes |
Y* | 응답이 특정 상태 코드를 반환하면 다시 시도합니다. *상태 코드는 retriable-status-codes 오류 속성을 지정하는 경우에만 필수 속성입니다. |
502: 503 |
matches.errors |
예 | 앱이 특정 오류를 반환하는 경우에만 다시 시도합니다. 발생 가능한 오류에 대해 자세히 알아봅니다. | connect-failure: reset |
헤더 일치
retriable-headers 오류를 지정한 경우 다음 헤더 일치 속성을 사용하여 응답에 특정 헤더가 포함될 때 다시 시도할 수 있습니다.
matches: {
headers: [
{
header: 'x-ms-retriable'
match: {
exactMatch: 'true'
}
}
]
}
| 메타데이터 | 설명 |
|---|---|
prefixMatch |
헤더 값의 접두사를 기준으로 다시 시도가 수행됩니다. |
exactMatch |
헤더 값과 정확히 일치하는 항목을 기준으로 다시 시도가 수행됩니다. |
suffixMatch |
헤더 값의 접미사를 기준으로 다시 시도가 수행됩니다. |
regexMatch |
헤더 값이 정규식 패턴과 일치해야 하는 정규식 규칙에 따라 다시 시도가 수행됩니다. |
Errors
다음 오류에 대해 다시 시도를 수행할 수 있습니다.
matches: {
errors: [
'retriable-headers'
'retriable-status-codes'
'5xx'
'reset'
'connect-failure'
'retriable-4xx'
]
}
| 메타데이터 | 설명 |
|---|---|
retriable-headers |
다시 시도를 트리거하는 HTTP 응답 헤더입니다. 헤더 일치 항목 중 응답 헤더와 일치하는 항목이 있으면 다시 시도가 수행됩니다. 일치하는 헤더에 대해 다시 시도하려는 경우 필수입니다. |
retriable-status-codes |
다시 시도를 트리거해야 하는 HTTP 상태 코드입니다. 일치하는 상태 코드에 대해 다시 시도하려는 경우 필수입니다. |
5xx |
서버가 5xx 응답 코드로 응답하면 다시 시도합니다. |
reset |
서버가 응답하지 않으면 다시 시도합니다. |
connect-failure |
컨테이너 앱과의 연결 문제로 인해 요청이 실패한 경우 다시 시도합니다. |
retriable-4xx |
컨테이너 앱이 409와 같은 400 시리즈 응답 코드로 응답하면 다시 시도합니다. |
tcpRetryPolicy
properties: {
tcpRetryPolicy: {
maxConnectAttempts: 3
}
}
| 메타데이터 | Required | 설명 | 예시 |
|---|---|---|---|
maxConnectAttempts |
예 | 실패한 연결을 다시 시도하기 위한 최대 연결 시도 횟수(maxConnectionAttempts)를 설정합니다. |
3 |
회로 차단기
회로 차단기 정책은 연속 오류 수와 같은 트리거를 기반으로 부하 분산 풀에서 컨테이너 앱 복제본을 일시적으로 제거할지 여부를 지정합니다.
properties: {
circuitBreakerPolicy: {
consecutiveErrors: 5
intervalInSeconds: 10
maxEjectionPercent: 50
}
}
| 메타데이터 | Required | 설명 | 예시 |
|---|---|---|---|
consecutiveErrors |
예 | 컨테이너 앱 복제본이 부하 분산에서 일시적으로 제거되기 전의 연속 오류 수입니다. | 5 |
intervalInSeconds |
예 | 부하 분산 풀에서 복제본이 제거되거나 복원되는지 확인하는 데 지정된 시간입니다. | 10 |
maxEjectionPercent |
예 | 부하 분산에서 꺼낼 실패한 컨테이너 앱 복제본의 최대 비율입니다. 값에 관계없이 하나 이상의 호스트를 제거합니다. | 50 |
연결 풀
Azure Container Apps의 연결 풀링은 컨테이너 앱에 대해 설정되고 재사용 가능한 연결 풀을 유지 관리합니다. 이 연결 풀은 각 요청에 대한 개별 연결을 만들고 해제하는 오버헤드를 줄여줍니다.
연결 풀을 사용하면 서비스에 허용되는 최대 요청 수 또는 연결 수를 지정할 수 있습니다. 이러한 제한은 각 서비스의 총 동시 연결 수를 제어합니다. 이 제한에 도달하면 기존 연결이 해제되거나 닫힐 때까지 해당 서비스에 대한 새 연결이 설정되지 않습니다. 이러한 연결 관리 프로세스는 리소스가 요청으로 인해 과부하되는 것을 방지하고 효율적인 연결 관리를 유지합니다.
httpConnectionPool
properties: {
httpConnectionPool: {
http1MaxPendingRequests: 1024
http2MaxRequests: 1024
}
}
| 메타데이터 | Required | 설명 | 예시 |
|---|---|---|---|
http1MaxPendingRequests |
예 | http1 요청에 사용됩니다. 컨테이너 앱에 대해 열려 있는 최대 연결 수입니다. |
1024 |
http2MaxRequests |
예 | http2 요청에 사용됩니다. 컨테이너 앱에 대한 최대 동시 요청 수입니다. |
1024 |
tcpConnectionPool
properties: {
tcpConnectionPool: {
maxConnections: 100
}
}
| 메타데이터 | Required | 설명 | 예시 |
|---|---|---|---|
maxConnections |
예 | 컨테이너 앱에 대한 최대 동시 연결 수입니다. | 100 |
복원력 가시성
컨테이너 앱의 메트릭과 시스템 로그를 통해 복원력 관찰을 수행할 수 있습니다.
복원력 로그
컨테이너 앱의 모니터링 섹션에서 로그를 선택합니다.
로그 창에서 쿼리를 작성하고 실행하여 컨테이너 앱 시스템 로그를 통해 복원력을 찾습니다. 예를 들어, 다음과 유사한 쿼리를 실행하여 복원력 이벤트를 검색하고 해당 이벤트를 표시합니다.
- 타임스탬프
- 환경 이름
- 컨테이너 앱 이름
- 복원력 유형 및 이유
- 로그 메시지
ContainerAppSystemLogs_CL
| where EventSource_s == "Resiliency"
| project TimeStamp_s, EnvironmentName_s, ContainerAppName_s, Type_s, EventSource_s, Reason_s, Log_s
쿼리를 실행하고 결과를 보려면 실행을 클릭합니다.
복원력 메트릭
컨테이너 앱의 모니터링 메뉴에서 메트릭을 선택합니다. 메트릭 창에서 다음 필터를 선택합니다.
- 컨테이너 앱 이름의 범위입니다.
- 표준 메트릭 메트릭 네임스페이스입니다.
- 드롭다운 메뉴의 복원력 메트릭입니다.
- 결과에 데이터를 집계하는 방법(평균, 최대 등)입니다.
- 지속 시간(지난 30분, 지난 24시간 등).
예를 들어, 30분 내에 검색하도록 평균 집계를 사용하여 test-app 범위에서 복원력 요청 다시 시도 메트릭을 설정하면 결과는 다음과 같습니다.
관련 콘텐츠
Azure Container Apps의 Dapr 구성 요소에 대한 복원력이 어떻게 작동하는지 알아봅니다.