요구사항 분석 소개: 아키텍처 토크(3) 사용성 주제

이전 기사에서는 비기능적 요구 사항 및 일부 산업 표준에 대한 다양한 지표를 소개했습니다.
비기능적 요구사항에는 신뢰성이 있으며 이와 관련된 지표를 사용성이라고 합니다 .
이 기사에서는 비기능적 요구사항의 가용성 및 신뢰성에 대해 자세히 설명합니다.

개념

우리가 인터넷에서 클라우드 서비스 제공업체에 있을 때 제품 소개에서 종종 이런 단어를 볼 수 있습니다: 우리 서비스 가용성은 99.99%입니다.
이 가용성은 무엇을 의미합니까?

• 정의:
  시스템이 정상적으로 실행되고 일정 기간 내에 정상적으로 사용할 수 있는 시간의 비율을 말합니다.
  예를 들어, 시스템이 1년 중 364일 동안 정상적으로 작동하고 누적 고장 시간이 1일이라면 가용성은364/365 ≈ 99.7%
• 신뢰성의 차이:
  신뢰성은 두 번의 실패 사이의 평균 간격입니다.
• 일반적으로 이 둘은 서로 관련되어 있습니다. 즉, 일반적으로 좋은 안정성은 높은 가용성을 가집니다.
  그러나 다음 두 시나리오를 비교하는 것과 같은 예외가 있습니다.
  • 가용성은 높으나 신뢰성이 낮음
    매분 다운타임이 있으며 1초만에 정상으로 돌아옴 가용성은 비교적 양호하나 ≈ 98.3%
    장애확률이 높음 연속적인 정상 서비스 시간은 59초에 불과하므로 신뢰성이 나쁩니다.
  • 신뢰도는 양호하나 가용성은 높지 않음 다운타임
    은 1일 1회, 매회 2시간 가용성은 위 시나리오보다 나쁨 ≈ 91.7%
    그러나 신뢰도는 이전 시나리오보다 양호 연속 정상 서비스 시간은 22시간

측정하다

일반적으로 소프트웨어 시스템의 가용성을 측정하는 두 가지 방법이 있습니다.

시간 기반

가동 시간 / (가동 시간 + 가동 중지 시간)은
정상 작업 시간을 총 시간으로 나눈 값입니다.

요청에 따라

Success / Total
은 성공한 응답 수를 총 요청 수로 나눈 값입니다.

다음 두 그림에서 왼쪽은 가용성이 달성되었을 때 시스템의 평균 장애 시간을 나열하고 오른쪽은 일반적인 클라우드 서비스 약속의 가용성을 보여줍니다. 위 그림에서 우리는 다음을 볼 수 있습니다

.

• 가용성이 낮을수록 사용자에게 미치는 영향이 크고 결함이 많을수록 사용자 불만, 불만 및 손실 가능성이 커집니다.
• 클라우드 서비스 벤더가 약속한 가용성이 높지 않기 때문에 시스템을 설계할 때 클라우드 서비스 벤더 실패의 영향도 고려해야 합니다.
  참고:
  • Alibaba Cloud SLA 서비스 수준 계약 진술: https://help.aliyun.com/document_detail/56773.htm
    SMS 서비스의 가용성은 95%만 약속되며 스토리지 가용성은 99.995%에 도달할 수 있습니다.
  • 마이크로소프트 클라우드 애저: https://azure.microsoft.com/zh-cn/support/legal/sla/

여담:

• 클라우드 제공자가 장애가 발생하면 약속된 가용성을 초과하지 않는 한 기본적으로 사과에 불과하며 초과하더라도 일반적으로 해당 장애 기간에 대해서만 보상됩니다.예를 들어 장애가 지속되는 경우 1시간 동안 클라우드 서비스 이용시간 3시간만큼만 보상해 드립니다. .
  따라서 데이터가 손실된 경우 큰 문제가 없다면 일반적으로 스스로 해결 방법을 찾아야 합니다.
  검색 가능: 2018년 Tencent Cloud에서 Frontier CNC 데이터 손실 사건이 발생했으며 청구 금액은 수천만 달러에 달했지만 지불된 금액은 130,000건에 불과했습니다.

• 이전 회사의 SaaS 서비스는 Alibaba Cloud에 배포되었습니다. 서비스가 실패하면 마케팅 담당자가 먼저 사용자에게 알리바바 클라우드가 다시 다운되고 R & D 직원에 대해 상사에게 불평했습니다.

• 대부분의 웹 서비스의 가용성은 3 9 이하입니다.

사용성을 개선하는 방법

