일시적인 오류 처리에 대한 권장 사항

이 Azure Well-Architected Framework 안정성 검사 목록 권장 사항에 적용됩니다.

RE:07	자체 보존 및 자가 복구 조치를 구현하여 워크로드의 복원력과 복구 가능성을 강화합니다. 인프라 기반 안정성 패턴 및 소프트웨어 기반 디자인 패턴을 사용하여 구성 요소 오류 및 일시적인 오류를 처리하여 솔루션에 기능을 빌드합니다. 시스템에 기능을 빌드하여 솔루션 구성 요소 오류를 감지하고 워크로드가 전체 또는 감소된 기능에서 계속 작동하는 동안 자동으로 수정 작업을 시작합니다.

관련 가이드:백그라운드 작업 | 자체 보존

이 가이드에서는 클라우드 애플리케이션에서 일시적인 오류를 처리하기 위한 권장 사항을 설명합니다. 원격 서비스 및 리소스와 통신하는 모든 애플리케이션은 일시적인 오류에 민감해야 합니다. 이는 환경의 특성과 인터넷을 통해 연결하기 때문에 이러한 유형의 오류가 더 자주 발생할 가능성이 있는 클라우드에서 실행되는 애플리케이션의 경우 특히 그렇습니다. 일시적인 오류에는 구성 요소 및 서비스에 대한 네트워크 연결의 일시적인 손실, 서비스의 일시적인 사용 불가, 서비스가 사용 중일 때 발생하는 시간 제한이 포함됩니다. 이러한 오류는 종종 자체 수정되므로 적절한 지연 후에 작업이 반복되면 성공할 가능성이 높습니다.

이 문서에서는 일시적인 오류 처리에 대한 일반적인 지침을 제공합니다. 일시적인 오류 처리에 대한 자세한 내용은 재시도 패턴을 참조하고, Azure 서비스를 사용하는 경우 Azure 서비스에 대한 재시도 지침을 참조하세요.

주요 디자인 전략

일시적인 오류는 환경, 플랫폼 또는 운영 체제 및 애플리케이션의 종류에 관계없이 발생할 수 있습니다. 로컬 온-프레미스 인프라에서 실행되는 솔루션의 경우 애플리케이션 및 해당 구성 요소의 성능 및 가용성은 일반적으로 비용이 많이 들고 자주 사용되지 않는 하드웨어 중복성을 통해 유지 관리되며 구성 요소와 리소스는 서로 가까이 있습니다. 이 방법을 사용하면 오류 가능성이 낮아지지만 외부 전원 공급 장치 또는 네트워크 문제와 같은 예기치 않은 이벤트 또는 재해 시나리오로 인한 중단이 발생할 수 있으므로 일시적인 오류가 계속 발생할 수 있습니다.

프라이빗 클라우드 시스템을 비롯한 클라우드 호스팅에서는 많은 상용 컴퓨팅 노드 간에 공유 리소스, 중복성, 자동 장애 조치(failover) 및 동적 리소스 할당을 사용하여 전체적인 가용성을 향상시킬 수 있습니다. 그러나 클라우드 환경의 특성으로 인해 일시적인 오류가 발생할 가능성이 더 높습니다. 이는 다음과 같은 여러 가지 원인 때문일 수 있습니다.

• 클라우드 환경의 많은 리소스가 공유되며 이러한 리소스에 대한 액세스는 리소스를 보호하기 위해 제한될 수 있습니다. 일부 서비스는 부하가 특정 수준으로 상승하거나 최대 처리량 속도에 도달할 때 기존 요청 처리를 허용하고 모든 사용자에 대한 서비스의 성능을 유지하기 위해 연결을 거부합니다. 제한은 공유 리소스를 사용하는 이웃 및 기타 테넌트의 서비스 품질을 유지하는 데 도움이 됩니다.

• 클라우드 환경에서는 많은 수의 상용 하드웨어 단위를 사용합니다. 여러 컴퓨팅 단위 및 인프라 구성 요소에 부하를 동적으로 분산하여 성능을 제공합니다. 실패한 단위를 자동으로 재활용하거나 교체하여 안정성을 제공합니다. 이러한 동적 특성으로 인해 일시적인 오류 및 임시 연결 오류가 가끔 발생할 수 있습니다.

