분산시스템 (7) Fault tolerance

- 주제: Fault tolerance

장애가 발생했을때 어떻게 해야 하는지.

 

 

 

01. 분산시스템은 기본적으로 Faulty하다(장애에 취약하다).

1) 왜? 데이터센터는 24시간 내내 작동하기 때문.

새벽에도 해당 서버를 사용하는 서비스는 얼마든지 존재한다. 그 서비스를 작동시키는 인프라도 계속 작동해야만 한다.

2) 장애가 하드웨어에만 발생하는건 아니다. 소프트웨어에서도 가능.

분산시스템에서의 장애는 - 하드웨어에 국한되어 있지 않다.

 

 

- 개념 정리

1) Errors: 사람의 실수. 물리적 세계와 연결.

2) Fault: 부정확한 결과물. 정보화 세계와 연결.

3) Failure: 관측 가능한 부정확한 행동. 서비스를 이용하는 사용자들에게 '관측'되어야 함. 외부 세계와 관련.

거의 유사한 단어. 용어가 엄밀하게 구분되지 않는다.

 

1) Fault tolerance(결함허용성, 내결함성, 결함포용성): 장애가 발생해도 서비스가 정상적으로 작동해야 함(문제 발생 이전과 차이가 없어야 함).

High availability보다 요구사항이 더 높다(결함허용성이 고가용성을 기본 조건으로 깔고 간다).

2) High availability(고가용성): 장애가 발생해도 서비스는 기능은 해야 한다(성능이 좀 떨어지더라도).

3) Reliability(신뢰성): 시스템이 얼마나 '안정적'인가. 예측 가능성 관련.

일반적으로 사용하는 단어.

비슷한 개념이고 구분해서 사용하지는 않지만 - 엄밀하게 다른 용어이다.

 

 

1. Failures의 구분

 

1) Crash failures: 가장 일반적인 실패. 서버가 멈추면 발생한다. 서버가 작동을 멈추기 전까지는 correctly하게 기능했어야 한다. 이미 이상하게 작동하고 있었으면 Carsh failures가 아니다.

 

2) Omission failures: 생략하는 것. 서버가 요청에 대해 답하는 것을 실패하는 것이다. Omission 안에 Crash가 포함된다.

- Receive omission: 요청 자체를 받는것을 실패했다.

- Send omission: 요청을 받는건 성공했지만 답장을 보내는 것을 실패했다.

 

3) Timing failures(=Performance failures): 서버의 답장이 정해진 시간을 초과한 경우.

ex. 서버가 요청을 받았을 때 - 3초 안에 답장해줘야 하는데 하지 못했다면.

- Crash/Omission은 Timing의 서브셋이다. 왜?

후자는 답장 자체를 못한 것. '답장하지 못했다' = 주어진 시간 내에 답장하지 못함과 동일.

여집합은 정상적으로 요청을 받고 답장 여부와 관계없이 데드라인을 벗어난 것.

 

4) Byzantine failures: 임의의 장애. 서버가 임의의 시간에 임의의 답장을 생성할 수 있다.

모든 하위에 있는 장애들을 포함하고 있다. 즉, 뭔가 이상하게 작동하는 것을 말한다.

여집합은 Correct miss. 주어진 시간 안에 답장했더라도 그 결과물이 잘못되었다면 포함된다. 결과물이 잘못된 것.

 

그 외에도 failures의 종류는 굉장히 많다. 이때 용어는 마음대로 부르는 편.

하지만 크게 구분하면 위의 4가지이다.

 

 

2. Crash failures

- 하드웨어와 소프트웨어 양쪽에 이유가 있을 수 있다.

- 하트비트 메세지/타임아웃 메세지를 통해 발견한다. 살아있냐고 물었는데 답장이 안 오면 - 장애 발생 판단.

1) synchronous systems: 답장이 와야 요청을 보낸다.

2) asynchronous systems: 요청을 다 던진다 - 답장이 오든 말든. 

전자와는 달리 후자에서는 '살아있는지의 하트비트 메세지'가 느리게 왔더라도 구분하기 힘들다. incorrect.

 

- Fail-stop failures: 어떤 노드가 다른 노드의 장애를 realiable하게 알 수 있으면, fail-stop이라 부른다.

항상 칼같이 정확하게 장애를 탐지하는 것이다. 대개의 경우 synchronous systems에 국한된다.

 

- 장애가 발생했을때 복구를 어떻게 하는가?

일반적으로는 operators가 복구한다.

 

 

3. High availability와 fault tolerance을 어떻게 제공하는가?

1) High availability는 레플리카를 만들면 가능하다.

2) fault tolerance는 "cloning"을 사용.

- 동일한 요청을 보내고, 더 빠른 반응을 취한다.

