[EVA] 4.9 Escalation - Patterns for Fault Tolerant Software 2013.09.06 - Updated : revision 1.1 (한글화, 내용 수정)

1. 4.9 Escalation
EVA community 정충선 (gomjang@gmail.com) 2013.09.07

2. 단계적 확대의 배경지식
• 시스템은 컴포넌트의 오류나 결함을 처리하거나 완화하려는 많은 옵션을 갖는다.
• 오류처리는 완료하지 않고, 지연 될 수 있다.
• 오류처리는 시스템이 정상동작이 가능하도록 꼭 성공해야 한다.
• 시스템은 Minimize Human INVTERVENTION (5)을 원칙으로 스스로 관리되게 설계한
다.
• SOMEONE IN CHARGE (8)를 통해서 컴포넌트의 역할이 할당된다.
• ‘단계적 확대’에 부적절한 활용 패턴
– CORRECTING AUDITS (2) : 성공하지 못할 수 있다.
– ROLLBACK (32), ROLL-FORWARD (33) : 동작하지 않을 수 있다.

3. Architectural Patterns의 관계

4. 오류처리가 성공적이지 못하다면?
• 아무일 없이 동작한다. 그 이후는?
• Ex) 녹음 작업 중 이물질(오류)이 붙은 경우.
– 음반은 문제없이 동작한다.
– 단, 특정 지점에서 잡음(오류)가 반복된다.
=> 오류 상태를 벗어나기 위해 무언가 강력한 조치가 필요하다.
Bug (ERROR)

5. 끝없이 반복되는 복구작업...
SYSTEM Warning
ERROR
…
해결 못한 복구 시도
끝없이...
SYSTEM Normal
Running
…
손상 없이 복구
SYSTEM Warning
ERROR
…
과도현상 유발
(원인 : 오류 메시지, HW 문제)

6. 과도 현상의 종류
과도현상 종류: 오류 메시지
하드웨어 결함
소프트웨어의 정확하지 않은 처리
정상적인 오류처리
정상적인 오류처리를 복구 시켜버리는 것을
피해기 위해, Riding Over Transients (26)을
통합해야 한다.
…
대부분 단순히 같은 작업을
반복하는 것은 올바른 작업이 아니다.
-> 시스템이 루프에 같이게 된다.
Limit Retries (35) 를 사용하여 예방.
복구 작업이 데이터를 삭제하는 경우, 이 작업을 반복하는 것은 안전하지 않다.

7. 더 강력한 오류처리 대안
• 더 강력한 대안은 오류 처리가 오류지역을 줄이게 한다.
– 더 강력한 오류 처리를 하면 할 수록, 결함과는 멀어지지만,
– 더 강력한 오류처리는 컴포넌트 동작을 방해하는 것을 포함한다.
SYSTEM Warning
< pre-error state >
첫 번째 시도
CHECKPOINT (37)
ROLLBACK (32)
RESTARTED (31)
FAILOVER (36)
실패
실패
“실패”

8. 더 강력한 대안
• 모든 수정 작업(에러 복구)는 더 강력한 대한이 있다.
• Escalation의 예) - (4ESS™ : Telephone switching systems)
– 짧은 시간에 동일한 데이터가 여러 번 오류가 날 경우,
‘Phase 1’: 소프트웨어 데이터 구조를 다시 초기화.
‘Phase 2’: 더 강력한 레벨.
‘Phase 3’: 시스템이 자동으로 할 수 있는 최상의 레벨.
(모든 동적 데이터를 초기화. 대규모 Data Reset (41) )
Restart a component process Restart a group of processors Restart an entire processor
데이터 오류 발견CORRECTING AUDITS (2) 시스템이 수정
A LEAKY BUCKET COUNTER (27)
얼마나 자주 발생하는지 계산
SOMEONE IN CHARGE (8)
Escalation의 주최
3번 시도 실패 시

9. Escalation의 제약
• 조치를 위해 Someone in Charge (8)에 보고해야 한다.
• 오류 및 장애의 특성에 따라 사람의 개입이 필요할 수 있다.
(단, 사람이 시스템 동작을 재정의 할 수 있는지 확인이 필요하다)
• 정의된 복구 목록은 관리자가 사용 할 수 있어야 한다.
(목록 중 가장 성공확률이 높은 것을 시작)
• 복구 작업은 시스템의 다른 동작에 영향을 최소화 해야 한다.
– 이 조건이 불만족 시, 시스템이 더 느려지거나 방해될 수 있다.
• 응용 프로그램들 마다 상황이 다르기 때문에 일반적인 Escalation 단계를 만
들 수 없다.

10. ESCALATION 설계 방법
• 특정 시간 내에서 너무 많은 작업이 발생할 경우 새는 BUCKET
COUNTER (27) 가 유용하다.
• 시스템의 오류나 결함의 원인을 이해하는 것은 필수다.
• 때때로 부분작업을 재개하는 것이 최선이다.
(오류 기능은 분리하고, 나머지 부분을 최대로 정상으로 작동 시킨다.)
– 부분 작업은 오류가 제한적이거나 해결방법이 있을 때의 선택이다.
예) - Weir and Noble in [NW01]
• 계산이 실패 시 대략적인 값을 사용하여 동작한다. (계산 실패에 멈춰있지 않고, 대략적인 값으로 진행)
– 진행 중 Escalation의 어느 단계에 있는지 잃을 경우 (메모리 손상, …), 중간 단계
라고 정하고, 작업을 진행한다. (추 후 정확한 단계 값을 조절)

11. 정리
• System
– 시스템은 컴포넌트의 오류나 결함을 처리하거나 완화하려는 많은 옵션을 갖는다.
– 오류처리는 완료하지 않고, 지연 될 수 있다.
– 오류처리는 시스템이 정상동작이 가능하도록 꼭 성공해야 한다.
– 시스템은 Minimize Human INVTERVENTION (5)을 원칙으로 스스로 관리되게 설계한다.
– SOMEONE IN CHARGE (8)를 통해서 컴포넌트의 역할이 할당된다.
• 비효율 적일 수 있는 patterns
– CORRECTING AUDITS (2) : 성공하지 못 할 수 있다.
– ROLLBACK (32) or ROLL-FORWARD (33) : 작동하지 않을 수 있다.
• 효과적인 patterns
– LIMIT RETRIES (35)
– RIDING OVER TRANSIENTS (26)
– Escalation (CORRECTING AUDITS (2), A LEAKY BUCKET COUNTER (27))
• CHECKPOINT (37)
• ROLLBACK (32)
• RESTARTED (31)
• FAILOVER (36)
• Phase 1 - Phase 2 - Phase 3(DATA RESET (41)) by SOMEONE IN CHARGE (8)
• 부분 분해
• SLOW IT DOWN (53)