• 종종 라우터 및 부하 분산 장치와 같은 네트워크 인프라를 포함하여 애플리케이션과 애플리케이션이 사용하는 리소스 및 서비스 간에 더 많은 하드웨어 구성 요소가 있습니다. 이러한 추가 인프라로 인해 가끔 추가 연결 대기 시간 및 일시적인 연결 오류가 발생할 수 있습니다.

• 클라이언트와 서버 간의 네트워크 조건은 특히 통신이 인터넷을 교차하는 경우 가변적일 수 있습니다. 온-프레미스 위치에서도 트래픽 부하가 많으면 통신 속도가 느려지고 간헐적인 연결 오류가 발생할 수 있습니다.

과제

일시적인 오류는 예측 가능한 모든 상황에서 철저히 테스트된 경우에도 애플리케이션의 인식된 가용성에 상당한 영향을 미칠 수 있습니다. 클라우드 호스팅 애플리케이션이 안정적으로 작동하도록 하려면 다음과 같은 문제에 대응할 수 있는지 확인해야 합니다.

• 애플리케이션은 오류가 발생할 때 오류를 감지하고 오류가 일시적일 가능성이 있는지, 오래 지속되는지 또는 터미널 오류인지 확인할 수 있어야 합니다. 오류가 발생할 때 리소스마다 다른 응답을 반환할 수 있으며 이러한 응답은 작업의 컨텍스트에 따라 달라질 수도 있습니다. 예를 들어 애플리케이션이 스토리지에서 읽을 때 오류에 대한 응답은 스토리지에 쓸 때 오류에 대한 응답과 다를 수 있습니다. 많은 리소스 및 서비스에는 잘 문서화된 일시적인 오류 계약이 있습니다. 그러나 이러한 정보를 사용할 수 없는 경우 오류의 특성과 일시적일 가능성이 있는지 여부를 검색하기 어려울 수 있습니다.

• 애플리케이션에서 오류가 일시적일 가능성이 있다고 판단되는 경우 작업을 다시 시도할 수 있어야 합니다. 또한 작업이 다시 시도되는 횟수를 추적해야 합니다.

• 애플리케이션은 재시도에 적절한 전략을 사용해야 합니다. 이 전략은 애플리케이션이 다시 시도해야 하는 횟수, 각 시도 사이의 지연 및 실패한 시도 후 수행할 작업을 지정합니다. 적절한 시도 횟수와 각 시도 간의 지연은 종종 결정하기 어렵습니다. 전략은 리소스 유형과 리소스 및 애플리케이션의 현재 운영 조건에 따라 달라집니다.

일반 지침

다음 지침은 애플리케이션에 적합한 일시적인 오류 처리 메커니즘을 설계하는 데 도움이 될 수 있습니다.

기본 제공 재시도 메커니즘이 있는지 확인

• 대부분의 서비스는 일시적인 오류 처리 메커니즘을 포함하는 SDK 또는 클라이언트 라이브러리를 제공합니다. 일반적으로 사용되는 재시도 정책은 대상 서비스의 특성 및 요구 사항에 맞게 조정됩니다. 또는 서비스에 대한 REST 인터페이스는 재시도가 적절한지 여부와 다음 재시도 전에 대기할 시간을 결정하는 데 도움이 되는 정보를 반환할 수 있습니다.

• 다른 재시도 동작을 보다 적절하게 만드는 구체적이고 잘 이해된 요구 사항이 없는 경우 기본 제공 재시도 메커니즘을 사용해야 합니다.

작업이 재시도에 적합한지 확인

• 오류가 일시적이고(일반적으로 오류의 특성으로 표시됨) 재시도 시 작업이 성공할 가능성이 있는 경우에만 재시도 작업을 수행합니다. 존재하지 않는 항목에 대한 데이터베이스 업데이트 또는 치명적인 오류가 발생한 서비스 또는 리소스에 대한 요청과 같이 잘못된 작업을 시도하는 작업을 다시 시도할 필요는 없습니다.

