재시도가 중단되는 경우

첫 번째 실패한 요청은 가동 중단에서 가장 흥미롭지 않은 부분인 경우가 많습니다. 종속성이 예상보다 오래 걸리고 한 호출자가 대기를 포기하면 애플리케이션이 다시 시도합니다. 합리적인 회복 조치처럼 보입니다. 수천 명의 다른 호출자가 동일한 결론에 도달하고 여러 계층이 자체적으로 시도하며 원래 작업이 여전히 실행 중일 때 어려움이 나타납니다. 이제 시스템은 복구 메커니즘에 의해 생성된 로드를 복구하는 데 점점 더 많은 용량을 사용하고 있습니다. 개별 재시도 루프의 어떤 것도 결합된 동작이 파괴적이 되기 위해 분명히 비합리적으로 보일 필요는 없습니다.

명시적으로 가상의 주문 상태 서비스를 고려해보세요. 일반적으로 들어오는 작업을 위한 충분한 용량이 있지만 다운스트림 종속성은 2분 동안 느려집니다. 요청은 더 오랫동안 진행되고, 호출자의 제한 시간이 만료되기 시작하며, 클라이언트 라이브러리가 또 다른 시도를 시작합니다. 외부 서비스에도 재시도 정책이 있습니다. 사용자 인터페이스는 자체 기한이 지났기 때문에 재시도 버튼을 제공합니다. 비즈니스 요구 사항은 거의 변하지 않았지만 종속성은 완료할 수 있는 작업이 적을 때 더 많은 작업 시도를 보게 됩니다. 이 기사에서는 해당 체인을 따라가며 설계가 이를 중단할 수 있는 위치를 조사합니다. 시나리오와 모든 수치 예는 예시일 뿐 MGCA 고객 사건에 대한 설명이나 측정된 벤치마크가 아닙니다.

재시도는 이전 의도를 나타내는 경우에도 리소스에 대한 새로운 요청입니다. 그 구별이 실패를 이해하는 출발점이다. 기업은 여전히 ​​상태 업데이트 1회, 제출된 신청서 1회 또는 완료된 보고서 1회를 원할 수 있습니다. 인프라는 이를 생성하기 위한 여러 시도를 처리 중일 수 있습니다. 대시보드가 ​​기본 작업에 연결하지 않고 요청을 계산하는 경우 추가 활동은 고객 수요의 급증처럼 보일 수 있습니다. 성공이 유용한 결과가 아닌 시도별로 측정된다면 서비스는 이를 기다리는 사람의 경험보다 더 건강해 보일 수도 있습니다.

1. 작은 지연이 제2의 삶을 얻는다

시간 초과는 로컬 질문에 대한 답변입니다. 이 호출자는 얼마나 오래 기다릴까요? 원격 작업이 중지되었는지, 실행 전에 실패했는지, 승인을 전달하지 않고 완료되었는지 자체적으로 응답하지 않습니다. 그것들은 다른 결과입니다. 읽기의 경우 요청을 반복하면 주로 리소스가 소모될 수 있습니다. 쓰기의 경우 불확실한 결과로 인해 정확성 문제가 발생할 수도 있습니다. 수신 시스템이 이미 변경 사항을 커밋했을 수도 있습니다. 명확한 답변을 받고자 하는 호출자의 욕구가 다른 실행을 안전하게 만들지는 않습니다. 따라서 전송 계층에 재시도를 할당하고 애플리케이션의 나머지 부분이 영향을 받지 않는다고 가정하기보다는 용량 보호와 비즈니스 정확성을 함께 고려해야 합니다.

속도 저하에 대한 첫 번째 대응은 시간 초과를 늘리는 것인 경우가 많습니다. 이를 통해 정상적인 변형이 중단으로 오인되는 잘못된 오류를 줄일 수 있습니다. 또한 더 많은 요청이 리소스를 더 오랫동안 점유하도록 할 수도 있습니다. 시간 초과를 낮추면 반대의 절충안이 생성됩니다. 호출자는 대기 상태를 더 빨리 해제하지만 이전 작업이 활성 상태인 동안 교체 시도를 시작할 수 있습니다. 어느 방향도 본질적으로 정확하지 않습니다. 유용한 질문은 어떤 리소스가 계속 점유되어 있는지, 어떤 작업이 실제로 중지되는지, 그리고 선택한 마감일이 작업 완료의 가치와 어떻게 관련되는지입니다. 이러한 질문에 대답하지 않고 숫자를 변경하면 압력을 제거하기보다는 이동할 수 있습니다.

시계도 두 개 이상 있습니다. 연결 설정, 이름 확인, ID 토큰 획득, 풀링된 연결 대기 및 응답 수신은 각각 호출자의 사용 가능한 시간의 일부를 소비할 수 있습니다. 이전 대기를 제외하는 요청 시간 초과는 전체 작업에 대해 잘못된 인상을 줄 수 있습니다. 반대로, 모든 단계에서 독립적으로 관대하게 허용하면 사용자가 직면한 약속보다 훨씬 더 전반적인 지연이 발생할 수 있습니다. 설계에는 원격 호출이 시작되기 전과 시도 사이에 소요된 시간을 포함하여 경과 시간에 대한 일관된 설명이 필요합니다. 중요한 경계는 구성하기 가장 쉬운 타이머가 아니라 전체 작업입니다.

가상 서비스에서 내부 클라이언트가 20초 동안 지속되도록 허용되는 동안 표시되는 페이지가 5초 후에 대기를 중지한다고 상상해 보세요. 이러한 값은 권장되는 설정이 아닙니다. 소유권 문제가 노출됩니다. 해당 기간 동안 서비스는 원래 독자가 이미 떠난 요청을 처리할 수 있습니다. 페이지가 새로운 작업을 제출하면 이전 작업과 새 작업이 경쟁합니다. 취소가 전파되는 경우 수신 구성 요소는 안전하게 취소할 수 있는 항목을 정의해야 합니다. 네트워크 대기를 중지하는 것과 커밋된 트랜잭션을 실행 취소하는 것은 동일한 기능이 아닙니다. 마감일은 결과를 되돌리지 않고 결과의 유용성을 종료할 수 있습니다.

