소프트웨어의 오류와 Fault-Tolerance 기법

** 본 글은 차성덕 교수님의 소프트웨어공학이야기 책을 정리한 글입니다. **

 

하드웨어의 경우 Fault-Tolerence를 중복으로 비교적 쉽게 해결 가능하다. 그러나 소프트웨어/OS는 복잡해짐
TMR triple modular redundancy:  single point failure를 피하는 것이 목표

 

Fault-Tolerence를 소프트웨어에도 적용해보자면...?
논리적인 오류 때문에 잘못된 결과가 나오더라도 이러한 한계를 극복하기 위해 시작
안전에 필수적인 기능을 담당하는 소프트웨어의 경우, 이는 필수적이다.

Recovery Block

1. primary alternative 블럭에 명시된 알고리즘 이용하여 계산
2. acceptance test 루틴을 이용해 결과값 검사
3. 통과하면 그대로 씀 / 통과하지 않으면 다음 블럭으로 재시도
4. * acceptance test 루틴을 통과하거나, 모든 블럭이 소진되어 에러 값을 반환해야지 끝남.

• 동일한 조건에서 block을 수행하기 위해선 checkpoint를 설정해 프로그램 전체 상태를 저장하고 복원해야 한다.
• 실시간 소프트웨어의 일부일 경우, 결과값이 정확해야 하고, 시간 제한 내에 완료되어야 한다
  출력값을 계산하는데 걸리는 시간도 중요하고, checkpoint 값이 일정 시간이 흐른 뒤 유효하지 않을 수도 있다.
• 각 블럭이 유사한 오류 common mode failure를 피해야 한다. 다양성을 통한 신뢰성의 향상을 기대할 수 있는가?
• primary block, alternative block의 우선순위를 어떻게 합리적으로 내릴 수 있는가?
• acceptance test는 어떻게 만들 수 있는가?
• 가능한 독립적으로 acceptance test, alternative block을 구현할 때 비용이 얼마나 들겠는가...
• 이를 지원하는 프로그래밍 언어가 없어, checkpoint 설정, 저장, 복원 등 모두 작성해야 하고 복잡도가 증가한다.
• acceptance test 코드에 오류가 있으면 제대로 계산된 값도 오류로 판단할 수도 있다.

N-version programming (NVP)

• 동일한 명세를 가지고 N개의 버전을 독립적으로 개발한 후 각각의 결과값을 비교하여 과반수의 답을 결과값으로 사용.
• 다수의 의견은 항상 옳다는 전제를 바탕으로 한다.

• 2-version일 경우, fault detection은 되지만 fault tolerence는 안 된다. 
  무엇이 옳은 것인지 판단 불가능
• 최소 3-version 이상 + 홀수 개수의 버전이 필요하다
• 여러 개의 버전이 독립적으로 구현되었을 것이라 가정하고, 병렬적으로 진행될 수 있다고 가정하면 간단해보이지만
• 모든 버전이 비슷한 시간대에 끝나고, majority voting이 쉽게 이루어질 수 있다는 보장이 없다.
• 과연 3개의 버전을 가지고 진행하면 3배 더 신뢰도가 높아지는가? 답은 No 
  각각의 failure가 확률적으로 독립적이라는 가설은 근거가 없다.

 

Fault-Tolerence는 아직도 해결하지 못한 문제가 많이 남은 분야이다.

비행기와 같은 산업체에서는 여러 단점에도 불구하고 NVP 기법을 사용하고 있을 것이다.

 

---

추가 자료 리스트

• 1번
• 2번