[소공 시험공부] Software Reliability

들어가기 앞서 먼저 용어를 좀 알아보자

Human mistake	시스템에 결함을 도입하게 되는 인간 행동
System fault	시스템 오류로 이어질 수 있는 소프트웨어 시스템의 특성
System error	시스템 사용자가 예상하지 못한 시스템 상태
System failure	시스템이 기대한 서비스를 제공하지 못할 때 발생하는 이벤트

 

System fault (버그가 존재함) -> Human mistake(버그를 발생시킴) -> System error(예상치 못한 결과가 나타남) -> System failure(Crash report 같은 결과 등장. system error의 결과)

 

fault가 반드시 error를 발생시키는 것은 아니고(오류 발생 전에 수정하거나 아에 오류 있는 코드가 실행 안될수도), error가 반드시 failure를 초래하는 것도 아니다(예외 처리를 잘 해주거나, 보호 메커니즘)

 

이러한 Fault를 관리하고 다루는 방법은 아래와 같다(a, d, t로 외우면 될 듯)

 

• 결함 회피(Fault avoidance):
  • 시스템은 human mistake를 방지하고 System fault를 최소화하도록 개발됩니다.
  • 개발 프로세스는 System fault가 배포 전에 감지되고 수정되도록 조직됩니다.
  • Dev 단계라고 보면 될 듯
• 결함 감지(Falut detection):
  • 검증 및 검증 기술은 배포 전에 System fault를 발견하고 제거하는 데 사용됩니다.
  • Releasing test 단계라고 보면 될 듯
• 결함 허용(Fault tolerance):
  • 시스템은 전달된 Software falut이 System failure을 초래하지 않도록 설계됩니다.

 

Reliability : 특정 환경에서 주어진 목적을 위해 지정된 시간 동안 시스템이 고장 없이 작동할 확률(예상하는 대로 작동하는지)

Availability : 시스템이 운영 가능하고 요청된 서비스를 제공할 수 있는 확률(원할 때 이용할 수 있는지)

 

본격적인 내용으로 들어가보자

시스템에 따라 Reliability가 필요한 정도가 다르다. 

"정도"를 다루기 위해서, 우리는 아래에서 Reliability와 Availability를 정량적으로 표현할 것이다.

Perception of Reliability and Availability

개발팀에서 Reliability를 Specification과 관련해서 Formal 하게 정의했다고 치자. 개발팀에서는 명세를 만족했다고 하지만, 명세가 불완전해서 사용자 Perception에서는 fail이라고 받아들일 수 있다. (사용자가 개발팀이 가지고 있는 명세를 읽는건 아니니...)

(즉. Reliability에 대한 formal definition은 user perception을 반영하지 않는다)

 

Availability는 어떨까? 보통 Availability를 표현할 때 서비스를 제공할 수 있는 시간의 비율로 표현하는데, 이게 함정이 있다.

서비스 중단으로 인한 영향을 받는 사용자의 수(낮 vs 새벽) 과, 중단의 길이를 고려하지 않는다. 즉. 사용자가 인식하는 정도를 완전하게 반영하지 못한다.

 

또한 Defection을 제거한다 하더라도, 그만큼 사용자가 인식하는 Reliability가 올라가는 것도 아니다. 사용자가 이미 적응해서 신뢰할 수 있는 영역이라고 볼 수도 있는거고, Defection 자체가 거의 발생하지 않았을수도 있다.

 

그러면 어떻게 Reliability를 다뤄야 하나요?

이때 등장하는 개념이 System reliability requirement다. 신뢰성을 어떻게 다루고 측정하고 명시할 지를 다룬다. 기능적 / 비기능적으로 나눌 수 있다.

이런 requirement를 어떻게 정의할 수 있을까? 정량적으로 명시한다.

reliability는 측정 가능하니까... 허용되는 실패 횟수라던지, 사용 가능 시간 등을 명시할 수 있다.

 

Reliability metrics

System reliability의 측정 단위 이다. 운영 실패 횟수를 세고, 이를 시스템에 가해지는 요구와 운영된 시간에 관련지어 측정한다.

아래 내용을 외워서, 어떤 상황이 주어졌을 때 어떤 메트릭스를 사용해야 하는지 판단하자

요구 시 실패 확률 (Probability of failure on demand, POFOD)

• 이는 서비스 요청 시 시스템이 실패할 확률입니다.
  • 서비스 요청이 간헐적이고 비교적 드문 경우에 유용합니다(Useful when demans for service are intermittent and relatively infrequent)
  • ex) 100번 중 10번의 실패가 발생하면 10%
• 서비스가 가끔 요구되며, 서비스가 제공되지 않으면 심각한 결과를 초래하는 보호 시스템에 적합합니다.
• 예외 관리 구성요소(exception management component)를 포함하는 많은 안전-중요 시스템(safety-critical systems)에 관련이 있습니다.
  • 화학 공장의 비상 정지 시스템.

---

실패 발생률 (Rate of occurrence of failures, ROCOF)

• 시스템에서 실패가 발생하는 비율을 반영합니다.
• ROCOF 0.002는 1000 운영 시간 단위당 2번의 실패가 발생할 가능성이 있음을 의미합니다. 예: 1000 시간 운영당 2번의 실패.(time unit이 1 hour라면)
•  단시간에 유사한 요청을 많이 처리해야 하는 시스템에 관련이 있습니다.(Relevant for systems where the system has to process a large number of similar request in a shor time)
  • 신용카드 처리 시스템, 항공사 예약 시스템.