결과적으로 첫 번째 중단 지점은 소유자가 있는 기한입니다. 구성 요소는 작업의 남은 시간이 얼마나 소요될 수 있는지, 다른 시도가 해당 내부에서 그럴듯하게 완료될 수 있는지, 해당 시간이 소진되면 어떤 일이 발생하는지 알아야 합니다. 대답은 명백한 실패, 상태 참조와 함께 유지된 비동기 작업 또는 불완전으로 표시된 결과일 수 있습니다. 동일한 작업을 다른 무제한 재시도 루프로 보이지 않게 전송해서는 안 됩니다. 복구 정책은 작업의 실제 제약 내에서 유효한 결과의 가능성을 높일 때 유용합니다.

Amazon의 엔지니어링 지침에서는 시간 초과, 백오프, 지터 및 시간 초과된 호출로 인해 이미 부작용이 발생하는 위험에 대해 설명합니다. Microsoft는 관련된 재시도 폭풍 방지 패턴에 대해 설명합니다. 즉, 자주 시도하면 문제가 있는 서비스가 복구되지 않을 수 있습니다. 이러한 소스는 이 문서의 특정 숫자를 검증하기보다는 광범위한 메커니즘을 지원합니다. 다음의 설계 추론은 해당 메커니즘을 의도적으로 단순화된 서비스에 적용하여 결과를 계속 검사할 수 있도록 합니다. [1] [2]

2. 곱셈은 팀 간에 발생합니다.

세 번의 시도는 겸손하게 들립니다. 각각 총 3번의 시도를 허용하는 3개의 레이어는 상당히 다를 수 있습니다. 모든 외부 시도가 모든 내부 시도를 유발하고 어느 것도 조기에 성공하지 못한다는 특정 최악의 가정 하에서 가장 깊은 종속성은 하나의 원래 작업에 대해 27번의 시도를 받을 수 있습니다. 이는 모든 실패가 자동으로 해당 횟수를 생성한다는 주장이 아니라 호출 계층 구조 전체에 걸친 곱셈입니다. 취소, 기한, 조기 성공, 회로 상태 및 재시도의 실제 소유권으로 인해 이를 줄일 수 있습니다. 계산의 요점은 각 구성 요소를 독립적으로 검토할 때 놓치기 쉬운 상호 작용을 노출하는 것입니다.

여기서 용어가 중요합니다. 3번의 재시도로 설명된 설정은 원래 시도에 3번이 더 추가된 것을 의미할 수 있는 반면, 3번의 시도에는 원래 시도가 포함됩니다. 이러한 정의를 혼동하면 구현 세부 사항이 입력되기 전에 계산이 변경됩니다. 아키텍처 논의에서는 각 경계에서 허용되는 총 시도 수를 기록하고 이를 시작하는 구성 요소를 식별해야 합니다. 또한 클라이언트 라이브러리, 게이트웨이 및 인프라에서 제공하는 동작도 포함되어야 합니다. 애플리케이션 코드만 표시하는 다이어그램에서는 트래픽을 지배하는 재시도 메커니즘을 생략할 수 있습니다. 호출자로부터 결함을 숨기는 구성 요소는 여전히 시스템 작업 부하에 영향을 미칩니다.

조직적인 원인은 이해할 수 있습니다. 각 팀은 짧은 중단을 견딜 수 있는 자체 서비스를 원합니다. 공유 라이브러리는 표준 정책을 채택합니다. 게이트웨이는 또 다른 보호 계층을 추가합니다. 작업자는 예외를 메시지를 포기하고 다시 수신하는 이유로 처리합니다. 이러한 선택 중 어느 것도 부주의할 필요가 없습니다. 정책이 예산을 공유하지 않고 종속성을 공유하기 때문에 실패가 발생합니다. 지역 탄력성은 집단적 낙관주의가 되었습니다. 모든 참가자는 또 다른 시도가 저렴하다고 가정하는 반면, 비즈니스 운영이 생성할 수 있는 총 시도 횟수에 대해 책임을 지는 참가자는 없습니다.

개구부의 방사형 다이어그램을 보면 이를 확인할 수 있습니다. 해당 링은 의도적으로 제한된 모델에서 하나의 원래 작업과 3, 9, 27개의 가능한 다운스트림 시도를 나타냅니다. 링은 측정된 트래픽이 아니며 해당 영역은 성능 추정치가 아닙니다. 이는 또 다른 직사각형 애플리케이션 환경을 그리지 않고 분기 가정을 검사하는 방법입니다. 밖으로 나가면 하나의 의도를 따르고 새로운 작품이 어디서 만들어지는지 물어보세요. 여러 계층이 독립적으로 확장할 수 있는 경우 최종 클라이언트의 최대 재시도 횟수만 검토하면 전체 경로가 부과할 수 있는 최대 로드가 설정되지 않습니다.

한 가지 실용적인 대응은 애플리케이션이 작업을 판단할 만큼 충분한 컨텍스트를 갖고 있는 경계에서 재시도 소유권을 명시적으로 만드는 것입니다. 그렇다고 해서 모든 시스템이 모든 복원력 논리를 한 곳에 집중시켜야 한다는 의미는 아닙니다. 애플리케이션이 더 긴 작업을 관리하는 동안 전송은 끊어진 연결을 합리적으로 복구할 수 있습니다. 요구 사항은 결합된 동작을 이해하고 제한하는 것입니다. 하위 계층은 상위 계층이 작업 허용량을 모두 소진했다고 판단한 후에 전체 비즈니스 작업을 자동으로 다시 시작해서는 안 됩니다. 재연결, 재전송, 재실행 사이의 경계는 설계와 관찰 모두에서 가시화되어야 합니다.

