일시적인 오류 처리에 대한 권장 사항
이 Power Platform Well-Architected Reliability 체크리스트 권장 사항에 적용:
| 제목:05 | 오류 처리 및 일시적인 오류 처리를 구현하여 워크로드의 복원력을 강화하세요. 구성 요소 오류 및 일시적인 오류를 처리할 수 있는 기능을 솔루션에 구축합니다. |
|---|
이 안내서에서는 클라우드 애플리케이션의 일시적 장애를 처리하기 위한 권장 사항을 설명합니다. 원격 서비스 및 리소스와 통신하는 모든 애플리케이션은 일시적인 오류에 민감해야 합니다. 이는 환경의 특성과 인터넷 연결로 인해 이러한 유형의 오류가 더 자주 발생할 가능성이 있는 클라우드에서 실행되는 애플리케이션의 경우 특히 그렇습니다. 일시적인 오류에는 구성 요소 및 서비스에 대한 일시적인 네트워크 연결 끊김, 서비스의 일시적인 사용 불가능, 서비스 사용량이 많을 때 발생하는 시간 초과 등이 포함됩니다. 이러한 결함은 자체 수정되는 경우가 많으므로 적절한 지연 후에 작업을 반복하면 성공할 가능성이 높습니다.
주요 디자인 전략
일시적인 오류는 모든 환경, 플랫폼, 운영 체제, 모든 종류의 애플리케이션에서 발생할 수 있습니다.
당면 과제
일시적인 오류는 예측 가능한 모든 상황에서 철저한 테스트를 거쳤더라도 애플리케이션의 가용성 인지에 큰 영향을 미칠 수 있습니다. Power Platform 워크로드가 안정적으로 작동할 수 있도록 하려면 워크로드가 다음 문제에 대응할 수 있는지 확인해야 합니다.
애플리케이션은 오류가 발생할 때 오류를 감지하고 오류가 일시적인지, 오래 지속되는지, 최종 오류인지 판단할 수 있어야 합니다. 오류가 발생하면 다양한 리소스가 서로 다른 응답을 반환할 가능성이 높으며 이러한 응답은 작업 상황에 따라 달라질 수도 있습니다. 예를 들어 애플리케이션이 사용자 정의 커넥터에서 데이터를 검색할 때 오류에 대한 응답은 애플리케이션이 클라우드 흐름을 실행하고 응답을 기다리고 있을 때의 응답과 다를 수 있습니다.
애플리케이션은 오류가 일시적일 가능성이 있다고 판단하는 경우 작업을 다시 시도할 수 있어야 합니다.
애플리케이션은 재시도에 적절한 전략을 사용해야 합니다. 전략은 애플리케이션이 재시도해야 하는 횟수, 각 시도 사이의 지연, 시도 실패 후 수행할 작업을 지정합니다. 적절한 시도 횟수와 각 시도 사이의 지연 시간을 결정하기 어려운 경우가 많습니다. 전략은 리소스 유형과 리소스 및 애플리케이션의 현재 운영 조건에 따라 달라집니다.
일반 가이드라인
다음 지침은 애플리케이션에 적합한 일시적 오류 처리 메커니즘을 설계하는 데 도움이 될 수 있습니다.
내장된 재시도 메커니즘이 있는지 확인
연결 중인 일부 서비스는 이미 일시적인 오류 처리 메커니즘을 제공할 수 있습니다. 사용되는 재시도 정책은 일반적으로 대상 서비스의 특성과 요구 사항에 맞게 조정됩니다. 또는 서비스용 REST 인터페이스는 재시도가 적절한지 여부와 다음 재시도 전까지 기다려야 하는 시간을 결정하는 데 도움이 되는 정보를 반환할 수 있습니다.
다른 재시도 동작을 더 적절하게 만드는 구체적이고 잘 이해된 요구 사항이 없는 한, 사용 가능한 경우 기본 제공 재시도 메커니즘을 사용해야 합니다.
작업이 재시도에 적합한지 확인
오류가 일시적인 경우(일반적으로 오류의 특성으로 표시됨)와 재시도 시 작업이 성공할 가능성이 어느 정도 있는 경우에만 재시도 작업을 수행하세요. 존재하지 않거나 사용자에게 권한이 없는 Microsoft Dataverse의 행을 업데이트하거나 존재하지 않는 API 엔드포인트를 호출하는 등 잘못된 작업을 시도하는 작업을 다시 시도하는 것은 의미가 없습니다.
전체 효과를 확인할 수 있고 조건을 잘 이해하고 검증할 수 있는 경우에만 재시도를 구현하세요. 제어할 수 없는 리소스 및 서비스에서 반환된 오류는 시간이 지남에 따라 발전할 수 있으며 일시적인 오류 감지 논리를 다시 검토해야 할 수도 있습니다.
애플리케이션에서 호출되는 개별 구성 요소나 서비스를 개발할 때 클라이언트가 실패한 작업을 재시도해야 하는지 여부를 결정하는 데 도움이 되는 오류 코드와 메시지를 반환해야 합니다. 클라이언트가 작업을 다시 시도해야 하는지 여부를 나타내는 것을 고려하세요. 예를 들어 isTransient 값을 반환합니다. 웹 서비스를 구축하는 경우 서비스 계약 내에 정의된 사용자 지정 오류 반환을 고려하세요.
적절한 재시도 횟수 및 간격 결정
사용 사례 유형에 따라 재시도 횟수와 간격을 최적화합니다. 충분한 횟수를 재시도하지 않으면 애플리케이션이 작업을 완료할 수 없으며 아마도 실패할 것입니다. 너무 많이 재시도하거나 시도 간 간격이 너무 짧은 경우 애플리케이션이 장기간 리소스를 보유할 수 있으며 이는 애플리케이션 상태에 부정적인 영향을 미칩니다.
작업 유형에 따라 시간 간격 및 재시도 횟수에 대한 값을 조정합니다. 예를 들어 작업이 사용자 상호 작용의 일부인 경우 간격은 짧아야 하며 몇 번의 재시도만 시도해야 합니다. 이 접근 방식을 사용하면 사용자가 응답을 기다리게 만드는 것을 방지할 수 있습니다. 작업이 장기 실행 또는 중요한 워크플로의 일부이고 프로세스를 취소하고 다시 시작하는 데 비용이 많이 들거나 시간이 많이 걸리는 경우 시도 사이에 더 오랜 시간을 기다려 더 많은 시간을 재시도하는 것이 적절합니다.
재시도 간의 적절한 간격을 결정하는 것은 성공적인 전략을 설계하는 데 가장 어려운 부분이라는 점을 명심하세요. 일반적인 전략에서는 다음 유형의 재시도 간격을 사용합니다.
지수 구간. 애플리케이션은 첫 번째 재시도 전에 짧은 시간을 기다린 후 각 후속 재시도 사이의 시간을 기하급수적으로 늘립니다. 예를 들어 3초, 12초, 30초 후에 작업을 다시 시도할 수 있습니다.
고정된 간격. 애플리케이션은 각 시도 사이에 동일한 시간 동안 대기합니다.
즉시 다시 시도하세요. 일시적인 오류가 일시적인 경우도 있고, 애플리케이션이 다음 요청을 보내는 데 걸리는 시간 내에 오류가 해결되면 작업이 성공할 수 있으므로 작업을 즉시 재시도하는 것이 적절합니다. 그러나 즉각적인 재시도는 두 번 이상 이루어져서는 안 됩니다. 즉각적인 재시도가 실패할 경우 지수 간격이나 대체 작업과 같은 대체 전략으로 전환해야 합니다.
일반적인 지침으로 백그라운드 작업에는 지수 간격 전략을 사용하고 대화형 작업에는 즉시 또는 고정 간격 재시도 전략을 사용합니다. 두 경우 모두 모든 재시도에 대한 최대 대기 시간이 필요한 종단 간 대기 시간 요구 사항 내에 있도록 지연 및 재시도 횟수를 선택해야 합니다.
재시도된 작업의 전체 최대 시간 초과에 기여하는 모든 요소의 조합을 고려하세요. 이러한 요소에는 실패한 연결이 응답을 생성하는 데 걸리는 시간, 재시도 간 지연 시간, 최대 재시도 횟수 등이 포함됩니다. 이러한 모든 시간의 합계로 인해 전체 작업 시간이 길어질 수 있으며, 특히 각 실패 후 재시도 간격이 빠르게 커지는 지수 지연 전략을 사용하는 경우 더욱 그렇습니다. 프로세스가 특정 SLA(서비스 수준 계약)를 충족해야 하는 경우 모든 시간 초과 및 지연을 포함한 전체 작업 시간은 SLA에 정의된 제한 내에 있어야 합니다.
지나치게 공격적인 재시도 전략을 구현하지 마세요. 이는 간격이 너무 짧거나 재시도가 너무 빈번한 전략입니다. 대상 리소스나 서비스에 부정적인 영향을 미칠 수 있습니다. 이러한 전략은 리소스나 서비스가 오버로드된 상태에서 복구되는 것을 방지할 수 있으며 계속해서 요청을 차단하거나 거부하게 됩니다. 이 시나리오는 점점 더 많은 요청이 리소스나 서비스로 전송되는 악순환을 초래합니다. 결과적으로 회복 능력이 더욱 감소됩니다.
후속 시도가 즉시 시작되지 않도록 재시도 간격을 선택할 때 작업의 시간 초과를 고려하세요(예: 시간 초과 기간이 재시도 간격과 유사한 경우).
오류 유형이나 서비스에서 반환된 오류 코드 및 메시지를 사용하여 재시도 횟수와 재시도 간격을 최적화하세요. 예를 들어, 일부 예외 또는 오류 코드(예: HTTP 코드 503, Service Unavailable, 응답에 Retry-After 헤더가 있는 경우)는 오류가 얼마나 오래 지속될 수 있는지 또는 서비스가 실패하여 후속 시도에 응답하지 않음을 나타낼 수 있습니다.
안티 패턴 피하기
대부분의 경우 재시도 코드의 중복 레이어를 포함하는 구현을 피하세요. 특정 요구 사항이 없는 한 계단식 재시도 메커니즘을 포함하거나 요청 계층 구조와 관련된 작업의 모든 단계에서 재시도를 구현하는 디자인은 피하세요. 이러한 예외적인 상황에서는 과도한 재시도 횟수와 지연 기간을 방지하는 정책을 사용하고 결과를 이해해야 합니다. 예를 들어, 한 구성 요소가 다른 구성 요소에 요청한 다음 대상 서비스에 액세스한다고 가정해 보겠습니다. 두 호출 모두에서 3회 재시도를 구현하면 서비스에 대해 총 9번의 재시도가 발생합니다. 많은 서비스와 리소스는 기본 제공 재시도 메커니즘을 구현합니다. 더 높은 수준에서 재시도를 구현해야 하는 경우 이러한 메커니즘을 비활성화하거나 수정할 수 있는 방법을 조사해야 합니다.
끝없는 재시도 메커니즘을 구현하지 마세요. 그렇게 하면 리소스나 서비스가 과부하 상황에서 복구되지 못하고 제한 및 거부된 연결이 더 오랜 시간 동안 계속될 수 있습니다.
즉시 재시도를 두 번 이상 수행하지 마세요.
Azure에서 서비스 및 리소스에 액세스할 때, 특히 재시도 횟수가 많은 경우 고정된 재시도 간격을 사용하지 마세요. 이 시나리오에서 가장 좋은 접근 방식은 지수 간격 전략입니다.
재시도 전략 및 구현 테스트
가능한 한 다양한 상황에서 재시도 전략을 완전히 테스트하세요. 특히 응용 프로그램과 응용 프로그램에서 사용하는 대상 리소스 또는 서비스가 모두 극도의 부하를 받는 경우에는 더욱 그렇습니다. 테스트 중에 동작을 확인하려면 다음을 수행할 수 있습니다.
일시적인 오류와 일시적이지 않은 오류를 서비스에 삽입합니다. 예를 들어 잘못된 요청을 보내거나 테스트 요청을 감지하고 다양한 유형의 오류로 응답하는 코드를 추가하세요.
실제 서비스가 반환할 수 있는 다양한 오류를 반환하는 리소스 또는 서비스의 모형을 만듭니다. 재시도 전략이 감지하도록 설계된 모든 유형의 오류를 포괄합니다.
생성하고 배포하는 사용자 지정 서비스의 경우 서비스를 일시적으로 비활성화하거나 오버로드하여 일시적인 오류가 발생하도록 합니다. (Azure에서 공유 리소스나 공유 서비스를 오버로드하려고 시도하지 마세요.)
일시적인 오류에 대한 클라이언트 웹 애플리케이션의 복원력을 테스트할 때 브라우저의 개발자 도구 또는 테스트 프레임워크의 모의 또는 차단 네트워크 요청 기능을 사용하세요.
높은 로드율과 동시 테스트를 수행하여 이러한 조건에서 재시도 메커니즘과 전략이 올바르게 작동하는지 확인하세요. 또한 이러한 테스트는 재시도가 클라이언트 작업에 부정적인 영향을 미치거나 요청 간 교차 오염을 유발하지 않는지 확인하는 데도 도움이 됩니다.
재시도 정책 구성 관리
재시도 정책은 재시도 전략의 모든 요소를 조합한 것입니다. 이는 오류가 일시적인지 여부, 사용할 간격 유형(예: 고정 또는 지수), 실제 간격 값 및 재시도 횟수를 결정하는 감지 메커니즘을 정의합니다.
기본 제공 또는 기본 재시도 전략을 활용하되 시나리오에 적합한 경우에만 사용하세요. 이러한 전략은 일반적으로 일반적입니다. 일부 시나리오에서는 이것이 필요한 전부일 수 있지만 다른 시나리오에서는 특정 요구 사항에 맞는 전체 옵션을 제공하지 않습니다. 가장 적절한 값을 결정하려면 테스트를 수행하여 설정이 애플리케이션에 어떤 영향을 미치는지 이해해야 합니다.
일시적 및 비일시적 오류를 기록하고 추적합니다
재시도 전략의 일부로 예외 처리 및 재시도 시도를 기록하는 기타 계측을 포함합니다. 가끔 일시적인 실패 및 재시도가 예상되지만 문제를 나타내지는 않습니다. 그러나 정기적이고 증가하는 재시도 횟수는 오류를 유발하거나 애플리케이션 성능 및 가용성을 저하시킬 수 있는 문제를 나타내는 경우가 많습니다.
일시적인 오류를 오류 항목이 아닌 경고 항목으로 기록하여 모니터링 시스템이 오류를 잘못된 경고를 트리거할 수 있는 애플리케이션 오류로 감지하지 않도록 합니다.
재시도가 서비스의 조절로 인해 발생했는지 또는 연결 실패와 같은 다른 유형의 오류로 인해 발생했는지 나타내는 값을 로그 항목에 저장하여 데이터 분석 중에 이를 구별할 수 있도록 하는 것이 좋습니다. 제한 오류 수가 증가하는 것은 애플리케이션의 설계 결함이나 환경에 프리미엄 용량을 추가해야 한다는 의미인 경우가 많습니다.
실패 횟수와 비율, 평균 재시도 횟수 또는 작업이 성공하기까지의 전체 경과 시간이 증가할 때 경고를 발생시킬 수 있는 원격 측정 및 모니터링 시스템을 구현하는 것이 좋습니다.
지속적으로 실패하는 작업 관리
시도할 때마다 계속해서 실패하는 작업을 처리하는 방법을 고려하세요. 이와 같은 상황은 불가피합니다.
재시도 전략은 작업을 재시도해야 하는 최대 횟수를 정의하지만 애플리케이션이 동일한 재시도 횟수로 작업을 반복하는 것을 막지는 않습니다. 예를 들어 애플리케이션에서 양식을 제출하면 흐름이 트리거될 수 있습니다. 재시도 전략은 연결 시간 초과를 감지하고 이를 일시적인 오류로 간주할 수 있습니다. 흐름은 지정된 횟수만큼 작업을 재시도한 다음 포기합니다. 그러나 동일하거나 새로운 사용자가 양식을 다시 제출하려고 하면 계속 실패하더라도 작업이 다시 시도됩니다.
애플리케이션은 요청 사이에 긴 간격으로 간헐적으로 서비스를 테스트하여 서비스가 사용 가능한 시기를 감지할 수 있습니다. 적절한 간격은 작업의 중요성 및 서비스의 성격과 같은 요소에 따라 달라집니다. 몇 분에서 몇 시간이 걸릴 수도 있습니다. 테스트가 성공하면 애플리케이션은 정상적인 작업을 재개하고 새로 복구된 서비스에 요청을 전달할 수 있습니다.
그동안 서비스가 곧 제공될 것이라는 희망에 따라 몇 가지 대체 작업을 수행할 수 있습니다. 예를 들어 서비스에 대한 요청을 대기열이나 데이터 저장소에 저장하고 나중에 다시 시도하는 것이 적절할 수 있습니다. 또는 애플리케이션을 사용할 수 없음을 나타내기 위해 사용자에게 메시지를 반환해야 할 수도 있습니다.
기타 고려 사항
재시도 횟수 및 정책의 재시도 간격 값을 결정할 때 서비스 또는 리소스에 대한 작업이 장기 실행 작업인지 아니면 다단계 작업인지 여부를 고려하세요. 하나의 실패 시 이미 성공한 다른 모든 운영 단계를 보상하는 것은 어렵거나 비용이 많이 들 수 있습니다. 이 경우 해당 전략이 부족한 리소스를 보유하거나 잠가서 다른 작업을 차단하지 않는 한 긴 간격과 많은 수의 재시도가 허용될 수 있습니다.
동일한 작업을 다시 시도하면 데이터 불일치가 발생할 수 있는지 고려하세요. 다단계 프로세스의 일부가 반복되고 작업이 멱등성이 아닌 경우 불일치가 발생할 수 있습니다. 예를 들어 Microsoft Dataverse에 레코드를 삽입하는 작업이 반복되면 테이블에 잘못된 값이 발생할 수 있습니다. 또는 사용자에게 알림을 보내는 작업을 반복하면 중복된 메시지를 받을 수도 있습니다.
재시도되는 작업의 범위를 고려하세요. 예를 들어 여러 작업을 포함하는 수준에서 재시도 코드를 구현하고 하나가 실패하면 모두 재시도하는 것이 더 쉬울 수 있습니다. 그러나 그렇게 하면 멱등성 문제나 불필요한 롤백 작업이 발생할 수 있습니다.
여러 작업을 포함하는 재시도 범위를 선택하는 경우 재시도 간격을 결정할 때, 작업 경과 시간을 모니터링할 때, 실패에 대한 경고를 발생시키기 전에 모든 작업의 총 대기 시간을 고려하세요.
Power Platform 간편 사용
다음 섹션에서는 일시적 장애를 관리하는 데 사용할 수 있는 메커니즘에 대해 설명합니다.
Power Automate
Power Automate에는 작업이 실패할 경우 작업을 다시 시도하는 기능이 포함되어 있습니다. 이를 작업별 수준으로 구성합니다. Power Automate 프로젝트에서 위험을 줄이고 오류 처리를 계획하는 방법에 대해 알아보세요. Power Automate는 또한 호출 앱이나 흐름에 사용자 지정 오류와 데이터를 반환하는 작업도 제공합니다.
일부 일시적 흐름은 처리량 및 요청 제한으로 인해 발생할 수 있습니다. 자동화된 흐름, 예약된 흐름 및 즉각적인 흐름의 제한에 대해 알아보고 제한 및 할당을 요청합니다.
범위와 실행 후 설정을 사용하여 클라우드 흐름에서 오류 및 예외 처리를 구성합니다.
Power Apps
Power Apps 캔버스 앱은 연결 상태를 확인하는 기능을 제공하므로 앱이 오프라인일 때 다르게 동작할 수 있습니다. 오프라인에서도 사용 가능한 캔버스 앱을 개발하는 방법을 알아보세요.
캔버스 앱에서 Error, IfError, IsError, IsBlankOrError functions 함수를 사용하여 오류가 발생할 경우 다음에 수행할 작업을 결정할 수도 있습니다.
Power Apps에서 일시적인 오류 처리에 대해 자세히 알아보세요.
Azure 및 사용자 지정 커넥터
워크로드가 Azure 서비스에 연결되는 경우 Azure Well-Architected 프레임워크를 사용하여 일시적인 오류를 처리하는 방법을 알아보세요.
오류에 대한 맞춤 커넥터 응답을 관리하려면 코딩 표준을 따르세요.
Application Insights
Application Insights 통합을 사용하여 Power Automate 및 Power Apps의 오류를 기록합니다.
관련 정보
Dynamics 365 SaaS 앱을 위한 비즈니스 연속성 및 재해 복구
안정성 체크리스트
전체 권장 사항 세트를 참조하세요.