Distributed System은 Failure을 어떻게 탐지할까? — Heartbeat (1)
일단 Distributed System의 Failure Detection 대해 이야기를 시작하기전에, 사람에 대해 먼저 이야기를 하고싶다.
만약 내가 길을 걸어가다가 갑자기 쓰러지는 상황이 생긴다고 가정 해보자.
여기서 가능한 시나리오는 무엇일까?
- 내가 기절 했지만 어떻게든 지나가는 사람들에게 도움을 요청한다.
- 지나가던 사람들이 나에게 달려와서 내 심장 박동/맥박을 체크한후 조치를 취해준다.
당연히 기절한 나는 아무런 일도 할수 없으므로 2번만이 가능한 시나리오 이다.
Distributed System의 각 노드들도 이와같이 Fail한 당사자가 System에 자신이 Fail했다는 사실을 알릴 수 없기에, 다른 노드 혹은 노드들이 계속 Failure을 탐지 해주어야 한다. 그렇게 하기위해서 Distributed System은 노드들끼리 각자의 상태를 공유하고 Failure을 감지한다. 이것을 Heartbeat라고 하며, 오늘은 이 Distributed System의 Heartbeat에 대해 알아보자.
Distributed System의 Failure Detection(heatbeat)은 4가지 점이 중요하다
- Completeness
- Accuracy
- Speed
- Scale
Completeness
- 모든 Failure가 감지 된다.
Accuracy
- 감지된 Failure가 오탐이 아니다 (No False Positive).
Speed
- Failure가 일어났을때 신속히 발견한다.
Scale
- 각 노드의 부하(Load)가 낮다 (Node의 개수가 늘어나도 소화 가능),
- Single point of failure (한 노드가 Fail했을때 모든 시스템이 Down)이 없다.
Completeness와 Accuracy는 인터넷처럼 불안전한 통신 방법으로는 둘 다 가질 수 없다. 즉 모든 Failure가 감지가 되면서 감지간 된 Failure들에 하나의 오차도 없는것은 불가능하다. 만약 가능하다면 Consensus라는 문제를 해결하는데 Consensus라는 문제는 수학적으로 불가능하다고 증명이 되있다. 이 Consensus라는 문제에 대해서는 나중에 알아보자.
사람이 쓰러진걸 확인을 못하는 것 과 사람이 쓰러졌다고 오판을 하는 것 둘중에서는 어떤게 더욱 심각할까?
당연히 쓰러진 사람을 감지를 못하는것이 더욱더 중요하다. 마찬가지로 Distributed System에서도 대부분의 경우에 Completeness를 더욱더 중요시한다. Failure가 일어났을때 탐지를 못하면 아예 대처를 할 수 없지만 (Data Loss같은 문제를 야기할수 있다), False Alarm같은 경우에는 과대응을 통해 성능저하가 있을 뿐, 시스템적으로 완벽함을 유지할 수 있다.
그러므로 대부분의 경우에는
- Completeness는 보장
- Accuracy는 부분적으로 보장 / 확률적으로 보장
하는 방식을 선택하게 된다.
Heartbeat의 종류에는 크게 다음 네가지가 있고
- Centralized
- Ring
- All-to-All
- Gossip
Heartbeat가 아닌 다른 종류의 Failure Detector는 Swim Protocol이라는 방식이 있는데, 다음 글에서는 Heartbeat 네종류의 장단점을 분석하고 실제로 어떻게 판단하는지에 대해 알아보자.
(AWS s3에서는 Gossip Heartbeat를 쓴다는 루머가 있다!)
Distributed System에 관해서 쓰는 글들은 많은 부분들이 University of Illinois — Urbana-Champaign의 CS425 수업에서 가져 왔으며, 2020년 가을 수업을 진행한 교수인 Indranil Gupta에게 감사를 표한다. Lecture Slide는 https://courses.engr.illinois.edu/cs425/fa2020/lectures.html에서 찾아볼 수 있다.