재시도 예산은 요청당 최대값을 초과하는 두 번째 제한을 추가합니다. 애플리케이션은 장애 발생 시 발생하는 추가 작업의 총량을 제한할 수 있습니다. 회계 단위는 요청, 동시 시도, 경과 시간, 가중 비용 또는 조합 등 의도적으로 선택해야 합니다. 값싼 캐시 읽기와 값비싼 보고서가 반드시 교환 가능한 토큰은 아닙니다. 메커니즘은 예산이 비어 있을 때 어떤 일이 발생하는지 정의해야 합니다. 거부된 재시도를 개인 대기열로 옮기기만 하면 압력을 유지하면서 원래 제한자로부터 이를 숨길 수 있습니다. 유용한 예산은 제한된 자원에 도달하는 행동을 변화시킵니다.

그러한 예산을 정확하게 만드는 보편적인 비율은 없습니다. 사용 가능한 복구 용량, 종속성 계약, 작업 값 및 실패 동작이 다릅니다. 서비스는 지속적인 오류가 발생하는 동안 비용이 많이 드는 작업을 늘리는 것을 거부하면서 짧은 일시적 오류에 대해 좁은 허용치를 예약할 수 있습니다. 또 다른 경우는 적격 작업을 별도로 제어되는 백그라운드 프로세스로 연기할 수도 있습니다. 중요한 것은 시스템이 스트레스를 받을 때, 성공이 거의 없을 때, 여러 호출자가 함께 실패할 때 정책이 의미를 유지한다는 것입니다. 예산 보충이 성공 여부에 달려 있는 경우 우발적인 폐쇄나 무제한 긴급 재정의보다는 성공률이 낮은 기간에 대한 명시적인 해석이 필요합니다.

실패한 시도는 새로운 사업 지시가 아니다

쓰기 가능 서비스의 경우 작업의 ID는 시도 후에도 유지되어야 합니다. 클라이언트가 동일한 의도를 다시 보낼 때마다 새로운 비즈니스 식별자를 생성하는 경우 수신자는 요청을 다른 작업으로 합리적으로 처리할 수 있습니다. 연결된 콘텐츠를 확인하지 않고 식별자를 재사용하는 경우 동일한 키가 실질적으로 다른 변경 사항에 연결될 수 있습니다. 따라서 멱등성 설계에는 요청 ID라는 필드 이상의 것이 필요합니다. 범위, 의도한 작업과의 관계, 보존 기간 및 호환되지 않는 콘텐츠와 함께 반복되는 식별자가 도착하는 경우 정의된 응답이 필요합니다.

결과 기록도 그만큼 중요합니다. 수신자가 완료된 작업을 식별할 수 있지만 그 결과를 복구할 수 없는 경우 중복 실행이 방지되더라도 호출자는 여전히 불확실할 수 있습니다. 서비스는 이전 결과를 반환할 수 있는지, 상태 참조를 제공할 수 있는지 또는 조사를 요구할 수 있는지 결정해야 합니다. 올바른 배열은 작업 및 정보 처리 요구 사항에 따라 다릅니다. 일반적인 구별은 안정적입니다. 오래된 명령을 인식하고, 다른 효과를 방지하고, 기존 효과를 설명하는 것은 관련 기능이지만 동일한 메커니즘에 의해 자동으로 전달되지는 않습니다.

3. 대기실은 수용력을 창출하지 않습니다.

대기열을 사용하면 워크로드를 더 쉽게 제어할 수 있습니다. 이는 수용과 실행을 분리하고 소비자에게 지속 가능한 속도로 작업을 처리할 수 있는 기회를 제공합니다. 또한 서비스가 이행할 수 없는 점점 커지는 약속을 숨길 수도 있습니다. 따라서 대기열 깊이는 성공 지표도 아니고 그 자체에 대한 설명도 아닙니다. 10개의 느린 보고서가 포함된 대기열은 수천 개의 작은 업데이트가 포함된 대기열보다 더 많은 작업을 나타낼 수 있습니다. 긴급 요청의 짧은 대기열은 이미 너무 오래되었을 수 있습니다. 유용한 관찰은 백로그를 서비스 비용, 완료 용량 및 결과가 비즈니스 가치를 잃는 시간과 연결합니다.

Microsoft의 대기열 기반 로드 평준화 패턴은 버퍼를 사용하여 수요를 원활하게 하고 다운스트림 처리를 제어해야 하는 필요성을 강조합니다. 서비스에 작업이 제공되면 패턴이 변경됩니다. 처리량을 생산하지 않습니다. 이 경계는 가상의 감속에 적용할 때 중요합니다. 소비자가 용량이 돌아올 때마다 가능한 한 빨리 대기열을 비우면 원래 급증을 다시 생성할 수 있습니다. 자동 크기 조정 소비자가 제한된 종속성에 대한 압력을 증가시키는 경우 대기열은 오버로드를 해결하기보다는 이동한 것입니다. 버퍼에서 방출되는 양에는 자체 운영 한도가 필요합니다. [3]

차트는 의도적으로 단순한 유동 모델을 사용합니다. 원래 수요는 초당 80작업 단위입니다. 처리 용량은 처음 120초 동안 60으로 감소한 다음 100으로 돌아옵니다. 각 단위에는 동일한 가정 비용이 있습니다. 초기 백로그는 0이고 스토리지는 이 계산에 제한 효과가 없으며 작업이 만료되거나 영구적으로 실패하지 않습니다. 이러한 가정은 산술을 투명하게 만듭니다. 실제 브로커, 데이터베이스, 네트워크 또는 애플리케이션의 전체 동작을 설명하지 않습니다. 목적은 증폭된 시도 작업량이 계속해서 뒤쳐지는 동안 변하지 않은 비즈니스 작업량을 어떻게 복구할 수 있는지 보여주는 것입니다.