• 일반적으로 이러한 작업을 수행하는 전체 효과를 확인할 수 있고 조건이 잘 이해되고 유효성을 검사할 수 있는 경우에만 재시도를 구현합니다. 그렇지 않으면 호출 코드가 재시도를 구현하도록 합니다. 제어 외부의 리소스 및 서비스에서 반환된 오류는 시간이 지남에 따라 진화할 수 있으며 일시적인 오류 검색 논리를 다시 확인해야 할 수 있습니다.

• 서비스 또는 구성 요소를 만들 때 클라이언트가 실패한 작업을 다시 시도해야 하는지 여부를 결정하는 데 도움이 되는 오류 코드 및 메시지를 구현하는 것이 좋습니다. 특히 클라이언트가 isTransient 값을 반환하여 작업을 다시 시도해야 하는지 여부를 나타내고 다음 재시도 전에 적절한 지연을 제안합니다. 웹 서비스를 빌드하는 경우 서비스 계약 내에 정의된 사용자 지정 오류를 반환하는 것이 좋습니다. 일반 클라이언트가 이러한 오류를 읽지 못할 수도 있지만 사용자 지정 클라이언트를 만드는 데 유용합니다.

적절한 재시도 횟수 및 간격 확인

• 재시도 횟수 및 사용 사례 유형에 대한 간격을 최적화합니다. 충분한 시간을 다시 시도하지 않으면 애플리케이션이 작업을 완료할 수 없으며 실패할 수 있습니다. 너무 많이 다시 시도하거나 시도 간격이 너무 짧은 경우 애플리케이션은 스레드, 연결 및 메모리와 같은 리소스를 장기간 보유하여 애플리케이션의 상태에 부정적인 영향을 줄 수 있습니다.

• 작업 유형에 대한 시간 간격 및 재시도 횟수에 대한 값을 조정합니다. 예를 들어 작업이 사용자 상호 작용의 일부인 경우 간격은 짧아야 하며 몇 번의 다시 시도만 시도해야 합니다. 이 방법을 사용하면 사용자가 열린 연결을 유지하고 다른 사용자의 가용성을 줄일 수 있는 응답을 기다리지 않도록 할 수 있습니다. 작업이 장기 실행 또는 중요한 워크플로의 일부인 경우 프로세스를 취소하고 다시 시작하는 데 비용이 많이 들거나 시간이 오래 걸리는 경우 시도 사이에 더 오래 기다렸다가 더 많은 시간을 다시 시도하는 것이 적절합니다.

• 재시도 사이의 적절한 간격을 결정하는 것은 성공적인 전략을 설계하는 데 가장 어려운 부분입니다. 일반적인 전략에서는 다음과 같은 유형의 다시 시도 간격을 사용합니다.

  • 지수적 백오프. 애플리케이션은 첫 번째 재시도 전에 짧은 시간을 기다린 다음 각 후속 재시도 사이의 시간을 기하급수적으로 증가합니다. 예를 들어 3초, 12초, 30초 등 후에 작업을 다시 시도할 수 있습니다.

  • 증분 간격. 애플리케이션은 첫 번째 재시도 전에 짧은 시간을 기다린 다음 각 후속 재시도 사이의 시간을 증분 방식으로 늘입니다. 예를 들어 3초, 7초, 13초 등이 지나면 작업을 다시 시도할 수 있습니다.

  • 정기적 간격. 애플리케이션이 각 시도 사이에 동일한 기간 동안 대기합니다. 예를 들어 3초마다 작업을 다시 시도할 수 있습니다.

  • 즉시 재시도. 네트워크 패킷 충돌 또는 하드웨어 구성 요소의 급증과 같은 이벤트로 인해 일시적인 오류가 발생하는 경우가 있습니다. 이 경우 애플리케이션이 다음 요청을 어셈블하고 보내는 데 걸리는 시간에 오류가 지워지면 작업이 성공할 수 있으므로 작업을 즉시 다시 시도하는 것이 적절합니다. 그러나 두 번 이상의 즉각적인 재시도는 없어야 합니다. 즉각적인 재시도에 실패하는 경우 지수 백오프 또는 대체 작업과 같은 대체 전략으로 전환해야 합니다.

  • 불규칙. 이전에 나열된 재시도 전략에는 클라이언트의 여러 인스턴스가 후속 재시도를 동시에 보내는 것을 방지하기 위한 임의화가 포함될 수 있습니다. 예를 들어 한 instance 3초, 11초, 28초 등 후에 작업을 다시 시도할 수 있고, 다른 instance 4초, 12초, 26초 후에 작업을 다시 시도할 수 있습니다. 임의화는 다른 전략과 결합할 수 있는 유용한 기술입니다.

