회로 차단기 패턴

원격 서비스 또는 리소스에 연결할 때 복구하는 데 걸리는 시간이 유동적인 오류를 처리합니다. 이 패턴은 애플리케이션의 안정성과 복원력을 향상시킬 수 있습니다.

컨텍스트 및 문제점

분산 환경에서는 느린 네트워크 연결, 시간 제한 또는 초과 커밋되거나 일시적으로 사용할 수 없는 리소스와 같은 일시적인 오류로 인해 원격 리소스 및 서비스에 대한 호출이 실패할 수 있습니다. 이러한 오류는 일반적으로 짧은 시간 후에 스스로 수정되며, 강력한 클라우드 애플리케이션은 재시도 패턴과 같은 전략을 사용하여 이를 처리할 준비가 되어 있어야 합니다.

그러나 예기치 않은 이벤트로 인해 오류가 발생할 수 있으며 이 경우에 문제를 해결하는 시간이 훨씬 더 오래 걸릴 수 있습니다. 이러한 오류는 심각도의 범위가 연결의 부분적인 손실에서 서비스의 전체 오류까지 퍼질 수 있습니다. 이러한 상황에서는 애플리케이션이 성공할 가능성이 없는 작업을 지속적으로 다시 시도하는 것은 무의미할 수 있으며, 대신 애플리케이션은 작업이 실패했음을 신속하게 받아들이고 그에 따라 이 오류를 처리해야 합니다.

또한 서비스가 매우 바쁜 경우 시스템의 한 부분에서 오류가 발생하면 연속 오류가 발생할 수 있습니다. 예를 들어 서비스를 호출하는 작업은 시간 초과를 구현하도록 구성하고, 서비스가 이 기간 내에 응답하지 않을 경우 실패 메시지로 회신할 수 있습니다. 그러나 이 전략으로 인해 제한 시간이 만료될 때까지 동일한 작업에 대한 많은 동시 요청이 차단될 수 있습니다. 이처럼 차단된 요청이 메모리, 스레드, 데이터베이스 연결 등의 중요한 시스템 리소스를 계속 잡아 둘 수 있습니다. 따라서 이러한 리소스가 소진되어 동일한 리소스를 사용해야 하는 시스템의 다른 관련 없는 부분이 실패할 수 있습니다. 이러한 상황에서는 작업이 즉시 실패하고 성공할 가능성이 있는 경우에만 서비스를 호출하는 것이 좋습니다. 더 짧은 제한 시간을 설정하면 이 문제를 해결하는 데 도움이 될 수 있지만, 제한 시간이 너무 짧아서 서비스에 대한 요청이 결국 성공하더라도 작업이 대부분의 시간 동안 실패할 수 있습니다.

솔루션

회로 차단기 패턴은 애플리케이션이 실패할 가능성이 있는 작업을 반복적으로 실행하지 못하도록 방지할 수 있습니다. 오류가 수정될 때까지 기다리거나 오류가 오래 지속되는 것으로 판단되는 동안 CPU 주기를 낭비하지 않고 계속하도록 허용합니다. 회로 차단기 패턴을 사용하면 애플리케이션에서 오류가 해결되었는지 여부를 감지할 수도 있습니다. 문제가 해결된 것으로 보이면 애플리케이션에서 작업을 호출하려고 시도할 수 있습니다.

회로 차단기 패턴의 용도는 재시도 패턴과 다릅니다. 재시도 패턴을 사용하면 애플리케이션에서 작업이 성공한다는 기대로 작업을 다시 시도할 수 있습니다. 회로 차단기 패턴은 애플리케이션이 실패할 수 있는 작업을 시도하지 않도록 방지합니다. 애플리케이션은 회로 차단기를 통해 작업 호출에 재시도 패턴을 사용하여 이 두 패턴을 결합할 수 있습니다. 그러나 재시도 논리는 회로 차단기에서 반환되는 모든 예외에 민감하며, 회로 차단기에서 오류가 일시적임을 나타내는 경우 재시도를 중단합니다.

회로 차단기는 실패할 수 있는 작업에서 프록시 역할을 합니다. 프록시는 발생한 최근 오류 수를 모니터링하고 이 정보를 사용하여 작업을 계속할지 아니면 즉시 예외를 반환할지 결정해야 합니다.

프록시는 전기 회로 차단기의 기능을 모방하는 다음과 같은 상태의 상태 컴퓨터로 구현할 수 있습니다.