이 모델링된 대기열에 추가 시도 트래픽이 허용되지 않으면 속도가 느려지는 동안 초당 20개의 장치가 누적됩니다. 2분 후 백로그는 2,400개가 됩니다. 새로운 수요가 80으로 유지되는 동안 용량이 100으로 돌아가면 서비스에는 초당 20단위의 예비 처리 용량이 있게 됩니다. 따라서 백로그를 지우는 데 2분이 더 걸립니다. 대기열은 시작부터 240초 후에 비어 있습니다. 즉각적인 용량 반환 시에는 복구가 발생하지 않습니다. 서비스는 먼저 도착보다 느린 동안 수락한 작업을 상환해야 합니다.

이제 표시된 간격 전체에 걸쳐 초당 가정된 40개의 시도 단위를 추가합니다. 이는 특정 재시도 알고리즘에 대한 예측이 아니라 민감도 사례입니다. 감속 중에는 도착 수가 120 대 60이 되므로 2분 기준으로 7,200개가 누적됩니다. 수용 인원이 100명으로 돌아온 후에도 도착 건수는 여전히 완료 건수를 20건 초과합니다. 6분이 지나면 잔고가 소진되지 않고 12,000개에 도달합니다. 이 비교에서 추가 수요는 그 효과를 분리하기 위해 일정하게 유지됩니다. 실제 재시도 인구는 마감일, 백오프, 성공적인 완료 및 애플리케이션이 적용되는 제어에 따라 변경됩니다.

두 추적은 동일한 규칙으로 계산됩니다. 백로그는 음수일 수 없으며 승인된 작업에서 완료된 작업을 뺀 값으로 변경됩니다. 서로 다른 결과가 모든 재시도가 해롭다는 것을 증명하지는 않습니다. 짧은 독립 실패 후에 잘 선택된 시도는 귀중한 작업을 복구할 수 있습니다. 추적은 사용 가능한 용량에 대해 시도를 평가해야 하는 이유를 보여줍니다. 제한된 서비스가 추가 로드를 처리할 수 없는 경우 지속성이 높아지면 아무도 적시에 결과를 받지 못하는 기간이 길어질 수 있습니다. 추가 트래픽을 줄이는 것은 기본 종속성이 여전히 복구되는 동안에도 복구 작업이 될 수 있습니다.

제공되는 부하와 허용되는 부하의 구별은 필수적입니다. 제한자는 많은 수의 요청을 볼 수 있지만 일부만 작업 대기열에 들어가도록 허용합니다. 거부된 시도는 경계에서 여전히 비용이 들기 때문에 허용 경로는 압력을 받고 작동할 수 있을 만큼 저렴해야 합니다. 단지 거부 여부를 결정하기 위해 비용이 많이 드는 동일한 종속성 호출을 수행해서는 안 됩니다. 동시에 값싼 거부는 완료된 고객 작업이 아닙니다. 서비스는 대기열 증가의 명백한 감소가 성공적인 이행으로 오인되지 않도록 요구, 허용, 거부 및 유용한 완료를 별도로 관찰해야 합니다.

대기열 사용 기간은 누락된 시간 차원을 추가합니다. 특정 보고서가 의사결정 회의 전에만 유용하다고 가정해 보겠습니다. 회의 후에 이를 처리하는 것은 시스템이 결국 성공을 보고하더라도 별 가치가 없을 수 있습니다. 해당 작업을 무기한 유지하면 여전히 중요한 새로운 작업이 지연될 수 있습니다. 그러나 만료는 차트 개선을 위해 작업을 조용히 삭제하는 것이 아니라 가시적인 결과가 있는 비즈니스 결정이어야 합니다. 호출자는 요청이 완료를 위해 승인되었는지, 거부되었는지, 대체되었는지 또는 만료가 허용되었는지 알아야 합니다. 계약을 포기하여 얻은 안정적인 대기열은 복구된 서비스가 아닙니다.

동일한 추론으로 인해 우선순위가 복잡해집니다. 긴급한 작업에 우선순위를 부여하면 중요한 결과를 보호할 수 있지만 긴급한 작업이 영구적으로 계속되면 다른 모든 작업이 중단될 수 있습니다. 테넌트, 운영 및 워크로드 클래스 간의 공정성을 위해서는 명시적인 정책이 필요합니다. 단일 글로벌 선입선출 큐는 격리가 좋지 않으면서 작동하기 쉬울 수 있습니다. 다수의 작은 대기열은 모니터링 및 예약 복잡성을 증가시키면서 분리를 개선할 수 있습니다. 유용한 선택은 부족한 자원을 공유하는 당사자가 누구인지, 전체 수요를 즉시 충족할 수 없을 때 조직이 방어할 수 있는 약속이 무엇인지에 따라 달라집니다.

4. 과부하가 빌릴 수 없는 경계를 구축하십시오.

아이소메트릭 뷰는 승인, 대기, 활성 실행, 다운스트림 종속성이라는 네 가지 문제를 하나의 서비스 상자로 압축하는 경우가 많습니다. 각 계층에는 서로 다른 희소 자원이 있습니다. 입학경로는 빠른 결정을 내려야 합니다. 버퍼에는 유한한 저장 공간과 연령 분포가 있습니다. 작업자는 메모리, 연결 슬롯 및 실행 시간을 소비합니다. 종속성에는 자체 용량과 권한 경계가 있습니다. 이러한 레이어를 표시하면 작업자 수를 늘리는 것이 전체 서비스 용량을 늘리는 것과 같지 않은 이유를 설명하는 데 도움이 됩니다. 다음 레이어가 무제한 공유 풀에서 빌릴 때 한 레이어의 제한이 무효화될 수 있습니다.

적절한 수의 활성 작업으로 제한되지만 각 작업이 많은 동시 다운스트림 호출을 열 수 있도록 허용하는 작업자를 예로 들어 보겠습니다. 최상위 수준 제한이 책임 있는 것처럼 보이지만 중요한 리소스는 그 아래에서 배가됩니다. 기본 작업이 실제로 종속성 사용을 중지하기 전에 시간 초과로 인해 애플리케이션 수준 허용이 해제되는 경우에도 동일한 문제가 발생합니다. 리미터는 리소스가 다른 항목에 대해 비용을 지불하는 동안 한 항목을 계산합니다. 설계에는 허가 취득 시점, 허가 대상 작업, 허가 공개를 정당화하는 관찰 사항이 명시되어야 합니다.

