다음을 통해 공유


캐리어 등급 워크로드에 대한 내결함성

통신 회사는 신뢰할 수 없는 요소를 기반으로 실행하는 동시에 통신 사업자 등급 가용성 요구 사항을 충족하고 초과하는 애플리케이션을 구현할 수 있음을 보여주었습니다. 회사는 다음 측면을 포함하는 내결함성을 통해 이러한 요구 사항을 초과합니다.

  • 독립적이고 고가용성이 아닌 요소의 조합입니다.
  • 트래픽 관리 실패 응답 메커니즘.
  • 복구 및 용량 복구 및 실패 응답 메커니즘.
  • 고가용성 요소 간 데이터베이스 사용.

캐리어 등급 안정성 및 복원력을 위해 디자인할 때는 모든 구성 요소가 실패할 수 있고 실패 할 수 있다고 가정합니다. 디자인에는 오류 해결에 대한 계층화된 접근 방식이 필요합니다. 디자인 유효성 검사의 일부는 애플리케이션에 있는 주요 종속성을 명확하게 식별하고 해당 종속성이 자체 SLO(서비스 수준 목표)를 충족하는 경우 애플리케이션이 필요한 가용성을 달성할 수 있음을 보여 주는 다양한 실패 모드의 정량적 확률적 모델을 만드는 것입니다. 테스트 및 라이브 데이터가 모델이 예측하는 것과 일치하도록 개발 후 프로덕션 환경에서 이 모델을 유지하고 지속적으로 유효성을 검사해야 합니다.

조합을 통한 고가용성

고가용성에 도달하려면 고가용성이 없는 독립 요소를 사용하고 독립 엔터티로 유지되도록 결합합니다. 여러 요소가 함께 실패할 확률은 단일 요소의 실패 확률보다 훨씬 낮습니다. 이 프로세스를 공유 없음 아키텍처 스타일로 정의합니다.

트래픽 관리 실패 응답

개별 요소가 실패하거나 연결 문제가 있는 경우 시스템의 트래픽 관리 계층에는 전반적인 서비스를 유지하기 위해 응답할 수 있는 다양한 방법이 있습니다. 솔루션은 가용성을 달성하기 위해 가능한 한 많은 메커니즘을 구현하거나 필요한 메커니즘을 구현해야 합니다. 처음 두 메커니즘은 항상 옵션이 아닐 수 있는 클라이언트의 특정 동작을 사용합니다.

  1. 대체 대상에 대한 즉각적인 클라이언트 재시도 — 실패 시 또는 재시도의 응답이 없는 경우 클라이언트는 새 DNS 쿼리를 제출하여 대안을 식별하는 대신 성공할 가능성이 있는 대체 요소로 요청을 즉시 다시 시도할 수 있습니다.

  2. 클라이언트 기반 상태 목록 - 알려진 정상알려진 비정상 요소 목록을 유지 관리합니다. 해당 목록이 비어 있지 않은 한 요청은 항상 정상 상태인 알려진 요소로 전송됩니다. 비어 있으면 알려진 비정상 요소가 시도됩니다.

  3. 서버 기반 폴링 - DNS 또는 ATM(Azure Traffic Manager)과 같은 시스템 기반 배포 메커니즘은 비정상 요소에 대한 라우팅을 사용하도록 자체의 활동성 검색 및 모니터링을 구현합니다.

복구 및 복구 실패 응답

트래픽 관리 응답은 오류를 해결할 수 있지만 오류가 수명이 길거나 영구적인 경우 결함이 있는 요소를 복구하거나 교체해야 합니다. 여기에는 두 가지 기본 선택 사항이 있습니다.

  1. 중복성 복원 - 요소의 오류가 발생하면 전체 시스템 용량이 줄어듭니다. 시스템 디자인은 중복 용량 프로비저닝을 통해 이러한 용량 감소를 허용해야 합니다. 그러나 여러 겹치는 오류로 인해 실제 중단이 발생합니다. 오류를 감지하고 정상 수준으로 중복성을 복원하는 용량을 추가하는 자동화된 프로세스가 있어야 합니다. 오류 비율 분석에서 영향을 확인할 수 있습니다. 대부분의 경우 중복성 수준을 자동으로 복원하면 개별 요소의 허용 가능한 가동 중지 시간이 증가할 수 있습니다.

  2. (선택 사항) 실패한 요소 복구 - 솔루션에는 오류를 감지하고 실패한 요소를 복구하려는 메커니즘이 포함되어야 할 수 있습니다. 이 솔루션은 중복성을 복원하는 프로세스가 실패한 요소를 대체하기 위해 새 요소를 인스턴스화하고 실패한 요소를 종료하고 해제하는 경우에는 적용되지 않을 수 있습니다.

다음 다이어그램에서는 두 가지 실패 응답 모드가 서비스 수준 내결함성을 제공하기 위해 협력하는 방법을 보여 줍니다.

두 가지 실패 응답 모드를 보여 주는 다이어그램

실패율 분석

어떤 노력도 완벽한 시스템으로 이어지지 않으므로 모든 것이 실패할 수 있고 실패할 것이라는 가정부터 시작하세요. 솔루션 전체가 어떻게 작동하는지 고려합니다. 실패율 분석은 하위 수준 개별 시스템에서 시작하여 결과를 결합하여 전체 솔루션을 모델링합니다.

분석은 일반적으로 가능한 모든 오류 모드를 고려하는 Markov 모델링을 사용하여 수행됩니다. 각 실패 모드에 대해 다음 요소를 고려합니다.

  • 비용
  • 기간 및 해결 시간
  • 상관 관계 오류의 확률(서비스 X의 오류로 인해 서비스 Y에서 오류가 발생할 확률)

결과는 시스템 가용성의 추정치이며 폭발 반경을 고려합니다. 폭발 반경은 특정 오류가 발생한 경우 작동하지 않는 일련의 항목입니다. 좋은 디자인은 실패가 발생할 것이기 때문에 해당 집합의 scope 심각도를 제한하는 것을 목표로 합니다. 예를 들어 새 사용자 만들기를 차단하지만 기존 사용자에 영향을 주지 않는 오류는 모든 사용자에 대한 서비스를 중지하는 오류보다 덜 우려됩니다.

실패율 분석은 전체 시스템 수준 가용성의 추정치를 제공합니다. 분석은 해당 가용성이 의존하는 중요한 종속성을 식별합니다. 오류율 분석에서 시스템 가용성이 부족하다는 것을 나타내는 경우 개선이 필요한 위치와 그 정도에 대한 구체적이고 정량적인 인사이트도 제공합니다.

Azure의 오류 모드 분석에 대한 자세한 내용은 Azure 애플리케이션에 대한 오류 모드 분석을 참조하세요.

연속 오류 및 오버로드

캐리어 등급 애플리케이션 디자인은 한 요소의 실패로 인해 종종 오버로드로 인해 다른 요소의 실패로 이어지는 연속 오류의 위험에 주의해야 합니다. 연속 오류는 캐리어 등급 애플리케이션에만 국한되지 않지만 안정성과 응답 시간은 정상적인 성능 저하 및 자동화된 복구를 요구합니다.

다음 단계

이동 통신 사업자 등급 워크로드에 대해 고려된 데이터 모델 디자인 영역을 검토합니다.