서론

신뢰성과 오류의 개념(Brian Randell의 Fault–Error–Failure 모델)

1. Human Error (인적 오류):

   • 개발자의 실수로 인해 시스템에 결함(fault)이 도입됨.
   • 예: 시간 계산 코드에서 23.00 이후 1시간을 더하는 실수로 인해 문제가 발생.

2. System Fault (시스템 결함):

   • 소프트웨어가 오류 상태(error)를 유발할 수 있는 특성.
   • 예: 값이 24.XX로 설정되는 코드 결함.

3. System Error (시스템 오류):

   • 실행 중 발생한 잘못된 상태가 시스템의 예상치 못한 동작으로 이어질 수 있음.
   • 예: Transmission_time이 잘못 설정됨.

4. System Failure (시스템 실패):

   • 시스템이 사용자 기대에 맞는 서비스를 제공하지 못할 때 발생.
   • 예: 잘못된 시간 설정으로 인해 데이터 전송 실패.

오류가 Failure로 이어지지 않는 경우

1. 미실행 코드:

   • 오류가 있는 코드가 실행되지 않을 경우, 문제가 발생하지 않음.

2. 일시적 오류:

   • 오류 상태가 다른 입력에 의해 유효 상태로 복구될 수 있음.

3. 오류 감지 및 보호 메커니즘:

   • 시스템이 오류를 감지하고 수정함으로써 failure를 방지.

4. 사용자 적응:

   • 사용자가 특정 입력이나 기능을 회피하여 오류를 피함.

소프트웨어 신뢰성 향상 접근법

Fault Avoidance (결함 회피)

• 설계 및 구현 단계에서 결함 발생 최소화:
  • 강 타입 언어 사용 (컴파일러 검사를 통한 오류 방지).
  • 에러가 발생하기 쉬운 언어 구문 최소화 (예: 포인터 사용 제한).

Fault Detection and Correction (결함 탐지 및 수정)

• 검증과 확인(Verification & Validation) 프로세스를 통해 결함을 발견하고 제거:
  • 체계적인 테스트와 디버깅.
  • 정적 분석을 통한 코드 결함 탐지.
  • 특히 핵심 시스템에서는 포괄적인 검증이 필수임.

Fault Tolerance (결함 허용)

• 런타임 오류 감지와 관리를 통해 시스템 실패를 방지:
  • 런타임 검사를 통한 기본적인 오류 감지.
  • 고신뢰성 시스템에서는 결함 허용 아키텍처 사용.

잔존 결함과 비용의 타협

1. 결함 제거 비용은 소프트웨어가 신뢰성을 높일수록 기하급수적으로 증가함.
2. 모든 결함을 제거하는 대신, 시스템 실패 시 결과를 감당하는 비용이 더 저렴할 수 있음.
3. 결함 허용 수준은 시스템 유형에 따라 다름:
   • 일반 소프트웨어: 결함 허용도가 높음.
   • 핵심 시스템: 결함 밀도가 낮아야 함.

---

11.1 Availability and reliability

시스템 신뢰성 및 가용성

• 가용성(Availability): 시스템이 작동 가능한 상태에 있는 확률.
  • 예: 0.999의 가용성은 시스템이 99.9% 시간 동안 작동함을 의미.
• 신뢰성(Reliability): 시스템이 오류 없이 작동할 확률.
  • 예: 1000개의 입력 중 2개에서 오류가 발생한다면 신뢰성은 0.002.

• 신뢰성과 가용성은 서로 밀접하지만, 상황에 따라 한 쪽이 더 중요할 수 있음.
  • 예: 전화 교환기 시스템에서는 가용성이 더 중요함. 사용자는 언제든지 전화를 걸 수 있어야 하므로 시스템의 가용성 요구 사항이 높음.
  • 전화가 끊기더라도, 빠르게 재연결하면 큰 문제가 되지 않음.

신뢰성

• 신뢰성은 사용 환경에 따라 달라질 수 있음.

  • 예를 들어, 사무실 환경에서는 소프트웨어를 사용자가 제한적으로만 사용하지만, 대학 환경에서는 학생들이 다양한 방식으로 시스템을 사용하여 오류가 발생할 수 있음.

• 시스템은 입력/출력 매핑으로 생각할 수 있음.

  • 예: URL을 입력하면 웹 브라우저는 해당 웹 페이지를 표시.

• 일부 입력은 시스템 오류나 잘못된 출력을 유발함.

  • 신뢰성은 오류를 발생시키는 입력 세트의 크기에 따라 다름.
  • 시스템에서 일부 입력은 오류를 발생시키지 않지만, 다른 입력은 오류를 일으킬 수 있음.