• 일반적인 지침으로 백그라운드 작업에 지수 백오프 전략을 사용하고 대화형 작업에 즉시 또는 정기적인 간격 재시도 전략을 사용합니다. 두 경우 모두, 모든 재시도 횟수의 최대 대기 시간이 필요한 엔드투엔드 대기 시간 요구 사항 내에 포함되도록 지연 시간 및 재시도 횟수를 선택해야 합니다.

• 재시도 작업의 전체 최대 시간 제한에 기여하는 모든 요인의 조합을 고려합니다. 이러한 요인에는 실패한 연결이 응답을 생성하는 데 걸리는 시간(일반적으로 클라이언트의 시간 제한 값으로 설정), 재시도 사이의 지연 및 최대 재시도 횟수가 포함됩니다. 이러한 모든 시간의 합계는 전체 작업 시간이 길어질 수 있으며, 특히 각 실패 후 재시도 사이의 간격이 빠르게 증가하는 지수 지연 전략을 사용하는 경우 더욱 그렇습니다. 프로세스가 특정 SLA(서비스 수준 계약)를 충족해야 하는 경우 모든 시간 제한 및 지연을 포함한 전체 작업 시간은 SLA에 정의된 한도 내에 있어야 합니다.

• 지나치게 공격적인 재시도 전략을 구현하지 마세요. 너무 짧거나 너무 자주 다시 시도되는 간격이 있는 전략입니다. 대상 리소스 또는 서비스에 부정적인 영향을 미칠 수 있습니다. 이러한 전략은 리소스 또는 서비스가 오버로드된 상태에서 복구되지 않도록 방지할 수 있으며 요청을 계속 차단하거나 거부합니다. 이 시나리오는 리소스 또는 서비스에 점점 더 많은 요청이 전송되는 악순환을 초래합니다. 따라서 복구 기능이 더 줄어듭니다.

• 후속 시도를 즉시 시작하지 않도록 하기 위해 재시도 간격을 선택할 때 작업의 시간 제한을 고려합니다(예: 시간 제한 기간이 재시도 간격과 유사한 경우). 또한 가능한 총 기간(시간 제한 및 재시도 간격)을 특정 총 시간 이하로 유지해야 하는지 여부를 고려합니다. 작업에 비정상적으로 짧거나 긴 시간 제한이 있는 경우 시간 제한은 대기 시간 및 작업을 다시 시도하는 빈도에 영향을 줄 수 있습니다.

• 예외 유형과 예외에 포함된 모든 데이터 또는 서비스에서 반환된 오류 코드 및 메시지를 사용하여 재시도 횟수와 간격을 최적화합니다. 예를 들어 일부 예외 또는 오류 코드(예: HTTP 코드 503, 서비스를 사용할 수 없음, 응답에 Retry-After 헤더 포함)는 오류가 얼마나 오래 지속될지 또는 서비스가 실패했으며 후속 시도에 응답하지 않음을 나타낼 수 있습니다.

• 배달 못한 편지 큐 접근 방식을 사용하여 모든 재시도 시도가 모두 소진된 후 들어오는 호출의 모든 정보가 손실되지 않도록 하는 것이 좋습니다.

안티패턴 방지

• 대부분의 경우 중복된 재시도 코드 계층을 포함하는 구현을 피합니다. 필요한 특정 요구 사항이 없는 한 연속 재시도 메커니즘을 포함하거나 요청 계층 구조를 포함하는 작업의 모든 단계에서 재시도를 구현하는 디자인을 사용하지 마세요. 이러한 예외적인 경우 과도하게 많은 재시도 및 지연 기간을 방지하는 정책을 사용하고 결과를 이해하고 있어야 합니다. 예를 들어 한 구성 요소가 다른 구성 요소에 요청을 한 다음 대상 서비스에 액세스한다고 가정해 봅시다. 두 호출에서 모두 3개의 횟수로 재시도를 구현하는 경우 서비스에 대해 총 9번의 재시도 시도가 있습니다. 많은 서비스 및 리소스는 기본 제공 재시도 메커니즘을 구현합니다. 더 높은 수준에서 재시도를 구현해야 하는 경우 이러한 메커니즘을 사용하지 않도록 설정하거나 수정하는 방법을 조사해야 합니다.

