애플리케이션 복원력 패턴

첫 번째 방어선은 애플리케이션 복원력입니다.

고유한 복원력 프레임워크를 작성하는 데 상당한 시간을 투자할 수 있지만 이러한 제품은 이미 존재합니다. Polly 는 개발자가 유창하고 스레드로부터 안전한 방식으로 복원력 정책을 표현할 수 있는 포괄적인 .NET 복원력 및 일시적인 오류 처리 라이브러리입니다. Polly는 .NET Framework 또는 .NET 7로 빌드된 애플리케이션을 대상으로 합니다. 다음 표에서는 Polly 라이브러리에서 사용할 수 있는 복원력 기능을 policies설명합니다. 개별적으로 적용하거나 함께 그룹화할 수 있습니다.

이전 그림에서 복원력 정책이 외부 클라이언트 또는 백 엔드 서비스에서 오는지 여부에 관계없이 요청 메시지에 적용되는 방법을 확인합니다. 목표는 일시적으로 사용할 수 없는 서비스에 대한 요청을 보정하는 것입니다. 이러한 단기 중단은 일반적으로 다음 표에 표시된 HTTP 상태 코드와 함께 표시됩니다.

질문: HTTP 상태 코드 403 - 금지됨을 다시 시도하시겠습니까? 아니요. 여기서 시스템은 제대로 작동하지만 요청된 작업을 수행할 권한이 없음을 호출자에게 알릴 수 있습니다. 오류로 인해 발생한 작업만 다시 시도하려면 주의해야 합니다.

1장에서 권장하는 대로 클라우드 네이티브 애플리케이션을 생성하는 Microsoft 개발자는 .NET 플랫폼을 대상으로 해야 합니다. 버전 2.1에는 URL 기반 리소스와 상호 작용하기 위한 HTTP 클라이언트 인스턴스를 만들기 위한 HTTPClientFactory 라이브러리가 도입되었습니다. 원래 HTTPClient 클래스를 대체하는 팩터리 클래스는 많은 향상된 기능을 지원하며, 그 중 하나는 Polly 복원력 라이브러리와의 긴밀한 통합 입니다. 이를 통해 애플리케이션 시작 클래스에서 복원력 정책을 쉽게 정의하여 부분 오류 및 연결 문제를 처리할 수 있습니다.

다음으로, 재시도 및 회로 차단 패턴을 살펴보겠습니다.

다시 시도 패턴

분산된 클라우드 네이티브 환경에서는 일시적(수명이 짧은) 오류로 인해 서비스 및 클라우드 리소스에 대한 호출이 실패할 수 있으며, 이는 일반적으로 짧은 시간 후에 스스로 수정됩니다. 재시도 전략을 구현하면 클라우드 네이티브 서비스가 이러한 시나리오를 완화하는 데 도움이 됩니다.

재시도 패턴을 사용하면 서비스에서 대기 시간이 기하급수적으로 늘어나면서 실패한 요청 작업을 (구성 가능한) 횟수만큼 다시 시도할 수 있습니다. 그림 6-2는 재시도 과정을 보여 줍니다.

그림 6-2. 실행 중인 다시 시도 패턴

이전 그림에서는 요청 작업에 대한 재시도 패턴이 구현되었습니다. 백오프 간격(대기 시간)이 2초에서 시작하여 실패하기 전에 최대 4번의 재시도를 허용하도록 구성되며, 이후 각 시도에 대해 기하급수적으로 두 배가 됩니다.

• 첫 번째 호출이 실패하고 HTTP 상태 코드 500을 반환합니다. 애플리케이션은 2초 동안 기다렸다가 호출을 다시 시도합니다.
• 두 번째 호출도 실패하고 HTTP 상태 코드 500을 반환합니다. 이제 애플리케이션은 백오프 간격을 4초로 두 배로 하여 호출을 다시 시도합니다.
• 마지막으로 세 번째 호출이 성공합니다.
• 이 시나리오에서 재시도 작업은 호출에 실패하기 전에 백오프 기간을 두 배로 늘리면서 최대 4번의 재시도를 시도했을 것입니다.
• 4번째 재시도에 실패하면 문제를 정상적으로 처리하기 위해 대체 정책이 호출됩니다.