- failures를 감춘다: 다른 서버에 동일한 요청을 보내왔기 때문에.

 

1) 클라이언트가 기존에는 요청을 1에게만 보내다가, 1에게 장애가 발생하면 2에게 보낸다 - High availability 충족.

2) fault tolerance는 평소에도 1, 2 모두에게 요청을 보낸다. 둘은 동일한 요청을 처리한다.

이때 운영체제가 굉장히 복잡하기 때문에 동일한 기기라고 하더라도 요청 처리 시간이 달라질 수 있다.

처음부터 모든 서버에 요청을 보내놓으면: 빠른것만 취하면서 클라이언트 입장에서는 Timing failures가 발생해도 다른 빠른걸 취하기 때문에 모르게 된다.

 

단점: 서버가 여러대가 있다. 그런데 cloning을 하면 모든 서버가 동일한 요청을 처리하기 때문에: 서버를 늘려도 동일한 처리량만 처리하게 된다.

즉, 성능 <-> tolerance 트레이오프 관계.

 

 

4. Byzantine failures에 왜 신경을 써야 하는가?

: 서버는 잘못된 반응을 잘못된 시간에 보낼 수 있기 때문에.

 

1) 리더가 죽어버려서 팔로워 중에서 새로운 리더를 선출하는 경우에, 죽어버린 리더를 발견했는데도 방송하지 않는 경우 - 서비스가 더이상 작동하지 않는다.

2) 분산시스템을 데이터센터에 국한하고 있지만 사실 서버들에만 적용되지는 않고, 여러대의 서버들이 하나의 목표를 위해 협업하는 것이기 때문에 - 블록체인 네트워크가 가장 대표적인 예이다. (설명이 아주 길어졌다.)

 

왜 Byzantine이냐? 동로마제국. 15세기에 멸망.

 

굉장히 군사적으로 요지였다.

둘러싸여서 오스만 제국에게 멸망했다.

 

- 내일 오전 9시에 공격하자고 전달을 해야 한다. 육지에서도, 바다에서도 정확하게 전파되어야 한다.

정확하지 못했다면 실패.

- 메세지 전달시 - '적에 의해 메세지가 위조될 수 있고', '장군이 배신을 할 수도 있다'.

- 각각의 장군들의 정보를 신뢰할 수 없는 경우: 신뢰할 수 있는 장군이 최소 몇명이 있어야 하고, 어떠한 규칙으로 전송되어야 신뢰할 수 없는 장군의 존재에도 불구하고 성공적으로 목표를 달성할 수 있는가.

 

유래에 대해서만 알면 OK.

 

 

 

02. 성능 하락 문제

- Fail-slow fault: '성능이 갑자기 떨어지는 문제'

- Fail-slow hardware: 기능적으로 문제가 없지만 성능이 기대한만큼 나오지 않는다.

 

- Fail-slow hardware is "not real".

Recent studies: REAL.

 

 

1. 원인:

내부적으로는 1) 디바이스 자체에 에러 존재. 2) 펌웨어에 버그가 있는 경우.

외부적으로는 3) 온도 4) 환경적 이유 등등.

 

1) 내부적 원인

- Device errors: 하드웨어 자체의 문제.

- Firmware bugs가 대표적.

성능이 갑자기 엄청나게 떨어질 수 있다. 

 

2) 외부적 원인

- 온도

- 전력 문제: 모든 서버에 전력이 고르게 들어가지 않는 문제

- 환경적 문제: 찝힌 선, BIOS

 

3) 증상

- Permanent slowdown 영구적인 속도 느려짐 (증상이 계속 지속되는 것 - 찾기 쉬움)

- Transient slowdown 일시적인 성능 느려짐 (특정 조건에서만 발생 - 찾기 어려움)

- Partial slowdown 부분적인 성능 하락

- Transient stop 성능이 아예 일시적으로 멈추는 것

 

 

2. 특징

1) 연쇄적으로 영향을 준다 Cascading impacts

 

ex. 어떠한 원인으로 인해 하나가 죽어버리면 -> 연쇄적으로 영향을 준다.

 

2) 얼마나 빈번한가?

- 레어하지만 발생하는 순간 치명적이다.

- 발견하는게 굉장히 힘들다. 17%는 한달이 걸려야 찾아낼 수 있다. 

 

- Cascading: 전 분야에 걸쳐서 모니터링해야 한다.

- full-stack monitoring이 필요. 

 

 

3. 교훈

Operators

- 온라인 diagnosis: 실시간 모니터링

- full-stack monitoring

 

- 시스템 디자이너

1) 오류 메세지 출력 처리를 명시적으로 해줘야 한다

2) fail-slow가 발생하면 fail-stop로 변경해버리는게 더 탐지가 쉽다.