• 무한 재시도 메커니즘을 구현하지 않습니다. 이렇게 하면 리소스 또는 서비스가 오버로드 상황에서 복구되는 것을 방지하고 제한 및 거부된 연결이 더 오랜 시간 동안 계속되도록 할 수 있습니다. 한정된 수의 재시도를 사용하거나 회로 차단기 같은 패턴을 구현하여 서비스가 복구되도록 합니다.

• 즉시 재시도를 두 번 이상 수행하지 않습니다.

• 특히 재시도 횟수가 많은 경우 Azure에서 서비스 및 리소스에 액세스할 때 정기적으로 다시 시도 간격을 사용하지 마세요. 이 시나리오에서 가장 좋은 방법은 회로 차단 기능이 있는 지수 백오프 전략입니다.

• 동일한 클라이언트의 여러 인스턴스 또는 다른 클라이언트의 여러 인스턴스가 동시에 재시도를 보내지 못하도록 방지합니다. 이 시나리오가 발생할 가능성이 있는 경우 재시도 간격에 임의화를 도입합니다.

재시도 전략 및 구현 테스트

• 특히 애플리케이션과 애플리케이션에서 사용하는 대상 리소스 또는 서비스가 모두 매우 많은 부하를 받고 있는 경우 가능한 한 광범위한 상황에서 재시도 전략을 완전히 테스트합니다. 테스트 중 동작을 확인하려면 다음을 수행할 수 있습니다.

  • 서비스에 일시적 오류 및 영구 오류를 주입합니다. 예를 들어 잘못된 요청을 보내거나 테스트 요청을 감지하고 다양한 유형의 오류로 응답하는 코드를 추가합니다.

  • 실제 서비스에서 반환할 수 있는 다양한 오류를 반환하는 리소스 또는 서비스의 모형을 만듭니다. 재시도 전략이 감지하도록 설계된 모든 유형의 오류를 다룹니다.

  • 만들고 배포하는 사용자 지정 서비스의 경우 서비스를 일시적으로 사용하지 않도록 설정하거나 오버로드하여 일시적인 오류가 발생하도록 합니다. (Azure에서 공유 리소스 또는 공유 서비스를 오버로드하지 마세요.)

  • 네트워크 트래픽을 가로채고 수정하는 라이브러리 또는 솔루션을 사용하여 자동화된 테스트에서 불리한 시나리오를 복제합니다. 예를 들어 테스트는 왕복 시간을 더 추가하거나, 패킷을 삭제하거나, 헤더를 수정하거나, 요청 본문 자체를 변경할 수 있습니다. 이렇게 하면 일시적인 오류 및 기타 유형의 오류에 대해 오류 조건의 하위 집합을 결정적으로 테스트할 수 있습니다.

  • 일시적인 오류에 대한 클라이언트 웹 애플리케이션의 복원력을 테스트할 때 브라우저의 개발자 도구 또는 테스트 프레임워크의 기능을 사용하여 네트워크 요청을 모 의하거나 차단 합니다.

  • 높은 부하 계수 및 동시 테스트를 수행하여 이러한 조건에서 재시도 메커니즘 및 전략이 올바르게 작동하는지 확인합니다. 또한 이러한 테스트는 재시도가 클라이언트 작업에 부정적인 영향을 미치지 않거나 요청 간에 교차 오염을 일으키지 않도록 하는 데 도움이 됩니다.

재시도 정책 구성 관리

• 재시도 정책은 재시도 전략의 모든 요소의 조합입니다. 오류가 일시적일 가능성이 있는지 여부, 사용할 간격 유형(예: 일반, 지수 백오프 및 임의화), 실제 간격 값 및 재시도 횟수를 결정하는 검색 메커니즘을 정의합니다.

