1. Fault Tolerance 1
1 장
장애 감내에 대한 소개
황희선

2. 시스템의 신뢰성 (Dependability)
▫ 의도한 기능을 수행하는데 필요한 시스템의 신용도
▫ 주요 속성
안정성 (reliability), 가용성 (availability), 안정 (safety), 보안
(security)
시스템의 신뢰성 향상을 위해 방법
▫ 결함회피 (Fault Avoidance)
▫ 결함은폐 (Fault Masking)
▫ 결함허용 (Fault Tolerance)
Fault Tolerance 2

3. Fault tolerance system
▫ 소프트웨어 , 하드웨어 구조와 시스템의 일부가 올바르게
동작하지 않더라도 그 기능을 지속할 수 있도록 설계된 시
스템
시스템 명세서
▫ 시스템 동작에 대한 요구사항을 정의
Failure( 장애 )
▫ 시스템 명세서대로 동작하지 않는 시스템의 동작
Fault Tolerance 3

4. Error( 오류 )
▫ 일으킬 수 있는 올바르지 않은 시스템의 동작 . 장애의 원인
 시간적인 오류
 값의 오류
Fault( 결함 )
▫ 시스템에 존재하는 결점 . 모든 시스템에 존재함
▫ 잠재된 결함 : 숨어 문제를 일으키지 않음
▫ 활성화된 결함 : 잠재되어 있는 결함이 발생할 조건이 되어
잘못된 기능을 수행한 경우로 , 오류로 나타남
Fault Tolerance
4

5. Fault( 결함 ) ,Error( 오류 ) ,Failure( 장애 )
의 순서도
Fault Tolerance
5
Cause of Error :
Fault
Subsystem
Unintended state :
Error
Deviation from
Intended service :
Failure
Under specific consideration

6. Fault Tolerance 6
타입
시스템이 멈추지 말아야 할 때 , 문제가 생겨 멈춤
시스템이 잘못된 결과를 도출
시스템이 서비스되지 않음
시스템이 사용자의 조작에 반응을 하지 않음

7. 오류의 타입 설명
시간 조건 또는
경쟁 상태
서로 통신하는 프로세스들이 동기화를 하지 못하여 자원을 서로 요청
하는 일이 발생
무한 반복
정지 조건도 없고 공유한 자원에 대해 요청한 응답이 없어 반복문
(loop) 이 계속 수행됨
프로토콜
사용하고 있는 프로토콜의 규약을 따르지 않아 메시지를 전송하는 스
트림에 오류가 있는 경우 . 잘못된 메시지가 전송되거나 , 메시지가 적
절하지 못한 때에 전송되거나 , 순서가 맞지 않을 수 있음
데이터 불일치
두 위치 ( 예를 들어 , 메모리와 디스크 , 또는 네트워크 상의 서로 다
른 장치 ) 에 있는 데이터가 서로 일치하지 않음
오버로드 조건을
제어하는데 실패
시스템이 작업량을 제어할 수 없는 경우
잘못된 전송
또는 기록
시스템의 결함으로 메모리의 잘못된 위치에 데이터를 쓰거나 잘못된
위치로 데이터를 전송하는 경우
Fault Tolerance 7

8. 원인의 타입 설 명
부정확한 요구사항
명세서
소프트웨어 설계자와 개발자가 잘못된 요구사항을 전
달받는 경우
부정확한 설계
순수하게 소프트웨어 입장에서만 작업한 경우
요구사항을 설계로 옮기는 과정이 정확하지 않은 경
우
코딩 오류
설계를 코드로 옮기는 과정에서 결함이 발생
-문법적 결함
-문법적으로 올바른 코드이지만 의도한 기능을 수
행 하지 못하는 경우
Fault Tolerance 8

9. Fault Tolerance 9
전 화 시스템
요구사항 전화 시스템은 올바른 수신자에게 연결되어야 한다
결함 시스템에 잘못된 경로 선택 데이터가 저장되어 있음
오류 잘못된 네트워크 경로를 찾아냄
장애 시스템에 문제가 발생하여 올바르게 연결시키지 못함

10. Fault Tolerance 10
제조 공정에서 무엇인가를 뚫는데 사용되는 드릴이 달린
로봇 팔
요구사항 로봇 팔은 정확한 위치에서 드릴을 내려야 한다
결 함
로봇의 팔을 얼마나 돌릴지 결정하는데 사용되는
데이터 상수에 소수점 위치가 잘못됨
오 류 로봇 팔의 방향 결정이 잘못됨
장 애 로봇 팔이 잘못된 방향에서 드릴을 내려버림