관련되지 않은 작업이 가장 느린 종속성으로 인해 모든 용량을 잃어서는 안 되기 때문에 격리는 유용합니다. 별도의 풀 또는 동시성 허용을 통해 실패한 통합이 정상적인 통합에 필요한 리소스를 점유하는 것을 방지할 수 있습니다. 이것은 무료가 아닙니다. 다른 파티션이 사용 중인 동안 파티션은 용량을 유휴 상태로 둘 수 있으며, 파티션이 너무 많으면 시스템 조정이 어려워질 수 있습니다. 이 값은 보다 예측 가능한 실패 경계입니다. 모든 기능에 대해 별도의 대기열과 스레드 풀을 생성하기 위한 범용 명령으로 격벽을 제시하기보다는 어떤 작업 부하가 서로 영향을 미칠 수 있는지에 대한 선택을 설명해야 합니다.

회로 차단기는 재시도 정책과 다른 결정을 내립니다. 실패할 가능성이 충분히 있는 리소스에 대한 시도를 일시적으로 중지하고 제어된 프로브가 복구를 평가하도록 허용할 수 있습니다. Microsoft의 패턴은 이러한 분리를 설명합니다. 가상 서비스의 경우 흥미로운 질문은 차단기 주변에서 어떤 일이 발생하는지입니다. 즉, 차단된 시도가 재시도 예산을 소비하는지, 대체 작업이 동일한 실패한 종속성을 사용하는지, 프로브 모집단이 모든 인스턴스에 걸쳐 제한된 상태로 유지되는지 여부입니다. 아키텍처 다이어그램에 그려진 차단기는 그 자체로 주변 동작을 설정하지 않습니다. [4]

폴백은 실수로 상황을 악화시킬 수 있습니다. 캐시 미스가 모든 요청을 원래 종속성으로 보내는 경우 탄력성이 있는 캐시 경로는 적중률이 낮은 기간 동안 로드를 집중시킬 수 있습니다. 대체 공급자의 할당량이 더 낮은 경우 모든 발신자를 한 번에 전환하면 사건을 전달할 수 있습니다. 저하된 답변을 계산하는 데 비용이 많이 드는 경우 유용할 만큼 충분한 용량을 유지하지 못할 수 있습니다. 대체는 자체 종속성 및 정확성 조건이 있는 또 다른 워크로드로 평가되어야 합니다. 그 이름은 실패한 기본 경로의 규모에서 더 저렴하고 안전하거나 사용 가능하다는 증거가 아닙니다.

오래된 정보가 허용되지 않는 작업도 있습니다. 눈에 보이는 타임스탬프가 포함된 오래된 정보 결과를 반환하는 것은 일부 독자에게는 합당한 성능 저하를 초래할 수 있습니다. 이전 승인 결정을 사용하거나 오래된 비즈니스 상태를 현재 상태로 제시하는 것은 다른 위험이 될 수 있습니다. 애플리케이션은 결과의 어느 부분이 저하될 수 있는지, 해당 조건이 어떻게 전달되는지, 어떤 작업을 거부해야 하는지 결정해야 합니다. 불확실성을 숨겨 가용성을 유지하면 오류율 대시보드가 ​​더 좋아 보이더라도 비즈니스에 피해를 줄 수 있습니다. 실패 응답에서는 서비스가 알고 있는 내용에 대한 진실한 설명을 보존해야 합니다.

Google의 과부하 처리에서는 저하된 응답과 축소된 응답도 제공할 수 없는 경우 작업을 거부해야 하는 필요성에 대해 논의합니다. 이는 패배주의적으로 들릴 수 있는 디자인 선택에 유용한 컨텍스트를 제공합니다. 일부 요청을 거부하면 다른 요청을 완료하는 능력이 보호될 수 있습니다. 가상 서비스에 대한 비즈니스 우선순위를 선택하지 않습니다. 이러한 우선 순위에는 대기할 수 있는 작업, 성능이 저하될 수 있는 작업, 빠르게 실패해야 하는 작업에 대한 명시적인 계약이 필요합니다. 그러면 기술 메커니즘은 단순히 문서에 기록하는 것이 아니라 해당 계약을 시행해야 합니다. [5]

5. 백오프 변경 타이밍; 지터는 회사를 변화시킨다

두 클라이언트가 개별적으로 감지할 수 있는 지연을 겪으면서도 함께 도착할 수 있습니다. 많은 인구가 동시에 실패하고 모든 구성원이 동일한 간격을 기다리는 경우 다음 물결은 동기화된 상태를 유지할 수 있습니다. 지연이 증가하면 각 파동의 구성원을 반드시 분산시키지 않고 파동 사이의 간격이 변경됩니다. 지터는 타이밍에 변화를 가져옵니다. 중요한 아이디어는 공식에 장식적으로 추가되는 무작위성이 아닙니다. 그것은 하나의 조화로운 폭발로 반복적으로 나타나는 회복 인구를 피하는 것입니다. 필요한 배포 및 범위는 프로토콜, 마감일 및 관찰된 작업량에 맞아야 합니다.

지수 백오프 및 지터에 대한 AWS 논의는 결정적 재시도 타이밍이 작업 클러스터를 떠날 수 있는 이유를 보여줍니다. 이는 다른 서비스에 대한 범용 매개변수 선택이 아닌 타이밍 메커니즘을 지원합니다. 가상 애플리케이션에서는 임의 지연이 길어지면 시도가 분산될 수 있지만 일부는 호출자의 유용한 기한을 초과할 수도 있습니다. 더 짧은 범위는 마감일에 맞을 수 있지만 동기화를 줄이기 위해 너무 적은 작업을 수행할 수 있습니다. 디자인에는 두 가지 제약 조건이 모두 필요합니다. 선택한 알고리즘 이름을 생성된 모든 지연이 작업에 적합하다는 증거로 취급해서는 안 됩니다. [6]