• 가장 간단한 애플리케이션과 더 복잡한 애플리케이션의 모든 계층에서 여러 위치에서 재시도를 구현합니다. 여러 위치에서 각 정책의 요소를 하드 코딩하는 대신 중앙 지점을 사용하여 모든 정책을 저장하는 것이 좋습니다. 예를 들어 간격 및 재시도 횟수와 같은 값을 애플리케이션 구성 파일에 저장하고, 런타임에 읽고, 프로그래밍 방식으로 재시도 정책을 빌드합니다. 이렇게 하면 설정을 더 쉽게 관리하고 변경 요구 사항 및 시나리오에 응답하기 위해 값을 수정하고 미세 조정할 수 있습니다. 그러나 매번 구성 파일을 다시 읽지 않고 값을 저장하도록 시스템을 디자인하고 구성에서 값을 가져올 수 없는 경우 적절한 기본값을 사용합니다.

• 애플리케이션을 다시 시작하지 않고도 변경할 수 있도록 런타임에 다시 시도 정책을 빌드하는 데 사용되는 값을 애플리케이션의 구성 시스템에 저장합니다.

• 사용하는 클라이언트 API에서 사용할 수 있지만 시나리오에 적합한 경우에만 기본 제공 또는 기본 재시도 전략을 활용합니다. 이러한 전략은 일반적으로 일반적입니다. 일부 시나리오에서는 필요한 것이 전부일 수 있지만 다른 시나리오에서는 특정 요구 사항에 맞는 전체 옵션을 제공하지 않습니다. 가장 적절한 값을 확인하려면 테스트를 수행하여 설정이 애플리케이션에 미치는 영향을 이해해야 합니다.

일시적 오류 및 비정상 오류 기록 및 추적

• 재시도 전략의 일부로 예외 처리 및 재시도 시도를 기록하는 기타 계측을 포함합니다. 일시적인 오류 및 재시도가 예상되며 문제를 나타내지 않습니다. 그러나 정기적으로 증가하는 재시도 횟수는 종종 실패를 유발하거나 애플리케이션 성능 및 가용성을 저하시킬 수 있는 문제를 나타내는 지표입니다.

• 일시적 오류를 오류 항목이 아닌 경고 항목으로 기록하여 모니터링 시스템이 거짓 경고를 트리거할 수 있는 애플리케이션 오류로 감지하지 않도록 합니다.

• 데이터를 분석하는 동안 구분할 수 있도록 재시도가 서비스의 제한으로 인해 발생하는지 또는 연결 오류와 같은 다른 유형의 오류로 인해 발생하는지 여부를 나타내는 값을 로그 항목에 저장하는 것이 좋습니다. 제한 오류 수의 증가는 애플리케이션의 설계에 결함이 있음을 나타내거나 전용 하드웨어를 제공하는 프리미엄 서비스로 전환해야 함을 나타냅니다.

• 재시도 메커니즘을 포함하는 작업의 전체 경과 시간을 측정하고 로깅하는 것이 좋습니다. 이 메트릭은 일시적인 오류가 사용자 응답 시간, 프로세스 대기 시간 및 애플리케이션 사용 사례의 효율성에 미치는 전반적인 영향을 나타내는 좋은 지표입니다. 또한 응답 시간에 영향을 주는 요인을 이해할 수 있도록 발생하는 재시도 횟수를 기록합니다.

• 오류 수와 속도, 평균 재시도 횟수 또는 작업이 성공하기 전에 경과된 전체 시간이 증가할 때 경고를 발생시키는 원격 분석 및 모니터링 시스템을 구현하는 것이 좋습니다.

지속적으로 실패하는 작업 관리