11. Fault Tolerance 11
계산서 작성 시스템
요구사항
고객이 자신이 받은 서비스에 대한 금액만 지불요청
받도록 하는 것
결 함
통신 채널에 문제가 있어 빌링 시스템에서 받은 메
시지가 훼손되거나 , 전송할 메시지를 준비하는 컴포
넌트에 문제가 있음
오 류 잘못된 계정으로 금액이 부과됨 ( 빌링 시스템 오류 )
장 애 고객이 잘못된 금액을 부과 받는 것

12. Fault Tolerance 12
지구 기지에서 프로그램을 업데이트 받는 우주선
요구사항 우주선의 안테나는 지구 방향을 가리켜야 한다
결 함
업데이트 설계 담당자가 업데이트 할 메모리 범위를 잘못 계산
함
오 류
지구 기지의 새로운 프로그램은 우주선 프로그램의 잘못된 메모
리 범위를 업데이트 시키고 , 이는 우주선의 다른 프로그램 또
한 손상시켜 우주선의 명령어를 손상시킴
장 애
우주선의 안테나가 지구 방향이 아닌 다른 곳을 가리켜 지구
기지와 우주선과의 통신이 두절되어 임무를 수행하지 못함

13. Fault Tolerance 13
은행 시스템
요구사항 돈을 안전하게 보호해야 한다
결 함
1. 부정확한 계산 모듈
2. 지폐가 ATM 에 잘못 놓여진 경우 ( 담당자가 20 달러
지폐를 5 달러 칸에 놓아 버림 )
오 류 기계가 지폐 양을 잘못 센 경우
장 애 자동 인출기 (ATM) 가 고객에게 많은 돈을 지급

14. 다수 결함의 장애
예시
Fault Tolerance 14
유럽 우주국에서 개발한 Ariane 5 로켓
요구사항 비행기는 계획한 비행 경로에서 벗어나선 안된다
결 함 Ariane 4 와 Ariane 5 의 서로 다른 비행 경로 선택 기준 요구사항들
오 류 수평 속도를 급격하게 증가시킴
장 애 관성 기준 시스템에 장애를 일으켜 비행 경로에서 벗어나게 되고 , 자
폭 회로를 가동시킴
Fault_1
Fault_2
Fault_3
Fault_4
Fault_5
Fault_6
Error_1
Error_2
Failure

15. Consistent failures
▫ 장애가 항상 동일한 시점에서 발생 . 어떤 사용자나 시스템 평가
자가 살펴봐도 동일한 유형의 장애로 인식됨 .
▫ 예시
 시스템에 어떤 명령을 내려도 ‘ 1’ 만 찍는 경우
◦ Fail silent
장애가 장애가 있는 부분에서 올바른 결과를 냈거나 아무 결과를 내지 않는 현상
◦ Fail stop
 fail-silent 장애 후에 장애가 있는 부분이 중지되는 것 , crash 장애라고도 불림
 예시
 동작이 멈춰버린 셋탑
 보이저 우주선의 컴퓨터에서 발생한 장애  주제어장치에서 발생했다고 추측되
는 첫 번째 장애가 발생한 후 시스템이 고장

16. Inconsistent failures
▫ 경험하는 사람마다 다른 현상을 보이는 경우 .
▫ 양면성의 장애 , 악의적인 장애 , 또는 비잔티움 (Byzantine) 장애라
고도 불림 .
▫ 예시
 어떤 사람한테는 ‘ 1’ 을 보여주고 , 다른 사람한테는 ‘ 2’ 를 보여주는 경우
 특정 네트워크 주소로 접근하는 트래픽에 대해서만 경로를 잘못 찾는 경우
 시스템 이용자거나 네트워크 피어에게 네트워크 트래픽이 전혀 없거나 , 트래픽의
대부분이 부정확해서 전송을 받을 수 없는 경우
▫ Fault Tolerance 설계 기법
▫ 장애가 있는 기능에 경계를 형성하고 , 모든 장애를 fail-silent 장애로 변화
시켜 장애의 원인은 분명하지 않지만 , 장애가 발생한 부분을 명확히 알 수
있고 장애가 시스템 전체로 퍼져나가지 않도록 설계해야 함
Fault Tolerance
16

17. 장애 유형에 따른 필요 중복 시스템 구성
(N = failure 의 수 )
Fault Tolerance 17
장애 유형
장애 완화를 위한
컴포넌트의 최소 개수
예 시
Fail-silent failure N+ 1
전화 교환기 시스템
( 단일 장애만 처리하도록 설계됨 )
Consistent failure 2N + 1
우주 왕복선의 컴퓨터 제어 시스템
( 일관성이 있는 두 개의 장애가 동시에 발
생하여도 장애를 완화시킬 수 있도록 설계
되어 5 개 컴퓨터로 운영에 차질이 없다 )
Inconsistent
failure
3N + 1