• 닫힘: 애플리케이션의 요청을 작업으로 라우팅합니다. 프록시는 최근 실패 횟수를 유지 관리하며, 작업에 대한 호출이 실패하면 프록시가 이 수를 증분합니다. 최근 오류 수가 지정된 기간 내에 지정된 임계값을 초과하면 프록시가 Open 상태로 전환됩니다. 이 시점에서 프록시는 시간 제한 타이머를 시작하고 이 타이머가 만료되면 프록시가 반 열기 상태에 배치됩니다.

  시간 제한 타이머의 목적은 애플리케이션이 작업을 다시 수행하도록 허용하기 전에 오류를 발생시킨 문제를 해결하기 위한 시스템 시간을 제공하는 것입니다.

• 열기: 애플리케이션의 요청이 즉시 실패하고 예외가 애플리케이션에 반환됩니다.

• 반 열림: 제한된 수의 애플리케이션 요청이 전달되도록 허용하고 작업을 호출할 수 있습니다. 이러한 요청이 성공하는 경우 이전에 오류가 발생된 오류가 해결되었고 회로 차단기가 닫힌 상태로 전환되었다(오류 카운터를 다시 설정함)고 가정합니다. 요청이 실패하는 경우 회로 차단기는 오류가 여전히 있다고 가정하므로 Open 상태로 되돌리고 시간 제한 타이머를 다시 시작하여 시스템에 오류로부터 복구할 수 있는 추가 기간을 제공합니다.

  반쯤 열린 상태는 복구 서비스가 갑자기 요청으로 넘쳐나지 않도록 방지하는 데 유용합니다. 서비스가 복구되는 대로 복구가 완료될 때까지 제한된 볼륨의 요청을 지원할 수 있지만 복구가 진행 중인 동안 많은 양의 작업으로 인해 서비스에 시간 초과 또는 다시 실패가 발생할 수 있습니다.

그림에서 닫힌 상태에서 사용하는 오류 카운터는 시간 기반입니다. 정기적 간격에 자동으로 다시 설정됩니다. 이 디자인은 회로 차단기가 가끔 오류가 발생하는 경우 Open 상태가 되는 것을 방지하는 데 도움이 됩니다. 회로 차단기를 Open 상태로 가져오는 오류 임계값은 지정된 간격 동안 지정된 수의 오류가 발생한 경우에만 도달합니다. 반 열린 상태에서 사용하는 카운터는 작업을 호출하는 시도가 성공한 수를 기록합니다. 지정된 수의 연속 작업 호출이 성공한 후 회로 차단기가 닫힌 상태로 되돌아갑니다. 호출에 실패하면 회로 차단기가 즉시 열기 상태로 들어가고 다음에 반쯤 열린 상태로 들어갈 때 성공 카운터가 다시 설정됩니다.

시스템 복구 방법은 실패한 구성 요소를 복원하거나 다시 시작하거나 네트워크 연결을 복구하여 외부에서 처리됩니다.

회로 차단기 패턴은 시스템이 오류로부터 복구되는 동안 안정성을 제공하여 성능에 대한 영향을 최소화합니다. 작업이 시간 초과되거나 반환되지 않을 때까지 기다리지 않고 실패할 가능성이 있는 작업에 대한 요청을 신속하게 거부하여 시스템의 응답 시간을 유지하는 데 도움이 될 수 있습니다. 회로 차단기가 상태를 변경할 때마다 이벤트가 발생하는 경우 이 정보를 사용하여 회로 차단기에 의해 보호되는 시스템 부분의 상태를 모니터링하거나 회로 차단기가 Open 상태로 주행할 때 관리자에게 경고할 수 있습니다.

패턴은 사용자 지정할 수 있으며 가능한 오류 유형에 따라 조정할 수 있습니다. 예를 들어 회로 차단기에 증가하는 시간 제한 타이머를 적용할 수 있습니다. 회로 차단기를 처음에 몇 초 동안 Open 상태에 배치한 다음 오류가 해결되지 않은 경우 시간 제한 시간을 몇 분으로 늘리는 등의 작업을 수행할 수 있습니다. 어떤 경우에는 오류를 반환하고 예외를 발생시키는 열린 상태가 아니라 애플리케이션에 의미 있는 기본값을 반환하는 것이 유용할 수 있습니다.

문제 및 고려 사항

이 패턴을 구현할 방법을 결정할 때 다음 사항을 고려해야 합니다.

예외 처리: 회로 차단기를 통해 작업을 호출하는 애플리케이션은 작업을 사용할 수 없는 경우 발생한 예외를 처리하도록 준비해야 합니다. 예외를 처리하는 방법은 애플리케이션별로 다릅니다. 예를 들어 애플리케이션이 일시적으로 기능을 저하하거나, 동일한 작업을 수행하거나, 동일한 데이터를 가져오려고 하는 대체 작업을 호출하거나, 사용자에게 예외를 보고하고 나중에 다시 시도하도록 요청할 수 있습니다.

