다음을 통해 공유

부분 오류를 처리하는 전략

팁 (조언)

이 콘텐츠는 .NET Docs 또는 오프라인으로 읽을 수 있는 다운로드 가능한 무료 PDF로 제공되는 컨테이너화된 .NET 애플리케이션용 .NET 마이크로 서비스 아키텍처인 eBook에서 발췌한 내용입니다.

PDF 다운로드

컨테이너화된 .NET 애플리케이션을 위한 .NET 마이크로서비스 아키텍처 eBook의 표지 썸네일.

부분 오류를 처리하려면 여기에 설명된 전략 중 하나를 사용합니다.

내부 마이크로 서비스에서 비동기 통신(예: 메시지 기반 통신)을 사용합니다. 잘못된 디자인이 결국 잘못된 중단의 주요 원인이 되기 때문에 내부 마이크로 서비스에서 동기 HTTP 호출의 긴 체인을 만들지 않는 것이 좋습니다. 반대로 클라이언트 애플리케이션과 첫 번째 수준의 마이크로 서비스 또는 세분화된 API 게이트웨이 간의 프런트 엔드 통신을 제외하고 내부 마이크로 서비스에서 초기 요청/응답 주기를 지나면 비동기(메시지 기반) 통신만 사용하는 것이 좋습니다. 최종 일관성 및 이벤트 기반 아키텍처는 파급 효과를 최소화하는 데 도움이 됩니다. 이러한 접근 방식은 더 높은 수준의 마이크로 서비스 자율성을 적용하므로 여기에 언급된 문제를 방지합니다.

지수 백오프와 함께 재시도를 사용합니다. 이 기술은 서비스를 짧은 시간 동안만 사용할 수 없는 경우 호출 재시도를 특정 횟수만큼 수행하여 짧고 일시적인 오류를 방지하는 데 도움이 됩니다. 이 문제는 일시적인 네트워크 문제 또는 마이크로 서비스/컨테이너가 클러스터의 다른 노드로 이동될 때 발생할 수 있습니다. 그러나 이러한 재시도가 회로 차단기를 사용하여 제대로 설계되지 않은 경우 파급 효과를 악화시켜 궁극적으로 DoS(서비스 거부)를 유발할 수도 있습니다.

네트워크 시간 제한을 해결합니다. 일반적으로 클라이언트는 무기한으로 차단되지 않고 응답을 기다릴 때 항상 시간 제한을 사용하도록 설계해야 합니다. 시간 제한을 사용하면 리소스가 무기한으로 연결되지 않습니다.

회로 차단기 패턴을 사용합니다. 이 방법에서 클라이언트 프로세스는 실패한 요청 수를 추적합니다. 오류율이 설정된 제한을 초과하면, 추가 시도가 즉시 실패하도록 "회로 차단기"가 작동합니다. (많은 수의 요청이 실패하는 경우 서비스를 사용할 수 없고 요청을 보내는 것은 무의미하다는 것을 시사합니다.) 시간 제한 기간이 지나면 클라이언트가 다시 시도해야 하며, 새 요청이 성공하면 회로 차단기를 닫습니다.

대체 기능을 제공하세요. 이 방법에서 클라이언트 프로세스는 캐시된 데이터 또는 기본값 반환과 같은 요청이 실패할 때 대체 논리를 수행합니다. 이는 쿼리에 적합한 접근 방식이며 업데이트 또는 명령에 더 복잡합니다.

대기 중인 요청 수를 제한합니다. 또한 클라이언트는 클라이언트 마이크로 서비스가 특정 서비스에 보낼 수 있는 미해결 요청 수에 상한을 적용해야 합니다. 제한에 도달한 경우 추가 요청을 수행하는 것은 무의미할 수 있으며 이러한 시도는 즉시 실패해야 합니다. 구현 측면에서 Polly Bulkhead 격리 정책을 사용하여 이 요구 사항을 충족할 수 있습니다. 이 접근 방식은 SemaphoreSlim를 구현하여 병렬 처리 속도를 조절하는 것입니다. 또한 격벽 외부의 "대기열"을 허용합니다. 실행 전에 과도한 부하를 사전에 제거할 수 있습니다(예: 용량이 전체로 간주되기 때문). 이렇게 하면 회로 차단기가 오류를 대기하므로 회로 차단기보다 특정 오류 시나리오에 대한 응답이 더 빠릅니다. Polly의 BulkheadPolicy 개체는 벌크헤드와 큐가 얼마나 꽉 찼는지 노출하고 오버플로에 대한 이벤트를 제공하므로 자동화된 수평 크기 조정을 구동하는 데도 사용할 수 있습니다.

추가 리소스

이전다음