• 모든 시도에서 계속 실패하는 작업을 처리하는 방법을 고려합니다. 이와 같은 상황은 불가피합니다.

  • 재시도 전략은 작업을 다시 시도해야 하는 최대 횟수를 정의하지만 애플리케이션이 동일한 재시도 횟수로 작업을 다시 반복하는 것을 방지하지는 않습니다. 예를 들어 주문 처리 서비스가 영구적으로 작동을 중단하는 치명적인 오류와 함께 실패하는 경우 재시도 전략은 연결 시간 제한을 감지하고 일시적인 오류로 간주할 수 있습니다. 코드는 작업을 지정된 횟수만큼 다시 시도한 다음 포기합니다. 그러나 다른 고객이 주문을 하면 매번 실패하더라도 작업이 다시 시도됩니다.

  • 지속적으로 실패하는 작업에 대한 지속적인 재시도를 방지하려면 회로 차단기 패턴을 구현하는 것이 좋습니다. 이 패턴을 사용하는 경우 지정된 기간 내의 오류 수가 임계값을 초과하면 요청은 오류로 즉시 호출자에게 반환되며 실패한 리소스 또는 서비스에 액세스하려고 시도하지 않습니다.

  • 애플리케이션은 간헐적으로 및 요청 사이에 긴 간격을 두어 서비스를 정기적으로 테스트하여 사용할 수 있게 되면 이를 감지할 수 있습니다. 적절한 간격은 작업의 중요도 및 서비스의 특성과 같은 요인에 따라 달라집니다. 몇 분에서 몇 시간 사이에 무엇이든 될 수 있습니다. 테스트가 성공하면 애플리케이션이 정상 작업을 다시 시작하고 새로 복구된 서비스에 요청을 전달할 수 있습니다.

  • 그 동안 다른 데이터 센터 또는 애플리케이션에서 서비스의 다른 instance 대체하거나, 호환 가능한(더 간단한) 기능을 제공하는 유사한 서비스를 사용하거나, 서비스가 곧 제공될 것이라는 희망에 따라 몇 가지 대체 작업을 수행할 수 있습니다. 예를 들어 서비스에 대한 요청을 큐 또는 데이터 저장소에 저장하고 나중에 다시 시도하는 것이 적절할 수 있습니다. 또는 사용자를 애플리케이션의 대체 instance 리디렉션하거나, 애플리케이션의 성능을 저하시킬 수 있지만 여전히 허용 가능한 기능을 제공하거나, 사용자에게 메시지를 반환하여 애플리케이션을 현재 사용할 수 없음을 나타낼 수 있습니다.

기타 고려 사항

• 재시도 횟수 및 정책에 대한 재시도 간격 값을 결정할 때 서비스 또는 리소스에 대한 작업이 장기 실행 또는 다단계 작업의 일부인지 여부를 고려합니다. 실패할 때 이미 성공한 다른 모든 운영 단계를 보상하는 것은 어렵거나 비용이 많이 들 수 있습니다. 이 경우 매우 긴 간격과 많은 재시도는 해당 전략이 부족한 리소스를 보유하거나 잠그어 다른 작업을 차단하지 않는 한 허용될 수 있습니다.

• 동일한 작업을 다시 시도하면 데이터가 불일치할 수 있는지 여부를 고려합니다. 다단계 프로세스의 일부 부분이 반복되고 작업이 멱등성이 아닌 경우 불일치가 발생할 수 있습니다. 예를 들어 값을 증가시키는 연산이 반복되면 잘못된 결과가 생성됩니다. 메시지를 큐에 보내는 작업을 반복하면 소비자가 중복 메시지를 검색할 수 없는 경우 메시지 소비자의 불일치가 발생할 수 있습니다. 이러한 시나리오를 방지하려면 각 단계를 멱등 연산으로 디자인합니다. 자세한 내용은 Idempotency 패턴을 참조하세요.

• 다시 시도되는 작업의 scope 고려합니다. 예를 들어 여러 작업을 포함하는 수준에서 재시도 코드를 구현하고 실패할 경우 모두 다시 시도하는 것이 더 쉬울 수 있습니다. 그러나 이렇게 하면 멱등성 문제 또는 불필요한 롤백 작업이 발생할 수 있습니다.

• 여러 작업을 포함하는 재시도 scope 선택하는 경우 재시도 간격을 결정할 때, 작업의 경과 시간을 모니터링할 때 및 오류에 대한 경고를 발생하기 전에 모든 작업의 총 대기 시간을 고려합니다.