예외 유형: 요청이 여러 가지 이유로 실패할 수 있으며, 그 중 일부는 다른 것보다 더 심각한 유형의 실패를 나타낼 수 있습니다. 예를 들어 원격 서비스가 충돌하여 복구하는 데 몇 분 정도 걸리거나 서비스가 일시적으로 오버로드되어 시간이 초과되어 요청이 실패할 수 있습니다. 회로 차단기는 발생하는 예외 유형을 검사하고 이러한 예외의 특성에 따라 전략을 조정할 수 있습니다. 예를 들어 회로 차단기를 Open 상태로 이동하려면 서비스를 완전히 사용할 수 없는 오류 수에 비해 더 많은 시간 제한 예외가 필요할 수 있습니다.

모니터링: 회로 차단기는 실패한 요청과 성공적인 요청 모두에 대한 명확한 관찰 가능성을 제공하여 운영 팀이 시스템 상태를 평가할 수 있도록 해야 합니다. 서비스 전반에서 엔드 투 엔드 가시성을 위해 분산 추적을 사용합니다.

복구 가능성: 회로 차단기가 보호 중인 작업의 복구 패턴과 일치하도록 구성해야 합니다. 예를 들어 회로 차단기가 오랫동안 Open 상태로 유지되는 경우 오류의 원인이 해결된 경우에도 예외가 발생할 수 있습니다. 마찬가지로 회로 차단기는 Open 상태에서 반쯤 열린 상태로 너무 빨리 전환할 경우 애플리케이션의 응답 시간을 변동시키고 줄일 수 있습니다.

테스트 실패 작업: Open 상태에서 타이머를 사용하여 반 열기 상태로 전환할 시기를 결정하는 대신 회로 차단기가 원격 서비스 또는 리소스를 주기적으로 ping하여 다시 사용할 수 있는지 여부를 확인할 수 있습니다. 이 ping은 이전에 실패한 작업을 호출하려는 시도의 형식을 사용할 수 있습니다. 또는 상태 엔드포인트 모니터링 패턴에 설명된 대로 서비스의 상태를 테스트하기 위해 특별히 원격 서비스에서 제공하는 특별한 작업을 사용할 수 있습니다.

수동 재정의: 실패한 작업의 복구 시간이 매우 가변적인 시스템에서 관리자가 회로 차단기를 닫고 실패 카운터를 다시 설정할 수 있는 수동 재설정 옵션을 제공하는 것이 좋습니다. 마찬가지로, 관리자는 회로 차단기에서 보호되는 작업을 일시적으로 사용할 수 없는 경우 회로 차단기를 열기 상태로 전환하고 시간 제한 타이머를 다시 시작할 수 있습니다.

동시성: 애플리케이션의 많은 동시 인스턴스에서 동일한 회로 차단기에 액세스할 수 있습니다. 구현은 동시 요청을 차단하거나 작업에 대한 각 호출에 과도한 오버헤드를 추가해서는 안 됩니다.

리소스 차별화: 기본 독립 공급자가 여러 개 있을 수 있는 경우 한 유형의 리소스에 단일 회로 차단기를 사용할 때는 주의해야 합니다. 예를 들어 여러 분할된 데이터베이스가 포함된 데이터 저장소에서는 한 분할된 데이터베이스에 완전히 액세스할 수 있고 다른 분할된 데이터베이스에는 임시 문제가 발생할 수 있습니다. 이러한 시나리오의 오류 응답이 병합되는 경우 애플리케이션은 실패 가능성이 높은 경우에도 일부 분할된 데이터베이스에 액세스하려고 시도할 수 있지만 다른 분할된 데이터베이스에 대한 액세스는 성공할 가능성이 높더라도 차단될 수 있습니다.

가속 회로 중단: 경우에 따라 오류 응답에는 회로 차단기가 즉시 이동하고 최소 시간 동안 트립된 상태를 유지할 수 있는 충분한 정보가 포함될 수 있습니다. 예를 들어 오버로드된 공유 리소스의 오류 응답은 즉시 재시도를 사용하지 않는 것이 좋으며 대신 애플리케이션을 몇 분 후에 다시 시도해야 한다는 점을 나타낼 수 있습니다.

다중 지역 배포: 회로 차단기는 단일 또는 다중 지역 배포용으로 설계될 수 있습니다. 후자는 제어된 장애 조치, 대기 시간 최적화 및 규정 준수를 보장하는 글로벌 부하 분산 장치 또는 사용자 지정 지역 인식 회로 중단 전략을 사용하여 구현할 수 있습니다.

서비스 메시 회로 차단기: 회로 차단기는 애플리케이션 계층에서 또는 교차 절단 추상화된 기능으로 구현할 수 있습니다. 예를 들어 서비스 메시는 사이드카 또는 애플리케이션 코드를 수정하지 않고 독립 실행형 기능으로 회로 중단을 지원하는 경우가 많습니다.

