아키텍쳐

[강의 정리] Distributed System 2.4: Fault tolerance and high availability

hayz 2023. 3. 15. 01:08

# 강의 영상

정리

우리가 분산 시스템을 구축하는 이유중의 하나는 단일 컴퓨터를 이용했을 때보다 높은 안정성을 제공하기 위해서입니다. 이제 이전 과정에서 살펴본 시스템 모델들 (network, nodes, timing) 의 관점으로 이러한 아이디어를 더 살펴보도록 하겠습니다. 

 

그 전에 Availability 가 어떤 것을 의미하는지 정리해보도록 하겠습니다. availability 는 한국어로 하면 가용성이라는 뜻인데요, 예를 들어 현재 운영되고 있는 하나의 웹 서비스가 있다고 했을때, "Service unavailability = downtime = 손실" 로 볼 수 있고, "Availability = uptime = 서비스 정상 동작 시간"  이라고 볼 수 있습니다. availability 는 중요한 서비스를 제공할 수록 더욱 필수적인 요건으로 볼 수 있는데요, 만약 1년에 3.7 일 정도가 서비스 다운 되었다고 했을때 이는 availability 가 99% 라고 할 수 있습니다. 반면 1년에 5.3분 정도 서비스가 다운 된다고 하면 99.999% 의 availability 를 보장 한다고 할 수 있을 것입니다. 

 

그렇다면, 서비스가 가능한 상태라고 하는 기준은 무엇일까요? 서비스를 실행하는데 5초 안에 응답이 오면 가능한 상태라고 볼수 있을 까요? 30초는 아니면 1시간은 안될까요? 이러한기준을 명확히 하기 위한 것이 Service-level objective (SLO) 입니다. 이 SLO 에서 성공적인 서비스란 "최소 하루에 99.9% 의 응답이 200ms 안에 나가야 한다" 라는 식의 조건을 명시할 수 있습니다. 그리고 이러한 SLO 를 지키겠다고 약속한 서비스에 Service-level agreement (SLA) 를 부여합니다. 서비스를 이 SLO 조건을 지키겠다는 약속하에  SLA 를 받은 것인데 만약 지키지 못한다면.. 사용자에게 보상을 해줘야 할 수도 있습니다. 

 

가용성을 지키기 위한 방법으로 우리는 fault (노드 충돌 혹은 네트워크 혼선 등의 장애 상황)를 최소한으로 발생시키거나, 특정 부분이 fault 되어도 서비스 제공에 이상이 없도록 하는 방안을 생각해 볼 수 있습니다. 그리고 여기서 후자의 방안을 fault tolerance 라고 합니다. 즉, fault 가 생겨도 서비스가 감내 할 수 있는 버틸 수 있는 상태를 이야기 합니다. 물론 전자의 방법으로 fault 를 줄여보고자 할 수도 있지만 이는 리소스 비용을 감수 해야 하고, 그렇다 하더라도 "fault 가 0 이 되는 것은 불가능에 가깝기 때문에 많은 분산 시스템은 fault tolerace 한 시스템을 만드는 방법에 초점을 맞추고 있습니다."

 

fault tolerance 한 시스템에 가기 위한 첫번째 단계는 "failure detector" 를 이용하여 faults 를 감지하는 방법이 있습니다. failure detector 는 보통 충돌 상황을 감지 할 수 있는데 다른 노드들에 주기적으로 메시지를 보내 통신을 확인하며, 일정 시간 안에 통신이 되지 않는 노드를 감지합니다. 그런데 이런 식으로 timeout 기반의 감지 방식은 동기 처리 시스템 에서는 동작할 수 있지만, 비동기 처리 시스템의 경우에는 별도의 대기 시간이 없으므로, 다른 방식을 사용해야 합니다.

 

우리는 추후에 이러한 failure detector 를 이용해 fault tolerance 한 매커니즘을 만들고, 자동 복구하는 방안에 대해서 더 자세히 살펴보도록 하겠습니다. 이렇게 fault tolerance 한 서비스를 제공한다면 사용자 측 뿐만 아니라 서비스를 관리하는 관리자 측에서도 서비스를 하나씩 중단하고 시작하는 무중단 rolling update 를 지원할 수 있게 됩니다. 또한, 최대한 100% 의 가용성을 보장하기 보다 어느정도의 fault 를 감내하는 것이 경제적으로 더 이로울 것입니다.