재시도 루프에는 응답 해석도 필요합니다. 인증 실패, 거부된 비즈니스 규칙 및 임시 용량 제한은 동일한 동작을 요구하지 않습니다. 변경되지 않은 유효하지 않은 요청을 반복하면 일반적으로 요청을 유효하지 않게 만든 정보를 복구할 수 없습니다. 제한 응답은 타이밍 지침을 제공할 수 있지만 호출자는 여전히 자체 기한과 총 허용량을 존중해야 합니다. 연결 실패로 인해 실행이 불확실해질 수 있습니다. 분류는 모든 예외에 다른 시도 횟수를 할당하는 조회가 아니라 작업에 대한 결정으로 이어져야 합니다.

시도 일정에는 유용한 작업을 수행하고, 응답을 기다리고, 다음 시도를 기다리는 데 소요된 시간이 포함되어야 합니다. 지연 시간이 별도로 나열되면 정책이 짧아 보일 수 있지만 실행이 포함되면 작업의 전체 허용 시간을 초과할 수 있습니다. 또한 애플리케이션에서 허용하는 경우 중복 시도도 고려해야 합니다. 병렬 추측은 때때로 대기 시간을 줄일 수 있지만 이를 위해 추가 용량을 소비합니다. 과부하 상태에서는 트레이드 오프가 특히 비용이 많이 들 수 있습니다. 조직은 서비스가 언제 그러한 선택을 하는지, 어떤 작업이 적격인지, 무엇이 추가 작업을 중지하는지 알아야 합니다.

일정이 동기화의 유일한 소스는 아닙니다. 정기적인 폴링, 토큰 새로 고침, 예약된 배치 시작 및 공유 이벤트 후 다시 시작되는 일련의 프로세스는 모두 활동을 집중시킬 수 있습니다. 따라서 명시적 재시도 루프가 개선된 후에도 가상의 중단이 다시 발생할 수 있습니다. 유용한 조사에서는 워크로드 전체에서 어떤 시계가 공유되는지, 어떤 시계가 트리거하는 비용이 많이 드는 작업이 무엇인지 묻습니다. 백그라운드 작업을 분산시키는 것이 도움이 될 수 있지만 마감일, 업무 시간 및 외부 서비스 창구로 인해 이러한 자유가 제한될 수 있습니다. 올바른 솔루션은 예약된 작업의 목적을 유지하면서 관련 도착 패턴을 변경합니다.

다시 버튼을 누른 발신자

사람들은 또 다른 재시도 계층이 될 수 있습니다. 요청 수락 여부를 설명하지 않고 회전하는 화면은 다시 제출을 요청합니다. 비활성화된 버튼은 우발적인 중복을 줄일 수 있지만 응답이 손실된 후 서버의 상태를 설정할 수는 없습니다. 지속 가능한 작업 참조와 명확한 상태 보기를 통해 독자는 다른 요청을 생성하는 대신 첫 번째 요청을 검사할 수 있습니다. 인터페이스는 승인된 작업을 기다리는 것과 서버에 새 작업을 시작하도록 요청하는 것을 구별해야 합니다. 긴 비동기 프로세스 앞에 짧은 대화형 마감일이 있을 때 이러한 구별은 특히 중요합니다.

소프트웨어가 약속을 하기 때문에 표현이 중요합니다. 결과를 알 수 없을 때 요청이 실패했다고 말하는 것은 처리가 승인되었고 해당 상태가 확인되고 있다고 말하는 것과 다른 작업을 장려합니다. 두 메시지 모두 시스템이 갖고 있지 않은 확실성을 주장해서는 안 됩니다. 또한 상태 보기는 사고 중에 통제되지 않은 폴링 소스가 되는 것을 방지해야 합니다. 간격 선택, 적절한 상태 캐싱, 반복 새로 고침 제한은 동일한 용량 설계의 일부입니다. 유용한 사용자 경험은 사람들이 불확실성을 또 다른 일의 물결로 바꾸지 않고도 의도를 회복하는 데 도움이 됩니다.

6. 복구 트래픽에는 집으로 돌아가는 경로가 필요합니다.

대기열 기반 서비스에는 또 다른 차이점이 있습니다. 성공적인 처리와 성공적인 승인은 별도의 이벤트입니다. 브로커가 메시지를 제거할 수 있다는 사실을 알기 전에 비즈니스 효과가 완료될 수 있습니다. 승인이 손실되면 시스템에서 메시지를 다시 볼 수 있습니다. Azure Service Bus는 전송, 잠금 및 정산을 별도의 배달 부분으로 문서화합니다. 구조적 결과는 메시지의 처리 ID를 비즈니스 운영에 연결하고 반복되는 전달을 의도적으로 처리하는 것입니다. 배달 횟수 임계값을 늘려도 반복 실행이 안전하다는 보장은 없습니다. [7]

또한 작업자는 반복을 통해 유효하지 않은 작업을 인식해야 합니다. 잘못된 페이로드, 지원되지 않는 작업 버전 또는 영구적으로 누락된 필수 구성 요소에는 수정이나 조사가 필요할 수 있습니다. 무기한으로 활성 대기열로 되돌리면 성공 가능성이 높아지지 않고 용량이 소모될 수 있습니다. 별도의 오류 경로를 통해 일반 워크로드를 계속 이동할 수 있지만 해당 경로에는 소유자와 가시적인 결과가 필요합니다. 내용이 전혀 검사되지 않은 배달 못한 편지 큐는 복구 전략이 아닙니다. 이는 주요 처리량 차트 외부에 있는 해결되지 않은 약속의 축적입니다.