• ROCOF의 역수(Reciprocal of ROCOF)는 평균 고장 간격 (Mean time to Failure, MTTF)입니다.
  • MTTF : 얼마나 Failure 없이 오랫동안 서비스 할 수 있는지를 나타낸다 
  • 긴 트랜잭션이 있는 시스템에 관련이 있으며, 예를 들어 CAD 시스템과 같이 처리 시간이 오래 걸리는 시스템에 적합합니다.
  • MTTF는 예상 트랜잭션 길이보다 길어야 합니다.

가용성 (Availability, AVAIL)

• 시스템이 사용 가능한 시간의 비율을 측정합니다.
• 수리 및 재시작 시간을 고려합니다.
  • ex) 카카오톡 업데이트로 인해 장애가 발생하여, 서비스 복구가 6시간이 걸렸다. 
    • 24시간 기준 availability는 75%, 365일 기준이라면 availability가 매우 높아짐 -->기준에 따라 달라진다
• 가용성 0.998은 1000 시간 단위 중 998 시간 동안 소프트웨어가 사용 가능함을 의미합니다.
•  비정지, 지속적으로 실행되는 시스템에 관련이 있습니다.(Relevant for non-stop, continuously running systems).
  • 전화 교환 시스템, 철도 신호 시스템.

Non-functional reliability requirement

System reliablity, availability에 필요한 명세를 reliability metrics를 사용하여 명시한다

아래 내용도 외우자

• 다양한 유형의 실패(different types of failure)에 대한 availability과 reliability requirements을 명시하십시오.
  • 심각한 결과를 초래하지 않는 실패보다 고비용 실패 확률이 낮아야 합니다
• 다양한 유형의 시스템 서비스(different types of system service)에 대한 availability과 reliability requirements을 명시하십시오.
  • 중요한 시스템 서비스는 가장 높은 신뢰성을 가져야 하지만, 덜 중요한 서비스에서는 더 많은 실패를 용인할 수 있습니다.
• 높은 수준의 신뢰성이 정말로 필요한지(whether a high level of reliability is really required) 고려하십시오.
  • 다른 메커니즘을 사용하여 신뢰할 수 있는 시스템 서비스를 제공할 수 있습니다.

참고)

예시: 은행의 온라인 뱅킹 시스템

1. 다양한 유형의 실패에 대한 요구사항:
   • 고비용 실패: 은행 계좌의 잘못된 거래 처리로 인한 데이터 손실. 이러한 실패의 확률은 매우 낮아야 합니다.
   • 저비용 실패: 사용자 인터페이스의 사소한 오류. 심각한 결과를 초래하지 않으므로, 조금 더 높은 실패 확률을 허용할 수 있습니다.
2. 다양한 유형의 시스템 서비스에 대한 요구사항:
   • 중요한 서비스: 금융 거래 처리 서비스. 이 서비스는 가장 높은 신뢰성을 가져야 합니다.
   • 덜 중요한 서비스: 고객 피드백 수집 서비스. 더 많은 실패를 허용할 수 있습니다.
3. 높은 수준의 신뢰성 필요성 고려:
   • 대안적 메커니즘: 중요한 서비스의 신뢰성을 높이기 위해 데이터 백업 및 복구 시스템을 사용할 수 있습니다.

이러한 요구사항을 명시하기 위해 신뢰성 메트릭스를 사용할 수 있습니다:

• POFOD (Probability of Failure on Demand): 예를 들어, 금융 거래 처리 서비스의 POFOD는 0.001 이하로 설정될 수 있습니다.
• ROCOF (Rate of Occurrence of Failures): 고객 피드백 수집 서비스의 ROCOF는 매달 5회 이하로 설정될 수 있습니다.
• AVAIL (Availability): 금융 거래 처리 서비스의 가용성은 99.99% 이상으로 설정될 수 있습니다.

 

Functional reliability requirement

시스템과 SW의 기능을 정의하고, fault를 avoid, detect, tolerance 하여 system failure로 이어지지 않도록 한다. HW 고장, 운영 오류도 다룰 수 있다. 요기 아래 내용도 외우자 (CRRP)

cf) metric : verifiable NFR로 정의

• 잘못된 데이터가 failure로 이어지기 전에 이를 detect 체크를 확인하는 요구사항 (Checking requirements).
• failure 발생 후 시스템이 복구될 수 있도록 돕는 복구 요구사항 (Recovery requirements).
  • ex) 널포인터 Exception : 구글 플레이 스토어 crash 발생 원인 1위
• 시스템에 포함될 중복 기능을 명시하는 중복 요구사항 (Redundancy requirements).
  • Redundancy와 Diversity를 잘 준비해야 한다(비용은 많이 듬).
• 사용할 개발 프로세스를 명시하는 프로세스 요구사항 (Process requirements).
  • 이 시점에서는 이러한 것들이 준비되어야 한다.

 

결국에는 Failure로 이어지지 않는게 중요하고, Depandable Programming을 통해 이를 실천해야한다

Fault avoidance / Fault detect / Fault tolerance 를 실천하고

가시성 제한, 입력 유효성 검사, 예외 핸들러, 오류발생 높은 것 사용 최소화, 재시작 기능 제공, 배열 경계검사, 타임아웃 포함, 실제 값을 나타내는 상수에 이름지정 등 ...