사례 분석

시스템에 로그인 요청이 있고 4개의 DB 데이터베이스(mysql/mongodb/cassandra/redis)에 액세스해야 한다고 가정하면 그림에서와 같이 각 DB의 가용성은 99.9%로 알려져 있습니다.

?
이 직렬 시스템 요청의 실제 가용성: 99.9%의 4승 = 99.6%, 즉
단일 DB가 99.9% 사용 가능, 즉 연중 8.76시간 동안 사용할 수 없음을
의미 합니다. 1년 내내 35.04시간 동안 사용할 수 없게 되고 실패 확률이 4배로 증가했습니다.

또한 그림에는 다른 서버와 네트워크가 있는데 네트워크가 불안정하고 각 DB의 가용성이 99.5%로 감소한다고 가정하면
이 시리즈 시스템 요청의 가용성은 다음과 같이 감소합니다. 98%는
1년 전체에 해당합니다. 175.2시간의 비가용 시간, 월 평균 14.6시간의 다운타임이 있습니다.

사용성을 개선하는 방법

위의 사례에서 시스템에 포함된 모듈(마이크로서비스)과 미들웨어(데이터베이스, 메시지 큐 등)가 많을수록 가용성이 낮다는 결론을 내릴 수 있습니다.
그렇다면 사용성을 어떻게 개선해야 할까요?
유일한 대답은 병렬 연결, 즉 우리가 종종 로드 밸런싱이라고 부르는 서비스 중복성을 사용하는 것입니다.

• 시리즈 시스템(노드 2개)의 가용성 계산: A = p1 * p2
  두 노드의 가용성이 99%이면 A = 99% * 99% = 98.01%
• 병렬 시스템(노드 2개)의 가용성 계산: A = 1-(1-p1)*(1-p2)
  두 노드의 가용성이 99%이면 A = 1-(1-99%) * ( 1- 99%) = 99.99%
  중복된 하나의 노드, 가용성은 충분합니다 从99%提升到99.99%.年故障87.6小时，降低到52分钟

시스템 병렬 연결을 실현하는 방법:

• 각 서비스에 대해 여러 독립 서버에 배포됩니다.
• 서비스의 각 노드의 상태에 따라 요청을 수신하고 정상 노드로 전송하는 프런트 엔드에 게이트웨이가 있습니다.
• 게이트웨이 자체도 중복되어야 합니다. 일반적으로 게이트웨이 자체의 상태를 확인하기 위해 선택 메커니즘 집합이 사용됩니다. 일반적인 선택 메커니즘에는 Paxos 알고리즘과 Raft 알고리즘이 포함되며 자체적으로 검색할 수 있습니다.

어려움:

• 아키텍처 설계는 복잡하고 오래된 시스템의 변형을 포함합니다.일부 시스템은 메모리 캐시 사용, 세션 사용 등과 같은 병렬 연결을 지원하지 않습니다.
• 비용을 두 배로 늘리려면 제품 시장과 개발 비용, 배포 비용, 후속 운영 및 유지 비용을 종합적으로 고려해야 합니다.
• 
  K8S와 같은 컨테이너를 사용할 때 동일한 서비스의 여러 인스턴스(Pod) 가 서로 다른 작업 노드에 배포되어야 한다는 사실에 주의해야 합니다. 이 노드 다운되고 전체 서비스를 사용할 수 없습니다.

최적화 목표 식별

시스템의 가용성을 향상시키려면 각 서비스 및 각 미들웨어에 병렬 처리를 맹목적으로 추가하는 대신 다음과 같은 특정 단계를 따라야 합니다.

• 1. 적절한 사용성 목표 결정
  • 사용자 기대치 조사
  • 회사의 사업 목표를 결정 (ToB 상품의 99.9% 이상)
  • 경쟁 제품의 규모 및 서비스 수준 참조
• 2. 우리 시스템 측정
  공통 측정, 지표 결정, 묻힌 포인트 및 데이터 수집(예: Proetheus) 수행, 통계 계산 수행, 통계 결과:
  avg, max, min, dev(average difference (∑|xx'|)÷ n ), 롱테일(95, 99)

사용성 에필로그

제품 동작의 3단계를 나타내는 아래 그림을 참조하십시오:

이 그림을 통해 말하고 싶습니다:
X의 아키텍처와 미들웨어가 아무리 훌륭해도 단계적으로 진화하고 침전됩니다. 매우 인간적입니다. . .

지속적인 리팩토링...

다음 기사에서는 성능 관련 개념과 성능 문제를 찾는 방법에 대해 소개하겠습니다.