• 사용자 환경에 따라 시스템의 신뢰성에 대한 인식 차이가 발생할 수 있음.
  

  • 예: User 1은 오류가 발생하지 않지만, User 2는 오류가 발생할 수 있음.

가용성

• 가용성은 시스템 실패의 빈도뿐만 아니라 복구 시간에도 영향을 받음.
  • 예: 시스템 A는 1년에 한 번 실패하지만, 복구에 6시간이 걸리고, 시스템 B는 매달 실패하지만 5분 만에 복구됨. 이 경우 시스템 B가 더 높은 가용성을 가짐.
• 시스템이 사용자에게 영향을 미치는 시간에 따라 가용성의 중요성이 달라짐.
  • 예: 3 am-4 am 사이의 시스템 다운타임은 적은 영향을 미칠 수 있지만, 업무 시간 동안의 다운타임은 큰 영향을 미칠 수 있음.

---

11.2 Reliability requirements

Warsaw Airport Incident 사례

1. 사건 개요
   1993년 9월, 폴란드 바르샤바 공항에서 한 항공기가 천둥번개가 치는 날씨 속에 착륙했습니다. 착륙 후 9초 동안 항공기의 컴퓨터 제어 브레이크 시스템이 작동하지 않았습니다. 브레이크 시스템이 착륙을 인식하지 못하고 항공기가 아직 공중에 있다고 판단한 것입니다. 이로 인해 비상 제동 시스템의 작동이 멈췄고, 항공기는 활주로 끝을 넘어 지면으로 떨어져 불이 붙었습니다.

2. 사고 조사 결과
   조사 결과, 브레이크 시스템의 소프트웨어는 명세서에 따라 정상적으로 작동했습니다. 제어 시스템에 오류는 없었지만, 소프트웨어 명세서가 불완전하여 이와 같은 드문 상황을 고려하지 않았습니다. 소프트웨어는 명세서대로 작동했지만, 시스템이 실패한 사례입니다.

• 시스템 신뢰성의 중요성
  • 시스템의 신뢰성이 단지 우수한 엔지니어링에만 의존하지 않음을 보여줌.
  • 시스템 요구 사항을 도출할 때 세부 사항에 대한 주의와 신뢰성 요구 사항을 충족시키는 소프트웨어 명세가 필요함을 강조.

신뢰성 요구 사항

1. 기능적 요구 사항 (Functional Requirements):

   • 시스템 내에서 체크 및 복구 기능을 포함하고, 시스템 실패나 외부 공격에 대한 보호 기능을 제공해야 함.

2. 비기능적 요구 사항 (Non-functional Requirements):

   • 시스템의 신뢰성과 가용성을 명시함.

신뢰성 지표

신뢰성 및 가용성 측정 지표

• POFOD (Probability of failure on demand): 서비스 요청 시 시스템 실패 확률. 예: POFOD = 0.001 (1/1000 확률로 실패 발생)
• ROCOF (Rate of occurrence of failures): 주어진 시간 또는 시스템 실행 횟수에 따른 시스템 실패 확률. 예: ROCOF = 1/1000, 실패 빈도수. MTTF는 ROCOF의 역수로, 평균 실패 시간 간격.
• AVAIL (Availability): 서비스 요청 시 시스템이 정상 작동할 확률. 예: AVAIL = 0.9999는 99.99% 시간 동안 시스템이 가용함.

사용 사례

• POFOD: 시스템 실패가 심각한 영향을 미칠 수 있는 경우 사용. 예: 화학 반응기 모니터링 시스템.
• ROCOF: 시스템에 정기적으로 요청이 발생하는 경우 사용. 예: 트랜잭션을 처리하는 시스템에서 하루에 10번 실패를 허용.
• MTTF (Mean Time to Failure): 시스템이 실패하기까지의 평균 시간을 정의. 예: 긴 트랜잭션을 처리하는 시스템에서 사용.

비기능적 신뢰성 요구사항

신뢰성 명세의 유용성

1. 신뢰성 수준 결정 과정이 이해를 돕고, 시스템 실패 유형을 구분하며, 높은 신뢰성 확보 비용을 명확히 인식시킴.
2. 시스템 테스트 종료 시점을 결정하는 기준 제공.
3. 신뢰성 향상을 위한 다양한 설계 전략을 평가할 수 있음.
4. 규제 기관이 시스템 승인 시 필요한 신뢰성 목표 충족 여부를 입증하는 데 사용.

신뢰성 요구사항 지정 가이드라인