Microsoft의 Service Bus 배달 못한 편지 문서에서는 보조 하위 대기열의 역할과 해당 메시지를 처리하는 애플리케이션의 필요성에 대해 설명합니다. 가상 서비스에 대한 중요한 선택은 다시 제출하기 전에 일어나는 일입니다. 팀은 근본적인 결함이 수정되었는지, 원래 비즈니스 의도가 여전히 유효한지, 이전 시도로 인해 이미 효과가 발생했는지 여부를 확인해야 합니다. 이러한 질문을 건너뛰는 대량 재생은 오래된 불확실성을 새로운 부하로 전환할 수 있습니다. 복구 절차에서는 저장된 모든 메시지를 다시 실행해도 안전한 것으로 처리하는 대신 작업을 선택할 수 있어야 합니다. [8]

용량이 회복되면 실시간 수요와 과거 복구 작업이 경쟁합니다. 사용 가능한 최대 속도로 모든 기존 작업을 소모하는 서비스는 현재 사용자에게 두 번째 중단을 초래할 수 있습니다. 새로운 작업을 위해 모든 것을 예약하는 서비스는 백로그를 결코 지울 수 없습니다. 따라서 복구 작업의 릴리스 속도는 실제 여유 용량 및 비즈니스 우선순위와 연계된 정책이 필요합니다. 종속성의 동작이 변경됨에 따라 조정될 수 있습니다. 중요한 점은 복구는 일반 트래픽에 적용되는 제한에서 면제되는 특별한 범주가 아니라 그 자체로 작업 부하라는 것입니다.

회복 결정에도 중지 조건이 있습니다. 대기 시간이 증가하거나, 가장 오래된 라이브 요청이 유효 기간을 초과하거나, 중복 검색에서 예상치 못한 패턴이 발견되거나, 종속성이 다시 제한되기 시작하면 재생을 일시 중지해야 할 수 있습니다. 관련 신호는 서비스에 따라 다릅니다. 중요한 것은 오래된 작업을 릴리스하는 사람이나 메커니즘이 이를 관찰하고 버퍼가 또 다른 급증의 원인이 되기 전에 조치를 취할 수 있다는 것입니다. 피드백 경로가 없는 재생 명령은 지속성을 제공하지만 그 결과에 대한 통제력은 거의 없습니다.

출처를 보존하면 피드백이 더욱 유용해집니다. 첫 번째 제출, 이후 시도, 대기열 전달 및 수동 수정 전반에 걸쳐 작업을 추적할 수 있어야 합니다. 이를 달성하기 위해 식별자가 민감한 콘텐츠를 노출할 필요는 없습니다. 비즈니스 의도에 대한 안정적인 관계와 각 시도가 실행된 정책을 설명하기에 충분한 구성 컨텍스트가 필요합니다. 연속성이 없으면 팀은 하나의 완고한 작업을 검토할지, 많은 새로운 요청을 검토할지, 아니면 두 가지를 혼합하여 검토할지 결정하면서 사고 대응에 시간을 투자할 수 있습니다. 추가 로깅 볼륨은 필요한 이해를 제공하지 못한 채 또 다른 리소스 압박이 됩니다.

7. 현재 진행 중인 작업을 찾아보세요

서비스는 바쁜 동시에 이용 가능하면서도 도움이 되지 않을 수 있습니다. CPU, 연결 사용률 및 요청 속도는 활동을 설명하고 유용한 완료는 진행 상황을 설명합니다. 두 카테고리 모두 다른 카테고리를 대체하지 않습니다. 흥미로운 관찰은 그들이 어떻게 갈라지는가이다. 고유한 완료된 작업이 감소하는 동안 시도가 증가하면 서비스는 더 적은 것을 달성하기 위해 더 많은 비용을 지출할 수 있습니다. 작업 중 더 많은 부분이 거부되었기 때문에 대기 시간이 개선된다면 애플리케이션은 여전히 ​​많은 판독기에 실패하면서 리소스를 보호했을 수 있습니다. 운영 관점에서는 더 안심할 수 있는 이야기를 전달하는 측정항목을 선택하기보다는 두 가지 사실을 모두 가시화해야 합니다.

분모는 재시도하는 애플리케이션에 특히 중요합니다. 시도 수준 성공률은 작업당 시도 횟수에 따라 왜곡될 수 있습니다. 사용자 수준 완료율은 각 성공을 달성하는 데 필요한 리소스 소비량을 숨길 수 있습니다. 유용한 대시보드는 원래 수요, 총 시도 횟수, 승인된 작업, 고유하게 완료된 작업, 유용한 완료 시간 및 불확실한 결과를 구분합니다. 또한 이러한 차이가 결정에 영향을 미치는 연령 및 작업 부하 등급도 표시됩니다. 이러한 측정은 다양한 질문을 설명합니다. 이를 수집하는 것은 팀이 변경 사항을 작업에 연결할 수 있는 경우에만 유용합니다.

하나의 진단 비율은 원래 작업당 종속성 호출을 시도하는 것입니다. 또 다른 하나는 시작 기한이 이미 만료된 작업에 소요되는 실행 시간이 부족하다는 것입니다. 어느 쪽도 보편적인 서비스 수준 목표로 취급되어서는 안 됩니다. 이는 의심되는 메커니즘을 눈에 띄게 만드는 방법입니다. 무해한 연결 복구를 추가 비즈니스 실행으로 간주하거나 의도적인 비동기 작업을 중단된 작업으로 간주하지 않도록 정의가 충분히 정확해야 합니다. 이 측정값은 사건 대시보드에 또 다른 매력적인 라인을 제공할 때가 아니라 설명을 구별할 때 가치가 있습니다.

비용은 관찰의 일부입니다. 추가 시도로 인해 추가 비즈니스 작업을 완료하지 못하더라도 요청 요금, 로깅 볼륨, 연결 이탈 또는 컴퓨팅 소비가 증가할 수 있습니다. 재시도로 분모가 커지면 요청당 비용이 개선되는 것처럼 보일 수 있지만 유용한 결과당 비용은 악화됩니다. 조직에는 실패하고 반복되는 노력을 포함할 만큼 작업을 추적하는 비용 보기가 필요합니다. 여기서는 절감액이 청구되지 않습니다. 요점은 단순히 다른 서비스나 청구서로 이동하는 것보다 제안된 복원력 변경이 낭비를 줄이는지 여부를 나타내는 회계 경계를 선택하는 것입니다.