서비스 시간을 자체 수정할 수 있도록 호출을 다시 시도하기 전에 백오프 기간을 늘리는 것이 중요합니다. 적절한 수정 시간을 허용하도록 기하급수적으로 증가하는 백오프(각 재시도 기간의 두 배)를 구현하는 것이 가장 좋습니다.

회로 차단기 패턴

재시도 패턴은 부분 실패에 얽힌 요청을 회수하는 데 도움이 될 수 있지만, 예기치 않은 이벤트로 인해 오류가 발생할 수 있는 상황이 있으며, 이 경우 해결하는 데 시간이 더 오래 걸릴 수 있습니다. 이러한 오류는 심각도의 범위가 연결의 부분적인 손실에서 서비스의 전체 오류까지 퍼질 수 있습니다. 이러한 상황에서 애플리케이션이 성공할 가능성이 없는 작업을 지속적으로 다시 시도하는 것은 무의미합니다.

설상가상으로, 응답하지 않는 서비스에서 지속적인 재시도 작업을 실행하면 메모리, 스레드 및 데이터베이스 연결과 같은 리소스를 지속적으로 호출하여 동일한 리소스를 사용하는 시스템의 관련 없는 부분에서 오류가 발생하는 자체 부과 서비스 거부 시나리오로 이동할 수 있습니다.

이러한 상황에서는 작업이 즉시 실패하고 성공할 가능성이 있는 경우에만 서비스를 호출하는 것이 좋습니다.

회로 차단기 패턴은 애플리케이션이 실패할 가능성이 있는 작업을 반복적으로 실행하지 못하도록 방지할 수 있습니다. 미리 정의된 수의 실패한 호출 후에는 서비스에 대한 모든 트래픽을 차단합니다. 정기적으로 평가판 호출을 통해 오류가 해결되었는지 여부를 확인할 수 있습니다. 그림 6-3은 작동 중인 회로 차단기 패턴을 보여 줍니다.

그림 6-3. 작동 중인 회로 차단기 패턴

이전 그림에서는 회로 차단기 패턴이 원래 재시도 패턴에 추가되었습니다. 100개의 요청이 실패한 후 회로 차단기가 열리고 더 이상 서비스에 대한 호출을 허용하지 않는 방법을 확인합니다. 30초로 설정된 CheckCircuit 값은 라이브러리에서 하나의 요청이 서비스를 계속 진행할 수 있는 빈도를 지정합니다. 해당 호출이 성공하면 회로가 닫히고 트래픽에서 서비스를 다시 사용할 수 있습니다.

회로 차단기 패턴의 의도는 재시도 패턴의 의도와 다릅니다 . 다시 시도 패턴을 사용하면 애플리케이션이 성공할 것으로 예상하여 작업을 다시 시도할 수 있습니다. 회로 차단기 패턴은 애플리케이션이 실패할 가능성이 있는 작업을 수행하지 못하게 합니다. 일반적으로 애플리케이션은 재시도 패턴을 사용하여 회로 차단기를 통해 작업을 호출하여 이러한 두 패턴을 결합 합니다.

복원력 테스트

복원력 테스트는 단위 테스트, 통합 테스트 등을 실행하여 애플리케이션 기능을 테스트하는 것과 동일한 방식으로 항상 수행할 수 없습니다. 대신 간헐적으로만 발생하는 오류 조건에서 엔드투엔드 워크로드가 수행하는 방식을 테스트해야 합니다. 예를 들어 프로세스 충돌, 만료된 인증서, 종속 서비스를 사용할 수 없도록 하여 오류를 삽입합니다. 카오스 원숭이 와 같은 프레임워크는 이러한 혼돈 테스트에 사용할 수 있습니다.

애플리케이션 복원력은 문제가 있는 요청된 작업을 처리하기 위한 필수 요소입니다. 하지만, 그것은 이야기의 절반에 불과합니다. 다음으로, Azure 클라우드에서 사용할 수 있는 복원력 기능을 다룹니다.