1. 고비용 실패와 저비용 실패: 고비용 실패의 확률은 낮게 설정.
2. 시스템 서비스에 따른 요구사항: 중요 서비스는 높은 신뢰성 요구, 덜 중요한 서비스는 실패를 더 용인.
3. 높은 신뢰성의 필요성 검토: 오류 감지 및 수정 기능이 있다면 높은 신뢰성 요구가 불필요할 수 있음.

예시: 은행 ATM 시스템

• 고객 서비스와 거래 기록: 고객 요청에 맞게 서비스를 제공하고 계좌 데이터베이스에 기록하는 것이 중요.
• 시스템 가용성: ATM이 사용 가능한지 여부가 중요하며, ATM 거래 실패는 미리 해결할 수 있음.

ATM 네트워크 가용성 요구사항

• 고객 계좌 데이터베이스 서비스: 높은 가용성이 필요 (0.9999, 주 1분 미만의 다운타임).
• ATM 개별 서비스: 낮은 소프트웨어 가용성 허용 (0.999, 하루 1~2분의 다운타임).

기능적 신뢰성 요구사항

기능적 신뢰성 요구사항의 종류

1. 체크 요구사항: 시스템에 입력되는 값이 잘못되었거나 범위를 벗어난 경우 이를 탐지하고 처리하기 전에 확인하는 요구사항.
2. 복구 요구사항: 실패 발생 후 시스템이 복구될 수 있도록 돕는 요구사항. 시스템과 데이터를 복사하고, 실패 후 서비스 복구 방법을 지정.
3. 중복 요구사항: 시스템의 한 구성 요소가 실패해도 전체 서비스가 중단되지 않도록 보장하는 중복 기능을 지정.
4. 프로세스 요구사항: 결함 회피를 위한 요구사항으로, 개발 과정에서 좋은 가이드라인을 사용하여 시스템 내 결함을 줄임.

---

11.3 Fault-tolerant architectures

결함 내구성

• 결함 내구성은 시스템이 소프트웨어나 하드웨어 결함이 발생하더라도 계속 작동할 수 있도록 하는 런타임 접근 방식.
• 결함 내구성 메커니즘은 결함이 발생한 상태를 감지하고 수정하여 시스템 실패를 방지.

• 결함 내구성이 필요한 시스템:
  • 오류가 감지될 때 시스템이 안전한 상태로 이동할 수 없는 시스템 (예: 항공기 시스템, 통신 시스템, 중요한 명령 및 제어 시스템)

결함 내구성 구현 방법

복제 서버

• 두 개 이상의 서버가 동일한 작업을 수행.
• 요청은 서버 관리 컴포넌트를 통해 처리되어 각 서버로 라우팅되고, 서버 응답을 추적.
• 서버 실패 시 응답이 없으면 해당 서버는 시스템에서 제외되고, 처리되지 않은 요청은 다른 서버로 재전송.
• 트랜잭션 처리 시스템에서 주로 사용되며, 거래가 완료된 후에만 데이터가 업데이트됨.
• 한계:
  • 복제 서버는 중복성을 제공하지만 보통 다양성은 제공하지 않음.
  • 하드웨어 및 소프트웨어 실패에는 대응할 수 있지만, 모든 버전의 소프트웨어에서 동시에 발생하는 설계 문제에는 대응할 수 없음.
  • 이를 해결하려면 다양한 소프트웨어와 하드웨어를 사용하는 시스템 설계가 필요.

보호 시스템

보호 시스템의 필요성

• 소프트웨어 단순화: 보호 시스템은 필수 기능만 수행하므로 제어 시스템보다 훨씬 간단한 소프트웨어로 구성.
• 고장 회피 및 감지: 고장 회피와 감지에 더 많은 노력을 투자할 수 있음.
• 신뢰성: 보호 시스템은 실패 확률이 매우 낮아야 함 (예: 1/1000). 요구 사항이 드물기 때문에 이러한 시스템 실패는 매우 드물어야 함.

보호 시스템의 예시

• 열차 보호 시스템: 열차가 빨간 신호를 지나면 자동으로 브레이크를 작동시켜 열차를 정지시킴.
• 기타 예시: 화학 공정 제어 시스템 또는 자동화된 기계 장비의 제어 시스템에서 발생할 수 있는 위험을 감지하고 처리.

보호 시스템의 기능