실패한 요청 재생: 열기 상태에서는 단순히 빠르게 실패하는 대신 회로 차단기가 각 요청의 세부 정보를 업무 일지에 기록하고 원격 리소스 또는 서비스를 사용할 수 있게 되면 이러한 요청을 재생하도록 정렬할 수도 있습니다.

외부 서비스부적절한 시간 제한: 회로 차단기가 긴 시간 제한 기간으로 구성된 외부 서비스에서 실패한 작업으로부터 애플리케이션을 완전히 보호하지 못할 수 있습니다. 제한 시간이 너무 길면 회로 차단기가 작업이 실패했음을 나타내기 전에 회로 차단기를 실행하는 스레드가 장기간 차단될 수 있습니다. 이때 다른 많은 애플리케이션 인스턴스는 회로 차단기를 통해 서비스를 호출하고 모두 실패하기 전에 상당수의 스레드를 연결하려고 할 수도 있습니다.

컴퓨팅 다각화적응성: 회로 차단기는 서버리스에서 컨테이너화된 워크로드까지 다양한 컴퓨팅 환경을 고려해야 하며, 콜드 시작 및 확장성과 같은 요소는 오류 처리에 영향을 줍니다. 적응형 접근 방식은 컴퓨팅 유형에 따라 전략을 동적으로 조정하여 다른 유형의 아키텍처에서 복원력을 보장할 수 있습니다.

이 패턴을 사용해야 하는 경우

다음과 같은 경우에 이 패턴을 사용합니다.

• 이러한 작업이 실패할 가능성이 높은 경우 원격 서비스에서 과도한 호출을 중지하거나 공유 리소스에 대한 요청에 액세스하여 연속 오류를 방지합니다.
• 실시간 오류 신호를 기반으로 트래픽을 지능적으로 라우팅하여 다중 지역 복원력을 향상시킵니다.
• 느린 종속성으로부터 보호하기 위해 SLO(서비스 수준 목표)를 따라가고 대기 시간이 긴 서비스로 인한 성능 저하를 방지할 수 있습니다.
• 일시적인 연결 문제를 처리하고 분산 환경에서 요청 실패를 줄이려면

이 패턴은 권장되지 않습니다.

• 메모리 내 데이터 구조와 같은 애플리케이션의 로컬 프라이빗 리소스에 대한 액세스를 처리합니다. 이 환경에서 회로 차단기를 사용하면 시스템에 오버헤드가 추가됩니다.
• 애플리케이션의 비즈니스 논리에서 예외를 처리하는 대신 사용할 수 있습니다.
• 잘 알려진 재시도 알고리즘이 충분하고 종속성이 재시도 메커니즘을 처리하도록 설계된 경우 이 경우 애플리케이션에서 회로 차단기를 구현하면 시스템에 불필요한 복잡성이 추가됩니다.
• 회로 차단기가 다시 설정될 때까지 기다리는 경우 허용할 수 없는 지연이 발생할 수 있습니다.
• 메시지 기반 또는 이벤트 기반 아키텍처가 있는 경우 수동 또는 지연 처리를 위해 실패한 메시지를 DLQ(배달 못 한 편지 큐)로 라우팅하는 경우가 많습니다. 이러한 디자인에서 일반적으로 구현되는 기본 제공 오류 격리 및 재시도 메커니즘은 종종 충분합니다.
• 전역 부하 분산 장치 또는 서비스 메시의 상태 검사와 같이 인프라 또는 플랫폼 수준에서 오류 복구를 관리하는 경우 회로 차단기가 필요하지 않을 수 있습니다.

워크로드 디자인

설계자는 워크로드 디자인에서 회로 차단기 패턴을 사용하여 Azure Well-Architected Framework 핵심 요소에서 다루는 목표와 원칙을 해결하는 방법을 평가해야 합니다. 예시:

디자인 결정과 마찬가지로 이 패턴을 통해 도입 가능한 다른 핵심 요소의 목표에 관한 절충을 고려합니다.

관련 참고 자료

이 패턴을 구현할 때 유용한 패턴은 다음과 같습니다.

• 신뢰할 수 있는 웹앱 패턴 은 회로 차단기 패턴을 클라우드에 수렴하는 웹 애플리케이션에 적용하는 방법을 보여 줍니다.

• 재시도 패턴. 애플리케이션이 이전에 실패한 작업을 투명하게 다시 시도하여 서비스 또는 네트워크 리소스에 연결하려고 할 때 예상되는 임시 오류를 처리하는 방법을 설명합니다.

• 상태 엔드포인트 모니터링 패턴입니다. 회로 차단기는 서비스에서 노출하는 엔드포인트에 요청을 전송하여 서비스의 상태를 테스트할 수 있습니다. 서비스는 상태를 나타내는 정보를 반환해야 합니다.