루프뿐만 아니라 체인도 테스트해 보세요

단위 테스트에서 성공적인 재시도는 상관 오류가 발생한 플릿에 대해 거의 정보를 제공하지 않습니다. 보다 공개적인 제어 테스트는 원래 수요를 식별 가능하게 유지하면서 종속성의 대기 시간 또는 완료 용량을 변경합니다. 시도 증폭이 제한된 상태로 유지되는지, 마감 기한이 의도한 대로 작동하는지, 교란 후 유용한 처리량이 회복되는지 여부를 관찰합니다. 환경과 한계에 따라 해당 테스트가 안전해져야 합니다. 목표는 강인함을 입증하기 위해 통제되지 않은 생산 사고를 일으키지 않는 것입니다. 많은 호출자가 함께 실패할 때 추가 시도가 여전히 도움이 된다는 구체적인 가정에 도전하는 것입니다.

시나리오에서는 느린 응답, 확실한 거부, 알 수 없는 결과를 구별해야 합니다. 호출자의 최종 기한 전에 복구되는 종속성과 그렇지 않은 종속성을 포함해야 합니다. 대기열 기반 서비스는 또한 승인 불확실성, 만료된 작업 및 의도적으로 제한된 재생을 실행해야 합니다. 예상되는 결과는 단순히 제출된 모든 작업이 결국 성공하는 것이 아닙니다. 일부 작업은 거부되거나 시도를 중단해야 합니다. 의미 있는 질문은 제한된 리소스가 계속 보호되고 조직이 각 작업 클래스에 발생한 일을 설명할 수 있는 동안 관찰된 결과가 계약과 일치하는지 여부입니다.

비교에는 동일한 원래 수요가 필요합니다. 그렇지 않으면 더 빨리 복구되는 것처럼 보이는 구성이 단지 더 쉬운 작업 부하를 받았을 수도 있습니다. 계정은 결과와 관련된 도착 패턴, 작업 혼합, 종속성 조건 및 구성 버전을 유지해야 합니다. 이 문서의 차트와 같은 계산된 예는 실행 중인 테스트에서 얻은 측정값과 구별되어야 합니다. 마치 벤치마크인 것처럼 그럴듯한 수치적 이야기를 반복하는 것은 증거를 약화시킬 것입니다. 투명한 소형 모델은 매끄러운 선이 생산 흔적과 비슷하기 때문이 아니라 가정이 도전받을 수 있다는 점에서 유용합니다.

8. 시도를 중단할 수 있는 시스템

첫 번째 지연된 요청으로 돌아갑니다. 정전이 될 필요는 없었습니다. 실패 체인은 여러 전환을 통해 그 힘을 얻었습니다. 시간 초과는 더 많은 작업을 시작할 수 있는 권한으로 해석되었습니다. 공통 예산 없이 여러 시도를 시도했습니다. 대기 작업으로 인해 용량 격차가 커졌습니다. 복구 트래픽은 긴급 상황으로 인해 추가 처리량이 발생한 것처럼 처리되었습니다. 각 전환은 체인을 중단할 수 있는 장소를 제공합니다. 디자인에는 가능한 모든 탄력성 패턴이 필요하지 않습니다. 이 서비스가 불확실성을 추가 부하 또는 반복적인 비즈니스 효과로 바꿀 수 있는 지점에 대한 제어가 필요합니다.

또 다른 시도가 딱 맞는 대응인 상황도 있다. 일시적이고 독립적인 실패가 사라질 수도 있고, 안전한 읽기가 다른 경로에서 빠르게 완료될 수도 있고, 제한된 재제출이 귀중한 작업을 복구할 수도 있습니다. 그 주장은 지속성에 반대하는 것이 아닙니다. 작업의 시간, 용량 및 의미에 대한 책임을 유지하는 것은 지속성을 위한 것입니다. 서비스는 시도가 이루어진 이유, 이에 대해 지불된 수당 및 다음 시도를 방해하는 관찰 사항을 설명할 수 있어야 합니다. 이 설명은 안정성을 위해 재시도가 활성화되었다는 일반적인 설명보다 더 유용합니다.

따라서 가장 중요한 복구 기능은 중지 기능일 수 있습니다. 마감일로 인해 결과가 쓸모없게 되면 시도 생성을 중지하세요. 관련 없는 작업에서 용량 차용을 중지합니다. 라이브 서비스에 문제가 발생하기 시작하면 백로그 재생을 중지하세요. 실행 결과를 아직 알 수 없는 경우 확실한 실패 주장을 중지하세요. 이는 서로 다른 결정이며 각각 적절한 소유자나 메커니즘이 필요합니다. 이들은 해결되지 않은 모든 의도를 동일한 과부하 경로를 통해 다시 강제로 되돌리는 대신 기본 종속성을 복구하고 조직이 남아 있는 작업을 수정할 수 있는 공간을 제공합니다.

신뢰할 수 있는 서비스는 영원히 노력할 것을 약속하지 않습니다. 이는 보다 실용적인 약속을 합니다. 받아들인 작업에는 정의된 의미가 있고, 추가 노력에는 한계가 있으며, 실패는 사람들이 이해하고 행동할 수 있는 결과를 낳습니다. 이러한 조건이 유지되면 재시도는 책임 있는 고객이 없는 눈에 보이지 않는 작업 부하가 되는 대신 유용한 도구로 남을 수 있습니다. 그 차이는 회복 중에 가장 분명하게 나타납니다. 원래 결함이 줄어들면 시스템은 유용한 작업을 재개할 수 있도록 자체 동작을 충분히 제어할 수 있습니다.