• 모니터링: 보호 시스템은 제어되는 장비와 환경을 독립적으로 모니터링.
• 문제 감지: 제어 시스템이 문제를 처리하지 못할 경우, 보호 시스템이 활성화되어 시스템을 종료하거나 안전장치를 작동시킴.
• 센서와 액추에이터: 보호 시스템에는 정상 모니터링을 위한 센서와 보호 시스템 전용 센서가 존재. 센서 고장 시 백업 시스템을 통해 계속 작동할 수 있도록 함.

보호 시스템의 설계 특징

• 핵심 기능만 포함: 보호 시스템은 시스템을 안전한 상태로 전환하는 데 필요한 핵심 기능만 포함.
• 단순한 백업 시스템: 원래 시스템의 보조 역할을 하며, 원래 시스템이 실패했을 때만 작동. 예: 우주왕복선의 백업 시스템은 "귀환" 기능만 제공.

자기 모니터링 아키텍처

자기 모니터링 시스템의 설계 요구사항

1. 하드웨어 다양성: 각 채널에서 사용하는 하드웨어는 다르게 설계되어야 합니다. 예를 들어, 각 채널이 다른 종류의 프로세서를 사용하거나 시스템을 구성하는 칩셋이 다른 제조업체에서 공급되어야 합니다. 이는 공통된 설계 결함이 계산에 영향을 미칠 확률을 줄입니다.
2. 소프트웨어 다양성: 채널별로 소프트웨어가 달라야 합니다. 동일한 소프트웨어 오류가 여러 채널에서 동시에 발생하는 것을 방지할 수 있습니다.

적용 사례

• 의료 치료 및 진단 시스템: 계산이 정확해야 하며 가용성은 필수적이지 않은 경우. 오류가 발생하면 시스템이 종료되지만, 환자에게 직접적인 피해는 발생하지 않습니다.
• 고가용성이 필요한 시스템: 여러 개의 자기 점검 시스템을 병렬로 사용해야 합니다. 이 경우, 오류를 감지하고 결과를 선택할 수 있는 전환 장치가 필요합니다.

Airbus 340 비행 제어 시스템 예시

Airbus 340 비행 제어 시스템에서는 다섯 개의 자기 점검 컴퓨터가 병렬로 계산을 수행합니다. 각 비행 제어 컴퓨터는 동일한 입력값을 사용하여 계산을 수행하고, 출력은 하드웨어 필터를 통해 오류를 감지하여 오류가 발생하면 해당 컴퓨터의 출력을 차단합니다. 그러면 다른 시스템에서 출력이 선택됩니다.

Airbus 시스템의 다양성 확보 방법:

1. 프로세서 다양성: 주요 비행 제어 컴퓨터와 보조 시스템은 다른 프로세서를 사용합니다.
2. 칩셋 제조업체 다양성: 주요 및 보조 시스템에서 사용하는 칩셋은 서로 다른 제조업체에서 공급됩니다.
3. 소프트웨어 복잡도 차이: 보조 시스템의 소프트웨어는 중요 기능만 제공하며, 주요 소프트웨어보다 간단합니다.
4. 프로그래밍 언어 다양성: 각 채널의 소프트웨어는 다른 프로그래밍 언어로 개발되고, 서로 다른 팀에서 개발됩니다.

다중 버전 프로그래밍

삼중 모듈 중복 (TMR) 시스템

• 하드웨어 유닛 복제 3회 이상.
• 출력 비교기를 통해 일치하는 값을 출력.
• 하나의 유닛이 실패하면 다른 유닛의 값을 사용.
• 실패한 유닛은 자동으로 재구성.

소프트웨어 결함 허용: N-버전 프로그래밍

• 여러 팀이 동일한 소프트웨어 시스템을 개발.
• 각 버전은 별도 컴퓨터에서 실행.
• 출력은 투표 시스템으로 비교하여 불일치 출력 거부.
• 최소 세 개 버전 필요.

비용 및 사용 사례

• 높은 가용성 필요시, 비용이 덜 들 수 있음.
• 여러 팀이 개발해야 하므로 개발 비용 높음.
• 보호 시스템 대신 사용되는 경우 사용.

소프트웨어 다양성

다양성 정책:

1. 설계 방법: 다른 방법 사용 (예: 객체 지향 설계 vs. 기능 지향 설계)
2. 프로그래밍 언어: 다른 언어로 구현 (예: Ada, C++, Java)
3. 도구 및 개발 환경: 다른 도구와 환경 사용
4. 알고리즘: 다른 알고리즘 사용, 다만 성능 요구사항과 충돌할 수 있음

문제점:

1. 공통적인 실수: 비슷한 문화적, 교육적 배경을 가진 팀들은 독립적으로 동일한 실수를 할 수 있음.
2. 잘못된 요구사항: 요구사항이 잘못되거나 잘못 이해되면 모든 시스템 버전에서 동일한 실수가 발생함.
3. 사양의 애매함: 애매한 사양은 팀들 간에 일관된 오류를 초래할 수 있음.

사양 오류 감소 방법:

• 독립적인 사양 개발: 서로 다른 언어로 시스템 사양을 개발 (예: 형식적 사양, 상태 기반 모델, 자연어)을 사용해 오해를 줄임.

신뢰성 계산:

• 독립성이 있을 경우 신뢰성은 곱셈 방식으로 계산됨:
  • 예시: 각 채널의 실패 확률이 0.001인 3채널 시스템은 단일 채널 시스템보다 신뢰성이 100만 배 더 높음.
• 실험 결과: 3채널 시스템은 단일 채널 시스템보다 5~9배 더 신뢰성이 높음 (Hatton 1997).
• 비용-효익 분석: 다중 버전 시스템이 신뢰성을 높일 수 있지만, 개발 비용이 항상 정당화되지 않을 수 있음.

---

11.4 Programming for reliability

신뢰성 공학에서의 가이드라인

1. 정보의 가시성 제어: 데이터는 필요한 정보만 공개하고, 추상 데이터 타입(ADT)을 사용해 다른 컴포넌트의 접근을 제한하여 데이터 표현 변경이 영향을 미치지 않도록 함.

2. 입력의 유효성 검사: 입력의 범위, 크기, 표현, 합리성을 검증하여 오류를 예방하고, 유효하지 않은 입력 시 오류 메시지나 대체 값을 제공.

3. 예외 핸들링: 예외 발생 시 상위 컴포넌트로 전달하거나 대체 처리로 오류를 처리하고, 시스템을 안전한 상태로 유지함.

4. 오류 발생 가능성 큰 구성 요소 사용 최소화: 부동소수점 수, 동적 메모리 할당 등 오류 발생 가능성이 큰 요소는 추상화하여 사용.

5. 재시작 기능 제공: 시스템 실패 시 데이터를 보호하고, 재시작할 수 있는 기능(체크포인트)을 제공하여 작업을 다시 시작할 수 있도록 함.

6. 배열 경계 확인: 배열의 인덱스가 유효한지 확인하여 범위 벗어난 접근을 방지하고, 버퍼 오버플로우와 같은 보안 취약점 예방.

7. 외부 컴포넌트 호출 시 타임아웃 설정: 외부 컴포넌트가 응답하지 않을 경우 무한 대기 상태를 방지하기 위해 타임아웃을 설정.

8. 실제 세계 값을 나타내는 상수에 이름 부여: 실제 세계 값을 상수로 정의하고, 이름을 사용하여 실수를 줄이고 유지 보수를 용이하게 함.

---

11.5 Reliability measurement

신뢰성 평가를 위한 데이터 수집

1. 시스템 실패 횟수: 서비스 요청 수 대비 시스템 실패 횟수는 POFOD 측정.
2. 시스템 실패 간 시간: ROCOF, MTTF 측정.
3. 수리 또는 재시작 시간: 가용성(Availability) 측정.

신뢰성 테스트

1. 운영 프로필 정의: 시스템 사용 패턴 정의.
2. 테스트 데이터 생성: 운영 프로필에 맞는 데이터 생성.
3. 시스템 테스트: 데이터로 시스템 실행 및 실패 기록.
4. 신뢰성 계산: 실패 수로 신뢰성 계산.

실용적인 어려움

1. 운영 프로필 불확실성: 기존 시스템과 차이 있을 수 있음.
2. 테스트 데이터 비용: 대량 데이터 생성 시 비용 높음.
3. 통계적 불확실성: 실패가 적어 신뢰성 측정 어려움.
4. 실패 인식 문제: 시스템 실패 판단 어려움.

테스트 데이터 생성 및 결함 주입

• 데이터 생성기: 자동화 가능하나, 상호작용 시스템은 수동 데이터 필요.
• 결함 주입: 오류 삽입으로 결함 테스트 효과 측정, 프로그래밍 오류 외에는 한계 있음.

운영 프로필

운영 프로필의 구성

• 높은 확률로 발생하는 입력은 소수의 클래스에 속함.
• 드문 입력 클래스는 많지만 발생 확률이 낮음.

운영 프로필 개발의 어려움

1. 다양한 사용자: 사용자가 시스템을 다르게 사용할 수 있음.
2. 사용자 변화: 시간이 지나면서 사용 패턴이 변할 수 있음.

출처: Ian Sommerville - Software Engineering