• 재시도 전략이 공유 애플리케이션의 이웃 및 기타 테넌트 및 공유 리소스 및 서비스를 사용하는 경우에 어떤 영향을 미칠 수 있는지 고려합니다. 적극적인 재시도 정책으로 인해 이러한 다른 사용자 및 리소스와 서비스를 공유하는 애플리케이션에 대해 일시적인 오류 수가 증가할 수 있습니다. 마찬가지로 애플리케이션은 리소스 및 서비스의 다른 사용자가 구현한 재시도 정책의 영향을 받을 수 있습니다. 중요 비즈니스용 애플리케이션의 경우 공유되지 않는 프리미엄 서비스를 사용할 수 있습니다. 이렇게 하면 이러한 리소스 및 서비스의 부하 및 그에 따른 제한을 더 잘 제어할 수 있으므로 추가 비용을 정당화하는 데 도움이 될 수 있습니다.

참고

장단 점 및 위험에 대한 추가 지침은 재시도 패턴 문서의 문제 및 고려 사항을 참조하세요.

Azure 촉진

대부분의 Azure 서비스 및 클라이언트 SDK는 재시도 메커니즘을 제공합니다. 그러나 각 서비스에는 서로 다른 특성과 요구 사항이 있고 각 재시도 메커니즘이 특정 서비스에 맞게 조정되므로 이러한 메커니즘은 다릅니다. 이 섹션에서는 일반적으로 사용되는 일부 Azure 서비스에 대한 재시도 메커니즘 기능을 요약합니다.

서비스	재시도 기능	정책 구성	범위	원격 분석 기능
Microsoft Entra ID	MSAL(Microsoft 인증 라이브러리)의 네이티브	MSAL 라이브러리에 포함	내부	없음
Azure Cosmos DB	서비스의 네이티브	구성할 수 없음	전역	TraceSource
Azure Data Lake Storage	클라이언트의 네이티브	구성할 수 없음	개별 작업	없음
Azure Event Hubs	클라이언트의 네이티브	프로그래밍 방식	클라이언트	없음
Azure IoT Hub	클라이언트 SDK의 네이티브	프로그래밍 방식	클라이언트	없음
Azure Cache for Redis	클라이언트의 네이티브	프로그래밍 방식	클라이언트	TextWriter
Azure Cognitive Search	클라이언트의 네이티브	프로그래밍 방식	클라이언트	ETW 또는 사용자 지정
Azure Service Bus	클라이언트의 네이티브	프로그래밍 방식	NamespaceManager, MessagingFactory 및 클라이언트	ETW
Azure Service Fabric	클라이언트의 네이티브	프로그래밍 방식	클라이언트	없음
ADO.NET 사용하여 데이터베이스 Azure SQL	Polly	선언적 방식 및 프로그래밍 방식	코드의 단일 문 또는 블록	사용자 지정
Entity Framework를 사용하는 SQL Database	클라이언트의 네이티브	프로그래밍 방식	AppDomain에 따라 전역	없음
Entity Framework Core를 사용하는 SQL Database	클라이언트의 네이티브	프로그래밍 방식	AppDomain에 따라 전역	없음
Azure Storage	클라이언트의 네이티브	프로그래밍 방식	클라이언트 및 개별 작업	TraceSource

참고

대부분의 Azure 기본 제공 재시도 메커니즘의 경우 현재 다양한 유형의 오류 또는 예외에 대해 다른 재시도 정책을 적용할 수 있는 방법이 없습니다. 최적의 평균 성능 및 가용성을 제공하는 정책을 구성해야 합니다. 정책을 미세 조정하는 한 가지 방법은 로그 파일을 분석하여 발생하는 일시적인 오류 유형을 확인하는 것입니다.

예제

이 문서에서 설명하는 많은 패턴을 사용하는 예제는 .NET용 신뢰할 수 있는 웹앱 패턴을 참조하세요. GitHub에는 참조 구현 도 있습니다.

관련 링크

• 회로 차단기 패턴
• 패턴 다시 시도
• 제한 패턴
• 보상 트랜잭션 패턴
• 멱등성 패턴에 대한 블로그 게시물
• 연결 복원력
• 모의 서비스 주입
• 배달 못 한 편지 큐 패턴

안정성 검사 목록

전체 권장 사항 집합을 참조하세요.

안정성 검사 목록