문서요약 - 분산 시스템 설계에 대한 소개 by Google Code University

제목: 분산 시스템 설계에 대한 소개(Introduction to Distributed System Design)

저자: Google Code University

문서유형: 웹 자료(약 8페이지), 2008년

 

분산 시스템 설계의 기본에 대하여 기술한 튜토리얼 자료

---

분산 시스템의 특성

신뢰할 수 있는 분산 시스템은 반드시 아래의 특성을 가져야 한다.

• 결함 허용(Fault-Tolerant): 부정확한 액션 수행 없이 컴포넌트 실패로부터 복구할 수 있다.
• 높은 가용성(Highly Available): 일부 컴포넌트가 실패 하였어도 오퍼레이션을 복구하여 서비스 제공을 재개할 수 있다.
• 복구가능성(Recoverable): 실패한 컴포넌트가 그 원인이 수정되면 재시작하여 시스템에 합류할 수 있다.
• 일관성(Consistent): 동시성(concurrency)과 실패(failure)의 존재 하에서도 시스템이 다수의 컴포넌트를 사용하여 액션들을 조정(coordinate)할 수 있다.
• 확장가능성(Scalable): 시스템의 일부 측면이 더 큰 규모로 확장되어도 정확하게 동작할 수 있다. 예, 시스템이 실행 중인 네트워크의 크기가 증가됨, 사용자 수 또는 서버 수가 증가됨, 시스템의 전체 부하가 증가됨 등
• 성능 예측가능성(Predictable Performance): 의도된 반응(responsiveness)을 적시에 제공하는 능력이 있다.
• 안전(Secure): 시스템이 데이터와 서비스로의 접근을 인증한다(access authentication).

 

위에 열거한 특징을 가지도록 분산 시스템을 설계하려면 반드시 ‘실패에 대비한 설계(design for failure)’를 해야 한다.

하드웨어 실패와 소프트웨어 실패

• 분산 시스템 설계에서 실패 처리(handling failures)는 중요한 주제이며, 실패는 크게 하드웨어 실패와 소프트웨어 실패의 두 개 카테고리로 구분된다.
• 80년대 후반까지는 하드웨어 실패(hardware failures)가 주된 문제점이었지만 이후 기술 개선으로 하드웨어 신뢰성이 크게 향상됨. 오늘날은 대부분의 문제가 연결 장치(connections devices)나 기계적 장치(mechanical devices)와 관련됨. 예, 네트워크 실패, 드라이브 실패 등
• 소프트웨어 실패(software failures)는 분산 시스템의 중요한 이슈로 엄격한 테스팅을 거쳤다 하더라도 예상치 못한 다운 시간의 많은 부분이 소프트웨어 버그에 기인한다(약 25-35%).

잔존 버그(residual bugs) 분류

상당 시간 동안 운영 중인 성숙 시스템(mature systems)에 잔존하는 버그들은 크게 아래 두 가지 카테고리로 나뉜다.

• 하이젠버그(Heisenbug): 관측이나 연구의 대상이 되면 사라져 버리거나 그 특성이 바뀌는 것 같은 버그. 예, 프로그램의 릴리즈 모드 컴파일에서는 나타났다가 디버그 모드에서 조사를 하려 하면 나타나지 않는 버그
• 보흐버그(Bohrbug): 하이젠버그와 달리 조사 시 사라지거나 그 성질이 바뀌는 일이 없는 버그. 보흐버그는 잘 정의된 조건 집합 하에서 신뢰성 있게 모습을 드러낸다(즉, 동일한 조건을 주면 항상 같은 모습을 보이는 버그).
• 하이젠버그는 로컬 시스템에서 보다는 분산 시스템에서 더 보편적으로 나타나는 경향이 있는데, 그 이유 중 하나는 프로그래머가 동시 프로세스(concurrent processes)의 상호작용에 대한 명확하고 포괄적인 뷰를 가지는데 어려움이 있기 때문이다. 

분산 시스템에서 발생할 수 있는 실패 타입

• 중단 실패(Halting failures): 컴포넌트가 그냥 멈추어버림. 즉, 살아있음을 알리는 심장 박동 메시지(heartbeat messages)를 보내는 것을 멈추거나 요청(requests)에 응답하지 않는다. 타임아웃 말고는 이 실패를 발견할 방법이 없음. 예) 컴퓨터 동결(freezing)
• 공지 후 중단(Fail-stop): 타 컴포넌트에 일종의 알림을 주면서 중단 실패(a halting failure)가 발생. 예) 네트워크 파일 서버가 자신의 클라이언트에게 곧 다운될 것임을 알림
• 생략 실패(Omission failures): 주로 버퍼링 공간 부족으로 인해 메시지를 보내거나 받는데 실패함. 메시지는 전송자나 수신자 쪽에 알림 없이 폐기됨. 라우터가 과부하 될 때 발생할 수 있다.
• 네트워크 실패(Network failures): 네트워크 연결이 깨진다.
• 네트워크 분할 실패(Network partition failure): 하나의 네트워크가 두 개 또는 그 이상의 배타적인 서브네트워크(sub-networks)로 분할됨. 서브네트워크 내에서는 메시지 전송이 가능하지만 서브네트워크들 간의 메시지는 유실됨. 이 실패는 네트워크 실패(a network failure) 때문에 발생할 수 있다.
• 타이밍 실패(Timing failures): 시스템의 시간적인 속성(a temporal property)이 위반됨. 예, 프로세스를 조정하는데 사용되는 여러 다른 컴퓨터 상의 클락이 동기화되지 않음, 메시지가 임계 기간(a threshold period)보다 길게 지연됨 등
• 비잔틴 실패(Byzantine failures): 다양한 유형의 잘못된 동작. 예, 데이터 훼손이나 유실, 악의적인 프로그램에 의한 실패 등

8가지 가정 오류(8 Fallacies)

실패에 대비한 설계(design for failure)를 위해서는 시스템의 컴포넌트 신뢰성에 대한 어떤 가정도 하지 않도록 주의해야 한다. 분산 시스템을 처음 구축하는 이들은 종종 아래와 같은 8가지 가정을 하게 되는데 이는 8가지 오류(the "8 Fallacies”)로 알려져 있다.

①     네트워크를 신뢰할 수 있다.

②     지연(Latency)이 0이다. Latency는 데이터 요청을 시작한 시점과 실제 데이터 전송이 시작되는 시점 간의 시간

③     대역폭(Bandwidth)이 무한하다. Bandwidth는 통신 채널의 용량(capacity)에 대한 측정치로, 높을수록 더 많은 정보를 전달할 수 있음

④     네트워크가 안전하다.

⑤     토폴로지가 변하지 않는다. Topology는 네트워크 구축 시 적용되는 다양한 구성(configurations)으로 링, 버스, 스타, 망사형 등이 있음

⑥     하나의 관리자(administrator)가 있다.

⑦     운송비(Transport cost)가 0이다.

⑧     네트워크가 동질적(homogeneous)이다. 즉, 네트워크가 단일 네트워크 프로토콜을 가동