18.  “ 결함” , “ 오류” , “ 장애” 를 명확히 구분하면 , 디버깅이 쉬워진다
 예시
Fault Tolerance 18
장 애 오 류 결 함 결 과
로봇 팔에서
발생한 장애
소프트웨어가 잘못된
방향으로 팔을 돌린 것
이 결함 결함 구분은 수정해야
할 부분을 결정상태를 변경시키는 값
의 오류로 발생한 결
함
Ariane5 의
장애
부정확한 명세서를
사용한 것
명세서에 예측한 비행
경로를 반영하지 않은
것 결함과 오류의 식별은
결함을 다루는 일을 명
료하게 한다ariane 5 의비행경로
가
ariane 4 의 비행경로
와 다른 것
재사용한 컴포넌트를
충분히 테스트하지 않
은 것

19.  시스템의 장애 감내의 측정 기준
 조건부 확률 ( 성공적으로 자동 복구됨 / 오류 발생 )
▫ 확률 ( 성공적인 오류 감지 )* 확률 ( 성공적인 오류 복구 )
▫ 확률 계산을 위해서는 광범위한 안정성과 장애 주입 테스트 시행 필요
 안정성과 가용성이 높은 시스템은 95% 이상의 커버리지 지향
▫ 예시 – 완벽한 Coverage 를 갖는 우주 왕복선의 항공 장치
• 네 개의 process 를 중복 설치 , 프로세서 통신 버스에 타이머를 장착하여 값의 무결
성을 검증
Fault Tolerance 19

20.  소프트웨어 안정성 공학에서 안전성 측정 방법
▫ 측정법 : 오랫동안 시스템을 관찰하여 장애율을 계산하는 방법
▫ 예측법 : 결함의 수를 예측하여 결함수를 토대로 장애율 ( 장애 기간과 횟수 ) 을 예측하는 방법
 시스템 설계나 평가 때 사용되는 신뢰도와 가용도의 측정 기준
▫ MTTF(Mean Time To Failure) 와 MTBF(Mean Time Between Failure)
▫ 시스템의 Reliability 계산 공식 : e-(1/MTTF)
▫ 관련 개념
• MTTR(Mean Time To Repair)
• FIT(Failures in Time) : 1*109
시간 동안에 발생하는 장애의 횟수
Fault Tolerance 20

21.  화성 탐사선
▫ 90 일간 설계된 화성 탐사선인 Spirit 호와 Opportunity 호
• 시스템 장애에 초점을 둔 경우 , 안정성은 1000 일 이상 지속될 정도로 우수함
• 임무 수행이나 결함 관리 측면에서는 6 개의 바퀴 중에 5 개만 동작하는 장애가 있었
음
 운행 중에 장애가 없어야 하는 항공기 항로 탐색 시스템
▫ 시카고에서 로스앤젤레스로 가는 비행의 경우
• MTTF 는 5 보다 크면 됨 ( 항공기가 지상에 정지해 있는 동안 발생한 장애는 정비가
가능하기 때문 )
• MTTR 은 반드시 낮아야 함 ( 항공사는 투자수익률을 극대화 하기 위해 항공기의 가
동률을 높여야 하기 때문 )
Fault Tolerance 21

22.  설계한 기능을 수행할 수 있는 시간을 백분율로 표현한 것
 시스템 Availability 계산 공식 : MTTF / MTTF+MTTR
 수치로 표현한 Availability
 가용성 예제
▫ Alcatel-Lucent 사의 4ESS™ 스위치
• 요구사항 : 40 년간 고장시간은 2 시간만 허용한다 즉 가용할 수 없는 시간이 연간 3 분이라는 의미
▫ 5ESS®
스위치
• 수년간 6 개의 9 에 해당하는 가용성을 달성
Fault Tolerance 22
표현 연간 고장 시간 ( 분 )
100 % 0
3 개의 9 99.9 % 525.6
4 개의 9 99.99 % 52.56
4 개의 9 와 한 개의 5 99.995 % 26.28
5 개의 9 99.999 % 5.256
6 개의 9 99.9999 % 0.5256
100 % 0

23.  하드웨어의 결함은 동작과 증상 , 소재의 물리적 현상을 토
대로 통계적으로 분석할 수 있다 .
 관련 토픽을 다루는 컨퍼런스와 저널
▫ 국제 안정성 물리학 심포지엄 (International Reliability Physics
Symposium)
▫ 전자 부품 및 기술 컨퍼런스 (Electronic Components and
Technology Conference)
▫ IEEE 저널 중 소자 및 재료의 안정성 (Device and Materials
Reliability)
▫ 고급 패키징 (Advanced Packaging)
▫ 반도체 회로 (Solid State Circuits)
Fault Tolerance 23

