1. 결함과 부분 장애
•
한 컴퓨터에서 프로그램을 작성할 때는 프로그램이 보통 상당히 예측 가능한 방식으로 동작한다.
◦
단일 컴퓨터에서 실행되는 소프트웨어를 믿지 못할 근본적인 이유는 없다.
•
네트워크로 연결된 여러 컴퓨터에서 실행되는 소프트웨어를 작성할 때는 근본적으로 상황이 다르다.
◦
부분 장애 = 분산 시스템에서는 시스템의 어떤 부분은 잘 동작하지만 다른 부분은 예측할 수 없는 방식으로 고장나는 것
◦
부분장애는 비결정적이라서 다루기 어렵다
1.1. 클라우드 컴퓨팅과 슈퍼 컴퓨팅
•
고성능컴퓨팅
◦
수천개의 CPU를 가진 슈퍼컴퓨터
◦
보통 일기예보나 분자 동력학처럼 계산 비용이 매우 높은 과학 계산 작업에 사용
•
클라우드 컴퓨팅
◦
멀티 테넌트 데이터센터
◦
IP 네트워크(이더넷)로 연결된 상용 컴퓨터 등 전통적인 기업형 데이터센터는 이 두 극단의 중간 지점에 있다.
◦
슈퍼컴퓨터에서 실행되는 작업은 보통 가끔씩 계산 상태를 지속성 있는 저장소에 체크포인트로 저장한다.
◦
장애가 발생하면 마지막 체크포인트로부터 계산을 재시작 한다.
▪
단일 노드 컴퓨터에 가깝다.
•
분산 시스템이 동작하게 만들려면 부분 장애 가능성을 받아들이고 소프트웨어에 내결함성 메커니즘을 넣어야 한다.
•
신뢰성 없는 구성 요소를 사용해 신뢰성 있는 시스템을 구축해야 한다.
◦
완벽한 신뢰성은 없다.
•
결함 처리는 소프트웨어 설계의 일부여야 하며 결함이 발생하면 소프트웨어가 어떻게 동작할지 알아야 한다.
2. 신뢰성 없는 네트워크
•
책에서 주로 다루는 분산시스템은 비공유 시스템으로 네트워크로 연결된 다수의 장비이다.
◦
네트워크가 유일한 통신수단으로 각 노드들은 서로 다른 장비의 메모리나 디스크엔 접근할 수 없다.
•
인터넷과 데이터센터 내부 네트워크 대부분은 비동기 패킷 네트워크로 노드는 다른 노드로 메시지(패킷)을 보낼 수 있지만 네트워크는 메시지가 도착할 것인지는 보장하지 않는다.
1. 요청이 손실
2. 요청이 큐에서 대기하다 나중에 전송
3. 원격 노드에 장애 발생
4. 원격 노드가 일시적으로 응답을 멈췄지만 나중에 다시 응답 시작
5. 응답이 네트워크상에서 유실
6. 응답이 지연되다가 나중에 전송
Plain Text
복사
보장되지 않는 원인
•
전송 측은 패킷이 전송됐는지 아닌지조차 구변할 수 없기때문에 타임아웃을 통해 해당 문제를 다룬다.
2.1. 현실의 네트워크 결함
•
아직 신뢰성 있는 네트워크를 만드는 완전한 방법은 없다.
•
한 회사의 제어된 환경에서도 네트워크 문제는 놀랄만큼 흔하게 발생한다.
•
네트워크 결함이 드물더라도 결함이 일어날 수 있다는 사실은 인지하고 소프트웨어가 이를 처리할 수 있도록 설계 해야 한다.
◦
오류 처리가 정의되고 테스트되지 않는다면 나쁜 일이 제멋대로 생길 수 있다.
•
반드시 네트워크 결함을 견뎌내도록 처리할 필요는 없다.
◦
네트워크가 믿을 만하다면 문제가 있을 때 그냥 사용자에게 오류 메시지를 보여주는 것도 타당한 방법이다.
2.2. 결함 감지
•
많은 시스템은 결함 있는 노드를 자동으로 감지할 수 있어야 한다.
◦
로드 밸런서는 죽은 노드로 요청을 그만 보내야 한다.
◦
단일 리더 복제를 사용하는 분산 데이터베이스에서 리더에 장애가 나면 팔로워 중 하나가 리더로 승격되어야 한다.
3. 타임아웃과 기약 없는 지연
•
타임아웃 길이를 정하는 간단한 답은 없다.
◦
타임아웃이 길면 노드가 죽었다고 선언될 때까지 기다리는 시간이 길어진다.
◦
타임아웃이 짧으면 결함을 빨리 발견하지만 응답이 일시적으로 느려졌어도 죽었다고 선언할 위험이 높아진다.
•
노드가 죽었다고 선언되면 그 노드의 책무는 다른 노드로 전달돼야 해서 다른 노드와 네트워크에 추가적인 부하를 준다.
◦
특히 노드가 실제로는 죽지 않았고 과부하 때문에 응답이 느릴 뿐일 수도 있다.
◦
그 부하를 다른 노드로 전달하면 연쇄 장애를 유발할 수 있다.
3.1. 네트워크 혼잡과 큐 대기
•
네트워크에서 패킷 지연의 변동성은 큐 대기 때문인 경우가 많다.
◦
여러 노드가 동시에 같은 목적지로 패킷을 보내려고 하면 네트워크 스위치는 패킷을 큐에 넣고 한번에 하나씩 네트워크 링크로 넘겨준다.
◦
네트워크 링크가 붐비면 패킷은 슬롯을 얻을 수 있을때까지 잠시 기다릴 수도 있다.
▪
이를 네트워크 혼잡이라고 한다.
◦
TCP는 흐름 제어를 수행하며 혼잡회피나 배압을 조절하여 과부하고 되지 않도록 송신을 제한하기도 한다.
◦
TCP는 타임아웃 안에 확인 응답을 받지 않으면 패킷이 손실됐다고 간주하고 재전송한다.
•
더 좋은 방법은 고정된 타임아웃을 설정하는 대신 시스템이 지속적으로 응답 시간과 그들의 변동성을 측정하고 관찰된 응답 시간 분포에 따라 타임아웃을 자동으로 조절하게 하는 것이다.
3.2. 동기 네트워크 대 비동기 네트워크
•
전화 네트워크에서 통화를 할 때는 회선이 만들어지며 두명 사이에 있는 전체 경로를 따라 통화에 대해 고정되고 보장된 양의 대역폭이 할당된다.
◦
이런 종류의 네트워크는 동기식이다.
◦
데이터가 여러 라우터를 거치더라도 큐 대기 문제를 겪지 않는다.
3.3. 그냥 네트워크 지연을 예측 가능하게 만들 수는 없을까?
•
데이터센터 네트워크와 인터넷이 회선 교환(circuit-switch) 네트워크라면 왕복 시간의 최대치를 보장할 수 있다.
•
이더넷과 IP는 큐 대기의 영향을 받는 패킷 교환(packet-switch) 프로토콜이고 따라서 네트워크에 기약 없는 지연이 있다.
•
순간적으로 몰리는 트래픽에 최적화됐기 때문에 데이터센터 네트워크와 인터넷은 패킷 교환을 사용한다.
◦
순간적으로 몰리는 데이터 전송에 회선을 쓰면 네트워크 용량을 낭비하고 전송이 불필요하게 느려진다
◦
TCP는 가용한 네트워크 용량에 맞춰 데이터 전송률을 동적으로 조절한다.
•
결과적으로 타임아웃에 올바른 값은 없으며 실험을 통해 결정해야 한다.
4. 신뢰성 없는 시계
•
애플리케이션은 다음과 같은 질문에 대답하기 위해 다양한 방식으로 시계에 의존한다.
1. 이 요청이 타임아웃됐나?
2. 이 서비스의 99분위 응답 시간은 어떻게 되나?
3. 이 서비스는 지난 5분 동안 평균 초당 몇 개의 질의를 처리했나?
4. 사용자가 우리 사이트에서 시간을 얼마나 보냈나?
5. 이 기사가 언제 게시됐나?
6. 며칠 몇 시에 미리 알림 이메일을 보내야 하나?
7. 이 캐시 항목은 언제 만료되나?
8. 로그 파일에 남은 이 오류 메시지의 타임스탬프는 무엇인가?
Plain Text
복사
•
네트워크에 있는 개별 장비는 자신의 시계를 갖고 있다.
•
이 장치는 완벽히 정확하지 않아서 각 장비는 자신만의 시간 개념이 있으며 이는 다른 장비보다 약간 빠를 수도 느릴 수도 있다.
5.1. 단조 시계 대 일 기준 시계
•
현대 컴퓨터의 시계는 일 기준 시계와 단조 시계로 구분할 수 있다.
5.1.1. 일 기준 시계
•
일 기준 시계는 달력에 따라 현재 날짜와 시간을 반환한다.
•
일 시계는 보통 NTP로 동기화된다.
•
윤초는 세지 않으며, 로컬 시게가 NTP 서버보다 앞설 경우 강제로 과거 시점으로 리셋 되어 종종 시간이 과거로 가는 것 같아 보인다.
•
NTP로 동기화를 하더라도 네트워크 지연이 있기 때문에 모든 분산시스템에서 완벽히 동일한 일 기준 시계를 가지는건 불가능하다.
5.1.2. 단조 시계
•
단조 시계는 항상 앞으로만 흐르는 시계라는 의미로 타임아웃이나 서비스 응답시간 같은 지속 시간을 재는데 적합하다.
•
로컬 시계가 NTP보다 빠르거나 느릴 때 단조 시계가 진행하는 진도수를 조정할 수는 있지만 단조 시계가 앞이나 뒤로 뛰게 할 수는 없다.
•
분산 시스템에서 경과 시간을 재는 데 단조 시계를 쓰는 것은 일반적으로 괜찮다.
5.2. 시계 동기화와 정확도
•
단조 시계는 동기화가 필요 없지만 일 기준 시계는 NTP 서버나 다른 외부 시간 출처에 맞춰 설정돼야 유용하다.
•
그러나 이는 신뢰성이 있거나 정확하지는 않다.
◦
컴퓨터 수정 시계는 아주 정확하지는 않습니다. 드리프트(drift) 현상이 발생할 수 있습니다. (더 빠르거나 느리게 실행)
◦
컴퓨터 시계가 NTP 서버와 너무 많은 차이가 나면 동기화가 거부되거나, 로컬 시계가 강제 리셋이 가능합니다.
◦
뜻하지 않게 노드와 NTP 서버 사이가 방화벽으로 막히면 잘못된 설정이 얼마 동안 알려지지도 않을 수도 있습니다.
◦
NTP 동기화는 패킷 지연의 변화가 큰 혼잡한 네트워크에서는 정확도에 한계가 있습니다.
◦
윤초가 발생하면 이를 고려하지 않고 설계된 시스템에서는 시간에 관한 가정이 엉망이 됩니다.
◦
가상 장비에서 하드웨어 시계는 가상화돼서 정확한 시간 엄수가 필요한 애플리케이션에서 추가적인 어려움이 생깁니다.
◦
완전히 제어할 수 없는 장치에서 소프트웨어를 실행하면 아마도 그 장치의 하드웨어를 전혀 믿을 수 없습니다.
•
시계 정확도가 중요한 경우에는 시계 정확도를 높이는 것도 가능하다.
◦
고빈도 트레이딩 펀드는 시계를 UTC와 100마이크로초 이내로 동기화하기를 요구한다.
•
이러한 정확도는 GPS 수신기, 정밀 시간 프로토콜(Precision Time Protocol, PTP)과 세심한 배포 및 모니터링을 사용해서 달성할 수 있다.
◦
그러나 상당한 노력과 전문 기술이 필요하며 시계 동기화가 잘못될 수 있는 수많은 방법이 있다.
5.3. 동기화된 시계에 의존하기
•
시계는 간단하고 사용하기 쉬워 보이지만 여러 함정이 있다.
•
네트워크가 대부분의 시간에 잘 동작하더라도 네트워크에 가끔 결함이 생길 수 있다는 가정하에 설계되는 것처럼 시계도 이와 같이 설계해야한다.
•
한가지 문제 중 하나는 시계가 잘못된다는 것을 눈치채기가 어렵다.
5.3.1. 이벤트 순서화용 타임스탬프
•
클라이언트 B는 클라이언트 A보다 인과성 측면에서 나중에 쓰지만 B가 쓸 때 사용하는 타임스탬프가 더 이르다.
•
위의 예시에서 x=1 이 더 나중의 결과로 시간에서 확인되므로 클라이언트 B의 증가 연산은 손실된다.
•
이러한 충돌 해소 전략을 최종 쓰기 승리(LWW, last write wins) 라고 불리며 리더 없는 데이터베이스에서 주로 사용된다.
- 데이터베이스 쓰기가 불가사의하게 사라질 수 있다.
- LWW는 순차적인 쓰기가 빠른 시간 내에 연속으로 실행되는 것과 동시에 쓰기가 실행되는 것을 구별할 수가 없다.
- 두 노드가 독립적으로 동일한 타임스탬프를 가진 쓰기 작업을 만들 수도 있다.
Plain Text
복사
발생할 수 있는 문제들
•
가장 "최근" 값을 유지하고 다른 것들을 버림으로써 충돌을 해소하고 싶더라도 "최근"의 정의는 로컬 일 기준 시계에 의존하며 그 시계는 틀릴 수 있는 것을 알아야한다.
•
잘못된 순서화가 발생하지 않을 정도로 NTP 동기화를 정확하게 하는 것은 거의 불가능하다.
•
올바르게 순서화를 하기위해서는 시계 출처가 대상보다 더 정확해야 하므로 논리적 시계(logical clock)을 사용하는 것이 방법이다.
5.3.2. 시계 읽기는 신뢰 구간이 있다
•
아무리 로컬 네트워크에 있는 NTP 부정확한 수정 시계에서 발생하는 드리프트는 쉽게 몇 밀리초가 될 수 있으며, 공개 인터넷의 NTP 서버를 사용해도 달성 가능한 최선의 정확도는 수십 밀리초에서 네트워크 혼잡에 따라 100밀리초 이상 될 수 있다.
•
따라서 시계 읽기는 신뢰 구간에 속하는 시간의 범위로 읽는 것이 타당하다.
•
불확실성 경계는 시간 출처를 기반으로 계산할 수 있다. (GPS 수신기 등)
•
대부분의 시스템은 이러한 불확실성을 노출하지 않는다. (ex. clock_gettime())
•
스패너(Spanner)에 있는 구글 트루타입(TrueTime) API의 경우, 로컬 시계의 신뢰 구간을 명시적으로 보고한다.
◦
두개의 값 [earliest, latest] 인 (가장 이른 것, 가장 늦은 것)을 받는다.
◦
시계는 불확실성 계산을 기반으로 실제 현재 시간이 그 구간 안에 어딘가에 있는 것을 알 수 있다.
5.3.3. 전역 스냅숏용 동기화된 시계
•
지난 내용에서는 다음과 같다.
◦
스냅숏 격리는 작고 빠른 읽기 트랜잭션과 크고 오래 실행되는 읽기 전용 트랜잭션 모두를 지원해야하는 데이터베이스에서의 중요한 기능
◦
가장 흔한 스냅숏 격리 구현은 단조 증가하는 트랜잭션 ID가 필요
•
데이터베이스가 여러 데이터센터에 있는 여러 장비에 분산되어 있을 때는 코디네이션이 필요하므로 트랜잭션 ID를 생성하기 어렵다.
◦
트랜잭션 ID는 인과성을 반영해야한다.
◦
작고 빠른 트랜잭션이 많을 수록 분산 시스템에서 트랜잭션 ID 생성은 방어할 수 없는 병목이 됨
◦
동기화된 일 기준의 시계의 타임스탬프를 트랜잭션 ID로 쓸 수 없는 것이 이또한 불확실성이 있다.
•
스패너는 이런 방법으로 데이터센터에 걸쳐서 스냅숏 격리를 구현한다.
•
트랜잭션 타임스탬프가 인과성을 반영하는 것을 보장하기 위해 스패너는 읽기 쓰기 트랜잭션을 커밋하기 전에 의도적으로 신뢰 구간의 길이만큼 기다린다.
◦
구글은 각 데이터센터에 GPS 수신기나 원자 시계를 배치해 시계가 약 7밀리초 이내로 동기화되게 함
5.4. 프로세스 중단
•
파티션마다 리더가 있는 데이터베이스 구조에서, 노드가 여전히 리드인지 그리고 안전하게 쓰기를 확인할 방법이 필요
◦
이에 대한 첫번째 선택은 리더가 다른 노드들로부터 임차권(lease) 을 얻는 것이다.
▪
일종의 타임아웃이 있는 잠금과 비슷하다. (특정 시점에 오직 하나의 리더만 임차권이 있다)
▪
어떤 노드가 임차권을 획득하면 임차권이 만료될 때까지 자신이 리더일 것임을 알 수 있고, 장애가 발생한 경우 임차권 갱신이 멈추므로 다른 노드가 리더 역할을 받을 수 있다.
while(true) {
request = getIncomingRequest();
if(lease.expiryTimeMillis - System.currentTimeMillis() < 10000) {
lease = lease.renew();
}
if(lease.isValid()) {
process(request);
}
}
Java
복사
코드로 표현된 안전한 쓰기 확인
•
위 코드는 두 가지 문제가 있다.
◦
동기화된 시계에 의존한다.
◦
로컬 단조 시계만 사용해도, 아래 갱신 시간동안은 장애가 발생했는지에 대해 모른다.
◦
lease.isValid 직전에 임차권이 만료된 경우, 임차권이 만료되었는지에 대해 전혀 모르고 작동하기에 안전하지 않은 일을 할 수 있다.
•
GC나 컨텍스트 스위칭 등 다양한 원인으로 인해서 스레드가 멈출 수 있다.
•
위의 경우가 발생하면 실행 중인 스레드를 어떤 시점에서 선점(preempt)하고 얼마간의 시간이 흐른 후 재개할 수 있다.
◦
선점된 스레드는 이를 알지못하고, 이 문제는 단일 장비에서 다중 스레드 코드를 스레드 안전(thread-safe)하게 하는 것과 비슷
◦
컨텍스트 스위치가 임의로 발생할 수도 있고 병렬성이 발생할 수 있으므로 타이밍에 대한 어떤 가정도 할 수 없음
◦
단일 장비에서는 다중 스레드를 처리하는 mutext, semaphore, atomic counter 등이 있으나 이런 도구는 분신 시스템에서 바로 적용할 수는 없다.
◦
분산 시스템의 노드는 어느 시점에서 실행이 상당히 멈출 수 있다는 것을 가정해야하며, 심지어 함수 중간에서 멈출수도 있다고 생각해야 한다.
5.4.1. 응답 시간 보장
•
이처럼 많은 프로그래밍 언어와 운영체제에서 스레드와 프로세스는 기약 없는 시간동안 중단가능
◦
다만 노력을 통해 중단 원인을 제거할 수 있습니다.
•
실패하면 안되는 환경에서는 소프트웨어 응답 데드라인(deadline) 을 명시해서 처리하며 이는 엄격한 실시간 시스템(hard real-time) 이라고 함
•
가비지 컬렉션의 영향을 제안해서 중단을 어느정도 완화 시킬 수 있음
6. 지식, 진실, 그리고 거짓말
6.1. 진실은 다수결로 결정된다.
•
네트워크는 여러의 경우에 따라 노드가 죽었다고 판단합니다.
◦
비대칭적 결함이 있는 네트워크는 노드가 자신에게 보내는 메시지를 모두 받을 수 있지만, 그 노드에서 밖으로 나가는 메시지는 유실되거나 지연됩니다. 이 경우 다른 노드들이 이 노드를 죽었다고 판단됩니다.
◦
한쪽 연결이 끊긴 노드는 자신이 보낸 메시지가 다른 노드로부터 확인 응답 못하는 것을 알아내 네트워크에 결함이 있다고 알았을 때, 그 네트워크는 어떤 일도 할 수 없습니다.
◦
가비지 컬렉션과 같은 중단을 진행중인 노드를 다른 노드에서는 죽었다고 판단합니다.
•
즉, 노드가 상황에 대한 자신의 판단을 반드시 믿을 수 있는 것은 아니란 것이다.
•
여러 분산 알고리즘은 정족수(quorum), 즉 노드들 사이의 투표에 의존한다.
6.1.1. 리더와 잠금
분산잠금을 잘못 구현한 예시
•
시스템이 오직 하나의 뭔가 필요할 때가 자주 있습니다.
◦
스플릿 브렌인을 피하기 위해 오직 한 노드만 데이터베이스 파티션의 리더가 될 수 있다.
◦
특정한 자원이나 객체에 동시에 쓰거나 오염시키는 것을 방지하기 위해 오직 하나의 트랜잭션이나 클라이언트만 어떤 자원이나 객체의 잠금을 획득할 수 있다.
◦
사용자명으로 사용자를 유일하게 식별할 수 있으므로 오직 한 명의 사용자만 특정한 사용자명으로 등록할 수 있다.
•
분산 시스템에서 어떤 노드가 스스로를 "선택된자" 라고 판단해도 노드의 정족수도 반드시 동의한다는 뜻이 아님
•
노드의 과반수가 어떤 노드가 죽었다고 선언했어도 그 노드가 선택된 자인 것처럼 계속 행동한다면 어떤 시스템에서는 문제가 발생할 수 있음
6.1.2. 펜싱 토크
•
잘못된 노드의 "선택된 자"를 문제를 해결하기 위한 단순한 기법으로 펜싱(fencing)이 있다.
•
잠금 서버가 잠금이나 임차권을 승인할 때마다 펜싱 토큰(fencing token)을 반환한다고 가정한다.
•
클라이언트가 쓰기 요청을 저장소 서비스로 보낼 때마다 자신의 현재 펜싱 토큰을 포함하도록 요구할 수 있다.
•
잠금 서비스로 주키퍼를 사용하면 트랜잭션 ID나 노드 버전을 펜싱 토큰으로 사용할 수 있다.
6.1.3. 비잔틴 결함
•
펜싱 토큰은 부주의에 의한 오류에 빠진 노드를 감지하고 차단할 수 있다.
◦
그러나 노드가 고의로 시스템의 보장을 무너뜨리려한다면 가짜 펜싱 토큰을 포함한 메시지를 보내면 됩니다.
•
분산 시스템 문제는 노드가 "거짓말"을 할지도 모른다는 위험이 있다면 훨씬 더 어려워진다.
◦
어떤 노드가 실제로는 받지 않은 특정 메시지를 받았다고 주장할 수 있으며 이런 동작을 비잔틴 결함(Byzantine fault) 라고 한다.
◦
신뢰할 수 없는 환경에서 합의에 도달하는 문제를 비잔틴 장군 문제(Byzantine Generals Problem) 라고 합니다.
•
일부 노드가 오작동하고 프로토콜을 준수하지 않거나 악의적 공격자가 네트워크를 방해하더라도 시스템이 계속 올바르게 동작한다면 이 시스템은 비잔틴 내결합성(Byzantine fault-tolerant)을 지닌다.
◦
항공우주 산업 환경에서 저장된 데이터가 방사선에 오염되서 전혀 에측할 수 없는 방식으로 반응
◦
여러 조직이 참여하는 시스템에서는 어떤 참여자들은 속이거나 사취할지도 모르므로 믿는 것 자체가 안전하지 않다.
•
대부분의 서버 측 데이터 시스템에서 비잔틴 내결함성 솔루션을 배치하는 것은 비용이 커서 실용적이지 않습니다.
•
웹 애플리케이션은 최종 사용자가 제어하는 웹브라우저 같은 클라이언트의 행동이 임의적이고 악의적이라고 예상해야 한다.
◦
웹 애플리케이션은 input validation(입력 확인), sanitization(살균), output escaping(출력 이스케이핑)이 매우 중요합니다.
◦
보통 비잔틴 내결함성 프로토콜은 여기에 쓰지는 않고 클라이언트의 행동이 허용된 것인지 아닌지 결정하는 권한을 서버에게 줄 뿐입니다.
◦
비잔틴 내결함성은 이런 중앙 권한이 없는 P2P 네트워크에 더 적절합니다.
6.1.3. 약한 형태의 거짓말
•
노드들이 일반적으로 정직하다고 가정하지만 약한 형태의 거짓말로부터 보호해주는 메커니즘을 소프트웨어에 추가하는 게 가치가 있을 수도 있다.
◦
네트워크 패킷은 때때로 오염되기 때문에 보호하려면 애플리케이션 수준 프로토콜에서 체크섬을 쓰는 것처럼 단순한 수단을 쓰면 충분하다.
◦
공개적으로 접근 가능한 애플리케이션은 사용자 입력을 신중하게 살균해야 한다.
◦
NTP 클라이언트는 여러 서버 주소를 설정할 수 있다.
7. 시스템 모델과 현실
•
시스템 모델(system model)을 정의해서 정형화하는데, 시스템 모델은 알고리즘이 가정하는 것을 기술한 추상화다.
•
타이밍 가정에 대해서는 세 가지 시스템 모델이 흔히 사용됩니다.
◦
동기식 모델
▪
네트워크 지연, 프로세스 중단, 시계 오차에 모두 제한이 있다고 가정한다.
▪
대부분 현실적인 모델이 아니다.
◦
부분 동기식 모델
▪
시스템이 대부분의 시간에는 동기식 시스템처럼 동작하지만 때때로 네트워크 지연, 프로세스 중단, 시계 드리프트의 한계치를 초과한다는 뜻이다.
▪
대부분 현실적인 모델이다.
▪
어떤 타이밍 가정이 깨질수도 있음을 고려한다.
◦
비동기식 모델
▪
타이밍에 대한 어떤 가정도 할 수 없다.
▪
시계가 없을 수도 있고 어떤 알고리즘은 비동기식 모델용으로 설계할 수 있지만 매우 제한적이다.
•
세 가지 노드용 시스템 모델은 다음과 같습니다.
◦
죽으면 중단하는(crash-stop) 결함
▪
죽으면 중단하는 모델에서 알고리즘은 노드 장애가 나면 죽는 경우만 있다.
▪
노드가 어느 순간에 갑자기 응답을 멈추면 이후로 노드는 영원히 사용할 수 없고 결코 되돌아오지 않는다.
◦
죽으면 복구하는(crash-recovery) 결함
▪
노드가 어느 순간에 죽을 수 잇지만 알려지지 않은 시간이 흐른 후에 다시 응답하기 시작할 것이라고 가정한다.
▪
죽으면 복구하는 모델에서는 노드는 메모리에 있는 상태는 손실되지만 죽어도 데이터가 남아 있는 안정된 저장소가 있다고 가정한다.
◦
비잔틴(임의적인) 결함
▪
다른 노드를 속이거나 기만하는 것 들이 모든 일이 가능한다.
•
현실 시스템을 모델링하는데 죽으면 복구하는 결함을 지닌 부분 동기식 모델이 일반적으로 유용한 모델이다.
