복원력을 고려한 디자인
 워크로드는 전체 기능 또는 축소된 기능으로 계속 작동해야 합니다. |
|---|
구성 요소 오작동, 플랫폼 중단, 성능 저하 및 기타 오류가 발생할 것으로 예상됩니다. 내결함성이 있고 정상적으로 성능이 저하될 수 있도록 시스템에 복원력을 빌드합니다.
예제 시나리오
Contoso Air는 내부 개발 부서가 있는 상업 항공사입니다. 기본 LOB 애플리케이션이 고객이 Contoso Air를 통해 직접 항공편을 예약할 수 있는 예약 솔루션입니다. 이 앱은 Azure에 빌드되었으며 Azure App Service, Cosmos DB, Azure Functions, Azure Logic Apps 및 Azure Service Bus를 사용합니다.
실패 위험 결정
시스템, 특히 중요한 구성 요소의 잠재적인 오류 지점을 식별하고 사용자 및 시스템 흐름에 미치는 영향을 판단합니다.
잠재적인 오류 지점별 오류 사례, 폭발 반경, 오류 강도를 분석합니다. 오류 사례와 그 강도는 백 엔드 프로세스의 일시적 손실과 같은 상대적으로 영향이 적은 시나리오부터 재해로 인한 대규모 중단까지 다양할 수 있습니다. 이 분석을 수행하면 구성 요소 수준에서 오류 처리 기능의 디자인을 결정하는 데 도움이 됩니다.
Contoso의 과제
- LOB 애플리케이션은 마케팅에서 상거래에 이르는 다양한 핵심 함수를 제공합니다. 티켓 구매 사용자 흐름이 가장 중요한 흐름으로 식별되었습니다. 워크로드 팀은 흐름이 복원력을 위해 최적화되도록 보장하기 위해 더 많은 안정성 측정을 구현해야 한다고 결정했습니다.
- 팀은 구성 요소 분리 및 흐름 재디자인과 같은 개선을 위해 예산을 책정했지만 그 시간을 가장 가치 있는 개선에 집중하는 데 사용하려고 합니다.
접근 방식 및 결과 적용
- 팀은 외부 결제 게이트웨이를 잠재적인 실패 지점으로 식별합니다. 게이트웨이는 가용성이 높지만 네트워크 문제 또는 매우 높은 요청 폭증으로 인해 사용자가 가끔 일시적인 오류를 경험할 가능성이 있습니다. 동시에 전송되는 여러 요청으로 인해 게이트웨이가 오버로드되면 게이트웨이가 일부 요청을 거부할 수 있습니다.
- 팀에서는 게이트웨이가 초기 요청을 거부하여 부정적인 사용자 환경을 초래하는 경우 사용자가 요청을 다시 제출해야 한다고 결정합니다.
자체 보존 메커니즘 구현
디자인 패턴을 올바르게 사용하고 디자인을 모듈화하여 결함을 격리함으로써 자체 보존 기능을 빌드합니다.
시스템에 자체 보존 기능을 빌드하면 문제가 다운스트림 구성 요소에 영향을 미치는 것을 방지할 수 있습니다. 시스템은 일시적 및 영구적 오류, 성능 병목 현상 및 안정성에 영향을 미칠 수 있는 기타 문제를 완화할 수 있습니다. 폭발 반경도 최소화할 수 있습니다.
Contoso의 과제
- 팀은 일시적인 오류로 인해 결제 게이트웨이에서 사용자 요청이 거부될 위험을 최소화하려고 합니다. 일부 오류 조건의 일시적인 특성으로 인해 동일한 요청을 다시 제출하면 성공할 가능성이 높습니다.
접근 방식 및 결과 적용
- 팀은 다시 시도 가능한 오류가 검색되면 짧은 지연 후 트랜잭션을 다시 시도하는 흐름의 사용자 지정 논리를 개발합니다.
- 다시 시도 패턴을 통합하도록 솔루션 설계가 수정되어 요청이 성공적으로 처리되거나 최대 실패 횟수에 도달할 때까지 다시 시도 간의 대기 시간이 약간 늘어납니다.
- 또한 팀은 Azure Service Bus의 이벤트 기반 방식을 사용하여 이 흐름의 사용자 상호 작용과 백 엔드 결제 처리 기능을 분리하기로 결정했습니다. 메시지를 처리하는 동안(최대 다시 시도 횟수 이후) 복구할 수 없는 오류가 발생하면 백 엔드 프로세서는 해당 요청 처리를 중단하고 나중에 재처리할 수 있도록 메시지를 큐에 남겨둡니다.
포괄적인 중복성 및 복원력 빌드
다양한 애플리케이션 계층에서 계층 중복성과 복원력을 빌드합니다.
실제 유틸리티의 중복성과 즉각적인 데이터 복제를 목표로 합니다. 또한 서비스, 운영, 인력을 포괄하는 기능 계층의 중복성을 목표로 합니다. 중복성은 단일 실패 지점을 최소화하는 데 도움이 됩니다. 예를 들어, 하나 이상의 구성 요소, 가용성 영역 또는 전체 지역에 영향을 미치는 중단이 있는 경우 중복(활성-활성 또는 활성-수동) 배포를 통해 작동 시간 목표를 충족할 수 있습니다.
매개자를 추가하면 구성 요소 간의 직접적인 종속성을 방지하고 버퍼링이 개선됩니다. 이러한 두 가지 이점 모두 시스템의 복원력을 강화합니다.
Contoso의 과제
- Service Bus를 사용하여 UI에서 다시 시도를 구현하고 결제 게이트웨이 호출을 분리하면 이 흐름의 안정성이 크게 향상되었지만, 비즈니스 관련자는 여전히 주 지역의 치명적인 오류로 인해 발생할 수 있는 데이터 손실에 대해 걱정하고 있습니다.
접근 방식 및 결과 적용
- 팀은 Service Bus 프리미엄 계층으로 업그레이드하기로 결정했습니다. 이렇게 하면 해당 계층의 가용성 영역 지원 기능을 활용할 수 있습니다. 이 기능을 사용하면 데이터의 여러 복사본이 실제로 분리된 3개의 시설(가용성 영역)에 저장되며 서비스는 데이터 센터의 전체적이고 치명적인 손실에 즉시 대처할 수 있는 충분한 용량을 보유하게 됩니다.
- 또한 팀은 주 지역에 완전한 오류가 발생할 가능성이 거의 없는 경우에 사용될 보조 지역에 데이터를 지속적으로 복제하도록 Azure Service Bus 지리적 재해 복구를 구성합니다.