24.  소프트웨어 안정성 공학
▫ 시스템의 안정성을 모니터링하고 관리하는 실전 기술
▫ 소프트웨어를 개발하고 테스트하고 운영하면서 결함과 오류 , 장애의 통계
데이터를 수집함으로써 , 안정성 및 가용성과 관련된 파라미터를 모니터링
하고 관리하는 것
▫ ‘Handbook of Software Reliability Engineering [Lyu96]’ 에 소프트웨어 안
정성 공학과 관련 논문이 소개됨
 Fault tolerance system 의 신뢰도 해석법
▫ 안정성 증진 모델링
• 시간에 대한 결함의 수를 누적하여 그래프화 하는 것 , 예측 기법을 통해 기대 누
적 결함 개수를 산정하고 측정된 결과와 비교해 시스템이 남은 기간 동안 얼마
나 결함을 보일 것인지를 결정할 수 있다
▫ Markov 모델링
• 소프트웨어 컴포넌트를 포함하여 전체 시스템의 안정성을 예측하는 방법 , 중복
된 기술들을 분석하고 MTTF 를 예측할 수 있다
Fault Tolerance 24

25.  Markov 모델
▫ 시스템의 가능한 상태와 상태들 간에 전이 , 전이가 발생할 가능성 ( 확률 ) 로
시스템을 표현하는 것
▫ 상태 전이 확률은 과거에 대한 고려 없이 , 현재 상태만 고려함
• 상태 : 중복된 구성요소의 개수
• λ 장애율
• μ 복구율
• c 커버리지 계수
그림 간단한 복식 시스템의 Markov 모델
 Unavailability
▫ (1-c)2 λ/ µ + 2(λ /µ)2
, µ>> λ
Fault Tolerance 25

26.  성능과 안정성과의 관계
그림 안정성은 성능 요구사항 & 성능은 안정성 요구사항
 성능 장애
▫ 성능이나 안전성 요구 사항을 만족 못하는 경우 발생
▫ 예시 : 시간당 작업량이 30 만 건을 초과하여 50 만 건에 이르는 경우 성능 저하나 시
스템 전체가 마비될 수 있음 .
▫  시스템 아키텍트와 설계자는 성능 요구사항과 장애에 대한 대비책을 정확히 정의해
야 함
Fault Tolerance 26

27.  과부하 걸린 시스템의 장애 예
그림 시스템의 가능한 동작
 명세된 요구사항에 달성하는데 실패된 경우
그림 요구사항 충족에 실패한 경우
Fault Tolerance 27

28.  시스템의 처리량은 비용과 부하상황에 대한 신뢰성 간의 tradeoff
▫ 예시
• 미국 공공 통신사의 연구 ( 부하나 성능 오류가 시스템 정지 원인의 6% 정도이지만 , 이로 인해 50% 이상의 고객이 접속되어
있는 네트워크와 연결이 끊어지게 된다 )
 결함
▫ 처리 한계에 도달했을 때 이를 처리하기 위해 필요한 기술을 시스템이 갖추지 못한 경우 발생
▫ 필요한 조치를 명백하게 요구사항에 정의하고 , 이 요구사항을 충족시키기 위해 설계하고 개발함으로써 회피할
수 있음
 서비스 요청의 수가 한계를 넘어선 경우 오류로 인지하고 처리해야 함
▫ 예시
• 전화로 콘서트 티켓을 예매한다거나 아메리칸 아이돌과 같은 TV 쇼에서 투표를 유도하는 경우 , 시스템에 엄청난 부하를 초래
할 수 있다 .
• 자연 재해가 발생했을 때 , 해당 지역에 사는 친구나 가족의 상황을 파악하느라 걸려오는 엄청난 양의 전화
• 통신사의 특성 곡선
 Fault tolerant 시스템은
작업량의 포화 상태에서 시스템을 사용할 수 없는
순간 없이 작업들을 지속적으로 처리할 수 있어야 하며
작업량이 감소함에 따라 보통 때의 성능으로 회복 가능해야 함
그림 7 이상적인 부하 처리와 실제 부하 처리
Fault Tolerance 28

29.  http://www.beinrohr.sk/sxool/3roc/mas/AdSyMod/tsld
 http://www.utdallas.edu/~ilyen/course/realtime/fau
 http://i-bada.blogspot.kr/2012/04/mttfmtbf.html?m=
 “Patterns for fault tolerant software” 책 원본 ,
번역본
Fault Tolerance
29